From report at bugs.python.org  Thu Jan  1 00:00:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Dec 2008 23:00:50 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230764450.92.0.76420619951.issue4753@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12511/threadedceval3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 00:01:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Dec 2008 23:01:37 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230764497.66.0.269057274626.issue4753@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12474/threadedceval2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 00:06:05 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 31 Dec 2008 23:06:05 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230764765.43.0.404012747606.issue4796@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Thu Jan  1 00:18:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Dec 2008 23:18:16 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230765496.74.0.0137101190191.issue4751@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  1 00:29:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Dec 2008 23:29:45 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230766185.84.0.100591040069.issue4751@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Based on quick testing on my computer, we could probably put the limit
as low as 1KB. But it may be that locks are cheap under Linux.
In any case, the patch looks good, but I'm no OpenSSL expert.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  1 00:43:16 2009
From: report at bugs.python.org (David Moss)
Date: Wed, 31 Dec 2008 23:43:16 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1230766995.94.0.793340858766.issue3959@psf.upfronthosting.co.za>


David Moss <drkjam at gmail.com> added the comment:

I think this might be worth a look before any hard and fast decisions
are made :-

http://code.google.com/p/netaddr/

----------
nosy: +drkjam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Jan  1 00:48:48 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 31 Dec 2008 23:48:48 +0000
Subject: [issue3023] Problem with invalidly-encoded command-line arguments
	(Unix)
In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za>
Message-ID: <1230767328.7.0.616070356075.issue3023@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3023>
_______________________________________

From report at bugs.python.org  Thu Jan  1 00:48:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 31 Dec 2008 23:48:51 +0000
Subject: [issue4795] inspect.isgeneratorfunction inconsistent with other
	inspect functions
In-Reply-To: <1230763627.06.0.589317806347.issue4795@psf.upfronthosting.co.za>
Message-ID: <1230767331.21.0.794211211405.issue4795@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r68112.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4795>
_______________________________________

From report at bugs.python.org  Thu Jan  1 01:04:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 00:04:30 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230768270.34.0.483951676866.issue4751@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, your code can deadlock since ENTER_HASHLIB doesn't release the
GIL. Think about it:

// Thread A is here, holding the GIL and waiting for self->lock to be 
// released by thread B
ENTER_HASHLIB(self)
Py_BEGIN_ALLOW_THREADS
// Thread B is here, holding self->lock and waiting for the GIL to be
// released by thread A
Py_END_ALLOW_THREADS
LEAVE_HASHLIB(self)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  1 01:07:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 00:07:08 +0000
Subject: [issue4738] Patch to make zlib-objects better support threads
In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za>
Message-ID: <1230768428.92.0.0885819613421.issue4738@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Same comment about potential deadlocks as in #4751.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4738>
_______________________________________

From report at bugs.python.org  Thu Jan  1 01:38:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 01 Jan 2009 00:38:24 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230770304.9.0.829539552545.issue4796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The decimal constructor should be lossless.  The underlying spec was
designed with the notion that all numbers in decimal are exact;
operations can be lossy but the numbers themselves are exact. 
Accordingly, I recommend Decimal.from_float(f) with no qualifiers or
optional arguments.

To support the use case of wanting to round the input, I suggest a
separate method modeled on Context.create_decimal().  It can either be
an extension of the existing method or a new method like
Context.create_decimal_from_float().  I recommend the former since
rounding is already implied by the context qualifier.  Either way, the
effect would be the same as Decimal.from_float(f) + 0 in a given
context.  Per the docs:  "Creates a new Decimal instance from num but
using self as context. Unlike the Decimal constructor, the context
precision, rounding method, flags, and traps are applied to the conversion."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Thu Jan  1 01:43:09 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 01 Jan 2009 00:43:09 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230770589.56.0.572003566636.issue4796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FYI, there is already a lossless implementation in the docs:

def float_to_decimal(f):
    "Convert a floating point number to a Decimal with no loss of
information"
    n, d = f.as_integer_ratio()
    with localcontext() as ctx:
        ctx.traps[Inexact] = True
        while True:
            try:
               return Decimal(n) / Decimal(d)
            except Inexact:
                ctx.prec += 1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Thu Jan  1 01:54:40 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 01 Jan 2009 00:54:40 +0000
Subject: [issue4781] The function, Threading.Timer.run(), may be Inappropriate
In-Reply-To: <1230651841.99.0.415726342941.issue4781@psf.upfronthosting.co.za>
Message-ID: <1230771280.8.0.276734985232.issue4781@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Note that doing this would change the class semantics.
Timer "[...] represents an action that should be run only after a 
certain amount of time has passed ? a timer." and the example clearly 
shows that the action is run *once*. 

Timer is basically an example of how to write custom Thread 
subclasses; if you want a "repetitive action", you may easily write a 
subclass based on the code you posted. Not every useful class must be 
in the standard library...

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4781>
_______________________________________

From report at bugs.python.org  Thu Jan  1 02:08:19 2009
From: report at bugs.python.org (pmoody)
Date: Thu, 01 Jan 2009 01:08:19 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1230772099.62.0.283432939327.issue3959@psf.upfronthosting.co.za>


pmoody <python at hda3.com> added the comment:

I'm biased ;) but I don't see what netaddr provides over ipaddr.  it
also seems to be in the neighborhood of 50% slower (at least on my mac
mini).

pmoody at mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
-> python -m timeit 'import ipaddr;\
ipaddr.IP("1.1.1.1")'
10000 loops, best of 3: 46.2 usec per loop

pmoody at mini - 04:52 PM - ~/Downloads/netaddr-0.5.2
-> python -m timeit 'import netaddr;\
netaddr.IP("1.1.1.1")'
10000 loops, best of 3: 71.9 usec per loop

dealing with netmasks, the difference is even greater.
pmoody at mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
-> python -m timeit 'import ipaddr;\
ipaddr.IP("1.1.1.1/255.255.255.0")'
10000 loops, best of 3: 78.4 usec per loop

pmoody at mini - 04:49 PM - ~/Downloads/netaddr-0.5.2
-> python -m timeit 'import netaddr;\
> netaddr.IP("1.1.1.1/255.255.255.0")'
1000 loops, best of 3: 247 usec per loop

(and it doesn't seem to deal with hostsmasked addresses).

it also seems to be layed out in an unintuitive way, treating address
ranges a something very different than network addresses. hopefully
someone who isn't intimately familiar with both libraries can comment,
but ipaddr feels a lot cleaner to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Jan  1 02:31:56 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 01 Jan 2009 01:31:56 +0000
Subject: [issue4795] inspect.isgeneratorfunction inconsistent with other
	inspect functions
In-Reply-To: <1230763627.06.0.589317806347.issue4795@psf.upfronthosting.co.za>
Message-ID: <1230773516.92.0.617860643085.issue4795@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This can be simplified to just:

    return (isfunction(object) or ismethod(object)) and \
         object.func_code.co_flags & CO_GENERATOR

No need for patterns like:

  if cond:
     return True
  return False

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4795>
_______________________________________

From report at bugs.python.org  Thu Jan  1 02:36:36 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 01 Jan 2009 01:36:36 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1230773796.95.0.383947217645.issue3959@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Performance shouldn't be a major concern here.  Utility is more
important and the implementation can be optimized later.

My initial impression of netaddr is pretty good.  One thing it has going
for it is documentation.  The netaddr google page gives a really great
overview of the functionality provided.  In comparison, the ipaddr-py
page is extremely sparse; the documentation in the repository is no
better (as there isn't really any).

There are a lot of minor things about ipaddr-py which are off-putting. 
It uses a naming convention that's not like any real Python software I'm
familiar with.  In particular, CamelCase method names really draw the
eye (in a bad way) and distract from the actual functionality being
provided.  I assume that if ipaddr-py is selected for inclusion, the API
will be adapted to fit PEP 8.  In comparison, netaddr appears to largely
comply with PEP 8 already.

Regarding the treatment of addresses versus address ranges, I prefer
netaddr's solution.  An address is not the same as an address range.  It
seems odd to try to represent them both with the same type as ipaddr-py
does.  This feels somewhat APLesque (where everything is a vector),
which isn't bad in itself, but generally if I want to manipulate an IP
address, I'm not thinking about it as a list of one address.  If I
wanted to do that, then I'd make a list and put the address in it.  By
comparison, the separate CIDR type in netaddr makes a lot of sense.  It
preserves a memory-efficient representation of the address range, but
does it with a different type than the fundamental address type.

This is far from a complete review of either library, obviously.  I've
done little more than glance over the documentation of each and do a
small amount of interactive playing around.  A lot more effort seems to
have gone into making netaddr accessible and appealing, and I think it
has succeeded.  Perhaps if some documentation for ipaddr-py is written
it will be easier to see where that library excels.  Of course, I assume
this is a prerequisite for inclusion in the standard library as well.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Jan  1 02:59:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 01:59:00 +0000
Subject: [issue1664] nntplib is not IPv6-capable
In-Reply-To: <1198094830.43.0.175472713308.issue1664@psf.upfronthosting.co.za>
Message-ID: <1230775140.6.0.446713914613.issue1664@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I was going to suggest writing a test but I see that nntplib hasn't got
a single unit test :-O

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1664>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:00:17 2009
From: report at bugs.python.org (pmoody)
Date: Thu, 01 Jan 2009 02:00:17 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1230775217.52.0.280972089133.issue3959@psf.upfronthosting.co.za>


pmoody <python at hda3.com> added the comment:

hm, all addresses have a subnet, even if its an implied /32, so
specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
off-putting than "1.1.1.0/24". You're also much more likely to see the
latter in network devices. I guess I don't see the utility in an address
range of .1 - .22 (or something arbitrary, something which doesn't fall
on a power-of-2 boundary); when dealing with ranges of addresses, i've
always only wanted to/needed to manipulate sub-networks of addresses.

and my expectation was always that method names, etc. would have to be
converted to more closely match other python code; ipaddr was written to
google's python style guide, which I understand can be different than
the python.org style guide ;)

also, ipaddr does make extensive use of pydoc, but you're right, the
webpage is spartan.

happy (PST) new year.

Cheers,
/peter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:05:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 02:05:13 +0000
Subject: [issue4572] add SEEK_* values to io and/or io.IOBase
In-Reply-To: <1228625063.64.0.370686457231.issue4572@psf.upfronthosting.co.za>
Message-ID: <1230775513.78.0.541328516706.issue4572@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sounds like a nice improvement.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4572>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:12:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 02:12:57 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1230775977.23.0.190256258791.issue4272@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

test_literal_output looks really too strict to me. At most, you could
check that the header and trailer are unchanged, but it would probably
make it equivalent to test_metadata.
Other than that, I think it's an useful addition.

----------
nosy: +pitrou
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:14:26 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 01 Jan 2009 02:14:26 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1230776066.74.0.888962584654.issue3959@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> hm, all addresses have a subnet, even if its an implied /32, so
specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
off-putting than "1.1.1.0/24". You're also much more likely to see the
latter in network devices.

I'm not sure which API in netaddr you're referring to.  If you want to
construct that /24 with netaddr, then I would use
netaddr.address.CIDR("1.1.1.0/24").  Offhand, I can't find an API which
accepts two endpoints of a range to construct a network in netaddr. 
When I wrote about having separate types for individual addresses vs
ranges of addresses in my previous comment, I had IP and CIDR
respectively in mind, as opposed to ipaddr-py's single IPv4 class which
can represent either.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:19:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 02:19:38 +0000
Subject: [issue4035] Support bytes for os.exec*()
In-Reply-To: <1223077104.22.0.62328245443.issue4035@psf.upfronthosting.co.za>
Message-ID: <1230776378.31.0.192933963147.issue4035@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, I think the supported types should be the same for all platforms,
otherwise it creates unnecessary headaches.

Perhaps, in addition to the proposed behaviour on Posix (convert
everything to bytes if the program name is a bytes object), the reverse
could be done under Windows (convert the program name to str if it is a
bytes object).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4035>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:25:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 02:25:31 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1230776731.5.0.748386262804.issue3976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For this to be integrated, it should also add an unit test.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:28:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 02:28:07 +0000
Subject: =?utf-8?q?[issue3680]_Cycles_with_some_iterator_are=09leaking.?=
In-Reply-To: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
Message-ID: <1230776887.85.0.817297994889.issue3680@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3680>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:33:13 2009
From: report at bugs.python.org (pmoody)
Date: Thu, 01 Jan 2009 02:33:13 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1230776066.74.0.888962584654.issue3959@psf.upfronthosting.co.za>
Message-ID: <8517e9350812311833q191a1c90k2757a7b87e673946@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

> I'm not sure which API in netaddr you're referring to.  If you want to
> construct that /24 with netaddr, then I would use
> netaddr.address.CIDR("1.1.1.0/24").  Offhand, I can't find an API which

netaddr.AddrRange

class AddrRange(__builtin__.object)
 |  A block of contiguous network addresses bounded by an arbitrary start and
 |  stop address. There is no requirement that they fall on strict bit mask
 |  boundaries, unlike L{CIDR} addresses.
 |

 |  __init__(self, first, last, klass=<class 'netaddr.address.Addr'>)
 |      Constructor.
 |
 |      @param first: start address for this network address range.
 |
 |      @param last: stop address for this network address range.
 |
 |      @param klass: (optional) class used to create each object returned.
 |          Default: L{Addr()} objects. See L{nrange()} documentations for
 |          additional details on options.

when looking through the code.google.com wiki, I couldn't find any
examples of creating addresses with netmasks and AddrRange was the
first thing I found when looking through pydoc.

> accepts two endpoints of a range to construct a network in netaddr.
> When I wrote about having separate types for individual addresses vs
> ranges of addresses in my previous comment, I had IP and CIDR
> respectively in mind, as opposed to ipaddr-py's single IPv4 class which
> can represent either.

and still having two separate classes represent the same thing seems odd to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:35:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 02:35:51 +0000
Subject: [issue3266] Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR'
	undeclared
In-Reply-To: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za>
Message-ID: <1230777351.76.0.794140416359.issue3266@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3266>
_______________________________________

From report at bugs.python.org  Thu Jan  1 03:38:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 02:38:34 +0000
Subject: [issue4522] Module wsgiref is not python3000 ready (unicode issues)
In-Reply-To: <1228389502.32.0.635218386971.issue4522@psf.upfronthosting.co.za>
Message-ID: <1230777514.47.0.893341949321.issue4522@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Resolution is more advanced in #4718.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> wsgiref package totally broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4522>
_______________________________________

From report at bugs.python.org  Thu Jan  1 04:19:15 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 01 Jan 2009 03:19:15 +0000
Subject: [issue3433] libtk
In-Reply-To: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>
Message-ID: <1230779955.1.0.54285889113.issue3433@psf.upfronthosting.co.za>


Changes by Mitchell Model <mlm at acm.org>:


----------
title: Mac, 3.0 framework install error with fink cp -> libtk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3433>
_______________________________________

From report at bugs.python.org  Thu Jan  1 04:42:49 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Thu, 01 Jan 2009 03:42:49 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230781369.93.0.0813994569898.issue4753@psf.upfronthosting.co.za>


Changes by Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com>:


----------
nosy: +blaisorblade

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 04:44:48 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Thu, 01 Jan 2009 03:44:48 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230781488.44.0.463651518108.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

Mentioning other versions as well.
The patch is so easy that it can be backported to all supported
versions, so I'm adding all of them (2.5 is in bugfix-only mode, and as
far as I can see this patch cannot be accepted there, sadly).

----------
versions: +Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 05:06:19 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 Jan 2009 04:06:19 +0000
Subject: [issue4572] add SEEK_* values to io and/or io.IOBase
In-Reply-To: <1228625063.64.0.370686457231.issue4572@psf.upfronthosting.co.za>
Message-ID: <1230782779.96.0.15103183997.issue4572@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4572>
_______________________________________

From report at bugs.python.org  Thu Jan  1 05:10:22 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 01 Jan 2009 04:10:22 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230781488.44.0.463651518108.issue4753@psf.upfronthosting.co.za>
Message-ID: <18780.16937.610896.883082@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Paolo> (2.5 is in bugfix-only mode, and as far as I can see this patch
    Paolo> cannot be accepted there, sadly).

You could backport it to 2.4 & 2.5 and just put it up on PyPI...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 05:28:10 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Thu, 01 Jan 2009 04:28:10 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230784090.43.0.883116133177.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

Some other comments.
The time saving of indirect threading are also associated with the
removal of the range check, but better branch prediction is the main
advantage.

> Also, the macro USE_THREADED_CODE should be renamed to something else;
> the word "thread" is too tightly associated with multi-threading.

That's true.

> Furthermore, threaded code simply refers to code consisting only of
> function calls. Maybe, USE_COMPUTED_GOTO or USE_DIRECT_DISPATCH would be
> better.

I'd prefer USE_DIRECT_DISPATCH (or better, USE_THREADED_DISPATCH) rather
than USE_COMPUTED_GOTO, since the latter is just the used language
construct.

"indirect threading" is the standard name in CS literature to define
this technique. "Direct threading" is a variation where in the bytecode
array, opcode is replaced by the pointer opcode_handler[opcode], so that
dispatch is slightly faster. Most interpreters use indirect threading to
save memory, and because it enables to switch the opcode handlers table
to activate for instance debugging.

The best paper about this is:
"The Structure and Performance of Efficient Interpreters, M. Anton Ertl
and David Gregg, 2003".

The original paper about (direct) threaded code is this:
"Threaded Code, James R. Bell, Comm. of ACM, 1973", but I don't feel it
relevant at all today.
Indirect threading was introduced in "Indirect Threaded Code, Robert B.
K. Dewar, Communications of the ACM, 1975" (that's just a bit more
relevant, but still).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 05:36:57 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Thu, 01 Jan 2009 04:36:57 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230784617.49.0.50655991643.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

> You may want to check out issue1408710 in which a similar patch was
> provided, but failed to deliver the desired results.
It's not really similar, because you don't duplicate the dispatch code.
It took me some time to understand why you didn't change the "goto
fast_next_opcode", but that's where you miss the speedup.

The only difference with your change is that you save the range check
for the switch, so the slowdown probably comes from some minor output
change from GCC I guess.

Anyway, this suggests that the speedup really comes from better branch
prediction and not from saving the range check. The 1st paper I
mentioned simply states that saving the range check might make a small
differences. The point is that sometimes, when you are going to flush
the pipeline, it's like adding a few instructions, even conditional
jumps, does not make a difference. I've observed this behaviour quite a
few times while building from scratch a small Python interpreter.

I guess (but this might be wrong) that's because the execution units
were not used at their fullest, and adding conditional jumps doesn't
make a differeence because flushing a pipeline once or twice is almost
the same (the second flush removes just few instructions). Or something
like that, I'm not expert enough of CPU architecture to be sure of such
guesses.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 06:03:05 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Thu, 01 Jan 2009 05:03:05 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230786185.08.0.151834797629.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

Topics
1) About different speedups on 32bits vs 64 bits
2) About PPC slowdown
3) PyPI

======= About different speedups on 32bits vs 64 bits =======
An interpreter is very register-hungry, so on x86_64 it spends much less
time on register spill (i.e. moving locals from/to memory), so
instruction dispatch takes a bigger share of execution time. If the rest
of the interpreter is too slow, indirect threading gives no advantage.

Look at the amount of register variables in PyEval_EvalFrameEx() (btw,
do you support any compiler where nowadays 'register' still makes a
difference? That's quite weird). Lots of them are simply cached copies
of fields of the current frame and of the current function; without
copying them to locals, the compiler should assume they could change at
any function call.

In fact, adding locals this way gave huge speedups on tight loops on the
Python interpreter I built with a colleague for our student project, to
experiment with speeding up Python.

And adding a write to memory in the dispatch code (to f->last_i) gave a
20% slowdown. Since my interpreter uses a copying garbage collector and
CPython uses reference counting, which is much slower (if you don't know
this, show me a fast JVM with reference counting), I'm even surprised
you can get such a big speedup from threading.

======= About PPC slowdown =======
Somebody should try the patch on Pentium4 as well.

During our VM course, threading slowed down a toy interpreter with 4 toy
opcodes. Our teachers suggested that with such a small interpreter,
since threaded code takes more space (in that case, ~64 vs ~100 bytes),
this could give problems with code caches, but suggested checking that
idea using performance counters. I'm not sure about why.

I don't have right now neither a Pentium4 nor a PowerPC available, so I
can't check myself. But this is the best way to analyze the performance
unexpected behaviour.

======= PyPI =======
Paolo> (2.5 is in bugfix-only mode, and as far as I can see this patch
Paolo> cannot be accepted there, sadly).

Skip> You could backport it to 2.4 & 2.5 and just put it up on PyPI...
I was thinking to a private backport as well.
I didn't know about PyPI, it looks like PyPI is more for contributed
modules than for this, would that work?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 06:06:10 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 01 Jan 2009 05:06:10 +0000
Subject: [issue4797] test_fileio error (windows)
In-Reply-To: <1230786370.88.0.170386258104.issue4797@psf.upfronthosting.co.za>
Message-ID: <1230786370.88.0.170386258104.issue4797@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

This patch fixes this error.

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%
20trunk/builds/1727/step-test/0

======================================================================
FAIL: testOpendir (test.test_fileio.AutoFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\test\test_fileio.py", line 112, in testOpendir
    self.assertEqual(e.filename, ".")
AssertionError: None != '.'

This error doesn't occur on py3k (because wide string is passed) but I 
think It's better to merge the patch into py3k too.

----------
components: Windows
files: fix_test_fileio_error.patch
keywords: patch
messages: 78690
nosy: ocean-city
severity: normal
status: open
title: test_fileio error (windows)
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12515/fix_test_fileio_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4797>
_______________________________________

From report at bugs.python.org  Thu Jan  1 06:15:12 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Thu, 01 Jan 2009 05:15:12 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230786912.6.0.31251595307.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

== On the patch itself ==
Why don't you use the C preprocessor instead of that Python code?
Sample code:

#define OPCODE_LIST(DEFINE_OPCODE) \
    DEFINE_OPCODE(STOP_CODE, 0)                 \
    DEFINE_OPCODE(POP_TOP, 1)                   \
    DEFINE_OPCODE(ROT_TWO, 2)                   \
    DEFINE_OPCODE(ROT_THREE, 3)                 \
    DEFINE_OPCODE(DUP_TOP, 4)                   \
    DEFINE_OPCODE(ROT_FOUR, 5)                  \
    DEFINE_OPCODE(NOP, 9)                       \
    ...

# define DECL_OPCODE(opcode)                    \
        [opcode] = && label_ ## opcode,

        void *opcodes[] = {
                OPCODE_LIST(DECL_OPCODE)
        };
# undef DECL_OPCODE

There are also other ways to do it, but using higher-order functions
within the preprocessor in this way is something that I learned from the
V8 source code.
It has the advantage that OPCODE_LIST can be used in a lot of other
places (maybe when implementing the 'opcode' module, if it's written in C).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 08:47:41 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Thu, 01 Jan 2009 07:47:41 +0000
Subject: [issue4798] Update deprecation of 'new' module in PEP 4.
In-Reply-To: <1230796061.0.0.856185746745.issue4798@psf.upfronthosting.co.za>
Message-ID: <1230796061.0.0.856185746745.issue4798@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached are two patches:

* Update PEP 4 about 'new' module which is deprecated since python 2.6
in favour of using types module.

* Update documentation for 'new' module.

Not sure about the exact date of proposal for deprecating 'new' module,
but closest that I was able to find was this python-dev mail thread
after it had been removed from py3k branch:

http://mail.python.org/pipermail/python-dev/2007-November/075386.html

----------
assignee: georg.brandl
components: Documentation
files: doc_update_for_new_module_dec_31_2008.patch
keywords: patch
messages: 78692
nosy: georg.brandl, loewis, vshenoy
severity: normal
status: open
title: Update deprecation of 'new' module in PEP 4.
versions: Python 2.6
Added file: http://bugs.python.org/file12516/doc_update_for_new_module_dec_31_2008.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4798>
_______________________________________

From report at bugs.python.org  Thu Jan  1 08:48:21 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Thu, 01 Jan 2009 07:48:21 +0000
Subject: [issue4798] Update deprecation of 'new' module in PEP 4.
In-Reply-To: <1230796061.0.0.856185746745.issue4798@psf.upfronthosting.co.za>
Message-ID: <1230796101.05.0.378019093966.issue4798@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


Added file: http://bugs.python.org/file12517/pep_update_for_new_module_dec_31_2008.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4798>
_______________________________________

From report at bugs.python.org  Thu Jan  1 08:52:47 2009
From: report at bugs.python.org (Cournapeau David)
Date: Thu, 01 Jan 2009 07:52:47 +0000
Subject: [issue4799] handling inf/nan in '%f'
In-Reply-To: <1230796367.25.0.681154044554.issue4799@psf.upfronthosting.co.za>
Message-ID: <1230796367.25.0.681154044554.issue4799@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

On windows, with python 2.6,  s = '%s' % float('inf') is 'inf', but s =
'%f' % float('inf') is equal to '1.#INF'.

This patch fixes the inconsistency, by using the code from floatobject.f
format_float into stringobject.c formatfloat. I think it would be better
to use the same underlying implementations for both functions, but it is
not so easy, because format_float cannot fail (return void), whereas
formatfloat can (return error code).

----------
components: Interpreter Core
files: nan.patch
keywords: patch
messages: 78693
nosy: cdavid
severity: normal
status: open
title: handling inf/nan in '%f'
versions: Python 2.6
Added file: http://bugs.python.org/file12518/nan.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4799>
_______________________________________

From report at bugs.python.org  Thu Jan  1 09:32:14 2009
From: report at bugs.python.org (James Brotchie)
Date: Thu, 01 Jan 2009 08:32:14 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1230798734.97.0.628466905416.issue4769@psf.upfronthosting.co.za>


Changes by James Brotchie <brotchie at gmail.com>:


----------
nosy: +brotchie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Thu Jan  1 09:38:25 2009
From: report at bugs.python.org (James Brotchie)
Date: Thu, 01 Jan 2009 08:38:25 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1230799105.81.0.404705812843.issue4768@psf.upfronthosting.co.za>


Changes by James Brotchie <brotchie at gmail.com>:


----------
nosy: +brotchie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Thu Jan  1 10:40:29 2009
From: report at bugs.python.org (Matthias Sommer)
Date: Thu, 01 Jan 2009 09:40:29 +0000
Subject: [issue2995] Idle, some Linuxes, cannot position Cursor by mouseclick
In-Reply-To: <1211995180.72.0.174580651078.issue2995@psf.upfronthosting.co.za>
Message-ID: <1230802829.57.0.753182453865.issue2995@psf.upfronthosting.co.za>


Matthias Sommer <sunny0815 at gmxpro.de> added the comment:

Retry is a bit difficult now, sinc I reverted back to Windows after 
getting quite some answers in some places, but none of them really 
helpful.

It happend under Madriva Linux (and some other tested Linuxes). Now I'm 
using Gentoo (this is, IF I'm using Linux). And there it works all fine.

The problem was: Usually one can set the cursorposition in any given 
(gui) text editor by mouse click in the text. Using Madriva, I can 
click, but the cursor is not affected.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2995>
_______________________________________

From report at bugs.python.org  Thu Jan  1 11:09:43 2009
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 01 Jan 2009 10:09:43 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230804583.45.0.739182933404.issue4753@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy:  -arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 11:32:35 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Thu, 01 Jan 2009 10:32:35 +0000
Subject: [issue4800] little inaccuracy in Py_ssize_t explanation
In-Reply-To: <1230805955.17.0.970467276629.issue4800@psf.upfronthosting.co.za>
Message-ID: <1230805955.17.0.970467276629.issue4800@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Documentation says that

========
There?s no chance that the reference count can overflow; at least as many bits 
are used to hold the reference count as there are distinct memory locations in 
virtual memory (assuming sizeof(Py_ssize_t) >= sizeof(void*)). Thus, the 
reference count increment is a simple operation.
========

But Py_ssize_t is a signed type so in case of sizeof(Py_ssize_t) == sizeof
(void*)) it can only reference a half of memmory :). But because any python 
object consumes much more than 2bytes this is not a problem.

----------
assignee: georg.brandl
components: Documentation
messages: 78695
nosy: exe, georg.brandl
severity: normal
status: open
title: little inaccuracy in Py_ssize_t explanation
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4800>
_______________________________________

From report at bugs.python.org  Thu Jan  1 12:47:00 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 11:47:00 +0000
Subject: [issue4100] xml.etree.ElementTree does not read xml-text over page
	bonderies
In-Reply-To: <1223650418.42.0.473297107812.issue4100@psf.upfronthosting.co.za>
Message-ID: <1230810420.47.0.891275677639.issue4100@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r68116.

----------
assignee: effbot -> georg.brandl
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4100>
_______________________________________

From report at bugs.python.org  Thu Jan  1 12:48:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 11:48:47 +0000
Subject: [issue4136] merge json library with simplejson 2.0.4
In-Reply-To: <1224194929.7.0.263636117378.issue4136@psf.upfronthosting.co.za>
Message-ID: <1230810527.87.0.494459284957.issue4136@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Bumping priority a bit.

----------
nosy: +georg.brandl
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4136>
_______________________________________

From report at bugs.python.org  Thu Jan  1 12:54:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 11:54:04 +0000
Subject: [issue4156] Docs for BaseHandler.protocol_xxx methods are unclear
In-Reply-To: <1224587370.27.0.33419504535.issue4156@psf.upfronthosting.co.za>
Message-ID: <1230810844.14.0.610621292248.issue4156@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r68117.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4156>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:00:37 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 12:00:37 +0000
Subject: [issue4185] re module treats raw strings as normal strings
In-Reply-To: <1224734129.35.0.170011642262.issue4185@psf.upfronthosting.co.za>
Message-ID: <1230811237.47.0.854153877864.issue4185@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added a bit to the re.sub(n) docstrings in r68118.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4185>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:01:45 2009
From: report at bugs.python.org (David Moss)
Date: Thu, 01 Jan 2009 12:01:45 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1230811305.7.0.402640242385.issue3959@psf.upfronthosting.co.za>


David Moss <drkjam at gmail.com> added the comment:

ipaddr appears to be on a fast track for "batteries included" status
without much consultation in the wider Python community. As BDFL it's
ultimately Guido's call, but it would be disappointing to see one
solution being chosen wholesale without much additional discussion.

There is no point in wrangling over the individual features of one
library at revision x versus another at revision y. Software is a moving
target. Omissions and bugs are easily dispatched. Ultimately we all want
the same thing, better software that makes our lives easier.

As for netaddr it is intended to cover more ground that all the other
solutions out there. Here is a handy list of them :-

http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule

This may preclude its suitability for the standard library in any event
being intended to support any and all network address types, not just
IPv4 and IPv6. It is also currently, very much in beta, being about 75%
feature complete with 6-9 months work of (part-time) work left on it
before it can reach version 1.0 ready. A Python 3.0 version is also
planned for release soon.

In answer to various specific issues raised about netaddr.

The need for separate IP and CIDR classes is set out in the FAQ page :-

http://code.google.com/p/netaddr/wiki/NetAddrFAQ

FYI, AddrRange is a (not yet abstract) base class with a start and end
address covering the shared functionality of 3 subclasses (IPRange,
CIDR, Wildcard) which should all interchangeable (within reason). It is
also supports generic address (Addr objects) rather than just IP
specific ones. Base 2 slices is not always the best way of expressing
groups of network hosts, they are *one* way.

With netaddr, I wanted to avoid the 'super object' syndrome that seems
to dog virtuall all other existing efforts out there, and not only those
in Python.

In any event confusion will hopefully be dealt with as the docs improve.

As for performance, netaddr's current speed for certain operations areas
may be slower than other implementations but the optimisation phase of
development hasn't even begun. There are loads more features to add and
get working before that starts.

One point I will make is on licensing. netaddr is BSD, so you can do
whatever you want with it and contribute as you see fit.

At the present time, contributing to ipaddr for anyone outside Google
seems like the software equivalent of climbing Mount Everest! Even if I
personally wanted to contribute to this particular project's efforts,
having to sign the individual CLA would automatically preclude me from
doing so. This is a *major* sticking point.

Regardless of whatever decision is taken, netaddr will always be
available as long as it has a user base, either as built in, optional
extra or as a part of some wider standardisation effort.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:10:10 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 12:10:10 +0000
Subject: [issue4222] dis.findlinestarts is missing from dis.__all__ and from
	the online documentation
In-Reply-To: <1225214206.66.0.527749553778.issue4222@psf.upfronthosting.co.za>
Message-ID: <1230811810.21.0.874713501957.issue4222@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Documented dis.findlinestarts() and put it into dis.__all__ in r68119.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4222>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:15:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 12:15:39 +0000
Subject: [issue4228] struct.pack('L', -1)
In-Reply-To: <1225294862.2.0.0798680271584.issue4228@psf.upfronthosting.co.za>
Message-ID: <1230812139.98.0.109625120131.issue4228@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed to trunk in r68120.

----------
nosy: +georg.brandl
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4228>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:32:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 12:32:40 +0000
Subject: [issue4742] 3.0 distutils byte-compiling -> Syntax error: unknown
	encoding: cp1252
In-Reply-To: <1230158367.11.0.521550154703.issue4742@psf.upfronthosting.co.za>
Message-ID: <1230813160.67.0.712968547794.issue4742@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4742>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:37:28 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 12:37:28 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1230813448.26.0.87751252923.issue4772@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

TypeError or ValueError?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4772>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:50:05 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 12:50:05 +0000
Subject: [issue4798] Update deprecation of 'new' module in PEP 4.
In-Reply-To: <1230796061.0.0.856185746745.issue4798@psf.upfronthosting.co.za>
Message-ID: <1230814205.37.0.00388253999661.issue4798@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied the doc patch in r68121.  Updated PEP 4 to point to PEP 3108
(which contains a list of all modules removed in 3k and deprecated in
2.6, not just "new") in r68122.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4798>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:52:37 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 12:52:37 +0000
Subject: [issue4784] Mismatch in documentation for module "webbrowser"
In-Reply-To: <1230658906.5.0.498985661284.issue4784@psf.upfronthosting.co.za>
Message-ID: <1230814357.84.0.727802068614.issue4784@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r68123.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4784>
_______________________________________

From report at bugs.python.org  Thu Jan  1 13:53:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 12:53:32 +0000
Subject: [issue4782] json documentation missing load(), loads()
In-Reply-To: <1230652909.54.0.874688686508.issue4782@psf.upfronthosting.co.za>
Message-ID: <1230814412.83.0.534556098443.issue4782@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r68124.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4782>
_______________________________________

From report at bugs.python.org  Thu Jan  1 14:02:20 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 13:02:20 +0000
Subject: [issue4776] distutils documentation
In-Reply-To: <1230610779.11.0.0228162085624.issue4776@psf.upfronthosting.co.za>
Message-ID: <1230814940.58.0.0670293443013.issue4776@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, documented in r68125.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4776>
_______________________________________

From report at bugs.python.org  Thu Jan  1 14:06:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 13:06:21 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230786912.6.0.31251595307.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230815186.7917.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi,

> Why don't you use the C preprocessor instead of that Python code?
> Sample code:

We would have to change opcode.h for this to be truely useful (in order
to re-use OPCODE_LIST()). I think that should be the subject of a
separate bug entry for code reorganization.

Thanks for all the explanation and pointers! About register allocation,
I wonder if the "temporary variables" u,v,w could be declared separately
in each opcode rather than at the top of the eval function, so that the
compiler doesn't try to store their values between two opcodes.

As for the "register" declarations, I think they're just remains of the
past.

Antoine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 14:15:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 13:15:02 +0000
Subject: [issue4767] email.mime incorrectly documented (or implemented)
In-Reply-To: <1230566108.89.0.124705904062.issue4767@psf.upfronthosting.co.za>
Message-ID: <1230815702.18.0.18382899748.issue4767@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r68127.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4767>
_______________________________________

From report at bugs.python.org  Thu Jan  1 14:26:57 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 01 Jan 2009 13:26:57 +0000
Subject: [issue4789] Documentation changes break existing URIs
In-Reply-To: <1230683867.44.0.219209732128.issue4789@psf.upfronthosting.co.za>
Message-ID: <1230816417.03.0.949531521828.issue4789@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've added the redirects. I hope that mailman updates its links in the
next release though :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4789>
_______________________________________

From report at bugs.python.org  Thu Jan  1 15:00:40 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 01 Jan 2009 14:00:40 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230786185.08.0.151834797629.issue4753@psf.upfronthosting.co.za>
Message-ID: <18780.52355.640703.581301@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Skip> You could backport it to 2.4 & 2.5 and just put it up on PyPI...

    Paolo> I was thinking to a private backport as well.  I didn't know
    Paolo> about PyPI, it looks like PyPI is more for contributed modules
    Paolo> than for this, would that work?

I don't see why it wouldn't.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 16:02:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 Jan 2009 15:02:00 +0000
Subject: [issue4797] test_fileio error (windows)
In-Reply-To: <1230786370.88.0.170386258104.issue4797@psf.upfronthosting.co.za>
Message-ID: <1230822120.29.0.0860160699969.issue4797@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please go ahead.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4797>
_______________________________________

From report at bugs.python.org  Thu Jan  1 16:39:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 15:39:58 +0000
Subject: =?utf-8?q?[issue3680]_Cycles_with_some_iterator_are=09leaking.?=
In-Reply-To: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
Message-ID: <1230824398.66.0.273249524263.issue3680@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed to trunk and py3k, thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3680>
_______________________________________

From report at bugs.python.org  Thu Jan  1 17:04:37 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 01 Jan 2009 16:04:37 +0000
Subject: [issue4797] test_fileio error (windows)
In-Reply-To: <1230786370.88.0.170386258104.issue4797@psf.upfronthosting.co.za>
Message-ID: <1230825877.08.0.450209118065.issue4797@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Done. Fixed in r68134(trunk) and r68139(py3k).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4797>
_______________________________________

From report at bugs.python.org  Thu Jan  1 19:30:55 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 01 Jan 2009 18:30:55 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1230834655.18.0.6908338838.issue2233@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I would like to confirm issue for trunk.

----------
nosy: +rpetrov
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Thu Jan  1 19:49:05 2009
From: report at bugs.python.org (Derek Morr)
Date: Thu, 01 Jan 2009 18:49:05 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1230835745.38.0.984602760083.issue1675455@psf.upfronthosting.co.za>


Derek Morr <derekmorr at psu.edu> added the comment:

Senthil,

I don't think your gethost_addrinfo() function will work. On a v6-
enabled machine, it will only return v6 or v4 names. Shouldn't it 
return both (since a machine could have both v4 and v6 addresses)? For 
example, on my machine, I have the following addresses for 
"localhost": ::1, fe80::1%lo0, 127.0.0.1.

Also, why is the AI_CANONNAME flag set? The canonname field isn't used. 
And you only appear to take the last IP address returned (sa[0]). 
Shouldn't you return all the addresses?

----------
nosy: +dmorr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Thu Jan  1 19:52:53 2009
From: report at bugs.python.org (Derek Morr)
Date: Thu, 01 Jan 2009 18:52:53 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1230835973.19.0.654530955783.issue1675455@psf.upfronthosting.co.za>


Derek Morr <derekmorr at psu.edu> added the comment:

Question: Why does FTPHandler.ftp_open() try to resolve the hostname()? 
The hostname will be passed into connect_ftp(), then into 
urllib.ftpwrapper(), and eventually into ftplib.FTP.connect(), which is 
IPv6-aware.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Thu Jan  1 19:56:03 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Jan 2009 18:56:03 +0000
Subject: [issue4035] Support bytes for os.exec*()
In-Reply-To: <1223077104.22.0.62328245443.issue4035@psf.upfronthosting.co.za>
Message-ID: <1230836163.27.0.859065495642.issue4035@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Hmm, I think the supported types should be the same for all
> platforms, otherwise it creates unnecessary headaches.

I'm don't know Windows very well, but I read many times that Windows 
uses unicode everywhere. I'm unable to decide if it's a good thing or 
not to support also bytes on Windows, and anyway I'm unable to write 
such patch.

See also issue #4036 (bytes for subprocess.Popen), especially Martin's 
message msg74305 (Martin is our Windows expert ;-)).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4035>
_______________________________________

From report at bugs.python.org  Thu Jan  1 19:59:21 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Jan 2009 18:59:21 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230836361.27.0.91383165779.issue4751@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  1 20:02:12 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Jan 2009 19:02:12 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230836532.64.0.190969738455.issue4751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooooh, I suggested to ebfe to remove the GIL unlock/lock, but I was 
wrong :-( I hate locks! What is the right fix? Replace
   ENTER_HASHLIB(self)
   Py_BEGIN_ALLOW_THREADS
   ...
   Py_END_ALLOW_THREADS
   LEAVE_HASHLIB(self)
by
   Py_BEGIN_ALLOW_THREADS
   ENTER_HASHLIB(self)
   ...
   LEAVE_HASHLIB(self)
   Py_END_ALLOW_THREADS
?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  1 20:09:12 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Jan 2009 19:09:12 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230836952.07.0.0306018577522.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm unable to reproduce the issue. I tried to create files on my FTP 
server with non-ASCII characters or spaces in the filenames, but 
everything is fine. Can you reproduce the problem outside IDLE? Or is 
the issue specific to IDLE? I mean: write a script and execute "python 
script.py" in a terminal.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Thu Jan  1 20:22:36 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 01 Jan 2009 19:22:36 +0000
Subject: [issue4780] Makefile.pre.in patch to run regen on OSX (framework
	build)
In-Reply-To: <1230642378.46.0.486113805886.issue4780@psf.upfronthosting.co.za>
Message-ID: <1230837756.81.0.232673992033.issue4780@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

The issue is same for trunk.
Step to reproduce(as example on linux):
- remove existing python installation (optional)
- rename <SRCDIR/>Lib/plat-linux2
...
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)'
/usr/include/netinet/in.h
python: error while loading shared libraries: libpython2.7.so.1.0:
cannot open shared object file: No such file or directory

----------
nosy: +rpetrov
versions: +Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4780>
_______________________________________

From report at bugs.python.org  Thu Jan  1 20:43:17 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Thu, 01 Jan 2009 19:43:17 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230838997.91.0.909395185673.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

> We would have to change opcode.h for this to be truely useful (in
order to re-use OPCODE_LIST()).

Yep.

> I think that should be the subject of a separate bug entry for code
reorganization.

Agreed, I'll maybe try to find time for it.

> Thanks for all the explanation and pointers!
You're welcome, thanks to you for writing the patch! And 
> About register allocation, I wonder if the "temporary variables" u,v,w
could be declared separately in each opcode rather than at the top of
the eval function, so that the compiler doesn't try to store their
values between two opcodes.

I didn't look at the output, but that shouldn't be needed with decent
optimizers, since they are local variables, so the compiler has a full
picture of their usage (this does not happen with the content of the
heap, where the frame object may lie).

I think that change would just save some compilation time for dataflow
analysis, maybe :-). Or could make clearer which variables is used
where, but that is a matter of taste (what's there is fine for me).

I just studied liveness analysis in compilers, and it computes whether a
variable is live before and after each statement; if the value of a
variable is not used in some piece of code until the next write to the
variable, it is considered dead in that piece of code, and that variable
does not take space; since u, v, w are either unused or are written to
before usage in all opcodes, they're dead at the beginning of each
opcode, so they're also dead just before dispatch.


The only important thing is that the content of the jump table are known
to the compiler and that the compiler makes use of that. Simply passing
a non-const jump table to some function defined elsewhere (which could
in theory modify it) would make the output much worse.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 21:03:39 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 01 Jan 2009 20:03:39 +0000
Subject: [issue4801] _collections module fail to build on cygwin
In-Reply-To: <1230840219.24.0.00127311298202.issue4801@psf.upfronthosting.co.za>
Message-ID: <1230840219.24.0.00127311298202.issue4801@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

make log:
gcc -shared -Wl,--enable-auto-image-base
.../Modules/_collectionsmodule.o -L/usr/local/lib -L. -lpython2.7 -o
build/lib.cygwin-1.5.25-i686-2.7/_collections.dll
.../Modules/_collectionsmodule.o: In function `deque_iter':
.../Modules/_collectionsmodule.c:970: undefined reference to
`__PyGC_generation0'
....

----------
components: Build
files: py-trunk-incl-objimpl.h-patch
messages: 78723
nosy: rpetrov
severity: normal
status: open
title: _collections module fail to build on cygwin
versions: Python 2.7
Added file: http://bugs.python.org/file12519/py-trunk-incl-objimpl.h-patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4801>
_______________________________________

From report at bugs.python.org  Thu Jan  1 21:08:30 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 01 Jan 2009 20:08:30 +0000
Subject: [issue4802] detect_tkinter for cygwin
In-Reply-To: <1230840510.49.0.878061128691.issue4802@psf.upfronthosting.co.za>
Message-ID: <1230840510.49.0.878061128691.issue4802@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

Check for installed X on cygwin can't find X11/Xlib.h in detect_tkinter
from setup.py

----------
files: py-trunk-detect_tkinter-cygwin.patch
keywords: patch
messages: 78724
nosy: rpetrov
severity: normal
status: open
title: detect_tkinter for cygwin
Added file: http://bugs.python.org/file12520/py-trunk-detect_tkinter-cygwin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4802>
_______________________________________

From report at bugs.python.org  Thu Jan  1 21:11:55 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 01 Jan 2009 20:11:55 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1230840715.01.0.857439850258.issue2233@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I'm not sure that installation work if slash is removed and DESTDIR is
not specified. What about to replace "slash before $(DESTDIR)" with "/./" ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Thu Jan  1 21:31:28 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 01 Jan 2009 20:31:28 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230841888.24.0.941077305817.issue4791@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Hi Chris

Since dir calls retrlines and retrlines has a 'while 1:' loop, the bug
probably comes from there. Either it hangs in the fp.readline call or
the break condition is never met.

Can you put some print diagnostics inside Lib/ftplib.py->FTP.retrlines
(around line 405) to help pinpointing the issue?

HTH,
Daniel

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Thu Jan  1 21:41:44 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Jan 2009 20:41:44 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230842504.59.0.53085681076.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Can you put some print diagnostics inside Lib/ftplib.py (...)

<your ftp object>.set_debuglevel(2) already prints a lot of 
informations.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Thu Jan  1 21:45:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Jan 2009 20:45:27 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1230842727.52.0.288938250361.issue4772@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

makesockaddr() raise a TypeError("Invalid address type") for an 
invalid AF_TIPC address, but I would prefer a ValueError.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4772>
_______________________________________

From report at bugs.python.org  Thu Jan  1 22:39:52 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Jan 2009 21:39:52 +0000
Subject: [issue4775] Incorrect documentation - UTC time
In-Reply-To: <1230706101.54.0.711688688948.issue4775@psf.upfronthosting.co.za>
Message-ID: <495D3825.7090100@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

FWIW: POSIX defines Unix time_t *not* to include leap seconds.

You can easily check whether your platform or C lib behaves
POSIX-ly correct or not:

   POSIX: 1986-12-31 23:59:59 UTC == 536457599 ticks

   With leap seconds:		  == 536457612 ticks

   (since there were 13 leap seconds in the years 1972-1985)

For most practical purposes the difference doesn't really matter,
since date differences are usually counted in days, not seconds.

In cases where it does matter, you're better off with a custom
solution, since applications or other libraries tend not to handle
leap seconds well.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4775>
_______________________________________

From report at bugs.python.org  Thu Jan  1 22:58:28 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 01 Jan 2009 21:58:28 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230847108.63.0.351801014097.issue4753@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Antoine Pitrou wrote:
> [...] count the number of indirect jump instructions in ceval.c:
> 
> grep -E "jmp[[:space:]]\*%" ceval.s
>
> There should be 85 to 90 of them, roughly. If there are many less, then
> the compiler has tried to optimize them by "sharing" them.

I get 86 with GCC 4.x and SUNCC. However, with GCC 3.4 I only get a
single computed goto. Is there some hidden option to make GCC avoid
sharing jumps? 

> Because otherwise the measurements these options are meant to do would
> be meaningless.

Ah, I see now. Maybe you should add a quick comment that mentions this. 

> I don't have a Sun machine to test, so I'll leave to someone else to
> check and enable if they want to.

I tested it and it worked, no test failures to report. Just change the
macro test: 

#ifdef __GNUC__ && \
...

to

#ifdef (__GNUC__ || __SUNPRO_C) && \
...


I attached some additional benchmarks on SunOS. So far, it seems the
benefits of the proposed optimization are highly compiler-dependent.

Added file: http://bugs.python.org/file12521/amd-athlon64-x2-suncc-pybench.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 22:58:40 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 01 Jan 2009 21:58:40 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230847120.71.0.532260709295.issue4753@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file12522/amd-athlon64-x2-gcc-sunos-pybench.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 23:00:26 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 01 Jan 2009 22:00:26 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230847226.06.0.711637972536.issue4753@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

> Attached new patch for fixes suggested by Alexandre (rename
> opcode_targets.c to opcode_targets.h, replace USE_THREADED_CODE with
> USE_COMPUTED_GOTOS).

You forgot to update your script to use the new name.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 23:05:46 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Thu, 01 Jan 2009 22:05:46 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230847546.8.0.602549249733.issue4566@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

Here's an option, though unfortunately not a trivial one:  use a private
build of the C runtime.  The Windows version of Firefox does this
(mozcrt19.dll).  The private CRT build doesn't use SxS in any way, so it
gets around this issue, as well as other issues like not allowing "for
me" installs on Vista (#4018).

For me to build the CRT from the source included with Visual Studio 2008
took some tweaking - apparently having the CRT source build properly out
of the box wasn't a priority for MS (the Mozilla CRT seems to be built
from the VS2005 source; perhaps that version is more cooperative).  It
does yield a CRT that links like an ordinary DLL, but the fact that it
can't be built without modifications is a major drawback to this solution.

Also, I'd assume that the CRT source isn't included in the Express
version (and possibly other ones), so that's a downside, too.

As far as Python itself, the project configurations would have to be
changed to define _CRT_NOFORCE_MANIFEST, suppress the default linking to
the stock CRT (/NODEFAULTLIB:msvcrt.lib), and link to the import library
for the private CRT.  I might try to create an experimental solution
config for this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Thu Jan  1 23:36:18 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 01 Jan 2009 22:36:18 +0000
Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <1230849378.3.0.702418740402.issue4472@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I just finish test for altbininstall make target on linux and cygwin.

Ronald,
About the SO issue - in makefile we may use $(LDLIBRARY) instead of
libpython$(VERSION)$(SO) (see py-issue-4472-makefile.patch).
For cygwin libpython$(VERSION)$(SO) is equal to $(DLLLIBRARY) and
DLLLIBRARY is set only on cygwin.

Added file: http://bugs.python.org/file12523/py-issue-4472-makefile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Thu Jan  1 23:46:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 22:46:15 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230836532.64.0.190969738455.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230849981.16684.3.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

The right fix would probably be to define ENTER_HASHLIB(self) as
	Py_BEGIN_ALLOW_THREADS
	PyThread_acquire_lock(self->lock)
	Py_END_ALLOW_THREADS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  1 23:48:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 22:48:37 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230847108.63.0.351801014097.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230850123.16684.6.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I get 86 with GCC 4.x and SUNCC. However, with GCC 3.4 I only get a
> single computed goto. Is there some hidden option to make GCC avoid
> sharing jumps? 

Try -fno-crossjumping.

> I tested it and it worked, no test failures to report. Just change the
> macro test: 
> 
> #ifdef __GNUC__ && \
> ...
> 
> to
> 
> #ifdef (__GNUC__ || __SUNPRO_C) && \
> ...

Thanks.

> You forgot to update your script to use the new name.

Ah, that's rather dumb :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  1 23:59:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 22:59:51 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230850791.65.0.79634207218.issue4753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've updated the comments as per Alexandre's request, added support for
SUN CC, and fixed the generation script to use the new filename.

Added file: http://bugs.python.org/file12524/threadedceval5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 00:02:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jan 2009 23:02:19 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230850939.52.0.4531649253.issue4753@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12514/threadedceval4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 00:07:49 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 01 Jan 2009 23:07:49 +0000
Subject: [issue4747] SyntaxError executing a script containing non-ASCII
	characters in its name or path
In-Reply-To: <1230252107.45.0.57470787699.issue4747@psf.upfronthosting.co.za>
Message-ID: <1230851269.02.0.98478897644.issue4747@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r68143 (py3k) and r68144 (3.0).
Thanks for the report!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4747>
_______________________________________

From report at bugs.python.org  Fri Jan  2 00:20:36 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 01 Jan 2009 23:20:36 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za>
Message-ID: <1230852036.91.0.153383854132.issue4718@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

One interesting thing of note that has occurred to me looking at the patch 
is that although with Python <3.0 you technically could return a str as 
iterable from application, ie., because iteration over str returns str for 
each character, the same doesn't really apply to bytes in Python 3.0. This 
is because iterating over bytes yields an int fdor each item.

Thus have odd situation where with Python 3.0, one could technically return 
str as iterable, with rule that would apply would be that each str returned 
would then be converted to bytes by way of latin-1 conversion, but for 
bytes returned as iterable, should fail.

Not sure how this plays out in wsgiref server yet as haven't looked. 
Anyway, make the validator code:

@@ -426,6 +436,6 @@
     # Technically a string is legal, which is why it's a really bad
     # idea, because it may cause the response to be returned
     # character-by-character
-    assert_(not isinstance(iterator, str),
+    assert_(not isinstance(iterator, (str, bytes)),
         "You should not return a string as your application iterator, "
         "instead return a single-item list containing that string.")

quite a good thing to have.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Fri Jan  2 00:44:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 01 Jan 2009 23:44:20 +0000
Subject: [issue4035] Support bytes for os.exec*()
In-Reply-To: <1223077104.22.0.62328245443.issue4035@psf.upfronthosting.co.za>
Message-ID: <1230853460.54.0.669176028081.issue4035@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Every function of the Windows API comes in pair: an Ansi function (which 
accepts char* names) and a Wide function (which accepts wchar_t* names; 
Py_UNICODE* can be passed as-is)

Don't perform conversion on Windows, just call the proper function.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4035>
_______________________________________

From report at bugs.python.org  Fri Jan  2 00:44:46 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Jan 2009 23:44:46 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1230853486.77.0.922088099182.issue3299@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It certainly looks like all direct calls to PyObject_DEL/PyObject_Del
from outside tp_dealloc implementations are going to be broken in
pydebug builds.

Replacing those calls with either Py_DECREF operations (as Victor's
patch does) or direct calls to _Py_Dealloc should get them to do the
right thing.

I'm a little wary of adding calls to _Py_ForgetReference into
PyObject_Del though, since most of the time the reference will already
have been forgotten by the time that PyObject_Del is called. My
suggestion would be:

1. Update the docs on PyObject_Del to specifically warn against using it
for error cleanup after a successful PyObject_New invocation, instead
pointing users of the C API to Py_DECREF. Basically, code that calls
PyObject_Del outside a tp_dealloc method is probably doing something
wrong. Note also that tp_dealloc implementations in such cases will need
to cope with instances that are only partially initialised (e.g. by
using Py_XDECREF instead of Py_DECREF).

2. Fix the instances in the standard library where _Py_Dealloc may be
bypassed by direct calls to PyObject_Del.

The alternative would be to change the pydebug version of PyObject_Del
to check if the reference count on the object is 1 rather than 0. That
should be a pretty good indication that we're dealing with a case of
cleaning up after a failure to fully initialise an object, and we can
call _Py_ForgetReference directly from PyObject_Del, retroactively
making all those direct invocations of PyObject_Del "correct".

Hmm, now that I write that idea down, it doesn't sound nearly as scary
as I thought it would...

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Fri Jan  2 00:47:18 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Jan 2009 23:47:18 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1230853638.63.0.659773500977.issue3299@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(changing title and unassigning from Fredrik since this isn't an RE
specific problem, flagged as also affecting interpreter core, flagged as
affecting all currently maintained versions)

----------
assignee: effbot -> 
components: +Interpreter Core
title: invalid object destruction in re.finditer() -> Direct calls to PyObject_Del/PyObject_DEL are broken for --with-pydebug
versions: +Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Fri Jan  2 01:05:07 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 02 Jan 2009 00:05:07 +0000
Subject: [issue4801] _collections module fail to build on cygwin
In-Reply-To: <1230840219.24.0.00127311298202.issue4801@psf.upfronthosting.co.za>
Message-ID: <1230854707.44.0.666338430006.issue4801@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed a different correction in r68145: 
according to documention, _PyObject_GC_TRACK should not be used in 
extension modules.

Thanks for the report.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4801>
_______________________________________

From report at bugs.python.org  Fri Jan  2 01:08:59 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Jan 2009 00:08:59 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1230854939.23.0.581472186321.issue3299@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, now that I go to implement it, I remember why I didn't like the idea
of doing anything directly in PyObject_Del. While the Python memory
allocator is primarily designed for allocation of Python objects, it
isn't actually *limited* to that. So there is no guarantee that the void
pointer passed in to PyObject_Del can be safely cast to a PyObject pointer.

The idea could still be implemented by scanning the list of active
objects to see if the passed in pointer refers to one of them, but that
would make object deallocation in pydebug builds extraordinarily slow.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Fri Jan  2 01:43:34 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Jan 2009 00:43:34 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1230857014.1.0.462620101645.issue4614@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Fri Jan  2 01:45:02 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Jan 2009 00:45:02 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1230857102.72.0.771973960722.issue4614@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Fri Jan  2 02:22:00 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 01:22:00 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1230859320.42.0.0950895992934.issue4768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think the library function base64.b64encode() should return 
> a string, not bytes.

Yes, in the email module, the payload is an unicode string, not a 
bytes string. We have to be able to concatenate headers 
(eg. "Content-Type: image/fish\nMIME-Version: 
1.0\nContent-Transfer-Encoding: base64\n") and encoded data 
(eg. "R0lGO").

Attached patch implements this fix: encode_base64() returns str (and 
not bytes). The patchs fixes the unit tests and adds a new regression 
test for MIMEImage.as_string().

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Fri Jan  2 02:22:12 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 01:22:12 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1230859332.43.0.595186568835.issue4768@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12525/email_base64_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Fri Jan  2 02:30:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Jan 2009 01:30:29 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1230859829.11.0.0808557231401.issue3999@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As mentioned in python-dev, the patch would be more suitable for
inclusion if it was changed to simply print a stack trace and bail out,
rather than try to resume execution of the Python program.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3999>
_______________________________________

From report at bugs.python.org  Fri Jan  2 02:31:58 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 01:31:58 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1230859918.89.0.470142978449.issue4769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About quoted printable, there are two implementations:
 - binascii.a2b_qp() (Modules/binascii.c): C implementation, use 
PyArg_ParseTupleAndKeywords(args, kwargs, "s*|i", ...) to parse the 
data
 - quopri.decode() (Lib/quopri.py): Python implementation
   => quopri.decodestring() uses io.BytesIO() to parse the data

But quopri.decodestring() reuses binascii.a2b_qp() if the binascii 
module is present. So quopri.decodestring behaviour depends of the 
presence of binascii module...
 - binascii present: accept bytes or unicode
 - missing binascii: accept only bytes!

binascii.a2b_qp() encodes unicode string to UTF-8 bytes string.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Fri Jan  2 03:10:06 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 02:10:06 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1230862206.18.0.318761620064.issue4769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If the input to b64decode is a str, just do a encode('ascii')
> operation on it and proceed.  If that fails, it wasn't valid 
> Base64 to begin with.

On unicode encode error, should we raise an UnicodeEncodeError or a 
binascii.Error?

And there is also the problem of base64.b64decode() 
alternate "characters". Should we accept non-ASCII alternate 
characters?
   base64.b64decode('01a\xfeb\xffcd', altchars=b'\xfe\xff')

For the example, the result depends on the choosen charset:
 - ASCII (strict): encode input text raise an UnicodeDecodeError
 - ISO-8859-1 (ignore): works as expected
 - UTF-8 (strict): unexpected result

The only valid choice is ASCII because ISO-8859-1 or UTF-8 will 
reintroduce bytes/character mixture.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Fri Jan  2 03:53:58 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Fri, 02 Jan 2009 02:53:58 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230864838.74.0.0710473304441.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

> I attached some additional benchmarks on SunOS. So far, it seems the
benefits of the proposed optimization are highly compiler-dependent.

Well, it would be more correct to say that as you verified for GCC 3.4,
"miscompilation" of the code happens easily.

Any literature research shows that threading in a fast interpreter does
help. My experience shows two exceptions to this rule:
a) bad compiler output
b) interpreters which are not efficient enough - when other operations
are even slower than instruction dispatch (which is really slow due to
costly mispredictions), threading can't help.

This is shown by the number of interpreters using threading.

Wikipedia has more pointers on this:
http://en.wikipedia.org/wiki/Threaded_code
Note that what I called "indirect threading" is called there instead
"token threading".

Another example of the importance of threading is also shown in this
article:
http://webkit.org/blog/189/announcing-squirrelfish/

Some clues about why Python does not use threading:

http://mail.python.org/pipermail/python-list/1999-May/002003.html

It is important to note that people in that mail are not aware of why
threading gives a speedup.

==
For SunCC, I can't say anything without looking at:
a) the generated code; if jump targets were aligned only for switch but
not for computed gotos, for instance, that could maybe explain such a
slowdown. Lots of other details might be relevant.
b) performance counters results, especially regarding mispredictions of
indirect branches.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 03:57:06 2009
From: report at bugs.python.org (Manas)
Date: Fri, 02 Jan 2009 02:57:06 +0000
Subject: [issue4803] Manas Thapliyal sent you a Friend Request on Yaari
In-Reply-To: <94e386e8cd976bbe7d6eb5b217870508@localhost.localdomain>
Message-ID: <94e386e8cd976bbe7d6eb5b217870508@localhost.localdomain>


New submission from Manas <gravitywarrior1 at gmail.com>:

Manas Thapliyal wants you to join Yaari!

Is Manas your friend?

<a href="http://yaari.com/?controller=user&action=mailregister&friend=1&sign=YaariNSF231MZA868MBK206SAQ399">Yes, Manas is my friend!</a> <a href="http://yaari.com/?controller=user&action=mailregister&friend=0&sign=YaariNSF231MZA868MBK206SAQ399">No, Manas isn't my friend.</a>

Please respond or Manas may think you said no :(

Thanks,
The Yaari Team
____
If you prefer not to receive this email tell us <a href="http://yaari.com/?controller=absn&action=addoptout&email=report at bugs.python.org">here</a>. If you have any concerns 
regarding the content of this message, please email abuse at yaari.com.  
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312

YaariNSF231MZA868MBK206SAQ399

----------
files: unnamed
messages: 78749
nosy: gravitywarrior1
severity: normal
status: open
title: Manas Thapliyal sent you a Friend Request on Yaari
Added file: http://bugs.python.org/file12526/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4803>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090102/a15e5aa2/attachment.txt>

From report at bugs.python.org  Fri Jan  2 04:04:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Jan 2009 03:04:25 +0000
Subject: [issue4803] Manas Thapliyal sent you a Friend Request on Yaari
In-Reply-To: <94e386e8cd976bbe7d6eb5b217870508@localhost.localdomain>
Message-ID: <1230865465.33.0.249176608379.issue4803@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4803>
_______________________________________

From report at bugs.python.org  Fri Jan  2 04:49:48 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 02 Jan 2009 03:49:48 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1230868188.52.0.491593071134.issue1675455@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Derek, 

This patch was along the lines that when IPv6 address is present, return
the first address,which I assumed to be active address and would make
the urllib2 work.

I am not sure, if returning all the addresses would help and how would
we define which address to use?

AI_CANONNAME flag, I don't accurately remember it now. But I had
encountered issues when testing on IPv-4 systems without it.

I am having different opinion on this issue now.

First is, taking from Facundo's comment on having this functionality in
gethostbyname() and implementing it in C. 

Second is, the wrapper function and suitable way needs to be defined.

I am sorry, I fail to understand the question on why ftp_open does
hostname resolution. You mean to say without it, if we pass it to
ftplib.FTP.connect() it would work for IPv6 address?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Fri Jan  2 04:58:16 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 03:58:16 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230868696.0.0.344618949929.issue4566@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I've no time to dig deeper now as I suspect testing will require removal
of the vc9 assembly from the GAC and testing with a local one, but some
comments:

test.c's error is "can't find the DLL" - this will be as we attempt to
load Python's DLL - but this isn't the same as the original error, which
is "DLL init routine failed".  To repro the initial error, I suspect you
will want to put the full assembly next to test.exe - that will allow
python.dll to load - then test.c should call PyExec_EvalString("import
socket\n") - it is at *that* point the error we care about is likely to
be thrown.

That specific error code means the DLL init routine in the CRT started
executing, but explicitly threw an error.  Its possible to use the
debugger to see exactly when this is thrown, and it relates to the
assembly configuration (the details escape me).  I suspect it will be
necessary to locate this CRT init code to determine exactly why it is
throwing the error, and possibly determine how to satisfy it (the DLL
*is* loaded, so it should be capable of working)

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 05:00:56 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 04:00:56 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230868856.45.0.560728694899.issue4566@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I meant to mention: FWIW, *some* py2exe apps work fine with the old
scheme - specifically, IIUC, any app will work fine so long as the .pyd
files were next to the executable, which is next to the assembly.  I
understand this is a significant restriction, but its worth mentioning
for completeness.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 05:09:40 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 04:09:40 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

This block in exceptions.c:

#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
...
    /* turn off assertions in debug mode */
    prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif

Does exactly what the comment says it does - disables all assertions. 
It disables *all* CRT assertions in the process, which includes some
very useful ones related to memory corruption, and all 'assert' and
'ASSERT' statements in all Python extension modules.

The change was introduced in:
"""
r46894 | kristjan.jonsson | 2006-06-13 01:45:12 +1000 (Tue, 13 Jun 2006)
| 2 lines

Fix the CRT argument error handling for VisualStudio .NET 2005.  Install
a CRT error handler and disable the assertion for debug builds.  This
causes CRT to set errno to EINVAL.
This update fixes crash cases in the test suite where the default CRT
error handler would cause process exit.
"""

which seems like a very large hammer to be using (ie, the problem
causing the assertions to blow should probably have been fixed).  I'd
like to remove these 2 lines.  Any objections, or should I upload the
trivial patch?

----------
components: Windows
messages: 78753
nosy: krisvale, mhammond
severity: normal
status: open
title: Python on Windows disables all C runtime library assertions
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 05:13:49 2009
From: report at bugs.python.org (Derek Morr)
Date: Fri, 02 Jan 2009 04:13:49 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1230869629.1.0.9760193206.issue1675455@psf.upfronthosting.co.za>


Derek Morr <derekmorr at psu.edu> added the comment:

My understanding is that the FileHandler checks if the file:// URL 
contains the hostname or localhost IP of the local machine (isn't that 
what FileHandler.names is for?). So, shouldn't the following URLs all 
open the same file:

file:///foo.txt
file://localhost/foo.txt
file://127.0.0.1/foo.txt
file://[::1]/foo.txt

If that is the case, then doesn't FileHandler.names need to have all of 
those values in it?

I am a little confused by this though. It looks like 
FileHandler.file_open() checks if there is a hostname in the URL, and 
if so, uses FTPHandler instead. So why does FileHandler.open_local_file 
check the hostname value?

For your other points, gethostbyname() in libc can only handle IPv4 
addresses. The IETF defined the getaddrinfo() interface as an IP 
version neutral replacement. I would recommend using getaddrinfo().

Yes, FTPHandler creates an urllib.FTPWrapper object. That object calls 
into ftplib, which is already IPv6-capable. So, I don't think we need 
to do hostname resolution in FTPHandler.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Fri Jan  2 05:51:27 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Fri, 02 Jan 2009 04:51:27 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230871887.45.0.34426692633.issue4566@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

> test.c's error is "can't find the DLL" - this will be as we attempt to
> load Python's DLL - but this isn't the same as the original error, which
> is "DLL init routine failed".  To repro the initial error, I suspect you
> will want to put the full assembly next to test.exe - that will allow
> python.dll to load - then test.c should call PyExec_EvalString("import
> socket\n") - it is at *that* point the error we care about is likely to
> be thrown.

The test program isn't having a problem loading python26.dll - it gets
to an interpreter prompt and it can execute simple Python statements. 
It doesn't throw ImportError until the user types in "import socket". 
Further, I can see in Process Explorer that python26.dll is loaded in
the running testpy.exe process.  I apologize if my initial description
wasn't clear on that point.

I do see the error codes are different (between testpy.c and
mod_python), but both are triggered by trying to load _socket.pyd.

Nonetheless:  if I copy the CRT assembly into the same folder as
testpy.exe, I get a popup dialog when I try to import socket, saying
"Runtime Error!" and "R6034; An application has made an attempt to load
the C library incorrectly.".  When I click OK in that dialog, I get this
error in the console running testpy.exe:

ImportError: DLL load failed: A dynamic link library (DLL)
initialization routine failed.

(If the assembly is not in the folder, there is no popup dialog at all.)
So it does indeed change the error code received.

Also, I see now that I made a mistake in reporting the error code from
the Apache log.  The actual behavior is this:

* Ordinary, the ImportError is:
ImportError: DLL load failed: The specified module could not be found.

* However, if I put the CRT assembly in the same folder as _socket.pyd:
ImportError: DLL load failed: A dynamic link library (DLL)
initialization routine failed.
and I received the same popup dialog as above.

Putting the CRT assembly in the Apache bin folder or Apache modules
folder still gives the first error (module could not be found).

I apologize for the confusion; when I first experienced this problem I
tried to fix it by experimenting with putting the manifest in various
folders and I wasn't paying close enough attention to what error was
given when.

To summarize:
testpy.exe with CRT assembly in testpy.exe folder: init routine failed
and popup.
testpy.exe with CRT assembly in _socket.pyd folder: init routine failed
and popup.
testpy.exe otherwise: module could not be found

Apache with CRT assembly in _socket.pyd folder: init routine failed and
popup.
Apache otherwise:  module could not be found

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 05:56:47 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Jan 2009 04:56:47 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>
Message-ID: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I am posting this patch mainly to support python-dev discussion on this 
topic.  In the past (see r45330) it was possible to compile python core 
and standard library modules using a C++ compiler.

According to Martin v. L?wis (issue4665), "It's not a requirement that 
the Python source code is compilable as C++. Only the header files 
should be thus compilable." However, I can see certain benefits from 
such requirement:

1. It is hard to verify that header files are compilable if source code 
is not.  With compilable source code, CC=g++ ./configure; make will 
supply an adequate test that does not require anything beyond a standard 
distribution.

2. Arguably, C++ compliant code is more consistent and less error prone.   
For example, "new" is a really bad choice for a variable name regardless 
of being a C++ keyword, especially when used instead of prevailing "res" 
for a result of a function producing a PyObject. Even clearly redundant 
explicit casts of malloc return values arguably improve readability by 
reminding the type of the object that is being allocated.

3. Compiling with C++ may reveal actual coding errors that otherwise go unnoticed.  For example, use of undefined PyLong_BASE_TWODIGITS_TYPE in Objects/longobject.c.

4. Stricter type checking may promote use of specific types instead of 
void* which in turn may help optimizing compilers.

5. Once achieved, C++ compilability is not that hard to maintain, but 
restoring it with patches like this one is hard because it requires 
review of changes to many unrelated files.

----------
files: c++-patch.diff
keywords: patch
messages: 78756
nosy: belopolsky
severity: normal
status: open
title: Make python code compilable with a C++ compiler
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file12527/c++-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Fri Jan  2 06:05:39 2009
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 02 Jan 2009 05:05:39 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1230868696.0.0.344618949929.issue4566@psf.upfronthosting.co.za>
Message-ID: <495DA09F.6020707@cheimes.de>


Christian Heimes <lists at cheimes.de> added the comment:

> Mark Hammond <mhammond at users.sourceforge.net> added the comment:
> 
> I've no time to dig deeper now as I suspect testing will require removal
> of the vc9 assembly from the GAC and testing with a local one, but some
> comments:

Isn't the GAC just for .NET assemblies while the SxS cache is for non
.NET assemblies? Microsoft's naming schema is confusing as usually. ;)

Christian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 06:12:51 2009
From: report at bugs.python.org (Jacques Frechet)
Date: Fri, 02 Jan 2009 05:12:51 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1230873171.32.0.210853875486.issue4272@psf.upfronthosting.co.za>


Jacques Frechet <jfrechet at users.sourceforge.net> added the comment:

I am uploading a new patch, identical to the previous patch except that
it does not contain the ill-advised third test case
(test_literal_output).  The patch still applies cleanly and the tests
still pass.

Added file: http://bugs.python.org/file12528/gzip-mtime-revised-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Fri Jan  2 06:13:52 2009
From: report at bugs.python.org (Jacques Frechet)
Date: Fri, 02 Jan 2009 05:13:52 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1230873232.39.0.0242507125414.issue4272@psf.upfronthosting.co.za>


Changes by Jacques Frechet <jfrechet at users.sourceforge.net>:


Added file: http://bugs.python.org/file12529/gzip-mtime-revised-2.x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Fri Jan  2 06:29:48 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 02 Jan 2009 05:29:48 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
In-Reply-To: <1230869629.1.0.9760193206.issue1675455@psf.upfronthosting.co.za>
Message-ID: <7c42eba10901012129qebc28dcsefa0cba09cec34c2@mail.gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

> I am a little confused by this though. It looks like
> FileHandler.file_open() checks if there is a hostname in the URL, and
> if so, uses FTPHandler instead. So why does FileHandler.open_local_file
> check the hostname value?

You are right. Even I had observed this, but did not dispute it. Let
me try to look into the history to see why it so. Perhaps it needs to
change.

> For your other points, gethostbyname() in libc can only handle IPv4
> addresses. The IETF defined the getaddrinfo() interface as an IP
> version neutral replacement. I would recommend using getaddrinfo().
> Yes, FTPHandler creates an urllib.FTPWrapper object. That object calls
> into ftplib, which is already IPv6-capable. So, I don't think we need
> to do hostname resolution in FTPHandler.

Thanks for the info. I shall look into both in revision of the path.
1) using getaddrinfo() for IP version neutral call.
2) passing the hostname directly to ftplib. ( I am not sure of
consequences, need to investigate).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Fri Jan  2 07:15:45 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Fri, 02 Jan 2009 06:15:45 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230876945.06.0.00128078698057.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

I modified the program by adding line: ftp.set_debuglevel(2)
START LISTING----------------
import ftplib

ftp = ftplib.FTP('ftp.edgecastcdn.net', user='myuserid',
passwd='mypassword')
ftp.set_debuglevel(2)
ftp.cwd('chrismahan-675')
ftp.dir()
#ftp.retrlines('LIST')
ftp.close()
END LISTING ---------------

Running from idle 1.2.4 with python 2.5.4 gives this output:

*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\r\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\r\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,234,6).\r\n'
*resp* '227 Entering Passive Mode (72,21,82,190,234,6).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\r\n'
*resp* '150 Opening ASCII mode data connection for file list'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04 test9_med.flv.jpg
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53 test9_sm.flv.jpg
*get* '226 Transfer complete\r\n'
*resp* '226 Transfer complete'


Then running with idle 3.0 with python 3.0 gives the following result.

*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,148,178).\n'
*resp* '227 Entering Passive Mode (72,21,82,190,148,178).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\n'
*resp* '150 Opening ASCII mode data connection for file list'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04 test9_med.flv.jpg
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53 test9_sm.flv.jpg

Note that the last two lines are missing.


>From a command prompt:
C:\>c:\python30\python.exe c:\python_scripts\python3\candee_processor.py
*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,219,8).\n'
*resp* '227 Entering Passive Mode (72,21,82,190,219,8).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\n'
*resp* '150 Opening ASCII mode data connection for file list'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04 test9_med.flv.jpg
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53 test9_sm.flv.jpg

same command prompt but with python 2.5:

C:\>c:\python25\python.exe c:\python_scripts\python3\candee_processor.py
*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\r\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\r\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,147,65).\r\n'
*resp* '227 Entering Passive Mode (72,21,82,190,147,65).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\r\n'
*resp* '150 Opening ASCII mode data connection for file list'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28 test9_lg.wmv.jpg
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04 test9_med.flv.jpg
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53 test9_sm.flv.jpg
*get* '226 Transfer complete\r\n'
*resp* '226 Transfer complete'

C:\>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Fri Jan  2 07:35:14 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Fri, 02 Jan 2009 06:35:14 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230878114.9.0.0123296844222.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

I went into the source for Libs/ftplib.py  and I noted that line 423 is: 

if self.debugging > 2: print('*retr*', repr(line))

so I changed the debuglevel to 3, as such:  ftp.set_debuglevel(3)
and I got these last 4 lines:

-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53 test9_sm.flv.jpg
*retr* ''
*get* '226 Transfer complete\r\n'
*resp* '226 Transfer complete'

First line, the last line of the listing.
second line, the debug, showing the last  line read
third and fourth lines: the program actually completed and didn't hang!

still digging

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Fri Jan  2 07:37:33 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Fri, 02 Jan 2009 06:37:33 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230878253.66.0.0124780593753.issue4566@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

I took a look at this with the debugger, as Mark recommended.  The CRT's
DLLMain is called _CRTDLL_INIT, that in turn calls __CRTDLL_INIT. 
__CRTDLL_INIT calls another function, _check_manifest.

_check_manifest calls an SxS function called FindActCtxSectionString. 
It's looking for a string called "msvcr90.dll" in the
ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION section of the process's
activation context (activation contexts are data structures used by
SxS).  That call fails (_check_manifest doesn't call GetLastError or
anything, it just returns FALSE right there).  There's a comment there
that says:

/* no activation context used to load CRT DLL, means no manifest present
in the process */

What's bizarre is that python26.dll successfully loaded msvcr90.dll (the
global one from WinSxS), so it must have passed _check_manifest.  It
seems like the activation context consists of the DLL's manifest
(_socket.pyd's in this case) and the exe's manifest, but no other ones,
regardless of what other libraries have been loaded.  The documentation
doesn't seem to explain the interaction between manifests in different
modules.  It's also annoying that this restriction (the _check_manifest
call) is completely artificial.

I don't know if any of this information is useful (I'm only
superficially familiar with activation contexts and the functions to
manipulate them).  The code is all in crtlib.c (in the CRT source) if
someone else wants to take a look.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 07:50:18 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Fri, 02 Jan 2009 06:50:18 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230879018.47.0.43911067427.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

I added the following two lines and I was able to run the code.


Before: 
            line = fp.readline()
            if self.debugging > 2: print('*retr*', repr(line))
            if not line:
                break
            if line[-2:] == CRLF:
                line = line[:-2]
            elif line[-1:] == '\n':
                line = line[:-1]
            callback(line)

After: 
            line = fp.readline()
            if self.debugging > 2: print('*retr*', repr(line))
            if not line:
                break
            if line == '':
                break
            if line[-2:] == CRLF:
                line = line[:-2]
            elif line[-1:] == '\n':
                line = line[:-1]
            callback(line)

As a patch:

426,427d425
<             if line == '':
<                 break

What else do I need to do?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Fri Jan  2 08:30:46 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Jan 2009 07:30:46 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>
Message-ID: <1230881446.85.0.664120268563.issue4805@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

A related question discussed on python-dev is whether extern "C" {} 
wrappers should ever be used in .c files.  I argue that the answer is "no" 
even if C++ compilability is desired.

The new patch eliminates several uses of extern "C" {} in .c files while 
preserving C++ compilability.  This is achieved by including proper header 
files instead of declaring external functions in .c files and in some 
cases adding declarations of functions that are used outside of the files 
they are defined in in the appropriate header files.

Added file: http://bugs.python.org/file12530/c++-patch-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Fri Jan  2 10:15:32 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 09:15:32 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230887732.44.0.476933589746.issue4566@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I've hacked together something that fixes the problem.  I'm working on
making it a real patch, but the basis is:

* In DllMain (dl_nt.c), we call:
  case DLL_PROCESS_ATTACH:
    GetCurrentActCtx(&PyWin_DLLhActivationContext);
    AddRefActCtx(PyWin_DLLhActivationContext);
  case DLL_PROCESS_DETACH:
    ReleaseActCtx(PyWin_DLLhActivationContext);

  (where PyWin_DLLhActivationContext is a module level HANDLE global)

* The LoadLibraryEx (in dynload_win.c) changes to:

    ActivateActCtx(PyWin_DLLhActivationContext, &cookie);
    /* XXX This call doesn't exist in Windows CE */
    hDLL = LoadLibraryEx(... as currently ...);
    DeactivateActCtx(0, cookie);

This makes the "import socket" test case work for me.  I'm not sure what
the impact will be should the .pyd file reference other assemblies. 
Also, the calls above all need to move to function pointer calls as the
functions only exist on Vista and later (hence the slight delay in
making a real patch)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 10:17:10 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 02 Jan 2009 09:17:10 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1230887830.55.0.601904720526.issue4804@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But then you get a nasty pop-up window on code like this:

>>> fd = os.open("foo", 0)
>>> os.close(fd)
>>> os.close(fd)

Instead of a gentle "OSError: [Errno 9] Bad file descriptor"

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 10:45:18 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 02 Jan 2009 09:45:18 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230887830.55.0.601904720526.issue4804@psf.upfronthosting.co.za>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F04D1702FD6@exchis.ccp.ad.local>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes, this is the biggest reason why this is required.
This, and and os.closerange().
I have browsed the CRT source and I find no way to determine if a fd is actually valid, before calling any of the functions that check for it.
Reintroducing the assertion will prevent a debug build python from passing the testsuite.
Much as I think this is useful (turning on the crt tests helped me find a couple of python bugs recently) it unfortunately needs to be off because of os.close().  All other troublesome cases (strftime(), open()) have workarounds.

Kristj?n

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 10:56:19 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 02 Jan 2009 09:56:19 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230887830.55.0.601904720526.issue4804@psf.upfronthosting.co.za>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F04D1702FD7@exchis.ccp.ad.local>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Btw,
It occurred to me that a more gentle way to do this is to disable the functionality only around close().
This is far less intrusive, for example, in an embedded environment.
I must confess that I had completely forgototten about the disabling of the assertion and only stumbled on this recently when I was trying to find out why none of my _ASSERTS in eve worked!  Making wholesale CRT settings certainly should be avoided.

So, as I said, we could very well avoid this by just wrapping a few instances of close() with a CrtSetErrorHandler calls and friends.  With the caveat that these are not threadsafe, that is, it is a process global setting for the CRT.  But toggling it during a limited scope surely is less intrusive than modifying it for the entire process permanently.

Kristj?n

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:24:36 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 10:24:36 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1230891876.78.0.451486550762.issue4804@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

It would be interesting to know which tests actually fail.  If the tests
are explicitly checking a bad fd, then IMO it makes more sense for that
test to simply be avoided in debug builds and nothing of value would be
left untested.  OTOH, I'd also be happy with just disabling them around
the 2 functions known to cause issues - anything other than leaving
assertions globally disabled for the process!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:30:17 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 10:30:17 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1230892217.97.0.646619281001.issue4804@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I guess another option is to expose it via msvcrt and let the test
themselves disable it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:33:46 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 10:33:46 +0000
Subject: [issue4738] Patch to make zlib-objects better support threads
In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za>
Message-ID: <1230892426.77.0.787032202647.issue4738@psf.upfronthosting.co.za>


Changes by ebfe <knabberknusperhaus at yahoo.de>:


Removed file: http://bugs.python.org/file12466/zlib_threads-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4738>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:38:18 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 10:38:18 +0000
Subject: [issue4738] Patch to make zlib-objects better support threads
In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za>
Message-ID: <1230892698.23.0.334663129664.issue4738@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

Here is a small test-script with concurrent access to a single
compressosbj. The original patch will immediately deadlock.

The patch attached releases the GIL before trying to get the zlib-lock.
This allows the other thread to release the zlib-lock but comes at the
cost of one additional GIL lock/unlock.

Added file: http://bugs.python.org/file12531/zlib_threads-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4738>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:39:36 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 10:39:36 +0000
Subject: [issue4738] Patch to make zlib-objects better support threads
In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za>
Message-ID: <1230892776.86.0.395321460996.issue4738@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

test-script

Added file: http://bugs.python.org/file12532/zlibtest2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4738>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:45:01 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 10:45:01 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230893101.08.0.0996947539189.issue4751@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

Releasing the GIL is somewhat expensive and should be avoided if
possible. I've moved LEAVE_HASHLIB in EVP_update so the object gets
unlocked before we call Py_END_ALLOW_THREADS. This is *only* possible
because EVP_update does not use the object beyond those lines.

Here is a new patch and a small test-script.

Added file: http://bugs.python.org/file12533/hashopenssl_threads-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:45:18 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 10:45:18 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230893118.37.0.467253221012.issue4751@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

test-script

Added file: http://bugs.python.org/file12534/hashlibtest2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:45:22 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 10:45:22 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230893122.49.0.27863521203.issue4751@psf.upfronthosting.co.za>


Changes by ebfe <knabberknusperhaus at yahoo.de>:


Removed file: http://bugs.python.org/file12461/hashopenssl_threads-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:46:35 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 10:46:35 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230893195.93.0.287757721788.issue4751@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

gnarf, actually it should be 'threads.append(Hasher(md))' in the script :-\

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:48:13 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 10:48:13 +0000
Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <1230893293.23.0.466289178047.issue4472@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

LDLIBRARY is indeed a good variable to use. 

I've applied issue447-v2.patch in r68146. Backported to 2.6.x in r68147.

Added file: http://bugs.python.org/file12535/issue4472-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:48:46 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 10:48:46 +0000
Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <1230893326.12.0.365438824453.issue4472@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution: accepted -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:51:15 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 10:51:15 +0000
Subject: [issue4780] Makefile.pre.in patch to run regen on OSX (framework
	build)
In-Reply-To: <1230642378.46.0.486113805886.issue4780@psf.upfronthosting.co.za>
Message-ID: <1230893475.9.0.996487051216.issue4780@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've ported the fix to the trunk in r68149

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4780>
_______________________________________

From report at bugs.python.org  Fri Jan  2 11:56:57 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 10:56:57 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230893817.75.0.734219589539.issue4566@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Attaching a patch which works for me against python 2.6.  Only ever
tested on Vista (ie, where the function pointers etc all load)

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file12536/bug4566.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:06:03 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 11:06:03 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230894363.28.0.614091438953.issue4566@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12536/bug4566.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:10:53 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 11:10:53 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230894653.46.0.461657848617.issue4566@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Attaching a new patch with some typos in the comments corrected.  While
I'm here, I also meant to mention (again!):

* No need to remove the the assembly from the sxs cache - the test
"fails correctly" with VS2009 installed.  FWIW, I compiled test.c from
the command line with:
  % cl /I {pypath}\include /I {pypath}\PC /DDEBUG /D_DEBUG /MTd test.c
/LINK {pypath}\pcbuild\python26_d.lib

* It appears the sxscache and the "gac" are indeed different things,
although at least one MS page refers to the sxscache as the "native
assembly cache" <wink/sigh>

Added file: http://bugs.python.org/file12537/bug4566.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:24:55 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 02 Jan 2009 11:24:55 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230891876.78.0.451486550762.issue4804@psf.upfronthosting.co.za>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F04D1702FEE@exchis.ccp.ad.local>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, I'll prepare a patch to the trunk.  I've had some experience with this and should have the code lying around somewhere.  I'll let you know once I?ve created an issue.
K

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:31:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 11:31:38 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230895898.96.0.199448932616.issue4796@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Accordingly, I recommend Decimal.from_float(f) with no qualifiers or
> optional arguments.

I agree with this.  Since lossless conversion is feasible, this seems 
the obvious way to go.

It's lucky that the exponent range for (binary) floats is relatively 
small, though:  for IEEE 754 floats the worst case conversions (e.g., 
(2**53-1)/2**1074) produce Decimals with something like 767 significant 
digits, which is still plenty small enough not to cause difficulties.

The recipe in the docs is not industrial strength: it doesn't handle 
infinities, nans and negative zero.  I think there's a place for a 
from_float method that handles these special cases correctly---or at 
least as correctly as reasonable:  +-infinity should convert to +-
infinity, nans to (quiet) nans.  I don't think it's worth worrying about 
preserving the sign or payload of a binary nan: just convert all float 
nans to Decimal('NaN').    I do however think it's worth trying to 
preserve the sign of negative zero.  Note: I'm not suggesting changing 
the *documentation* at all---the recipe there is fine as it is, IMO, but 
I think an official version should include these corner cases.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:40:02 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 11:40:02 +0000
Subject: [issue3055] test_list on 64-bit platforms
In-Reply-To: <1212788254.95.0.00817873629987.issue3055@psf.upfronthosting.co.za>
Message-ID: <1230896402.7.0.879844477247.issue3055@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I can confirm that this issue is fixed.

----------
resolution: works for me -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3055>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:43:18 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 11:43:18 +0000
Subject: [issue4165] Failure building 64-bit Python on Leopard
In-Reply-To: <1224621107.94.0.119625965208.issue4165@psf.upfronthosting.co.za>
Message-ID: <1230896598.66.0.692387848081.issue4165@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I located the problem, it's in the configure line:

 ./configure --with-framework-name=Python64 --
with-universal-archs=all --enable-framework --enable-
universalsdk=MACOSX_DEPLOYMENT_TARGET=10.5

That's wrong because the argument for --enable-universalsdk should be a 
filesystem path for the SDK. In this case the following command-line 
will work:

./configure --with-framework-name=Python64 --
with-universal-archs=all --enable-framework --enable-
universalsdk=/

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4165>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:48:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 11:48:37 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230896917.76.0.887409781686.issue4796@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One also has to worry about the exponent of the converted result:  e.g., 
should Decimal.from_float(10.0) produce Decimal('1E1') or Decimal('10')?
The latter looks nicer, to me.

IEEE 754 isn't much help here:  as far as I can tell it says nothing about 
binary <-> decimal conversions.

I see two reasonable strategies:  (1) always use the largest exponent 
possible (so we'd get Decimal('1E1') above), or (2) when the quantity 
converted is an exact integer, use an exponent of zero; otherwise fall 
back to (1).

Option (2) is pretty much what the recipe in the docs does already, I 
think:  it computes a quotient of two Decimals, each having exponent zero, 
so the preferred exponent of the result is also zero.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:49:58 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 11:49:58 +0000
Subject: [issue3433] Mac, 3.0 framework install error with fink cp
In-Reply-To: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>
Message-ID: <1230896998.86.0.646301445656.issue3433@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r68150 (python-trunk), r68151 (python 2.6.x), r68152 (python 
3.x).

Could someone that actually has Fink installed confirm that the issue is 
actually fixed? My patch consists of changing 'cp' to '/bin/cp' to ensure 
that the system copy of that command is used.

----------
resolution:  -> fixed
status: open -> pending
title: libtk -> Mac, 3.0 framework install error with fink cp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3433>
_______________________________________

From report at bugs.python.org  Fri Jan  2 12:51:35 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 11:51:35 +0000
Subject: [issue2754] Mac version of IDLE doesn't scroll as expected
In-Reply-To: <1209903976.71.0.763172048838.issue2754@psf.upfronthosting.co.za>
Message-ID: <1230897095.17.0.528457924007.issue2754@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is almost certainly a Tk issue and hence not something we can fix.

I'm not closing the bug though because I no too little of Tk to be sure.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2754>
_______________________________________

From report at bugs.python.org  Fri Jan  2 13:22:51 2009
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 02 Jan 2009 12:22:51 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1230852036.91.0.153383854132.issue4718@psf.upfronthosting.co.za>
Message-ID: <495E0717.9070402@hlabs.spb.ru>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Graham Dumpleton wrote:
> Thus have odd situation where with Python 3.0, one could technically return 
> str as iterable, with rule that would apply would be that each str returned 
> would then be converted to bytes by way of latin-1 conversion, but for 
> bytes returned as iterable, should fail.
> 
> Not sure how this plays out in wsgiref server yet as haven't looked. 

If application return bytes instead of an iterable AssertionError will
be raised in handlers.BaseHandler.write().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Fri Jan  2 13:46:04 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 02 Jan 2009 12:46:04 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

If we call some function f with a generator as star argument and this
generator raises a TypeError, we get the following exception:

>>> def f(x): pass
... 
>>> def broken(): raise TypeError
... 
>>> f(*(broken() for x in (0,)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() argument after * must be a sequence, not generator

This is a misleading error message, as it's usually no problem to use a
generator as a star argument. Even just replacing the TypeError by some
other exception leads to the expected result, i.e. the exception gets
correctly propagated.

The problem seems to be around line 3710 of Python/ceval.c where the
generator is converted to a tuple. If this conversion raises a
TypeError, then the error message is replaced, which will mask any
TypeError raised by the generator.

I'm not sure how to solve this. We probably can't distinguish a "good"
TypeError from a "bad" TypeError at this point, so we might have to make
a special case for the conversion of generators.

----------
components: Interpreter Core
messages: 78788
nosy: hagen
severity: normal
status: open
title: Function calls taking a generator as star argument can mask TypeErrors in the generator
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Fri Jan  2 14:05:36 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 02 Jan 2009 13:05:36 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230901536.27.0.461506578557.issue4796@psf.upfronthosting.co.za>


Steven D'Aprano <steve at pearwood.info> added the comment:

Mark suggested the following strategy for Decimal.from_float: "always 
use the largest exponent possible".

Just for the avoidance of all doubt, do you mean the largest exponent 
with the number normalised to one digit to the right of the decimal 
place? Because 1e1 = 0.1e2 = 0.01e3 = ... and there is no "largest 
exponent possible" if you allow unnormalised numbers. Seems obvious to 
me, but maybe I'm missing something.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Fri Jan  2 14:08:03 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 02 Jan 2009 13:08:03 +0000
Subject: [issue4807] wrong wsprintf usage
In-Reply-To: <1230901683.42.0.873273528074.issue4807@psf.upfronthosting.co.za>
Message-ID: <1230901683.42.0.873273528074.issue4807@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

Note up front: there is a win32 function wsprintf() and an ISO C
function swprintf(), these are different things in case you wonder.

In _winreg.c, there are two functions that use wsprintf on a char
buffer, while the function takes a TCHAR buffer instead. This leads to
compile warning and runtime errors when _UNICODE is defined, like e.g.
under MS Windows CE. The attached patch replaces the two calls to that
function with calls to fprintf() and PyString_FromFormat().

----------
components: Windows
files: python-2.7-no-wsprint.0.patch
keywords: patch
messages: 78790
nosy: eckhardt
severity: normal
status: open
title: wrong wsprintf usage
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file12538/python-2.7-no-wsprint.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4807>
_______________________________________

From report at bugs.python.org  Fri Jan  2 14:11:15 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 13:11:15 +0000
Subject: [issue3549] Missing IDLE Preferences on Mac
In-Reply-To: <1218662954.17.0.753425221317.issue3549@psf.upfronthosting.co.za>
Message-ID: <1230901875.22.0.67756354283.issue3549@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The lack of a preferences menu is a bug: the current revisions of python 
contain some code to detect a recent version of Tcl/Tk, used to create the 
Preferences... menu in different way. Sadly enough this code is buggy, the 
end result is that you will not have a IDLE->Preferences...' menu when 
using the system version of Tcl/Tk.

Fixed in r68153 (python-trunk), r68154 (python-2.6), r68155 (python-3.1)

----------
nosy: +ronaldoussoren
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3549>
_______________________________________

From report at bugs.python.org  Fri Jan  2 14:14:22 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 13:14:22 +0000
Subject: [issue789545] zappyfiles.py absent from MacPython binary
Message-ID: <1230902062.35.0.859546851181.issue789545@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing because zappyfiles.py is no longer part of the python distribution

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue789545>
_______________________________________

From report at bugs.python.org  Fri Jan  2 14:18:09 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 02 Jan 2009 13:18:09 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230902289.3.0.400550805188.issue4796@psf.upfronthosting.co.za>


Steven D'Aprano <steve at pearwood.info> added the comment:

Raymond:
> Accordingly, I recommend Decimal.from_float(f) with no 
> qualifiers or optional arguments.

-0 on this one. It's going to confuse an awful lot of newbies when 
they write Decimal.from_float(1.1) and get 
Decimal('110000000000000008881784197001252...e-51').

Also, why not just extend the Decimal() constructor to accept a float 
as the argument? Why have a separate from_float() method at all?

> To support the use case of wanting to round the input, I 
> suggest a separate method modeled on Context.create_decimal().

+1 on this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Fri Jan  2 14:21:23 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 13:21:23 +0000
Subject: [issue1602133] non-framework built python fails to define environ
	properly
Message-ID: <1230902483.81.0.835191882101.issue1602133@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I won't commit this patch because I cannot reproduce the problem.

The python trunk works fine for my in these build configurations: unix-
build (static library), unix-build (shared library), framework build.

All of this on OSX 10.5. 

Can you please provide more information on how to reproduce the problem 
(os releases, which version of python, how to build, what should I do to 
get the segfault you mention)?

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602133>
_______________________________________

From report at bugs.python.org  Fri Jan  2 14:37:08 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 02 Jan 2009 13:37:08 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1230903428.84.0.0869831309386.issue4681@psf.upfronthosting.co.za>


Changes by Ulrich Eckhardt <eckhardt at satorlaser.com>:


----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:03:38 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 02 Jan 2009 14:03:38 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1230905018.89.0.89434507226.issue1699259@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

Concerning the SetArgv( int, char**), that one will have to be changed
to a SetArgv( int, char const* const*), i.e. applying the const on both
levels. Otherwise, there is no implicit conversion between the two.

The reason is a bit complicated: if the function stored a
pointer-to-const in the array, it would become a pointer-to-nonconst
outside. Only if modification of the array is forbidden, changing the
element type to pointer-to-const is allowed.

Otherwise, I'm +1 on this kind of changes, because it makes immediately
obvious which functions modify a passed buffer and which don't.

----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:09:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 14:09:36 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230905376.02.0.82600617505.issue4796@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Just for the avoidance of all doubt, do you mean the largest exponent 
> with the number normalised to one digit to the right of the decimal 
> place?

No.  I'm using 'exponent' in the sense described in the standard.  See:

http://speleotrove.com/decimal/dbover.html

Equivalently, it's the value of the _exp attribute for a Decimal 
instance.  (For the purposes of disambiguation, the alternative exponent 
that you describe above is often referred to as the 'adjusted exponent' 
in the documentation and code.)

Briefly, every finite Decimal can be thought of as a triple (sign, 
coefficient, exponent), representing the value (-1)**sign * coefficient 
* 10**exponent, with the coefficient an integer.  It's this exponent 
that should be maximized.

> Because 1e1 = 0.1e2 = 0.01e3 = ... and there is no "largest 
> exponent possible"

All these have exponent 1:

>>> Decimal('1e1')._exp
1
>>> Decimal('0.1e2')._exp
1
>>> Decimal('0.01e3')._exp
1

IOW, leading zeros have no significance;  only trailing zeros do.

> Also, why not just extend the Decimal() constructor to accept a float 
> as the argument? Why have a separate from_float() method at all?

This was discussed extensively when the decimal module was being 
proposed;  see the Decimal PEP for arguments against this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:11:27 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 14:11:27 +0000
Subject: [issue1594] MacOS.GetCreatorAndType() and SetCreatorAndType() broken
	on intel
In-Reply-To: <1197404452.81.0.608484843399.issue1594@psf.upfronthosting.co.za>
Message-ID: <1230905487.92.0.822588082772.issue1594@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r68156 (including testcase). Annoyingly enough only 
GetCreatorAndType needed fixing, SetCreatorAndType already did the right 
thing (makeing the two functions inconsistent with each other).

Won't fix for earlier releases, this might break existing code.

----------
nosy: +ronaldoussoren
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1594>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:13:10 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 02 Jan 2009 14:13:10 +0000
Subject: [issue2754] Mac version of IDLE doesn't scroll as expected
In-Reply-To: <1209903976.71.0.763172048838.issue2754@psf.upfronthosting.co.za>
Message-ID: <1230905590.57.0.826748923427.issue2754@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I see some issues related to scrolling under macosx were fixed in tk
8.4.13, but I can't test them since I don't have a mac.

If scrolling doesn't work with the example below then I can just say the
problem is indeed with tk, but you could try upgrading it.

import Tkinter

root = Tkinter.Tk()

text = Tkinter.Text()
text.focus_set()
vbar = Tkinter.Scrollbar(orient='vertical', command=text.yview)
text.configure(yscrollcommand=vbar.set)

vbar.pack(side='right', fill='y')
text.pack(fill='both', expand=True)

for l in range(int(text['height']) + 10):
    text.insert('end', "x\n")

root.mainloop()

----------
nosy: +gpolo
Added file: http://bugs.python.org/file12539/tktext_scroll.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2754>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:16:32 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 14:16:32 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230905792.13.0.760045849768.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you paste the full output with debuglevel=3?

"if not line:" should be equivalent to "if len(line) == 0:" and to "if 
line == '':".

ftp.dir() is equivalent to ftp.retrlines('LIST').

By default, the socket created to get the result of LIST has no 
timeout (is blocking). So fp.readline() only returns an empty string 
when the socket is closed (by the server).

fp is a io.BufferedReader(SocketIO(socket, "r"), 
io.DEFAULT_BUFFER_SIZE).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:26:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 02 Jan 2009 14:26:27 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1230906387.85.0.505795668381.issue4806@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The issue1615 has the same kind of problems: an AttributeError is masked
by another one.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:44:22 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 14:44:22 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230907462.32.0.345917072702.issue4751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Releasing the GIL is somewhat expensive and should be avoided 
> if possible.

Another possible solution is to create a lockless object by default, 
and create a lock if the data size is bigger than N (eg. 8 KB). When 
the lock is created, update will always use the lock (and so the GIL).

In general, you have two classes of hashlib usages:
 - hash a big files by chunk of k KB (eg. 256 KB)
 - hash a very small string (eg. 8 bytes)

When you have a small string, you don't need to release the GIL nor to 
use locks. Whereas for a file, you can always release the GIL (and so 
you need a lock to protect the context).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:45:46 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Fri, 02 Jan 2009 14:45:46 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230907546.52.0.162757210556.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

Full output with debuglevel 3

*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,217,227).\n'
*resp* '227 Entering Passive Mode (72,21,82,190,217,227).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\n'
*resp* '150 Opening ASCII mode data connection for file list'
*retr* '-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski
Beat - Why.mp3\n'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
*retr* '-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi\n'
-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi
*retr* '-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28
test9_lg.wmv\n'
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28
test9_lg.wmv.jpg\n'
-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28 test9_lg.wmv.jpg
*retr* '-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04
test9_med.flv\n'
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04
test9_med.flv.jpg\n'
-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04 test9_med.flv.jpg
*retr* '-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53
test9_sm.flv\n'
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53
test9_sm.flv.jpg\n'
-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53 test9_sm.flv.jpg
*retr* ''

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:46:40 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 14:46:40 +0000
Subject: [issue900949] plat-mac/videoreader.py not working on OS X
Message-ID: <1230907600.43.0.118441791306.issue900949@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r68158.

----------
nosy: +ronaldoussoren
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue900949>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:48:25 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Fri, 02 Jan 2009 14:48:25 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230907705.75.0.982977878042.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

haypo writes:
>By default, the socket created to get the result of LIST has no 
>timeout (is blocking). So fp.readline() only returns an empty string 
>when the socket is closed (by the server).

Even if the server closed the socket and fp.readline() returned an empty
string, the prog should not hang, no?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:48:35 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 14:48:35 +0000
Subject: [issue1627952] plat-mac videoreader.py auido format info
Message-ID: <1230907715.2.0.0355584861007.issue1627952@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixd in r68159

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1627952>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:52:37 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 14:52:37 +0000
Subject: [issue1737832] EasyDialogs patch to remove aepack dependency
Message-ID: <1230907957.5.0.274030615631.issue1737832@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied this patch in r68160.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1737832>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:55:13 2009
From: report at bugs.python.org (Corey Goldberg)
Date: Fri, 02 Jan 2009 14:55:13 +0000
Subject: [issue4808] doc issue for threading module (name/daemon properties)
In-Reply-To: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>
Message-ID: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>


New submission from Corey Goldberg <cgoldberg at gmail.com>:

In the current 3.0 doc for threading:
http://docs.python.org/dev/py3k/library/threading.htm

it says:

Thread.getName()
Thread.setName()
  Old API for name.
  
and

Thread.isDaemon()
Thread.setDaemon()
  Old API for daemon.
  
  
'name' and 'daemon' properties should be listed as defaults and the old
getter/setter methods should be noted as "Old API".

----------
assignee: georg.brandl
components: Documentation
messages: 78807
nosy: cgoldberg, georg.brandl
severity: normal
status: open
title: doc issue for threading module (name/daemon properties)
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4808>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:57:16 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 02 Jan 2009 14:57:16 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230850791.65.0.79634207218.issue4753@psf.upfronthosting.co.za>
Message-ID: <495E2B49.8020702@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-01 23:59, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> I've updated the comments as per Alexandre's request, added support for
> SUN CC, and fixed the generation script to use the new filename.

Since the patch heavily relies on the compiler doing the right
thing (which esp. GCC often doesn't, unfortunately), I think that the
opcode dispatch code should only be enabled via a configure option.

This is safer than enabling the support unconditionally for GCC and
the SUN Pro C compiler, since it is rather likely that some GCC versions
have bugs which could render Python unusable if compiled with the
dispatching support enabled.

A configure option also has the additional benefit that you can enable
the support for compilers which support the syntax, but are not included
in the hard-coded list of compilers included in the patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 15:58:42 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Jan 2009 14:58:42 +0000
Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <1230908322.86.0.25576388115.issue4472@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Ronald,
cygwin is a special case too.
LDLIBRARY is so called import library !

So the make target can be (as I propose in py-issue-4472-makefile.patch)
+		if test -n "$(DLLLIBRARY)"; then \
+			$(INSTALL_SHARED) $(DLLLIBRARY) $(DESTDIR)$(BINDIR); \

or if new check is not ok then we has to restore old code .
-		if test "$(SO)" = .dll; then \
-			$(INSTALL_SHARED) libpython$(VERSION)$(SO) $(DESTDIR)$(BINDIR); \

More info for cygwin:
- SO = .dll
- DLLLIBRARY is set only for cygwin
- libpython$(VERSION)$(SO) = $(DLLLIBRARY)
- but $(LDLIBRARY) = libpython$(VERSION).dll.a !!!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:00:24 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 15:00:24 +0000
Subject: [issue1149804] macostools.mkdirs: not thread-safe
Message-ID: <1230908424.67.0.439688466314.issue1149804@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed this issue in r68161 by porting the solution for this in os.mkdirs 
to macostools.

----------
nosy: +ronaldoussoren
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1149804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:06:21 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Fri, 02 Jan 2009 15:06:21 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230908781.42.0.375234888778.issue4566@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

I haven't been able to try this patch myself yet, but I see a potential
problem:  the "cookie" variable is declared as a DWORD, while
ActivateActCtx expects a ULONG_PTR. DWORD and ULONG_PTR are only the
same thing in 32-bit Windows.

Also, where are you seeing that these SxS functions are "Vista or
later"?  My XP kernel32.dll has all of them.  MSDN says they're XP or Vista.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:06:49 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 15:06:49 +0000
Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <1230908809.58.0.610754571515.issue4472@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied this patch. If I understand things correctly that should 
fix the cygwin issue.

Index: Makefile.pre.in
===================================================================
--- Makefile.pre.in	(revision 68149)
+++ Makefile.pre.in	(working copy)
@@ -773,8 +773,8 @@
 	done
 	$(INSTALL_PROGRAM) $(BUILDPYTHON) 
$(DESTDIR)$(BINDIR)/python$(VERSION)$(EXE)
 	if test -f $(LDLIBRARY); then \
-		if test "$(SO)" = .dll; then \
-			$(INSTALL_SHARED) $(LDLIBRARY) 
$(DESTDIR)$(BINDIR); \
+		if test -n "$(DLLLIBRARY)" ; then \
+			$(INSTALL_SHARED) $(DLLLIBRARY) 
$(DESTDIR)$(BINDIR); \
 		else \
 			$(INSTALL_SHARED) $(LDLIBRARY) 
$(DESTDIR)$(LIBDIR)/$(INSTSONAME); \
 			if test $(LDLIBRARY) != $(INSTSONAME); then \

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:10:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 15:10:07 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1230909004.94.0.703329006939.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch (against py3k) generated from the current state of the 
py3k-issue1717 branch, for ease of review and testing.

The patch needs serious review;  it should be considered a first draft, 
and there are probably many more changes still to be made.  I don't 
think I can do much more for now without getting input from others.

Known places in the source tree where cmp/__cmp__ still lingers on:

Demos/<many>
Doc/extending/newtypes.rst
Misc/cheatsheet
Misc/python-mode.el
Misc/Vim/python.vim
Parser/spark.py   # (I don't know what this does.  Anyone?)
Tools/<various>   # (notably pynche and pybench)

Apart from the newtypes.rst, all of the above files are somewhat out of 
date in other ways.  In my opinion it's only the doc fixes that stop the 
patch from being complete enough.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file12540/remove_cmp6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:10:19 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 15:10:19 +0000
Subject: [issue900514] bundlebuilder: easily keep main routine in orig location
Message-ID: <1230909019.94.0.793160872286.issue900514@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree with Bob's last response. Futhermore bundlebuilder is deprecated, 
use py2app instead.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue900514>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:11:24 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 15:11:24 +0000
Subject: [issue905737] BuildApplet needs to get more BuildApplication features
Message-ID: <1230909084.21.0.466946111855.issue905737@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing this issue as bundlebundler is deprecated.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue905737>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:26:00 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 15:26:00 +0000
Subject: [issue841800] -O breaks bundlebuilder --standalone
Message-ID: <1230909960.39.0.628698845873.issue841800@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r68163

----------
nosy: +ronaldoussoren
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue841800>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:26:26 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 15:26:26 +0000
Subject: [issue900506] bundlebuilder: an arg to disable zipping the code
Message-ID: <1230909986.89.0.159977974878.issue900506@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r68163

----------
nosy: +ronaldoussoren
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue900506>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:32:34 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 15:32:34 +0000
Subject: [issue957652] Implement BundleBuilder GUI as plugin component
Message-ID: <1230910354.76.0.0191640684014.issue957652@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closed as won't fix because bundlebuilder is deprecated and it is rather 
unlikely that anyone will spent time on this feature request.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue957652>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:35:56 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Fri, 02 Jan 2009 15:35:56 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230910556.1.0.589080165495.issue4566@psf.upfronthosting.co.za>


Craig Holmquist <craigholm at gmail.com> added the comment:

The patch works fine on my system (32-bit XP).  Also I verified in
Process Explorer that there's only one instance of msvcr90.dll loaded.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:43:40 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 15:43:40 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230911020.98.0.73380882947.issue4751@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

I don't think this is actually worth the trouble. You run into situation
where one thread might decide that it needs a lock now with other
threads being in the to-be-locked-area at that time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:51:54 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 02 Jan 2009 15:51:54 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>
Message-ID: <1230911514.91.0.0936643511762.issue4805@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Moving declarations into header files is not really in line with the way
Python developers use header files:

We usually only put code into header files that is meant for public use. 

Buy putting declarations into the header files without additional
warning, you implicitly document them and make them usable in
non-interpreter code.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:54:42 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 02 Jan 2009 15:54:42 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>
Message-ID: <1230911682.85.0.598113499033.issue4805@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Also note that by removing the extern "C" declarations, you not only
change the exported symbol names of functions, but also those of
exported globals.

Those would also have to get declared in the header files, to prevent
their names from being mangled (causing the exported C API to change).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:55:35 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 02 Jan 2009 15:55:35 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>
Message-ID: <1230911735.12.0.300123200363.issue4805@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The added type casts are useful to have - even outside the context of
the idea behind the patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Fri Jan  2 16:57:21 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 15:57:21 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1230911841.32.0.50506089114.issue2121@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Raymond]
> I would
> not like to see that extended to cmath or complex() unless compelling
> real-world use cases arise.

Hmm.  Have you looked at the cmath module recently?  You may be in for a 
nasty surprise...

> Mark, does Inf have a standard interpretation for complex numbers?  Do
> all infinities meet or do they radiate, each with their own phase
> angle?

Shrug.  Mathematically, by far the most common and useful model is the 
complex plane plus a single extra point at infinity.  But when complexes 
are implemented as pairs of floats things look a little strange. Kahan, 
in his 'branch cuts' paper identifies 9 'different' complex infinities 
in this model, and C99 Annex G specifies exactly how functions should 
behave for various different infinities.

It's never really been clear to me how useful it is to be able to 
distinguish these infinities.  But the cmath module *does* make an 
effort to return the 'correct' (according to C99 Annex G) values for 
inputs with a special real or imaginary component.  On balance, I'd 
support making complex('nan + nan*j') do the right thing.

(Though I can't help feeling that the repr of complex(nan, nan)
should have been 'nan + nan*1j' rather than the current 'nan + nan*j'.)

> Also, do you want to stick with the 754 interpretation of NaNs as the
> result of invalid operations

I've never much liked the use of NaN to represent missing values, and
I don't think Python should embrace that usage.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:01:39 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 16:01:39 +0000
Subject: [issue4794] garbage collector blocks and takes worst-case linear time
	wrt number of objects
In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za>
Message-ID: <1230912099.82.0.660538055717.issue4794@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Hard real-time applications written in Python should not rely on the
cyclic garbage collector. They should call gc.disable at startup, and
completely rely on reference counting for releasing memory. Doing so
might require rewrites to the application, explicitly breaking cycles so
that reference counting can release them.

Even with cyclic gc disabled, applications worried about meeting hard
deadlines need to look even more into memory allocation and
deallocation; e.g. releasing a single object may cause a chained release
of many objects, which can affect worst case execution times. There are
more issues to consider (which are all out of scope of the bug tracker).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4794>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:07:09 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 16:07:09 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1230766995.94.0.793340858766.issue3959@psf.upfronthosting.co.za>
Message-ID: <495E3BAA.6070200@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I think this might be worth a look before any hard and fast decisions
> are made :-
> 
> http://code.google.com/p/netaddr/

Looking at code isn't really helpful for determining whether it can
be included into Python. What matters more is whether the authors
want to contribute it, how they want to support it afterwards, and
so on.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:08:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 16:08:19 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1230912499.33.0.453177575031.issue2121@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

cdavid, in your application, how hard is it to work around the problem by 
simply printing and parsing pairs of floats rather than complex numbers?

E.g.,

<get real part and imaginary part from string> 
z = complex(float(real_part), float(imag_part))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:10:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Jan 2009 16:10:35 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <495E2B49.8020702@egenix.com>
Message-ID: <1230912587.9067.23.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This is safer than enabling the support unconditionally for GCC and
> the SUN Pro C compiler, since it is rather likely that some GCC versions
> have bugs which could render Python unusable if compiled with the
> dispatching support enabled.

What do you mean, "unusable"? 10% slower? Well, Python 3.x is already
unusable (compared to 2.x) by that metric... Until now, only Skip has
reported a slowdown on his PPC machine, while x86 systems have all seen
a positive (if tiny, sometimes) improvement.

I fear that with a configure option, disabled by default, the code will
get very poor testing and perhaps get broken in some subtle way without
anyone noticing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:16:00 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 16:16:00 +0000
Subject: [issue4035] Support bytes for os.exec*()
In-Reply-To: <1223077104.22.0.62328245443.issue4035@psf.upfronthosting.co.za>
Message-ID: <1230912960.71.0.245879177735.issue4035@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Any discussion in the tracker should be deferred until a PEP has been
written, discussed, and accepted. Then the question whether to accept a
specific patch shouldn't be a matter of taste, but should follow from
the general rules that the PEP has set up.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4035>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:16:10 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Jan 2009 16:16:10 +0000
Subject: [issue4065] _multiprocessing doesn't build on macosx 10.3
In-Reply-To: <1223376772.75.0.564119782301.issue4065@psf.upfronthosting.co.za>
Message-ID: <1230912970.69.0.519029183933.issue4065@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The manpage for writev(2) mentions #include <sys/uio.h>. Adding a #include 
for <sys/uio.h> is the right fix after all...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4065>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:17:41 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 02 Jan 2009 16:17:41 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230912587.9067.23.camel@localhost>
Message-ID: <18782.15905.838842.10862@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> I fear that with a configure option, disabled by default, the
    Antoine> code will get very poor testing and perhaps get broken in some
    Antoine> subtle way without anyone noticing.

That can be fixed by enabling that option on the buildbots where it is
presumed to help.  I see more slowdown on PPC than people are reporting as
speedups on Intel.  Is there something I can do to help debug the problem?
It doesn't appear the Apple version of gcc supports the -fno-crossjumping
flag.  If I dump the assembler code for ceval.c will that help others debug
the problem?

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:18:15 2009
From: report at bugs.python.org (Randy Syring)
Date: Fri, 02 Jan 2009 16:18:15 +0000
Subject: [issue4809] 2.5.4 release missing from python.org/downloads
In-Reply-To: <1230913095.06.0.854632300097.issue4809@psf.upfronthosting.co.za>
Message-ID: <1230913095.06.0.854632300097.issue4809@psf.upfronthosting.co.za>


New submission from Randy Syring <randy at rcs-comp.com>:

http://www.python.org/download/ is missing a link to 2.5.4 in the
standard releases section.

----------
assignee: georg.brandl
components: Documentation
messages: 78832
nosy: georg.brandl, rsyring
severity: normal
status: open
title: 2.5.4 release missing from python.org/downloads

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4809>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:26:11 2009
From: report at bugs.python.org (Cournapeau David)
Date: Fri, 02 Jan 2009 16:26:11 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1230913571.52.0.378472470119.issue2121@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

It is not really for an application, but for numpy. Of course, one can
always get around the problem - but since this is really a limitation
which can be easily fixed, why not fixing the problem :) ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:28:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Jan 2009 16:28:28 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <18782.15905.838842.10862@montanaro-dyndns-org.local>
Message-ID: <1230913712.9067.26.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If I dump the assembler code for ceval.c will that help others debug
> the problem?

Well, I'm no PPC expert but it can be useful. Can you dump it with "-S
-dA"?

(also, can you try the latest patch? I've made some tiny adjustement in
the opcode epilogues, I don't think it will make a difference but who
knows)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:34:09 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 16:34:09 +0000
Subject: [issue4800] little inaccuracy in Py_ssize_t explanation
In-Reply-To: <1230805955.17.0.970467276629.issue4800@psf.upfronthosting.co.za>
Message-ID: <1230914049.16.0.645708801602.issue4800@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the documentation is correct as it stands; the question is what
a "distinct memory location" is. Wrt. reference count, this surely
refers to pointers; each pointer is at least 4 bytes, and pointers are
four-aligned. So for N bits address space, there can be at most 2**(N-2)
pointers.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4800>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:38:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 16:38:12 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1230811305.7.0.402640242385.issue3959@psf.upfronthosting.co.za>
Message-ID: <495E42F1.9000906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> One point I will make is on licensing. netaddr is BSD, so you can do
> whatever you want with it and contribute as you see fit.

That is not sufficient for inclusion to Python. We also want support
from the author (along with a promise to eventually give up the external
project).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:40:41 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 02 Jan 2009 16:40:41 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230912587.9067.23.camel@localhost>
Message-ID: <495E4384.40100@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-02 17:10, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> This is safer than enabling the support unconditionally for GCC and
>> the SUN Pro C compiler, since it is rather likely that some GCC versions
>> have bugs which could render Python unusable if compiled with the
>> dispatching support enabled.
> 
> What do you mean, "unusable"? 

Well, not working. GCC versions often have optimizer bugs (esp. the
3.x series and early 4.x versions) and I wouldn't bet on them always
getting the dispatch optimizations right.

Trying to compile Python with an unconditionally enabled dispatch
patch on such a system would render Python unusable.

> 10% slower? Well, Python 3.x is already
> unusable (compared to 2.x) by that metric... Until now, only Skip has
> reported a slowdown on his PPC machine, while x86 systems have all seen
> a positive (if tiny, sometimes) improvement.
> 
> I fear that with a configure option, disabled by default, the code will
> get very poor testing and perhaps get broken in some subtle way without
> anyone noticing.

Like Skip said: the buildbots could take care of identifying such
problems.

People using the option would certainly report problems as well and
I'm sure that Linux distributions would compile Python with the switch
after verifying that their GCC version works correctly.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:41:28 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 02 Jan 2009 16:41:28 +0000
Subject: [issue4810] timeit needs "official" '--' flag
In-Reply-To: <18782.17333.839740.4416@montanaro-dyndns-org.local>
Message-ID: <18782.17333.839740.4416@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

Consider this timeit run:

    % python -m timeit '-1.0e-3 < -0.0001 < 1.0e-3'
    option -1 not recognized
    use -h/--help for command line help

As it turns out this works:

    % python -m timeit -- '-1.0e-3 < -0.0001 < 1.0e-3'
    10000000 loops, best of 3: 0.192 usec per loop

but the output using the -h flag doesn't report it as a possibility.  It
probably should.

----------
messages: 78838
nosy: skip.montanaro
severity: normal
status: open
title: timeit needs "official" '--' flag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4810>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:50:56 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 16:50:56 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1230847546.8.0.602549249733.issue4566@psf.upfronthosting.co.za>
Message-ID: <495E45ED.2010102@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Here's an option, though unfortunately not a trivial one:  use a private
> build of the C runtime.

I'm not sure whether the license allows us to do so.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 17:54:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 16:54:35 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1230915275.93.0.271973281722.issue4614@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's the policy for marking bug reports as critical? If the
description of the priority (Might block a future release) is normative,
why got this report marked critical? I don't think a documentation bug
can ever block a release.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:00:23 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Jan 2009 17:00:23 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1230915623.4.0.832045844571.issue4614@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm not suggesting that this should block a release (if that is the
definition of critical). I do however think this is critical for 3.x's
adoption and therefore should be of much importance to us.

----------
nosy: +benjamin.peterson
priority: critical -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:01:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 17:01:14 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1230915674.76.0.138353263276.issue4804@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As long as the CRT contains bogus assertions (that violate standard C),
I think Python rightfully should continue to disable assertions. If
applications desire assertions, they should explicitly turn them on
(provided there is an API to do so).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:08:26 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 02 Jan 2009 17:08:26 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230916106.3.0.455479805252.issue4796@psf.upfronthosting.co.za>


Steven D'Aprano <steve at pearwood.info> added the comment:

Mark wrote:
>> Also, why not just extend the Decimal() constructor to accept
>> a float as the argument? Why have a separate from_float() 
>> method at all?
>
> This was discussed extensively when the decimal module was 
> being proposed;  see the Decimal PEP for arguments against this.

I'm very aware of that. The Decimal PEP says the consensus was for 
from_float() to take a second argument specifying the precision. 
Decimal(1.1) => Decimal("1.1") was rejected for the reasons given in 
the PEP by Paul Moore, and Decimal(1.1) => 
Decimal('110000000000000008881784197001252...e-51') was (presumably) 
rejected because it would confuse newbies. Hence the decision to (1) 
make an alternative constructor and (2) have it take a second 
argument.

It looks like you and Raymond have rejected #2 but are keeping #1, and 
I'm curious why. That's genuine curiosity, and a real question, not a 
thinly-veiled scowl of disapproval disguised as a question :)

Anyway, I'm happy enough so long as Raymond's suggested 
Context.create_decimal() exists, that's the actual functionality I'm 
after, so maybe I should let you guys get on with it. Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:20:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 17:20:34 +0000
Subject: [issue4760] cmp gone---What's new in 3.1
In-Reply-To: <1230436607.02.0.835606741355.issue4760@psf.upfronthosting.co.za>
Message-ID: <1230916834.89.0.690211523373.issue4760@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Uhm ? The builtin cmp wasn't removed.

Non-removal of cmp for 3.0 was an oversight.  It *might* be removed in 
3.0.1.  See issue 1717.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4760>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:24:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 17:24:32 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1230917072.46.0.602903439883.issue4614@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm a bit worried about committers giving other committers priorities on
how they should work; as a principle, volunteers are free to work on
whatever they please, in whatever order they please.

So unassigning Georg.

----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:28:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 17:28:26 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230917306.67.0.0793953943984.issue4796@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It looks like you and Raymond have rejected #2 but are keeping #1

I'm not against #2, but I'm not particularly for it either.  In any case, 
once you've converted your float to Decimal it's trivial to round it to 
whatever precision you feel like, so #2 seems unnecessary to me.  -0.0.

I am -1.100000000000000088817841970012523233890533447265625 on any 
implementation of from_float (with or without keywords, defaults, etc.) 
for which Decimal.from_float(1.1) gives Decimal('1.1').

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:31:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Jan 2009 17:31:13 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1230917072.46.0.602903439883.issue4614@psf.upfronthosting.co.za>
Message-ID: <1afaf6160901020931h6d1df7d9tf77904c93abf133a@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Fri, Jan 2, 2009 at 11:24 AM, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> I'm a bit worried about committers giving other committers priorities on
> how they should work; as a principle, volunteers are free to work on
> whatever they please, in whatever order they please.

Of course.

>
> So unassigning Georg.

It would be really nice if there were some notes on use of the tracker.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:31:16 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 02 Jan 2009 17:31:16 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230915674.76.0.138353263276.issue4804@psf.upfronthosting.co.za>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F04D1883E4D@exchis.ccp.ad.local>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

We've had this discussion before, you know, 2006.
MS is asserting on preconditions that are undefined by the standard.
As such, they are not in violation.  In fact, it is foolish by us to invoke undefined behaviour, because it may, proverbially, result in the formatting of the hard drive :)

K

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:35:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Jan 2009 17:35:18 +0000
Subject: [issue4738] Patch to make zlib-objects better support threads
In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za>
Message-ID: <1230917718.96.0.322010051322.issue4738@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Checked in r68165. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4738>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:49:53 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 17:49:53 +0000
Subject: [issue4738] Patch to make zlib-objects better support threads
In-Reply-To: <1230136171.32.0.121363130694.issue4738@psf.upfronthosting.co.za>
Message-ID: <1230918593.99.0.066561675096.issue4738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@pitrou: You added "Also, the GIL is now released when computing the 
CRC of a large buffer." in the NEWS. The GIL released for crc32 but 
also for adler32.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4738>
_______________________________________

From report at bugs.python.org  Fri Jan  2 18:58:03 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 17:58:03 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1afaf6160901020931h6d1df7d9tf77904c93abf133a@mail.gmail.com>
Message-ID: <495E55A9.8060002@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It would be really nice if there were some notes on use of the tracker.

I think Brett has a vision here; you might ping him what the status
of that is.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Fri Jan  2 19:07:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Jan 2009 18:07:43 +0000
Subject: [issue4809] 2.5.4 release missing from python.org/downloads
In-Reply-To: <1230913095.06.0.854632300097.issue4809@psf.upfronthosting.co.za>
Message-ID: <1230919663.33.0.105254868138.issue4809@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Normally this bug tracker isn't meant for website problems (mail to
pydotorg at python.org instead), but since this is minor, I've fixed it
right now. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4809>
_______________________________________

From report at bugs.python.org  Fri Jan  2 19:11:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Jan 2009 18:11:07 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1230919867.72.0.97128542556.issue1717@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Doc/extending/newtypes.rst

  I'll fix this one after the patch has landed.

Misc/cheatsheet

  This needs a general overhaul.

Misc/python-mode.el

  I think this should be removed from the distribution; it's maintained
externally.

Parser/spark.py   # (I don't know what this does.  Anyone?)

  This is used by asdl_c.py which generates Python-ast.c -- it should be
updated.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Fri Jan  2 19:15:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 18:15:21 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F04D1883E4D@exchis.ccp.ad.local>
Message-ID: <495E59B6.10706@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> We've had this discussion before, you know, 2006.
> MS is asserting on preconditions that are undefined by the standard.
> As such, they are not in violation.

I remember, and you were already wrong back then :-)

MS asserts (in winsig.c) that the signal number in signal() is one
of the explicit list of supported or ignored signals; if it isn't,
it aborts. This is in violation to ISO C, 7.14.1.1p8, which specifies
that SIG_ERR must be returned and errno set.

It is true that Python *also* invokes undefined behavior in certain
cases; contributions to eliminate these are welcome.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 19:32:56 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Jan 2009 18:32:56 +0000
Subject: [issue4809] 2.5.4 release missing from python.org/downloads
In-Reply-To: <1230913095.06.0.854632300097.issue4809@psf.upfronthosting.co.za>
Message-ID: <1230921176.37.0.686148525204.issue4809@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

webmaster at python.org is better.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4809>
_______________________________________

From report at bugs.python.org  Fri Jan  2 19:51:34 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Jan 2009 18:51:34 +0000
Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <1230922294.34.0.497070247621.issue4472@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

10x cygwin is now not impacted.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Fri Jan  2 19:55:09 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 18:55:09 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230922509.44.0.38793838169.issue4751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New implementation of finer lock grain in _hashlibopenssl: only create 
the lock at the first update with more than 8 KB bytes. Object 
creation/deallocation is faster if we hash less than 8 KB.

Changes between hashopenssl_threads-4.diff and my new patch: fix the 
deadlock in ENTER_HASHLIB() (for the GIL) without speed change 
(because we don't change the GIL state if we don't use a lock).

Changes between py3k trunk and my new patch:
 - release the GIL with large byte string => faster with multiple CPUs
 - fix EVP_get_block_size() and EVP_get_digest_size(): the context was 
not protected by the lock!

Added file: http://bugs.python.org/file12541/hashlibopenssl_small_lock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 19:55:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 18:55:27 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230922527.35.0.443489898704.issue4751@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12459/hashopenssl_threads-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 20:02:01 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 19:02:01 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230922921.76.0.828266682073.issue4751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update small lock patch: replace all tabs by spaces! I forget a change 
between Python trunk and my patch: there is also the error message for 
Unicode object. Before:
   >>> import hashlib; hashlib.md5("abc")
   TypeError: object supporting the buffer API required
after:
   >>> import hashlib; hashlib.md5("abc")
   TypeError: Unicode-objects must be encoded before hashing

Added file: http://bugs.python.org/file12542/hashlibopenssl_small_lock-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 20:02:15 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 19:02:15 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230922935.41.0.442349846963.issue4751@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12541/hashlibopenssl_small_lock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 20:09:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Jan 2009 19:09:34 +0000
Subject: [issue4808] doc issue for threading module (name/daemon properties)
In-Reply-To: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>
Message-ID: <1230923374.65.0.789951399668.issue4808@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't understand -- both name and daemon are already documented on
their own.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4808>
_______________________________________

From report at bugs.python.org  Fri Jan  2 20:19:08 2009
From: report at bugs.python.org (Corey Goldberg)
Date: Fri, 02 Jan 2009 19:19:08 +0000
Subject: [issue4808] doc issue for threading module (name/daemon properties)
In-Reply-To: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>
Message-ID: <1230923948.55.0.326938770324.issue4808@psf.upfronthosting.co.za>


Corey Goldberg <cgoldberg at gmail.com> added the comment:

sorry for the confusion.  The doc might actually be correct, but it
seems ambiguous and confusing with respect to the name and daemon
properties.


if you look here:
http://docs.python.org/dev/py3k/library/threading.html

scroll down to where it says:

Thread.getName()
Thread.setName()
    Old API for name.

when you click on "name", it expands and shows you the 'name' property.
 However, it looks like it is denoting this as the "Old API".

at first glance it appears as though Thread.getName() and
Thread.setName() are the new way, and you can click on 'name' to see the
old API.  

I think the issue is actually the fact that Thread.name and
Thread.daemon are not expanded in the HTML doc until you click on their
names (unlike other properties/attributes in the doc which are already
expanded)

Let me know if I am not explaining well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4808>
_______________________________________

From report at bugs.python.org  Fri Jan  2 20:24:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Jan 2009 19:24:12 +0000
Subject: [issue4808] doc issue for threading module (name/daemon properties)
In-Reply-To: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>
Message-ID: <1230924252.66.0.472478852853.issue4808@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, I do see docs for name and daemon, directly below the respective
getter/setter entries.

For more clarity, I can only offer moving the getter/setter entries
below the property entries.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4808>
_______________________________________

From report at bugs.python.org  Fri Jan  2 20:25:05 2009
From: report at bugs.python.org (Corey Goldberg)
Date: Fri, 02 Jan 2009 19:25:05 +0000
Subject: [issue4808] doc issue for threading module (name/daemon properties)
In-Reply-To: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>
Message-ID: <1230924305.0.0.899066663558.issue4808@psf.upfronthosting.co.za>


Corey Goldberg <cgoldberg at gmail.com> added the comment:

Just took another look.  The doc is correct and already shows name and
daemon properties.

it was just confusing at first since where it says "Old API for name",
it links to the new style API and you jump to that section.

perhaps it could be stated more clearly?  If this is just a nit, please
close this issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4808>
_______________________________________

From report at bugs.python.org  Fri Jan  2 20:26:58 2009
From: report at bugs.python.org (Corey Goldberg)
Date: Fri, 02 Jan 2009 19:26:58 +0000
Subject: [issue4808] doc issue for threading module (name/daemon properties)
In-Reply-To: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>
Message-ID: <1230924418.34.0.0268528489113.issue4808@psf.upfronthosting.co.za>


Corey Goldberg <cgoldberg at gmail.com> added the comment:

yes if the new style was listed first, and the old style was below and
marked as "Old API", it would help with some confusion (like I ran into).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4808>
_______________________________________

From report at bugs.python.org  Fri Jan  2 20:51:25 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 02 Jan 2009 19:51:25 +0000
Subject: [issue1482122] Shift+Backspace exhibits odd behavior
Message-ID: <1230925885.32.0.569542752713.issue1482122@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I'm closing this as won't fix but let me tell what you can do to solve
the problem yourself (this may be added somewhere else then, like in the
tkinter wiki).

First, check the keysym you get when pressing Shift-BackSpace:

import Tkinter

def show_key(event):
    print event.keysym, event.keycode, hex(event.keysym_num)

root = Tkinter.Tk()
root.bind("<Key>", show_key)

root.mainloop()

While running this I pressed Shift-BackSpace, this is what I got:

Shift_L 50 0xffe1
Terminate_Server 22 0xfed5

You can clearly see that Shift-BackSpace is assigned to something else
here, Terminate_Server. You can confirm this by doing:

$ xmodmap -pk | grep 0xfed5

     22    	0xff08 (BackSpace)	0xfed5 (Terminate_Server)	0xff08
(BackSpace)	0xfed5 (Terminate_Server)	0xff08 (BackSpace)	0xfed5
(Terminate_Server)

The second field in this output indicates that when I press the key 22
(BackSpace) while holding shift, a Terminate_Server is sent. For more
information about xmodmap you should consult its documentation.
Then, to fix the initial problem you can do the following:

$ xmodmap -e "keycode 22 = BackSpace"

But then it may happen that you can no longer issue a Ctrl-Alt-BackSpace
to finalize your X (till you end this session and start another, since
nothing was permanently saved here). To solve this issue I suggest
checking conflicts between xkb and xmodmap.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1482122>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:10:30 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Jan 2009 20:10:30 +0000
Subject: [issue4808] doc issue for threading module (name/daemon properties)
In-Reply-To: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>
Message-ID: <1230927030.57.0.548975584742.issue4808@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, moved the old methods below the new properties in r68170.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4808>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:15:19 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 02 Jan 2009 20:15:19 +0000
Subject: [issue4811] invalid reST markup in several documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Several documents contain invalid reST markup that "leaks" into the 
html output (missing ``, incorrect indentation, etc.)
This patch fixes the obvious ones.

----------
assignee: georg.brandl
components: Documentation
files: invalid-doc-markup.diff
keywords: patch
messages: 78866
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: invalid reST markup in several documents
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12543/invalid-doc-markup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4811>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:16:42 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 20:16:42 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1230927402.79.0.859128453563.issue2827@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed in r68022.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:20:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Jan 2009 20:20:16 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1230927616.68.0.542696236314.issue4614@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Attaching a doc patch -- Martin, could you please confirm that I didn't
write nonsense?

----------
assignee:  -> loewis
keywords: +patch
Added file: http://bugs.python.org/file12544/new-module-apis.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:23:05 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 02 Jan 2009 20:23:05 +0000
Subject: [issue1482122] Shift+Backspace exhibits odd behavior
Message-ID: <1230927785.5.0.53380861438.issue1482122@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Just for future reference it is now on
http://tkinter.unpy.net/wiki/Linux_Shift-Backspace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1482122>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:25:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Jan 2009 20:25:39 +0000
Subject: [issue4811] invalid reST markup in several documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1230927939.23.0.0377056525462.issue4811@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Many thanks! Applied in r68171.

Did you find those yourself, or with some sort of tool?

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4811>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:26:58 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 02 Jan 2009 20:26:58 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230928018.0.0.899207248331.issue4753@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

OK, I think I'm misreading the output of pybench.  Let me reset.  Ignore
anything I've written previously on this topic.  Instead, I will just
post the output of my pybench comparison runs and let more expert people
interpret as appropriate.  The first file is the result of the run on
PowerPC (Mac G5).

Added file: http://bugs.python.org/file12545/pybench.sum.PPC

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:27:55 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 02 Jan 2009 20:27:55 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230928075.39.0.719545310432.issue4753@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

The next is the result of running on my MacBook Pro (Intel Core 2 Duo).

Added file: http://bugs.python.org/file12546/pybench.sum.Intel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:33:18 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 20:33:18 +0000
Subject: [issue4075] Use WCHAR variant of OutputDebugString
In-Reply-To: <1223471607.48.0.166278298943.issue4075@psf.upfronthosting.co.za>
Message-ID: <1230928398.93.0.891352801504.issue4075@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r68172.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4075>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:40:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 20:40:32 +0000
Subject: [issue4051] UNICODE macro in cPickle conflicts with Windows define
In-Reply-To: <1223288926.88.0.428745871562.issue4051@psf.upfronthosting.co.za>
Message-ID: <1230928832.18.0.890643259267.issue4051@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r68173.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4051>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:44:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 20:44:15 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230929055.51.0.462955688035.issue4796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> once you've converted your float to Decimal it's trivial 
> to round it to whatever precision you feel like, so #2 
> seems unnecessary to me.

Agree with Mark on how to control rounding.  The DecimalWay(tm) is that
used by Context.create_decimal().  A second argument is problematic for
two reasons.  First, it demands that some rounding take place but
doesn't let you control the rounding method or signal an Inexact
conversion -- you need a context for that.  Second, the API for decimal
is already somewhat complex and we don't want to make it worse by
introducing a new variant with a second argument that has no parallel
elsewhere in the API.

Also agree with Mark regarding Decimal.from_float() which needs to be
lossless and exact.  It parallels fractions.from_float() which does the
same thing for rationals.

The DecimalWay(tm) is to have Decimal constructors be exact and to use
Context based constructors when rounding is desired.

I'll submit a patch to this effect (unless someone beats me to it).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Fri Jan  2 21:57:15 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 02 Jan 2009 20:57:15 +0000
Subject: [issue1135] xview/yview of Tix.Grid is broken
In-Reply-To: <1189314445.29.0.484479560219.issue1135@psf.upfronthosting.co.za>
Message-ID: <1230929835.46.0.72373290614.issue1135@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I would actually prefer to move xview and yview method to classes like
it was done in xview_yview.patch (I've done this on a personal branch
some time ago too, but named them as XScroll, YScroll), we can see they
are used in several places in Tkinter, Tix and other extensions, and we
are just duplicating code for them all the time.

Also, what I would prefer to see in place of this:

if not args:
    return self._getdoubles(self.tk.call(self._w, 'xview'))
self.tk.call((self._w, 'xview') + args)

would be this:

res = self.tk.call(self._w, 'xview', *args)
if args:
    return self._getdoubles(res)

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1135>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:04:18 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Fri, 02 Jan 2009 21:04:18 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1230930258.88.0.618289224688.issue2827@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

Thank you. Not sure, what to do now, cause the putting down of IDLE is
fixed, but still within IDLE I get wrong output:

x="?????????"
print (x)

>>> 
??????????????????

when running this script under python command line form another editor,
I get the output readable as expected. Shall I open another issue?

Added file: http://bugs.python.org/file12547/q.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:18:58 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 02 Jan 2009 21:18:58 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230931138.88.0.294171668038.issue4791@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:21:33 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 21:21:33 +0000
Subject: [issue4615] de-duping function in itertools
In-Reply-To: <1228877279.97.0.446063330744.issue4615@psf.upfronthosting.co.za>
Message-ID: <1230931293.65.0.860904659412.issue4615@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Added recipes to the itertools docs: r68177 .

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4615>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:28:38 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 02 Jan 2009 21:28:38 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230931718.61.0.230637741805.issue4791@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I'm unable to reproduce the issue.
Could you please repeat the test by using the "timeout" parameter as 
such?

< ftp = ftplib.FTP('ftp.edgecastcdn.net', user='theusername', 
passwd='thepassword')
> ftp = ftplib.FTP('ftp.edgecastcdn.net', user='theusername', 
passwd='thepassword', timeout=2)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:30:43 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 02 Jan 2009 21:30:43 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1230931843.41.0.170339991371.issue4608@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Jakub,

I have attached a revision to the patch.
You are right, when __iter__ returns self.fp (as in previous patch), the
__next__ is superflous. 
But, I was thinking of __iter__ returning an instance of addbase,
instead of self.fp and in that case __next__ was required. But I see
that i had not changed self.fp to self. 

This is implemented in the similar lines of  IOBase class, io.py
w.r.t to your other comment, why do you think __next__ implementation is
incorrect?

Thanks,
Senthil

Added file: http://bugs.python.org/file12548/issue4608_py31-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:38:53 2009
From: report at bugs.python.org (David Watson)
Date: Fri, 02 Jan 2009 21:38:53 +0000
Subject: [issue3023] Problem with invalidly-encoded command-line arguments
	(Unix)
In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za>
Message-ID: <1230932333.8.0.834610747321.issue3023@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

@ Victor Stinner: Yes, the behaviour of those functions is as you
describe - it's been changed since I filed this issue.  I do
consider it an improvement.

By the password database, I mean /etc/passwd or replacements that
are accessible via getpwnam() and friends.  Users are often
allowed to change things like the GECOS field, and can generally
stick any old junk in there, regardless of encoding.  Now that I
come to check, it seems that in the Python 3.0 release, the pwd.*
functions do raise UnicodeDecodeError when the GECOS field can't
be decoded (bizarrely, they try to interpret it as a Python
string literal, and thus choke on invalid backslash escapes).
Unfortunately, this allows a user to change their GECOS field so
that system programs written in Python can't determine the
username corresponding to that user's UID or vice versa.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3023>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:47:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 21:47:37 +0000
Subject: [issue1402289] Allow mappings as globals (was: Fix dictionary
	subclass ...)
Message-ID: <1230932857.05.0.568650957078.issue1402289@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Haven't had a chance to work on this one.  Unassigning.

----------
assignee: rhettinger -> 
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1402289>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:49:10 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 21:49:10 +0000
Subject: [issue980098] Module to dynamically generate structseq objects
Message-ID: <1230932950.11.0.29731648397.issue980098@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I agree with Georg.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue980098>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:49:34 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 21:49:34 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple
	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1230932974.45.0.668064921108.issue1820@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:50:18 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 21:50:18 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1230933018.43.0.382707755139.issue1533@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:50:48 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Jan 2009 21:50:48 +0000
Subject: [issue4793] Glossary incorrectly describes a decorator as "merely
	syntactic sugar"
In-Reply-To: <1230749976.35.0.878652242005.issue4793@psf.upfronthosting.co.za>
Message-ID: <1230933048.07.0.185859184631.issue4793@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Based on my reading of the pydev discussion, the doc correctly describes
the design intent.  If there is any bug, it is in the optimization of
skipping the apparently redundant first name binding.  I presume the
thinking was that since the decorator gets the function as an input,
there is no sensible need to access it again via its name.  A conforming
implementation should be free to not do this optimization, but to simply
make the easy and obvious translation.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4793>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:51:17 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Fri, 02 Jan 2009 21:51:17 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1230933077.65.0.529321541026.issue2827@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

Moreover: do you think its good idea to change the file encoding at
opened and then saved file without any question when there is no
encoding declaration? :-( Users do not edit just python programs, they
can edit also config files, text files, etc ....

It could be that at first saving we are asked to use 
*utf8 
*used one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:51:31 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Jan 2009 21:51:31 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1230933091.47.0.0538773739319.issue4705@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Instead of importing IO each time in create_stdio, maybe you should just
pass io.open to create_stdio.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:55:35 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Jan 2009 21:55:35 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1230933335.0.0.754245099986.issue2827@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Well, if you're still using 3.0, it's not patched yet. :)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Fri Jan  2 22:57:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 21:57:43 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1230930258.88.0.618289224688.issue2827@psf.upfronthosting.co.za>
Message-ID: <495E8DD5.7060806@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Thank you. Not sure, what to do now, cause the putting down of IDLE is
> fixed, but still within IDLE I get wrong output:

In general, when a reported issue is closed, and you have a further
issue, the right thing is to report this as a new issue, rather than
following up on closed one.

In the specific case, I believe you are referring to issue 4008, and
its duplicates #4410, and #4623. There might be more duplicate reports,
so no need to report yet another one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:02:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 22:02:30 +0000
Subject: [issue3023] Problem with invalidly-encoded command-line arguments
	(Unix)
In-Reply-To: <1230932333.8.0.834610747321.issue3023@psf.upfronthosting.co.za>
Message-ID: <495E8EF4.6050006@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> By the password database, I mean /etc/passwd or replacements that
> are accessible via getpwnam() and friends. 

Please only discuss one issue at the time in the bug tracker. This
issue is about "invalidly-encoded command-line arguments", not about
the password database. If you want to report an issue with the password
database, please do so in a separate report.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3023>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:05:59 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 22:05:59 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230933959.46.0.424643093509.issue4566@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12537/bug4566.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:07:24 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 22:07:24 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230934044.57.0.32856162272.issue4566@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Uploading a corrected patch; some old docs I saw said DWORD, and I
obviously neglected to fix every spot I used that, and I've changed
'Vista' to 'XP' in the patch comments.

Added file: http://bugs.python.org/file12549/bug4566.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:08:13 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 22:08:13 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1230933077.65.0.529321541026.issue2827@psf.upfronthosting.co.za>
Message-ID: <495E9049.3030509@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Moreover: do you think its good idea to change the file encoding at
> opened and then saved file without any question when there is no
> encoding declaration?

See my previous comment: one issue at a time. This issue was about
code that IDLE 3.0a5 cannot parse, but IDLE 3.0 can. If you have
a further issue with the proposed solution, please report it separately.

> Users do not edit just python programs, they
> can edit also config files, text files, etc ....

I don't think IDLE was designed to support editing any other files.
I would be opposed to adding user interface relevant only for editing
non-Python text files. If IDLE would assume a different encoding at save
time than was assumed at load time, this might be still considered
a bug; you would need to provide detailed instructions to reproduce
such a bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:21:28 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 22:21:28 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1230934888.56.0.34612443196.issue4804@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Can anyone point me at a test that failed in this case?  A quick look
over winsig.c shows no asserts.  I didn't compare the vs2005 crt source
though, so its highly likely I just missed it...

On the broader point, it could be argued that if it is the apps
responsibility to re-enable assertions, it is also the apps
responsibility to disable them in the first place.  If other libraries
on the system attempted the same as Python, it would obviously be
undefined if Python's attempt had any actual affect - the last called
would win.  As we found with the old locale() issues, we really can't
rely on Python setting a global shared state to keep things nice.  From
a pragmatic POV, if we know the MS crt asserts on certain constants
signal numbers, can't we just avoid passing those numbers?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:31:05 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 22:31:05 +0000
Subject: [issue4812] Junk in the decimals namespace
In-Reply-To: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>
Message-ID: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

In r59144 , a bunch of internal-use constants were dumped in the main
namespace.  These all need to be prefixed with an underscore.  

They should be fixed right-away before people start using them.  Since
they are externally undocumented and since the internal notes describe
them as being only for internal-use, I think this can go in as a bugfix.

----------
assignee: facundobatista
components: Library (Lib)
messages: 78893
nosy: facundobatista, rhettinger
priority: high
severity: normal
status: open
title: Junk in the decimals namespace
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4812>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:35:13 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 22:35:13 +0000
Subject: [issue4812] Junk in the decimals namespace
In-Reply-To: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>
Message-ID: <1230935713.04.0.736686900254.issue4812@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, it looks like r59144 merely moved these around and that they
existed beforehand.  Can we go ahead and get them renamed?  They are
defeating the extensive efforts we've made to keep that namespace free
of anything that isn't part of the documented spec.

----------
assignee: facundobatista -> marketdickinson
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4812>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:35:32 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 02 Jan 2009 22:35:32 +0000
Subject: [issue1581476] Text search gives bad count if called from variable
	trace
Message-ID: <1230935732.8.0.763589014286.issue1581476@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Fixed the issue now.
_tkinter.call needs to use the TCL_EVAL_GLOBAL flag since all the
variables in Tkinter are global variables.

Matthias: your issue about the pattern should be placed in a different
issue.

----------
keywords: +patch
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.4
Added file: http://bugs.python.org/file12550/issue_1581476.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581476>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:45:18 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 02 Jan 2009 22:45:18 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230936318.78.0.61097220207.issue4751@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

First:  thanks for doing this.  I've had a patch sitting in my own
sandbox to release the GIL while hashing for a while but I hadn't
finished testing it.  It looks pretty similar to what you've done so
lets go with the patch being developed in this issue.

Rather than making HASHLIB_GIL_MINSIZE a constant I suggest making it a
property of the hash object so that it can be set by the user.  Most
users will be fine with the default but depending upon the application,
platform and hash algorithm being used other values may make more sense.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:50:04 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 02 Jan 2009 22:50:04 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230934888.56.0.34612443196.issue4804@psf.upfronthosting.co.za>
Message-ID: <495E9A18.4060706@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Can anyone point me at a test that failed in this case?

See issue 1350409 (and subsequently #1167262 and #1311784). Python
fails to start when assertions are turned on (haven't tested for
VS 2008, though).

If you were looking for a test case that fails specifically - there
might none. However, try Amaury's example.

> On the broader point, it could be argued that if it is the apps
> responsibility to re-enable assertions, it is also the apps
> responsibility to disable them in the first place.

Ideally, assertions should be enabled in debug builds, and disabled
in release builds, and there should be no runtime configuration.
Unfortunately, Microsoft chose to add bogus assertions, so this general
rule is useless within the context of MSC.

(it's not just that the signal issue is a standards violation. Assuming
that _close apparently follows POSIX close, it should always set
errno to EBADF for a double-close, rather than raising an assertion. It
is conforming in release mode, but loses conformance in debug mode)

> From
> a pragmatic POV, if we know the MS crt asserts on certain constants
> signal numbers, can't we just avoid passing those numbers?

It's the other way 'round: it rejects all but a list of known signals.
Still, it would be possible to hack around - one such hack is currently
implemented.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Fri Jan  2 23:57:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Jan 2009 22:57:08 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230928018.0.0.899207248331.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230937035.9067.29.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> OK, I think I'm misreading the output of pybench.  Let me reset.  Ignore
> anything I've written previously on this topic.  Instead, I will just
> post the output of my pybench comparison runs and let more expert people
> interpret as appropriate.  The first file is the result of the run on
> PowerPC (Mac G5).

Ok, so the threaded version is actually faster by 20% on your PPC, and
slower by 5% on your Core 2 Duo. Thanks for doing the measurements!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:03:16 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 02 Jan 2009 23:03:16 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230937035.9067.29.camel@localhost>
Message-ID: <18782.40240.905009.93554@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> Ok, so the threaded version is actually faster by 20% on your
    Antoine> PPC, and slower by 5% on your Core 2 Duo. Thanks for doing the
    Antoine> measurements!

Confirmed by pystone runs as well.  Sorry for the earlier misdirection.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:09:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 23:09:42 +0000
Subject: [issue4812] Junk in the decimals namespace
In-Reply-To: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>
Message-ID: <1230937782.56.0.368028704047.issue4812@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I assume you're referring to Dec_0 and friends?

Fixed in the trunk in r68182.  Leaving open until I get the chance to 
merge it to the other branches.

----------
resolution:  -> fixed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4812>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:22:47 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 23:22:47 +0000
Subject: [issue4812] Junk in the decimals namespace
In-Reply-To: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>
Message-ID: <1230938567.04.0.760106519475.issue4812@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks.  BTW, my preferred new names are _One _Zero and _NegativeOne.
Names like dec_n1 are cryptic in places other than where they're defined.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4812>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:34:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Jan 2009 23:34:04 +0000
Subject: [issue4812] Junk in the decimals namespace
In-Reply-To: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>
Message-ID: <1230939244.65.0.95874288202.issue4812@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fine.  Will re-rename in the morning.  Are _Inf, _negInf, _NaN and 
_Infsign okay as they are?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4812>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:36:50 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 02 Jan 2009 23:36:50 +0000
Subject: [issue4811] invalid reST markup in several documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1230939410.1.0.996980305751.issue4811@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I did a search on the .html files using a regular expression, and 
manually filtered out the false positives.
The expression used was this "::[^=]|:[a-zA-Z][a-zA-Z0-9]+|`|\.\.\s*\w
+:"
I'll try to come up with a useable tool.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4811>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:42:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 23:42:19 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1230939739.49.0.772930011382.issue4705@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12477/unbufferedstdout-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:50:06 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 02 Jan 2009 23:50:06 +0000
Subject: [issue4813] On OS-X the directories searched by setup.py for Tk are
	in the wrong order.
In-Reply-To: <1230940206.74.0.201449731913.issue4813@psf.upfronthosting.co.za>
Message-ID: <1230940206.74.0.201449731913.issue4813@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In function detect_tkinter_darwin of setup.py framework_dirs should be 
the reverse of what it is: first the user's library should be searched, 
then /Library, and finally /System/Library.  If Tk 8.5 is installed in 
/Library or ~/Library make will otherwise find the headers from 8.4 but 
the libraries from 8.5.

Issue 4017 discusses this problem, among others, and is marked fixed, 
but it is still incorrect in the 2.6 and 3.0 downloads as well as in the 
trunk, 3.0, and 3.1 subversion repositories.  It may have been "fixed" 
in so far as someone was able to make a .dmg by manually altering 
setup.py, and that's great, but it isn't fixed in the source and the 
problem will reappear with each new version.

----------
components: Build
messages: 78904
nosy: MLModel
severity: normal
status: open
title: On OS-X the directories searched by setup.py for Tk are in the wrong order.
type: compile error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4813>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:50:56 2009
From: report at bugs.python.org (ebfe)
Date: Fri, 02 Jan 2009 23:50:56 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230940256.41.0.926530895119.issue4751@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

I don't think so.

The interface should stay simple - python has very few such magic knobs.
People will optimize for their own box as you said - and that code will
run worse on all the others...

Besides, we've lived so long with single-threaded openssl. Let's make
HASHLIB_GIL_MINSIZE such that there is no risk of additional overhead
introduced by this patch and refer to it's current value in the
hashlib-module's documentation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 00:58:49 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Jan 2009 23:58:49 +0000
Subject: [issue3023] Problem with invalidly-encoded command-line arguments
	(Unix)
In-Reply-To: <1230932333.8.0.834610747321.issue3023@psf.upfronthosting.co.za>
Message-ID: <200901030059.16522.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> By the password database, I mean /etc/passwd or replacements that
> are accessible via getpwnam() and friends.  Users are often
> allowed to change things like the GECOS field, and can generally
> stick any old junk in there, regardless of encoding.

I started to patch pwd module to return bytes instead of unicode, but I didn't 
finished my work and the lost it :-/ Today, most UNIX uses UTF-8 as the 
default charset. About GECOS: is it really used? If you have real problems, 
open a new issue as proposed by Martin.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3023>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:01:56 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Jan 2009 00:01:56 +0000
Subject: [issue4812] Junk in the decimals namespace
In-Reply-To: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>
Message-ID: <1230940916.05.0.127989267364.issue4812@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Let's spell them out:  _Infinity, _NegativeInfinity, _NaN, and
_SignedInfinity.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4812>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:13:26 2009
From: report at bugs.python.org (pmoody)
Date: Sat, 03 Jan 2009 00:13:26 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <495E42F1.9000906@v.loewis.de>
Message-ID: <8517e9350901021613m44082a53g3676652612693fc1@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

> That is not sufficient for inclusion to Python. We also want support
> from the author (along with a promise to eventually give up the external
> project).

As Guido had mentioned in a previous message, this is along the lines
of my thinking wrt ipaddr.

Cheers,
/peter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:32:11 2009
From: report at bugs.python.org (ebfe)
Date: Sat, 03 Jan 2009 00:32:11 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230942731.86.0.427818216077.issue4751@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

haypo, the patch will not compile when WITH_THREADS is not defined. The
'lock'-member in the object structure is not present without
WITH_THREADS however the line 'if (self->lock == NULL && view.len >=
HASHLIB_GIL_MINSIZE)' will always refer to it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:45:29 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 03 Jan 2009 00:45:29 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230943529.41.0.969700026517.issue4753@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The patch make a huge difference on 64-bit Linux. I get a 20% speed-up
and the lowest run time so far. That is quite impressive!

At first glance, it seems the extra registers of the x86-64 architecture
permit GCC to avoid spilling registers onto the stack (see assembly just
below). However, I don't know why the speed up due to the patch is much
more significant on x86-64 than on x86.

This is the x86 assembly generated by GCC 4.3 (annotated and
slightly edited for readability):

    movl    -440(%ebp), %eax  # tmp = next_instr
    movl    $145, %esi        # opcode = LIST_APPEND
    movl    8(%ebp), %ecx     # f
    subl    -408(%ebp), %eax  # tmp -= first_instr
    movl    %eax, 60(%ecx)    # f->f_lasti = tmp
    movl    -440(%ebp), %ebx  # next_instr
    movzbl  (%ebx), %eax      # tmp = *next_instr
    addl    $1, %ebx          # next_instr++
    movl    %ebx, -440(%ebp)  # next_instr
    movl    opcode_targets(,%eax,4), %eax  # tmp = opcode_targets[tmp]
    jmp     *%eax             # goto *tmp


And this is the x86-64 assembly generated also by GCC 4.3:

    movl    %r15d, %eax      # tmp = next_instr
    subl    76(%rsp), %eax   # tmp -= first_instr
    movl    $145, %ebp       # opcode = LIST_APPEND
    movl    %eax, 120(%r14)  # f->f_lasti = tmp
    movzbl  (%r15), %eax     # tmp = *next_instr
    addq    $1, %r15         # next_instr++
    movq    opcode_targets(,%rax,8), %rax  # tmp = opcode_targets[tmp]
    jmp     *%rax            # goto *tmp


The above assemblies are equivalent to the following C code:

    opcode = LIST_APPEND;
    f->f_lasti = ((int)(next_instr - first_instr));
    goto *opcode_targets[*next_instr++];

On the register-starved x86 architecture, the assembly has 4 stack load
and 1 store operations. While on the x86-64 architecture, most variables
are kept in registers thus it only uses 1 stack store operation. And
from what I saw from the assemblies, the extra registers with the
traditional switch dispatch aren't much used, especially with the opcode
prediction macros which avoid manipulations of f->f_lasti.

That said, I am glad to hear the patch makes Python on PowerPC faster,
because this supports the hypothesis that extra registers are better
used with indirect threading (PowerPC has 32 general-purpose registers).

Added file: http://bugs.python.org/file12551/amd-athlon64-x2-64bit-pybench.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:48:08 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 03 Jan 2009 00:48:08 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230943688.13.0.0315157723558.issue4753@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

One more thing, the patch causes the following warnings to be emited by
GCC when USE_COMPUTED_GOTOS is undefined.  

Python/ceval.c: In function ?PyEval_EvalFrameEx?:
Python/ceval.c:2420: warning: label ?_make_function? defined but not used
Python/ceval.c:2374: warning: label ?_call_function_var_kw? defined but
not used
Python/ceval.c:2280: warning: label ?_setup_finally? defined but not used

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:52:14 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 03 Jan 2009 00:52:14 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

When using the optional ftplib.FTP()'s timeout parameter which 
specifies a timeout in seconds for blocking operations like the 
connection attempt, it is applied on both FTP control and passive data 
channel (if any).
It is not applied for active (PORT/EPRT) data connections.
The patch in attachment modifies ftplib so that when ntransfer method 
is called in active mode, timeout is applied on the resulting data 
connection.

----------
files: ftplib.patch
keywords: patch
messages: 78912
nosy: giampaolo.rodola
severity: normal
status: open
title: ftplib does not honour "timeout" parameter for active data connections
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12552/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:53:26 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 00:53:26 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230944006.66.0.53357007636.issue4751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About HASHLIB_GIL_MINSIZE, I'm unable to mesure the overhead. I tried 
timeit with 8190 and 8200 but the results are *very* close. I'm 
running Linux, it's maybe different on other OS.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:56:09 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Sat, 03 Jan 2009 00:56:09 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230944169.64.0.808282817298.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

Per Giampaolo's suggestion, I added the timeout. Program listing and
output below:

-----begin listing----
import ftplib

ftp = ftplib.FTP('ftp.edgecastcdn.net', user='theusername',
passwd='thepassword', timeout=2)
ftp.set_debuglevel(3)
ftp.cwd('chrismahan-675')
ftp.dir()
#ftp.retrlines('LIST')
ftp.close()
----end listing----

*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,172,22).\n'
*resp* '227 Entering Passive Mode (72,21,82,190,172,22).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\n'
*resp* '150 Opening ASCII mode data connection for file list'
*retr* '-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski
Beat - Why.mp3\n'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
*retr* '-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi\n'
-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi
*retr* '-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28
test9_lg.wmv\n'
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28
test9_lg.wmv.jpg\n'
-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28 test9_lg.wmv.jpg
*retr* '-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04
test9_med.flv\n'
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04
test9_med.flv.jpg\n'
-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04 test9_med.flv.jpg
*retr* '-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53
test9_sm.flv\n'
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53
test9_sm.flv.jpg\n'
-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53 test9_sm.flv.jpg
*retr* ''
Traceback (most recent call last):
  File "C:\python_scripts\python3\candee_processor.py", line 6, in <module>
    ftp.dir()
  File "c:\python30\lib\ftplib.py", line 511, in dir
    self.retrlines(cmd, func)
  File "c:\python30\lib\ftplib.py", line 433, in retrlines
    return self.voidresp()
  File "c:\python30\lib\ftplib.py", line 225, in voidresp
    resp = self.getresp()
  File "c:\python30\lib\ftplib.py", line 211, in getresp
    resp = self.getmultiline()
  File "c:\python30\lib\ftplib.py", line 197, in getmultiline
    line = self.getline()
  File "c:\python30\lib\ftplib.py", line 184, in getline
    line = self.file.readline()
  File "C:\Python30\lib\io.py", line 1813, in readline
    while self._read_chunk():
  File "C:\Python30\lib\io.py", line 1560, in _read_chunk
    input_chunk = self.buffer.read1(self._CHUNK_SIZE)
  File "C:\Python30\lib\io.py", line 994, in read1
    self._peek_unlocked(1)
  File "C:\Python30\lib\io.py", line 981, in _peek_unlocked
    current = self.raw.read(to_read)
  File "C:\Python30\lib\io.py", line 575, in read
    n = self.readinto(b)
  File "C:\Python30\lib\socket.py", line 214, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:59:21 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 03 Jan 2009 00:59:21 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230944361.69.0.636552690846.issue4753@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Alexandre's last comment reminded me I forgot to post the PPC assembler
code.  Next two files are the output as requested by Antoine.

Added file: http://bugs.python.org/file12553/ceval.i.unthreaded

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 01:59:55 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 00:59:55 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230944395.46.0.462879597401.issue4751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> haypo, the patch will not compile when WITH_THREADS is not defined.

Ooops, fixed (patch version 3).

Added file: http://bugs.python.org/file12554/hashlibopenssl_small_lock-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:00:51 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 03 Jan 2009 01:00:51 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230944451.66.0.545711575541.issue4753@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Added file: http://bugs.python.org/file12555/ceval.i.threaded

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:13:48 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Jan 2009 01:13:48 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1230945228.36.0.298587550738.issue4626@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is what I have found out so far.
Python/bltinmodule.c:builtin_compile takes in a PyObject and gets the
char * representation of that object and passes it to
Python/pythonrun.c:Py_CompileStringFlags. Unfortunately no other
information is passed along in the call, including what the encoding
happens to be. This is unfortunate as builtin_compile makes sure that
the char* data is encoded using the default encoding before calling
Py_CompileStringFlags.

I just tried setting a PyCF flag to denote that the char* data is
encoded using the default encoding, but Parser/tokenizer.c is not
compiled against unicodeobject.c and thus one cannot use
PyUnicode_GetDefaultEncoding() to know what the data is stored as.

I'm going to try to explicitly convert to UTF-8 and see if that works.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:14:59 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 01:14:59 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230945299.15.0.911506327915.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The traceback shows that the problem is not related to the socket 
created to retrieve the content of the directory listing, but 
the "main" socket (the one used for the whole ftp session) used by 
dir() command the retrieve the command answer code:

   Traceback (most recent call last):
     ftp.dir()
      => self.retrlines(cmd, func)
      => return self.voidresp()
      => line = self.getline()
      => line = self.file.readline() (ftplib.py:184)
      ...
    socket.timeout: timed out

I don't understand why the readline() blocks. It's maybe related to 
the newline: voidresp() uses getline() which reads a line using 
self.file. The file is created by self.sock.makefile('r', 
encoding=self.encoding) and so the newline is always \n whereas ftplib 
of Python2 uses \r\n (CRLF) or \n (LF).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:16:14 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 01:16:14 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230945374.26.0.14459869644.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Christopher: Can you paste the full output with debuglevel=3 of Python 
2.x (python2.5)?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:36:37 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Sat, 03 Jan 2009 01:36:37 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1230946597.86.0.515334893136.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

When running scritp with python 2.5.4, got this error. I'll remove the
"timeout=2" and run again. see below.

Traceback (most recent call last):
  File "C:\python_scripts\python3\candee_processor.py", line 3, in <module>
    ftp = ftplib.FTP('ftp.edgecastcdn.net',
user='client1 at arcostream.com', passwd='1210184520', timeout=2)
TypeError: __init__() got an unexpected keyword argument 'timeout'

Same without the timeout argument:

>>> 
*cmd* 'CWD chrismahan-675'
*put* 'CWD chrismahan-675\r\n'
*get* '250 CWD command successful\r\n'
*resp* '250 CWD command successful'
*cmd* 'TYPE A'
*put* 'TYPE A\r\n'
*get* '200 Type set to A\r\n'
*resp* '200 Type set to A'
*cmd* 'PASV'
*put* 'PASV\r\n'
*get* '227 Entering Passive Mode (72,21,82,190,228,195).\r\n'
*resp* '227 Entering Passive Mode (72,21,82,190,228,195).'
*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Opening ASCII mode data connection for file list\r\n'
*resp* '150 Opening ASCII mode data connection for file list'
*retr* '-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski
Beat - Why.mp3\r\n'
-rwxrwxrwx   1 nobody   nogroup   3905538 Dec 29 09:51 Bronski Beat -
Why.mp3
*retr* '-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53
test9.avi\r\n'
-rwxrwxrwx   1 nobody   nogroup    873966 Dec 28 13:53 test9.avi
*retr* '-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28
test9_lg.wmv\r\n'
-rwxrwxrwx   1 nobody   nogroup   2512653 Dec 29 08:28 test9_lg.wmv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28
test9_lg.wmv.jpg\r\n'
-rwxrwxrwx   1 nobody   nogroup      6549 Dec 29 08:28 test9_lg.wmv.jpg
*retr* '-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04
test9_med.flv\r\n'
-rwxrwxrwx   1 nobody   nogroup   1788466 Dec 29 03:04 test9_med.flv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04
test9_med.flv.jpg\r\n'
-rwxrwxrwx   1 nobody   nogroup      6394 Dec 29 03:04 test9_med.flv.jpg
*retr* '-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53
test9_sm.flv\r\n'
-rwxrwxrwx   1 nobody   nogroup   1263041 Dec 28 13:53 test9_sm.flv
*retr* '-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53
test9_sm.flv.jpg\r\n'
-rwxrwxrwx   1 nobody   nogroup      6465 Dec 28 13:53 test9_sm.flv.jpg
*retr* ''
*get* '226 Transfer complete\r\n'
*resp* '226 Transfer complete'
>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:37:18 2009
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 03 Jan 2009 01:37:18 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230943529.41.0.969700026517.issue4753@psf.upfronthosting.co.za>
Message-ID: <495EC14C.7010405@cheimes.de>


Christian Heimes <lists at cheimes.de> added the comment:

> Alexandre Vassalotti <alexandre at peadrop.com> added the comment:
> The patch make a huge difference on 64-bit Linux. I get a 20% speed-up
> and the lowest run time so far. That is quite impressive!

I'm really, REALLY impressed by the speed up. Good work!

I'm not an expert in this kind of optimizations. Could we gain more
speed by making the dispatcher table more dense? Python has less than
128 opcodes (len(opcode.opmap) == 113) so they can be squeezed in a
smaller table. I naively assume a smaller table increases the amount of
cache hits.

Christian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:40:12 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 01:40:12 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1230946812.36.0.388326745255.issue4705@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Instead of importing IO each time in create_stdio, 
> maybe you should just pass io.open to create_stdio

create_stdio() uses io.open() but also io.TextIOWrapper. Since io 
module is already imported in initstdio(), I updated the patch to just 
pass the pointer to the module to create_stdio().

Added file: http://bugs.python.org/file12556/unbufferedstdout-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:40:16 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 01:40:16 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1230946816.67.0.615037870769.issue4705@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12478/unbufferedstdout-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Sat Jan  3 02:51:47 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sat, 03 Jan 2009 01:51:47 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230947507.57.0.625781170189.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

About miscompilations: the current patch is a bit weird for GCC, because
you keep both the switch and the computed goto.

But actually, there is no case in which the switch is needed, and
computed goto give less room to GCC's choices.

So, can you try dropping the switch altogether, using always computed
goto and seeing how does the resulting code get compiled? I see you'll
need two labels (before and after argument fetch) per opcode and two
dispatch tabels, but that's no big deal (except for code alignment -
align just the common branch target).

An important warning is that by default, on my system, GCC 4.2 aligns
branch targets for switch to a 16-byte boundary (as recommended by the
Intel optimization guide), by adding a ".p2align 4,,7" GAS directive,
and it does not do that for computed goto.

Adding the directive by hand gave a small speedup, 2% I think; I should
try -falign-jumps=16 if it's not enabled (some -falign-jumps is enabled
by -O2), since that is supposed to give the same result.

Please use that yourself as well, and verify it works for labels, even
if I fear it doesn't.

> However, I don't know why the speed up due to the patch is much
more significant on x86-64 than on x86.

It's Amdahl's law, even if this is not about parallel code. When the
rest is faster (x86_64), the same speedup on dispatch gives a bigger
overall speedup.

To be absolutely clear: x86_64 has more registers, so the rest of the
interpreter is faster than x86, but dispatch still takes the same
absolute time, which is 70% on x86_64, but only 50% on x86 (those are
realistic figures); if this patch halved dispatch time on both (we're
not so lucky), we would save 35% on x86_64 but only 25% on x86.
In fact, on inefficient interpreters, indirect threading is useless
altogether.

So, do those extra register help _so_ much? Yes. In my toy interpreter,
computing last_i for each dispatch doesn't give any big slowdown, but
storing it in f->last_i gives a ~20% slowdown - I cross-checked multiple
times because I was astonished. Conversely, when the program counter had
to be stored in memory, I think it was like 2x slower.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 03:02:06 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 02:02:06 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1230948126.61.0.66875700403.issue3959@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Sat Jan  3 03:19:28 2009
From: report at bugs.python.org (ebfe)
Date: Sat, 03 Jan 2009 02:19:28 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230949168.31.0.750114514563.issue4751@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

Here is another patch, this time for the fallback-md5-module. I know
that situations are rare where openssl is not present but threading is.
However they might occur out there and the md5module needed some love
anyway:

- The MD5 class from the fallback module can now also use threads with
'small locks'
- The behaviour regarding unicode data input is now consistent as to
what the openssl-driven classes do.
- Some code cleanup.


I might act on the sha modules as way the next days. sha256.c still
accepts 's#'...

I might a

Added file: http://bugs.python.org/file12557/md5module_small_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 03:20:58 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sat, 03 Jan 2009 02:20:58 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1230949258.6.0.586239956138.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

> I'm not an expert in this kind of optimizations. Could we gain more
speed by making the dispatcher table more dense? Python has less than
128 opcodes (len(opcode.opmap) == 113) so they can be squeezed in a
smaller table. I naively assume a smaller table increases the amount of
cache hits.

Well, you have no binary compatibility constraint with a new release, so
it can be tried and benchmarked, or it can be done anyway!
On x86_64 the impact of the jump table is 8 bytes per pointer * 256
pointers = 2KiB, and the L1 data cache of Pentium4 can be 8KiB or 16KiB
wide.
But I don't expect this to be noticeable in most synthetic
microbenchmarks. Matrix multiplication would be the perfect one I guess;
the repeated column access would kill the L1 data cache, if the whole
matrixes don't fit.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 03:44:58 2009
From: report at bugs.python.org (darrenr)
Date: Sat, 03 Jan 2009 02:44:58 +0000
Subject: [issue4794] garbage collector blocks and takes worst-case linear time
	wrt number of objects
In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za>
Message-ID: <1230950698.31.0.95639563177.issue4794@psf.upfronthosting.co.za>


darrenr <python-roundup at dranalli.com> added the comment:

OK cool, that's the development strategy we've already adopted. Is this
limitation of Python's garbage collector in relation to real-time
applications documented anywhere?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4794>
_______________________________________

From report at bugs.python.org  Sat Jan  3 03:55:45 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 02:55:45 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230951345.26.0.153561705088.issue4751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ebfe> Here is another patch, this time for the fallback-md5-module

Please open a separated issue for each module, this issue is already 
too long and complex ;-) And it would be easier to fix other modules 
when patches for hashlib will be accepted ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 04:38:10 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jan 2009 03:38:10 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <1230911682.85.0.598113499033.issue4805@psf.upfronthosting.co.za>
Message-ID: <d38f5330901021938q43239b4fw349ac09d4e4bee47@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jan 2, 2009 at 10:54 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Also note that by removing the extern "C" declarations, you not only
> change the exported symbol names of functions, but also those of
> exported globals.
>
What are " exported globals" other than "exported symbol names of
functions"?  AFAIK, C++ does not mangle non-function symbols.

> Those would also have to get declared in the header files, to prevent
> their names from being mangled (causing the exported C API to change).

I believe .c files should only contain static functions and functions
that are declared in an included header file.  If a function that is
not advertised in a header, it is not part of API and it is a fair
game to mangle it.  The only exception is the module init functions
that are part of the ABI rather than API.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Sat Jan  3 04:55:52 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Jan 2009 03:55:52 +0000
Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong
In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za>
Message-ID: <1230954952.26.0.680099205966.issue4580@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Finally got around to looking at the most recent patch
(issue4580-2.patch). It looks good to me.

I still think something needs to change when it comes to item assignment
for memoryviews with itemsize > 1, but that's not as urgent as fixing
the rest of the slicing behaviour (and probably should be a different
issue).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4580>
_______________________________________

From report at bugs.python.org  Sat Jan  3 05:02:15 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Jan 2009 04:02:15 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1230955335.81.0.913226579403.issue4626@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So explicitly converting to UTF-8 didn't work, or at least as simply as
I had hoped.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Sat Jan  3 05:33:25 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Jan 2009 04:33:25 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230957205.18.0.983310338173.issue4796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See attached patch for Py27.

----------
keywords: +patch
Added file: http://bugs.python.org/file12558/decimal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sat Jan  3 05:56:21 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 04:56:21 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>


New submission from Pavel Kosina <geon at post.cz>:

When you open file without encoding declaration, make changes and save,
then IDLE changes without any question encodings to utf8. You can try it
on attached file that is cp1250 now. 

It could be that at first saving we are asked to use 
*utf8 
*current one.

----------
components: IDLE
files: cp1250.py
messages: 78932
nosy: geon
severity: normal
status: open
title: idle 3.1a1 utf8
versions: Python 3.1
Added file: http://bugs.python.org/file12559/cp1250.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 06:00:26 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 05:00:26 +0000
Subject: [issue4008] IDLE: checksyntax() doesn't support Unicode?
In-Reply-To: <1222875475.18.0.22602254781.issue4008@psf.upfronthosting.co.za>
Message-ID: <1230958826.67.0.681001280305.issue4008@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

I vote for fixing this too. This might be simplified/another example of
above mentioned issues:

# -*- coding: utf-8 -*-
print ("?????????")

in IDLE prints this:
>>> 
??????????????????

When running this script under python command line from another editor,
I get the output readable as expected.

----------
nosy: +geon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4008>
_______________________________________

From report at bugs.python.org  Sat Jan  3 06:17:23 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jan 2009 05:17:23 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>
Message-ID: <1230959843.63.0.423882230771.issue4805@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file12560/c++-patch-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Sat Jan  3 06:17:29 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jan 2009 05:17:29 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>
Message-ID: <1230959849.58.0.514116386843.issue4805@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12530/c++-patch-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Sat Jan  3 08:32:41 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 07:32:41 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1230967961.2.0.278733823257.issue3638@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is incorrect. Tkapp_Mainloop is supposed to work both as a
module function and a method, and it tests for self to find out which
case it is. Now, this test is apparently broken in 3.x, but that could
be fixed, instead of ripping the module function out. Or, if that
function is removed, the code to support it should also be removed.

The same issue probably also affects other functions that double both as
instance methods and module functions.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 08:36:13 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 07:36:13 +0000
Subject: [issue4794] garbage collector blocks and takes worst-case linear time
	wrt number of objects
In-Reply-To: <1230950698.31.0.95639563177.issue4794@psf.upfronthosting.co.za>
Message-ID: <495F156A.2030807@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> OK cool, that's the development strategy we've already adopted. Is this
> limitation of Python's garbage collector in relation to real-time
> applications documented anywhere?

Why do you ask? (this is OT for the bug tracker)
It's not in the Python documentation. However, any good
book on real-time systems will tell you that garbage collection
is a problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4794>
_______________________________________

From report at bugs.python.org  Sat Jan  3 08:45:36 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 07:45:36 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230968736.91.0.839573715947.issue4815@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IDLE is right to save the file as UTF-8; the file is invalid Python 3.0
code. In Python 3.0, the source encoding *is* UTF-8; nothing else is
allowed unless you have an encoding declaration.

Perhaps IDLE should offer to convert it on opening.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 09:29:39 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 08:29:39 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230971379.79.0.225620079723.issue4815@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

You can open script made in python 2.x and it stops immediately working
after saving, if it is coding-aware. You can have bigger project and use
idle for editing config and text files from this project too. It is
"unfair" to change without notification the encodings. Or do you
consider IDLE just for beginners for learning?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 09:36:05 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 08:36:05 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230971765.2.0.460725348831.issue4815@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

I forgot about "Perhaps IDLE should offer to convert it on opening."
That would be nice, too.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 09:39:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 08:39:35 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230971975.81.0.773597663187.issue4815@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch to provide an explicit message that the file will be
converted when the file is opened (also querying what encoding should be
converted from), answering the complaint that the conversion is without
notice.

If you want to edit Python 2.x scripts with IDLE 3, you need to add
encoding declarations to the files. For bigger projects, it is
reasonable to expect that they do add these declarations.

Again, please only report one issue at the time. You chose to make
Python source files the topic of this issue, so please don't divert into
config or text files.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 09:50:30 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 08:50:30 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230972630.29.0.893412424.issue4815@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

Sorry, where is the patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 09:54:39 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 08:54:39 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230972879.95.0.204097043841.issue4815@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12561/conv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 09:55:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 08:55:07 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230972907.96.0.796154778207.issue4815@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +needs review
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 10:38:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Jan 2009 09:38:41 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230975521.04.0.257626071774.issue4796@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> marketdickinson
keywords: +needs review -patch
Added file: http://bugs.python.org/file12562/decimal2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sat Jan  3 10:38:47 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Jan 2009 09:38:47 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230975527.33.0.99503487777.issue4796@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12558/decimal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sat Jan  3 11:36:13 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 10:36:13 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230978973.03.0.846244652385.issue4815@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

OK, I got it. 

In my opinion it would nice if user can either convert file to utf8 or
to do nothing and add new encodings declaration or cancel. Current
"Cancel" gives an Decoding error. If you give an encodings that doesn't
exist, it shouldn't  destroy IDLE. Hoping its not my mistake, cause I do
not have all files from 3.1a  - just those from idlelib.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 11:40:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Jan 2009 10:40:43 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230979243.38.0.906207633131.issue4796@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Instead of the repeated divisions and Inexact tests, how about a direct 
approach:  n/2**k = (n*5**k)/10**k, so something like:

    sign = 0 if copysign(1.0, self) == 1.0 else 1
    n, d = abs(self).as_integer_ratio()
    k = d.bit_length() - 1
    return _dec_from_triple(sign, str(n*5**k), -k)

should work, and would likely be faster too.

I also think the sign of 0 should be preserved:  i.e.,

>>> Decimal.from_float(-0.0)
Decimal('-0')

Am still reviewing---more comments to come.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sat Jan  3 11:51:15 2009
From: report at bugs.python.org (Thomas Finley)
Date: Sat, 03 Jan 2009 10:51:15 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>


New submission from Thomas Finley <tfinley at gmail.com>:

This is a patch for the Python 3.1 build checked out from
http://svn.python.org/projects/python/branches/py3k

The current behavior of itertools.combinations(iterable,r) and
itertools.permutations(iterable,r) is to throw a ValueError if iterable
yields fewer than r items.  This changes these functions so the
generator instead yields 0 items.

As for my argument for acceptance, while the original behavior is not a
bug insofar as its implementation was deliberate, I'd argue this is
undesirable on grounds of mathematical consistency and functionality.

In mathematics the "choose" function is defined as "(n choose r)=0" for
r>n, so itertools.combinations' behavior is inconsistent with its
obvious combinatorial analogy.  (Similar for permutations and the
combinatorial "P" function.)

For functionality I'll cite my own case as anecdote.  In writing
regression tests I wanted to ensure that a group of items obeyed a
certain "mutually consistent" property between all triples.  (Something
akin to the triangle inequality.)  So:

all(triangle_respected(*triple) for triple in
itertools.combinations(group, 3))

If len(group)<=2, that's fine, since with no triangles there is no
inconsistency, and all(())==True.  However, the code failed with a
ValueError when groups were that small.  Working around this was fairly
awkward, since I wanted to continue to fail noisily if my
triangle_respected function threw a ValueError, and I wasn't sure at all
that it wouldn't if my items were 

The patch modifies Modules/itertoolsmodule.c slightly, changing
combinationsobject_new and permutationsobject_new.  (Deleting the error
throwing code, and have one line changes in both structures to handle
the n>r case.  One could handle this special case more efficiently than
I do by not bothering to allocate certain structures in this case, but I
didn't want to tempt fate.)  The patch also changes the appropriate
tests in Lib/test/test_itertools.py .

Obviously, this would break code that depends upon Python throwing
ValueError in the event of the combination or permutation sequence being
empty.  However, I hope given that combinations and permutations are a
relative novelty that their behavior in this corner case is not yet
etched in stone.

Sorry if this belongs in a PEP -- it seems quite minor, but I don't
quite have a feel what the threshold is.

----------
components: Library (Lib), Tests
files: itertools-empty-combinations.diff
keywords: patch
messages: 78943
nosy: TFinley
severity: normal
status: open
title: Patch of itertools.{combinations,permutations} for empty combinations
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file12563/itertools-empty-combinations.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Sat Jan  3 11:52:57 2009
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 03 Jan 2009 10:52:57 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1230979977.71.0.587177461214.issue4608@psf.upfronthosting.co.za>


Jakub Wilk <ubanus at users.sf.net> added the comment:

Oops, __next__ is OK. Sorry for the confusion.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Sat Jan  3 12:09:46 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sat, 03 Jan 2009 11:09:46 +0000
Subject: [issue4817] PyOS_GetLastModificationTime is unused
In-Reply-To: <1230980986.2.0.22709793272.issue4817@psf.upfronthosting.co.za>
Message-ID: <1230980986.2.0.22709793272.issue4817@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

This is just to record that the above function is wrongly documented,
inconsistently implemented, but fortunately unused, so it can be removed.

In addition to the patch attached, there are two files that can be removed:
Python/getmtime.c
RISCOS/Python/getmtime_riscos.c

----------
components: Interpreter Core
files: python-2.7-eradicate-getmtime.0.patch
keywords: patch
messages: 78945
nosy: eckhardt
severity: normal
status: open
title: PyOS_GetLastModificationTime is unused
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file12564/python-2.7-eradicate-getmtime.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4817>
_______________________________________

From report at bugs.python.org  Sat Jan  3 12:19:25 2009
From: report at bugs.python.org (ebfe)
Date: Sat, 03 Jan 2009 11:19:25 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230981565.46.0.497351403812.issue4751@psf.upfronthosting.co.za>


Changes by ebfe <knabberknusperhaus at yahoo.de>:


Removed file: http://bugs.python.org/file12557/md5module_small_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 12:19:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Jan 2009 11:19:33 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1230981573.69.0.301980119243.issue4796@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A couple more things:

1. There's a typo 'equilvalent' in the decimal.py part of the patch.

2. Can I suggest using

return d._fix(self)

instead of 

return self.plus(d)

in create_decimal_from_float.  The plus method does two things: rounds 
to the current context *and* converts -0.0 to 0.0; we only want the 
first of these.

(It's always been a source of mild irritation to me that there's no 
public method for simply rounding a Decimal to a given context---i.e., a 
public equivalent of _fix.)

----------
assignee: marketdickinson -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sat Jan  3 12:24:00 2009
From: report at bugs.python.org (ebfe)
Date: Sat, 03 Jan 2009 11:24:00 +0000
Subject: [issue4818] Patch for thread-support in md5module.c
In-Reply-To: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>
Message-ID: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>


New submission from ebfe <knabberknusperhaus at yahoo.de>:

Here is another patch, this time for the fallback-md5-module. I know
that situations are rare where openssl is not present but threading is.
However they might occur out there and the md5module needed some love
anyway:

- The MD5 class from the fallback module can now also use threads with
'small locks'
- The behaviour regarding unicode data input is now consistent as to
what the openssl-driven classes do.
- Some code cleanup.


I might act on the sha modules as way the next days. sha256.c still
accepts 's#'...


Also see issue #4751

----------
files: md5module_small_locks.diff
keywords: patch
messages: 78947
nosy: ebfe
severity: normal
status: open
title: Patch for thread-support in md5module.c
Added file: http://bugs.python.org/file12565/md5module_small_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4818>
_______________________________________

From report at bugs.python.org  Sat Jan  3 12:53:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Jan 2009 11:53:46 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1230983626.02.0.730324688636.issue4816@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree that the proposed behaviour seems more correct:  the collection of 
all subsets of size 4 of range(3) is perfectly valid and well-defined;  it 
just happens to be empty.  I've also encountered this in practice (in code 
that was enumerating partitions of a list into a fixed number of pieces), 
but in my case it was easier to work around.

I guess the counterargument is that the current ValueError might catch 
bugs early;  I don't know how often this is true in practice.

In any case, this is Raymond's call.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Sat Jan  3 13:06:47 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 12:06:47 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230984407.84.0.801107914282.issue4815@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> In my opinion it would nice if user can either convert file to utf8 or
> to do nothing and add new encodings declaration or cancel.

Ypu can still add an encoding declaration after the file got converted.
Cancelling is also possible.

> If you give an encodings that doesn't exist, it shouldn't  destroy IDLE.

Right. Here is a patch that fixes that.

Added file: http://bugs.python.org/file12566/conv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 13:06:55 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 12:06:55 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230984415.87.0.22460864134.issue4815@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file12561/conv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 13:14:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 12:14:26 +0000
Subject: [issue4818] Patch for thread-support in md5module.c
In-Reply-To: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>
Message-ID: <1230984866.02.0.982007913624.issue4818@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

ebfe, please identify yourself with a real name; please also sign a
contributor form.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4818>
_______________________________________

From report at bugs.python.org  Sat Jan  3 13:18:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Jan 2009 12:18:41 +0000
Subject: [issue4812] Junk in the decimals namespace
In-Reply-To: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>
Message-ID: <1230985121.88.0.111302811041.issue4812@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Done (r68191 through r68194).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4812>
_______________________________________

From report at bugs.python.org  Sat Jan  3 13:28:53 2009
From: report at bugs.python.org (ebfe)
Date: Sat, 03 Jan 2009 12:28:53 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1230985733.4.0.5704593272.issue4751@psf.upfronthosting.co.za>


ebfe <knabberknusperhaus at yahoo.de> added the comment:

Haypo, we can probably reduce overhead by defining ENTER_HASHLIB like this:

#define ENTER_HASHLIB(obj) \
    if ((obj)->lock) { \
        if (!PyThread_acquire_lock((obj)->lock, 0)) { \
            Py_BEGIN_ALLOW_THREADS \
            PyThread_acquire_lock((obj)->lock, 1); \
            Py_END_ALLOW_THREADS \
        } \
    }

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 13:48:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Jan 2009 12:48:20 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1230986900.42.0.910046093886.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Georg Brandl, on spark.py]
> This is used by asdl_c.py which generates Python-ast.c -- it should be
> updated.

The only issue here is a single comment, which reads:

#  GenericASTMatcher.  AST nodes must have "__getitem__" and "__cmp__"

Still, I'm reluctant to remove or alter the comment without
understanding why it was there in the first place.  If someone more
familiar with AST stuff can confirm that __cmp__ is definitely no
longer needed, I'll remove the mention of it from the comment.

> Misc/cheatsheet
>
>  This needs a general overhaul.

I'll open a separate issue for this, if that's okay with everyone.  
Presumably 3.0.1 doesn't need to wait for Misc/cheatsheet to be updated.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Sat Jan  3 13:55:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 12:55:43 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1230987343.91.0.614683129411.issue1717@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
title: Get rid of more refercenes to __cmp__ -> Get rid of more references to __cmp__

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Sat Jan  3 13:59:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 12:59:58 +0000
Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong
In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za>
Message-ID: <1230987598.96.0.857169707959.issue4580@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4580>
_______________________________________

From report at bugs.python.org  Sat Jan  3 14:00:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 13:00:30 +0000
Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong
In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za>
Message-ID: <1230987630.24.0.369005219068.issue4580@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4580>
_______________________________________

From report at bugs.python.org  Sat Jan  3 14:03:43 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 13:03:43 +0000
Subject: [issue4818] Patch for thread-support in md5module.c
In-Reply-To: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>
Message-ID: <1230987823.83.0.938309928363.issue4818@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

Sent the form by fax

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4818>
_______________________________________

From report at bugs.python.org  Sat Jan  3 14:16:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Jan 2009 13:16:34 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Misc/cheatsheet could do with an upgrade, both for the 2.x and 3.x branches.

For 3.x, I guess the changes needed are quite extensive.  I'm not sure
how much needs to be changed or added for 2.x; at a quick
glance, the 'with' statement, the 'x if b else y' construction, and the 
unified try-except-finally are missing.

----------
assignee: georg.brandl
components: Documentation
messages: 78955
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Misc/cheatsheet needs updating
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Sat Jan  3 14:22:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 13:22:38 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <495EC14C.7010405@cheimes.de>
Message-ID: <1230988965.10091.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm not an expert in this kind of optimizations. Could we gain more
> speed by making the dispatcher table more dense? Python has less than
> 128 opcodes (len(opcode.opmap) == 113) so they can be squeezed in a
> smaller table. I naively assume a smaller table increases the amount of
> cache hits.

I don't think so. The end of the current table, which doesn't correspond
to any valid opcodes, will not be cached anyway. The upper limit to be
considered is the maximum value for a valid opcode, which is 147.
Reducing that to 113 may reduce cache pressure, but only by a tiny bit.

Of course, only experimentation could tell us for sure :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 14:44:57 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 03 Jan 2009 13:44:57 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1230990297.36.0.701438062512.issue4806@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

I'm getting confused about whether it's actually desired behaviour that
generators can be star arguments.

The error message seems to say it's not: "argument after * must be a
sequence". The docs seem to agree: "If the syntax *expression appears in
the function call, expression must evaluate to a sequence." However
test_extcall specifically tests function calls with (non-sequence)
iterables as star arguments.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Sat Jan  3 14:57:22 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 13:57:22 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1230991042.32.0.650800719563.issue3638@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11200/tkinter_remove_mainloop.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 15:00:15 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 14:00:15 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1230991215.35.0.664074846446.issue3638@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Tkapp_Mainloop is supposed to work both as a module function 
> and a method, and it tests for self to find out which
> case it is. Now, this test is apparently broken in 3.x, ...

Ok. In Python 2.x, selfptr is NULL whereas selfptr is a pointer to the 
module in Python 3.x. New attached patch uses PyModule_Check() to 
check if selfptr is the module or an object.

> if that function is removed, the code to support 
> it should also be removed.

Which code? I don't see which code uses _tkinter.mainloop. I saw code 
that calls the method mainloop() of a Tkapp object, like 
tkinter.mainloop() does. Or am I wrong?

Added file: http://bugs.python.org/file12567/_tkinter_mainloop.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 15:10:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 14:10:02 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1230991215.35.0.664074846446.issue3638@psf.upfronthosting.co.za>
Message-ID: <495F71B7.6080600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Ok. In Python 2.x, selfptr is NULL whereas selfptr is a pointer to the 
> module in Python 3.x. New attached patch uses PyModule_Check() to 
> check if selfptr is the module or an object.

The patch looks right in principle. Please make sure not to include
printf calls in it.

Please also consider all similar cases, such as Tkapp_CreateFileHandler.

>> if that function is removed, the code to support 
>> it should also be removed.
> 
> Which code? 

The code inside the function: all tests whether self is NULL. If
mainloop would stop being a module function, this code also should go.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 15:21:32 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 03 Jan 2009 14:21:32 +0000
Subject: [issue4811] invalid reST markup in several documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1230992492.68.0.09259638563.issue4811@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Could you also fix the indentation of "Queues" example code at
http://docs.python.org/library/multiprocessing.html#exchanging-objects-between-processes
?

----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4811>
_______________________________________

From report at bugs.python.org  Sat Jan  3 15:27:10 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 14:27:10 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1230992830.93.0.120031725509.issue3638@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Victor, you seem to be confusing "code that supports it" with "functions
that use it". There are some conditional code inside Tkapp_MainLoop that
depends on self being available, that is what Martin meant by code that
supports it, and since it would no longer be a module function that code
would no longer be needed.

Now, I'm much more in favour to remove it from moduleMethods than from
adjusting it to work in py3k. My reasons for the moment are: 

1) To me, it makes much more sense to call a mainloop function from a
Tcl interpreter object than from a module;
2) There is a member named dispatching in TkappObject, so I believe when
this tcl/tk bridge was created -- or at least when this member was added
-- it had the intention to allow multiple mainloops at some time (or is
it really only intended to be used when trying to grab the thread that
created the tcl interpreter ?);
3) It reduces code :)

Although the reason #2 won't just work after removing mainloop from the
module functions, it also doesn't help keeping it there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 15:30:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Jan 2009 14:30:03 +0000
Subject: [issue4811] invalid reST markup in several documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1230993003.22.0.610258718266.issue4811@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Done.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4811>
_______________________________________

From report at bugs.python.org  Sat Jan  3 15:44:24 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 14:44:24 +0000
Subject: [issue4818] Patch for thread-support in md5module.c
In-Reply-To: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>
Message-ID: <1230993864.99.0.722347918052.issue4818@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

fixed naming, lock get's tried before releasing the gil to wait for it

Added file: http://bugs.python.org/file12568/md5module_small_locks-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4818>
_______________________________________

From report at bugs.python.org  Sat Jan  3 15:44:29 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 14:44:29 +0000
Subject: [issue4818] Patch for thread-support in md5module.c
In-Reply-To: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>
Message-ID: <1230993869.69.0.167797521525.issue4818@psf.upfronthosting.co.za>


Changes by Lukas Lueg <knabberknusperhaus at yahoo.de>:


Removed file: http://bugs.python.org/file12565/md5module_small_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4818>
_______________________________________

From report at bugs.python.org  Sat Jan  3 15:48:20 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 03 Jan 2009 14:48:20 +0000
Subject: [issue4820] ctypes.util.find_library incorrectly documented
In-Reply-To: <1230994100.6.0.728617029399.issue4820@psf.upfronthosting.co.za>
Message-ID: <1230994100.6.0.728617029399.issue4820@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

In the "ctypes reference / Finding shared libraries" section of the ctypes 
documentation, the find_library() function is described as being located 
in ctypes.util.   However, it's formal description right below that lists 
it as ctypes.find_library().

----------
assignee: georg.brandl
components: Documentation
messages: 78964
nosy: beazley, georg.brandl
severity: normal
status: open
title: ctypes.util.find_library incorrectly documented
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4820>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:00:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 15:00:30 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1230992830.93.0.120031725509.issue3638@psf.upfronthosting.co.za>
Message-ID: <495F7D82.8080809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Now, I'm much more in favour to remove it from moduleMethods than from
> adjusting it to work in py3k.

Would you apply the same reasoning to the other Tkapp methods available
on _tkinter?

IIRC, these functions were there first; the Tkapp object was added
later. The module functions are kept for compatibility (which we
were free to break in 3.0).

I'm not opposed to removing these module functions now (not even for
3.0.1), but...

> 1) To me, it makes much more sense to call a mainloop function from a
> Tcl interpreter object than from a module;

To me, it makes perfect sense. Windowing events are a global, and not
specific to a Tcl interpreter - before receiving it, you cannot know
(in general) what interpreter it is for. Indeed, Tcl's Tcl_DoOneEvent
doesn't take a Tcl_Interp* parameter.

> 2) There is a member named dispatching in TkappObject, so I believe when
> this tcl/tk bridge was created -- or at least when this member was added
> -- it had the intention to allow multiple mainloops at some time (or is
> it really only intended to be used when trying to grab the thread that
> created the tcl interpreter ?);

This entire machinery got added when Tcl started supporting threads in
a way fundamentally different from Python's support for threads. Tcl
is inherently single-threaded, no GIL. To support threads, you create
a new interpreter for each new thread, and the different interpreters
are completely independent from each other. So when a Tkinter
application passes a Tcl command from one thread to another, this would
crash or otherwise not work.

In the old days, Python's threading could be used with Tcl just fine;
any thread could make Tk calls (on Unix, at least). When Tcl threading
was added, I tried to preserve this mode, by making one thread the
Tcl thread. Any other Python thread can't make direct Tcl calls (since
those would get to a different interpreter), but instead an RPC
system based on Tcl's thread synchronization was added. As this RPC
depends on the Tcl mainloop, the "dispatching" member tells the caller
if the Tcl thread is up.

So, no: the "dispatching" member is there for continued support of
a single mainloop, not for multiple mainloops.

> 3) It reduces code :)

That is a good reason. We would still need a complete patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:08:23 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 15:08:23 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230995303.87.0.918540869956.issue4815@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

seems to be working.

Seems to me now I get it. The file encoding is ruled by the encoding
declaration. When I stated 

# -*- coding: cp1250 -*-

then the file would be saved in cp1250. 

Now hoping that I would keep this issue, cause it comes with this
patches: when I open file *with* say # -*- coding: cp1250 -*-, I am
asked to change to utf8. This behaviour was not before and is probably
unwanted.....

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:22:13 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 15:22:13 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230995303.87.0.918540869956.issue4815@psf.upfronthosting.co.za>
Message-ID: <495F82A2.10509@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Now hoping that I would keep this issue, cause it comes with this
> patches: when I open file *with* say # -*- coding: cp1250 -*-, I am
> asked to change to utf8. This behaviour was not before and is probably
> unwanted.....

Actually, the behavior was there before - it's just that conversion was
silent. If you put an empty line after the coding declaration, it should
work well. issue 4008 contains a patch for that problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:27:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Jan 2009 15:27:38 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1230992830.93.0.120031725509.issue3638@psf.upfronthosting.co.za>
Message-ID: <200901031628.02453.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, you seem to be confusing "code that supports it" with "functions
> that use it"

Oh ok, I didn't understood what "code that supports it" mean.

> There are some conditional code inside Tkapp_MainLoop that 
> depends on self being available, that is what Martin meant by code that
> supports it, and since it would no longer be a module function that code
> would no longer be needed.

Yes, right. I also prefer smaller code base with same functions ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:36:14 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 15:36:14 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <495F7D82.8080809@v.loewis.de>
Message-ID: <ac2200130901030736n4238b3e2i4ff641b59e1e4fbd@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> Now, I'm much more in favour to remove it from moduleMethods than from
>> adjusting it to work in py3k.
>
> Would you apply the same reasoning to the other Tkapp methods available
> on _tkinter?
>

As I see all those functions that are calling into Tcl should be moved
from the module functions. Some parts of the code inside these
functions are conflicting with each other, while one will try to allow
multiple threads, the other part will just disallow it. And since to
follow the Tcl appartment model we need to access some of the members
in TkappObject it just makes me want to remove those functions even
more.

> IIRC, these functions were there first; the Tkapp object was added
> later. The module functions are kept for compatibility (which we
> were free to break in 3.0).
>
> I'm not opposed to removing these module functions now (not even for
> 3.0.1), but...
>
>> 1) To me, it makes much more sense to call a mainloop function from a
>> Tcl interpreter object than from a module;
>
> To me, it makes perfect sense. Windowing events are a global, and not
> specific to a Tcl interpreter - before receiving it, you cannot know
> (in general) what interpreter it is for. Indeed, Tcl's Tcl_DoOneEvent
> doesn't take a Tcl_Interp* parameter.
>

That is way to see it. But what I was taking into account was
something like the proper update of the dispatching member for
different interpreters, this would mean dispatching could be used to
stop a running mainloop by setting it to 0.

>> 2) There is a member named dispatching in TkappObject, so I believe when
>> this tcl/tk bridge was created -- or at least when this member was added
>> -- it had the intention to allow multiple mainloops at some time (or is
>> it really only intended to be used when trying to grab the thread that
>> created the tcl interpreter ?);
>
> This entire machinery got added when Tcl started supporting threads in
> a way fundamentally different from Python's support for threads. Tcl
> is inherently single-threaded, no GIL. To support threads, you create
> a new interpreter for each new thread, and the different interpreters
> are completely independent from each other. So when a Tkinter
> application passes a Tcl command from one thread to another, this would
> crash or otherwise not work.
>

That is exactly one of the reasons to move mainloop and others from
the moduleMethods. It is hard for me to accept the two distinct
behaviours present in _tkinter, which are based from where you call
the function.

> In the old days, Python's threading could be used with Tcl just fine;
> any thread could make Tk calls (on Unix, at least). When Tcl threading
> was added, I tried to preserve this mode, by making one thread the
> Tcl thread. Any other Python thread can't make direct Tcl calls (since
> those would get to a different interpreter), but instead an RPC
> system based on Tcl's thread synchronization was added. As this RPC
> depends on the Tcl mainloop, the "dispatching" member tells the caller
> if the Tcl thread is up.
>

But I don't see a RPC being used there, I just see some polling.

> So, no: the "dispatching" member is there for continued support of
> a single mainloop, not for multiple mainloops.
>
>> 3) It reduces code :)
>
> That is a good reason. We would still need a complete patch.
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:37:58 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 15:37:58 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230997078.61.0.0444043880725.issue4815@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

Well, thanks a lot. 

(aware this is really off this issue): Now I even get the system of
patches  - issue 4008 solved the inconvenience in print Unicode signs
inside IDLE. Still not sure how works patches for Python versions. I
vote for including this a that patch about IDLE even in some 3.0.1, not
only in branch 3.1. In non-English speaking countries troubles with
encodings are more common, more beginners-frustrating than you can believe.

HNY 2009
Pavel Kosina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:48:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 15:48:12 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <ac2200130901030736n4238b3e2i4ff641b59e1e4fbd@mail.gmail.com>
Message-ID: <495F88B9.3060107@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> But I don't see a RPC being used there, I just see some polling.

Consider Tkapp_Call (e.g.). If this is invoked in the Tk interpreter
thread, then there is a direct call to Tcl_EvalObjv/Tkapp_CallResult.

If the call is made from a different thread, then a Tkapp_CallEvent
is allocated, filled with the parameters, and Tkapp_ThreadSend is
invoked. This puts the event into the thread queue of the receiving
thread, and waits for a condition.

In the interpreter thread, Tkapp_CallProc is invoked, which extracts
the arguments from the event, invokes Tcl_EvalObj/Tkapp_CallResult,
and notifies the condition.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:53:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 15:53:32 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230997078.61.0.0444043880725.issue4815@psf.upfronthosting.co.za>
Message-ID: <495F89F8.5070409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I
> vote for including this a that patch about IDLE even in some 3.0.1, not
> only in branch 3.1.

This is my plan, yes - hence I marked them all release-critical. They
still need review. I agree that IDLE in 3.0 is fairly broken wrt.
non-ASCII characters. I knew that before the release, but there is so
much work and only so little time. FWIW, my own language (German) also
uses (some) non-ASCII characters.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 16:57:51 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 15:57:51 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <495F88B9.3060107@v.loewis.de>
Message-ID: <ac2200130901030757p49810fcdwf6234e14821fb3b3@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> But I don't see a RPC being used there, I just see some polling.
>
> Consider Tkapp_Call (e.g.). If this is invoked in the Tk interpreter
> thread, then there is a direct call to Tcl_EvalObjv/Tkapp_CallResult.
>
> If the call is made from a different thread, then a Tkapp_CallEvent
> is allocated, filled with the parameters, and Tkapp_ThreadSend is
> invoked. This puts the event into the thread queue of the receiving
> thread, and waits for a condition.
>
> In the interpreter thread, Tkapp_CallProc is invoked, which extracts
> the arguments from the event, invokes Tcl_EvalObj/Tkapp_CallResult,
> and notifies the condition.

This is all true but the dispatching isn't used there actually.
dispatching is being used in a polling manner to try to catch the
thread running the tcl interpreter which someone tried to call into,
the code then proceeds to do what you described.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 17:04:31 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 16:04:31 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <ac2200130901030757p49810fcdwf6234e14821fb3b3@mail.gmail.com>
Message-ID: <495F8C8B.8080809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This is all true but the dispatching isn't used there actually.
> dispatching is being used in a polling manner to try to catch the
> thread running the tcl interpreter which someone tried to call into,
> the code then proceeds to do what you described.

Right. If the main thread doesn't actually invoke mainloop(), the
Tcl events don't get dispatched, and the RPC system breaks down,
effectively leading to a deadlock. To prevent application
breakage during startup, a grace period is added in case applications
create threads before starting the mainloop.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:08:24 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 17:08:24 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>


New submission from Lukas Lueg <knabberknusperhaus at yahoo.de>:

Here is the follow-up to issue #4818. The patches attached allow the
built-in SHA modules to release the GIL.

Also the build-in SHA modules will now no longer accept "s#" as input.
Input is parsed just as in the openssl-driven classes where
unicode-objects are explicitly rejected.


The built-in hash modules have been not quite beautiful before even more
code is now copy & pasted between them. Is there any interest in
refactoring all those modules? AFAIK _sha1 and such are only used by
hashlib.py ...

----------
messages: 78975
nosy: ebfe
severity: normal
status: open
title: Patches for thread-support in built-in SHA modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:08:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 17:08:38 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231002518.58.0.344967124374.issue4751@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure about the approach of dynamically allocating self->lock.
Imagine you allocate this lock while another thread is between
ENTER_HASHLIB and LEAVE_HASHLIB. What happens on LEAVE_HASHLIB? The
thread tries to release a lock it hadn't acquired (because the lock was
NULL at the time). Is it simply ignored?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:08:41 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 17:08:41 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1231002521.37.0.13867794574.issue4821@psf.upfronthosting.co.za>


Changes by Lukas Lueg <knabberknusperhaus at yahoo.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12569/sha1module_small_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:08:52 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 17:08:52 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1231002532.95.0.539299982406.issue4821@psf.upfronthosting.co.za>


Changes by Lukas Lueg <knabberknusperhaus at yahoo.de>:


Added file: http://bugs.python.org/file12570/sha256module_small_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:09:06 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 17:09:06 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1231002546.95.0.44320881661.issue4821@psf.upfronthosting.co.za>


Changes by Lukas Lueg <knabberknusperhaus at yahoo.de>:


Added file: http://bugs.python.org/file12571/sha512module_small_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:11:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 17:11:34 +0000
Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong
In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za>
Message-ID: <1231002694.75.0.793626354927.issue4580@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is committed in r68200, r68202. Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4580>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:14:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 17:14:13 +0000
Subject: [issue4822] Fix indentation in memoryobject.c
In-Reply-To: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>
Message-ID: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The rules state new files should be indented with 4-spaces, but
indentation has no consistent indentation: parts of it are indented with
tabs, others with spaces.
We could probably reindent it all with 4-spaces, especially since it
hasn't been backported to trunk yet (and the versions in py3k and 3.0
should be identical).

----------
messages: 78978
nosy: pitrou
priority: low
severity: normal
status: open
title: Fix indentation in memoryobject.c
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4822>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:14:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 17:14:34 +0000
Subject: [issue4580] slicing of memoryviews when itemsize != 1 is wrong
In-Reply-To: <1228681907.24.0.868516520055.issue4580@psf.upfronthosting.co.za>
Message-ID: <1231002874.5.0.629240428412.issue4580@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4580>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:17:53 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 17:17:53 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231003073.1.0.527062862251.issue4751@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

The lock is created while having the GIL in EVP_update. No other
function releases the GIL (besides the creator-function which does not
need the local lock).

Thereby no other thread can be in between ENTER and LEAVE while the lock
is allocated.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:23:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 17:23:10 +0000
Subject: [issue4817] PyOS_GetLastModificationTime is unused
In-Reply-To: <1230980986.2.0.22709793272.issue4817@psf.upfronthosting.co.za>
Message-ID: <1231003390.03.0.0855289377184.issue4817@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r68203 and r68204.

----------
nosy: +loewis
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4817>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:24:35 2009
From: report at bugs.python.org (djc)
Date: Sat, 03 Jan 2009 17:24:35 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231003475.35.0.0538888451218.issue4753@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 18:55:31 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Jan 2009 17:55:31 +0000
Subject: [issue4822] Fix indentation in memoryobject.c
In-Reply-To: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>
Message-ID: <1231005331.6.0.784232214137.issue4822@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think this is the kind of reindention that Guido approved of on
python-dev, along with unicodeobject.c.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4822>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:00:28 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Jan 2009 18:00:28 +0000
Subject: [issue4822] Fix indentation in memoryobject.c
In-Reply-To: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>
Message-ID: <1231005628.69.0.0709946574632.issue4822@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+1

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4822>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:02:21 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 18:02:21 +0000
Subject: [issue4823] idle height and place
In-Reply-To: <1231005741.18.0.260844388854.issue4823@psf.upfronthosting.co.za>
Message-ID: <1231005741.18.0.260844388854.issue4823@psf.upfronthosting.co.za>


New submission from Pavel Kosina <geon at post.cz>:

Nearly always (after opening) is IDLE window outside visible area.
Mainly the status bar is hidden under bottom windows menu bar. Same
situation happens when choosing Window-Zoom Height from IDLE menu.

xpsp3, 1024x768, py2.x-3.x

----------
components: IDLE
messages: 78983
nosy: geon
severity: normal
status: open
title: idle height and place
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4823>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:03:23 2009
From: report at bugs.python.org (Duncan McGreggor)
Date: Sat, 03 Jan 2009 18:03:23 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1231005803.66.0.454539375867.issue3959@psf.upfronthosting.co.za>


Duncan McGreggor <duncan.mcgreggor at gmail.com> added the comment:

I am a contributor to netaddr, having deprecated my own old and crufty 
IP address library in its favor. JP's comments on the library in this 
ticket are included in the set of reasons that I initially chose it to 
replace my own.

When I first looked at the ipaddr code a month ago, the features I was 
delighted to see in the ipaddr project include address exclusion and 
address collapsing (we'd been discussing these features in netaddr since 
my old project had similar functionality).

Perhaps the following might be a prudent course:
 * determine how small or big a standard library ip address module or 
subpackage should be;
 * have a mutual discussion on the netaddr and ipaddr mail lists to 
determine what would need to be changed in each project in order to 
support inclusion in the standard lib;
 * choose the option that requires the least code changes (simple naming 
convention changes should probably be given less weight than any changes 
to logic).

As for shutting down any project that is chosen, does such an action not 
leave older Python versions out in the cold? Shouldn't the project 
remain open to support Python versions < 2.7, with a highly visible note 
that the code is included in 2.7/3.1+? (I am completely ignorant of 
related Python development policy.)

----------
nosy: +oubiwann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:12:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 18:12:35 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1231005803.66.0.454539375867.issue3959@psf.upfronthosting.co.za>
Message-ID: <495FAA90.8050409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Perhaps the following might be a prudent course:

This sounds all good. It is better if the experts in a domain
make a recommendation, than if some random committer makes
a choice.

> As for shutting down any project that is chosen, does such an action not 
> leave older Python versions out in the cold? Shouldn't the project 
> remain open to support Python versions < 2.7, with a highly visible note 
> that the code is included in 2.7/3.1+? 

Of course - hence I said "eventually". The project could continue to
maintain the external version as long as they please, provided it
doesn't diverge from the in-core version (unless it is the in-core
version itself that diverges). What I don't want to see happen is that
the community recommends at some point to ignore the outdated crappy
version in the core, and replace it with the more-powerful bug-fixed
version available separately. This has happened in the past, so I'm
extremely cautious here.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:18:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 18:18:29 +0000
Subject: [issue4822] Fix indentation in memoryobject.c
In-Reply-To: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>
Message-ID: <1231006709.31.0.630512788866.issue4822@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file12572/reindent-memview.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4822>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:19:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 18:19:32 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1231006772.86.0.991762290249.issue3959@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:22:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 03 Jan 2009 18:22:35 +0000
Subject: [issue4822] Fix indentation in memoryobject.c
In-Reply-To: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>
Message-ID: <1231006955.61.0.739825925971.issue4822@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Do you expect a review? ;)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4822>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:46:51 2009
From: report at bugs.python.org (Duncan McGreggor)
Date: Sat, 03 Jan 2009 18:46:51 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1231008411.02.0.941743663734.issue3959@psf.upfronthosting.co.za>


Duncan McGreggor <duncan.mcgreggor at gmail.com> added the comment:

>> As for shutting down any project that is chosen, does such an action 
not 
>> leave older Python versions out in the cold? Shouldn't the project 
>> remain open to support Python versions < 2.7, with a highly visible 
note 
>> that the code is included in 2.7/3.1+? 
>
> Of course - hence I said "eventually". The project could continue to
> maintain the external version as long as they please, provided it
> doesn't diverge from the in-core version (unless it is the in-core
> version itself that diverges). What I don't want to see happen is that
> the community recommends at some point to ignore the outdated crappy
> version in the core, and replace it with the more-powerful bug-fixed
> version available separately. This has happened in the past, so I'm
> extremely cautious here.

Fantastic! Thanks for the clarification.

David, in the event of netaddr's complete or partial inclusion, are you 
+1 with this and the maintenance of an ip/net library in Python?

Guido, what is your preference regarding feature set/size for an ip/net 
library in Python?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Sat Jan  3 19:56:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 18:56:09 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1231008969.5.0.246477365804.issue3959@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If there's going to be lots of discussion, perhaps it should be taken to
python-dev?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Sat Jan  3 20:03:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 19:03:55 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za>
Message-ID: <1231009435.09.0.231694817933.issue4718@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is committed now in py3k and the 3.0 maintenance branch. Thanks all
for your participation!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 20:10:21 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 19:10:21 +0000
Subject: [issue4823] idle height and place
In-Reply-To: <1231005741.18.0.260844388854.issue4823@psf.upfronthosting.co.za>
Message-ID: <1231009821.47.0.452345132793.issue4823@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

sorry it is duplicate to issue 3286
pls close

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4823>
_______________________________________

From report at bugs.python.org  Sat Jan  3 20:11:09 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 19:11:09 +0000
Subject: [issue3286] IDLE opens window too low on Windows
In-Reply-To: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za>
Message-ID: <1231009869.39.0.699499303673.issue3286@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

+1

----------
nosy: +geon
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3286>
_______________________________________

From report at bugs.python.org  Sat Jan  3 20:21:03 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Jan 2009 19:21:03 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1231010463.89.0.950872218075.issue4796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The direct method is *much* faster!
Applied Mark's suggestions.
Committed as r68208 and r68211 .

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sat Jan  3 20:29:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 19:29:23 +0000
Subject: [issue4822] Fix indentation in memoryobject.c
In-Reply-To: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>
Message-ID: <1231010963.08.0.376955173932.issue4822@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, committed.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4822>
_______________________________________

From report at bugs.python.org  Sat Jan  3 20:47:22 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 19:47:22 +0000
Subject: [issue4823] idle height and place
In-Reply-To: <1231005741.18.0.260844388854.issue4823@psf.upfronthosting.co.za>
Message-ID: <1231012042.46.0.271226589588.issue4823@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4823>
_______________________________________

From report at bugs.python.org  Sat Jan  3 20:55:31 2009
From: report at bugs.python.org (Neil Richardson)
Date: Sat, 03 Jan 2009 19:55:31 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1231012531.63.0.815279214901.issue3329@psf.upfronthosting.co.za>


Neil Richardson <richyneil at gmail.com> added the comment:

I'll be in agreement here. I integrated Python into a game engine not 
too long ago, and had to a do a fair chunk of work to isolate Python 
into it's own heap - given that fragmentation on low memory systems can 
be a bit of a killer. Would also make future upgrades a heck of a lot 
easier too, as there'd be no need to do a search for all references and 
carefully replace them all.

----------
nosy: +neilo
versions: +Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Sat Jan  3 20:56:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 19:56:27 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za>
Message-ID: <1231012587.38.0.113650947739.issue4718@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening, the patch actually produces failures when run with "python
-bb", that is there are comparisons between str and bytes.

See the errors at the end of
http://www.python.org/dev/buildbot/3.x.stable/ppc%20Debian%20unstable%203.0/builds/26/step-test/0

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 21:08:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 20:08:58 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za>
Message-ID: <1231013338.88.0.223436306227.issue4718@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

People, does this patch look ok to you?

Added file: http://bugs.python.org/file12573/wsgiref-bb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 21:19:51 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 20:19:51 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1231013991.3.0.0893553306829.issue3638@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Here is a patch, two actually. The next one deprecates the functions in
trunk

Added file: http://bugs.python.org/file12574/issue3638.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 21:20:12 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 20:20:12 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1231014012.31.0.508832698201.issue3638@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Added file: http://bugs.python.org/file12575/deprecated_funcs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 21:24:29 2009
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Sat, 03 Jan 2009 20:24:29 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1231013338.88.0.223436306227.issue4718@psf.upfronthosting.co.za>
Message-ID: <495FC97A.3080508@hlabs.spb.ru>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Antoine Pitrou wrote:
> People, does this patch look ok to you?

Oh, didn't know about -bb.
The patch looks OK for me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 21:26:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 20:26:57 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <495FC97A.3080508@hlabs.spb.ru>
Message-ID: <1231014402.22041.6.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 03 janvier 2009 ? 20:24 +0000, Dmitry Vasiliev a ?crit :
> Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:
> 
> Antoine Pitrou wrote:
> > People, does this patch look ok to you?
> 
> Oh, didn't know about -bb.

Well, it's meant to catch potential bugs. str and bytes always compare
unequal in py3k (i.e. "a" != b"a"), so it's good to use -bb when porting
some stuff from 2.x.

There's another problem in that buildbot failure with the environment
variable "NO_PROXY". We'll see if it's still there after the patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 21:57:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 20:57:11 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1231016231.37.0.770299680835.issue3638@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

These look fine. I think further changes are necessary:
tkinter/__init__.py tries to load createfilehandler/deletefilehandler;
this becomes redundant. Also, why did you leave DoOneEvent and Quit
as-is - don't they fall into the same category?

One minor nit: I personally dislike function pointer casts, because they
can easily go wrong. I rather prefer if the C compiler tells me when I
mess up with function pointer types. Hence _tkinter uses selfptr/self
all the time.

----------
assignee:  -> gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 21:59:45 2009
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Sat, 03 Jan 2009 20:59:45 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1231014402.22041.6.camel@localhost>
Message-ID: <495FD1B1.1020204@hlabs.spb.ru>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Antoine Pitrou wrote:
> There's another problem in that buildbot failure with the environment
> variable "NO_PROXY". We'll see if it's still there after the patch.

Strange error and it seems there is only part of the traceback. I've
already seen such "partially displayed" Python 3 traceback and error
actually can be in very different place.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:07:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 21:07:46 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <495FD1B1.1020204@hlabs.spb.ru>
Message-ID: <1231016853.22041.7.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Strange error and it seems there is only part of the traceback. I've
> already seen such "partially displayed" Python 3 traceback and error
> actually can be in very different place.

If you can reproduce such a problem, please open a bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:09:05 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 21:09:05 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1231016945.82.0.643243839334.issue4815@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

I might have another problem with this patch and maybe also that one in
issue 4008. Having a file with

print ("?????????")
# saved in cp1250

Open - confirm converting to utf8 - F5 - error: see attached file
idleunicode1.jpg

Added file: http://bugs.python.org/file12576/idleunicode1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:14:35 2009
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Sat, 03 Jan 2009 21:14:35 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1231016853.22041.7.camel@localhost>
Message-ID: <495FD537.8040906@hlabs.spb.ru>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Antoine Pitrou wrote:
>> Strange error and it seems there is only part of the traceback. I've
>> already seen such "partially displayed" Python 3 traceback and error
>> actually can be in very different place.
> 
> If you can reproduce such a problem, please open a bug.

OK, I'll try to reproduce.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:24:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 21:24:14 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1231016945.82.0.643243839334.issue4815@psf.upfronthosting.co.za>
Message-ID: <495FD77C.8000702@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> print ("?????????")
> # saved in cp1250

I can't reproduce the problem. Can you please attach the
exact file that failed to work?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:24:21 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 21:24:21 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1231016231.37.0.770299680835.issue3638@psf.upfronthosting.co.za>
Message-ID: <ac2200130901031324y11ec5fe6ibd871e332a4b85fa@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> These look fine. I think further changes are necessary:
> tkinter/__init__.py tries to load createfilehandler/deletefilehandler;
> this becomes redundant.

Indeed, I forgot to look into the Python code.

I also see as redundant the checks for _tkinter._flatten and
_tkinter._cnfmerge, the former because if we are still on Tkinter.py
(or __init__.py in py3k) then _tkinter exists and _flatten is there
too, the latter because there is no _cnfmerge in _tkinter.

> Also, why did you leave DoOneEvent and Quit
> as-is - don't they fall into the same category?
>

Ah, it is nice you ask this. I was indeed going to move then, but I
noticed strange things with DoOneEvent which made me only remove those
functions that were already checking the thread id of the caller and
the interp creator. But rethinking about this, it seems to make more
sense to do the move now and fix the "strange things" in other patch.
The problems I noticed may be a bit off-topic for this specific issue,
but I would hate to just say I had problems with a function and don't
say which errors I got, and how I got, so I have to write. So, the
problem started when I noticed DoOneEvent doesn't check for python
errors after Tcl_DoOneEvent returns, making me try to get one of those
SystemErrors "NULL result without error" -- I failed to get it, but I
got other unexpected results:

I get an empty string with the text below, but I was expecting some
nameerror message:

import _tkinter

def mybgerror(errmsg):
    print errmsg

called = []
def bad():
    called.append(True)
    raise InvalidThing

x = _tkinter.create()
x.createcommand("bad", bad)
x.createcommand("bgerror", mybgerror)
x.call("after", 1, "bad")

while not called:
    _tkinter.dooneevent()
_tkinter.dooneevent()

I ended up finding another problem (or problems, I forgot to annotate
them), like with call:

import _tkinter

def bad():
    raise InvalidThing

x = _tkinter.create()
x.createcommand("bad", bad)
x.call("bad")

Results in:

Traceback (most recent call last):
  File "my_badtests/test1.py", line 7, in <module>
    x.call("bad")
_tkinter.TclError

Meaning call is overwriting a python error by a tcl error, but since
there was no error in the tcl interpreter the error message was empty
(too many errors in a message).

But these all would deserve another(s) issues, so I will be moving
"quit" and "dooneevent" from there too.

> One minor nit: I personally dislike function pointer casts, because they
> can easily go wrong. I rather prefer if the C compiler tells me when I
> mess up with function pointer types. Hence _tkinter uses selfptr/self
> all the time.
>

Fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:26:46 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 21:26:46 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <ac2200130901031324y11ec5fe6ibd871e332a4b85fa@mail.gmail.com>
Message-ID: <ac2200130901031326ob548cf6u53f508adda39887@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> I get an empty string with the text below, but I was expecting some

s/text/test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:33:38 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 21:33:38 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <495FD77C.8000702@v.loewis.de>
Message-ID: <495FD9B2.9020909@post.cz>


Pavel Kosina <geon at post.cz> added the comment:

Martin v. L?wis napsal(a), dne 3.1.2009 22:24:
> I can't reproduce the problem. Can you please attach the
> exact file that failed to work?
>   

You can use that one that is already here: cp1250.py. It is the same 
error with me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:38:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 21:38:30 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <ac2200130901031324y11ec5fe6ibd871e332a4b85fa@mail.gmail.com>
Message-ID: <495FDAD4.2030205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> But these all would deserve another(s) issues, so I will be moving
> "quit" and "dooneevent" from there too.

I haven't tried reproducing these problems, but this all sounds plausible.

So go ahead and check in all the changes for this issue.

Don't forget Misc/NEWS entries, and don't forget to svnmerge block
the 2.7 change from being merged into 3.k. You should then also
merge the 3k change into the 3.0 branch. I don't think we have
to merge the warnings into 2.6 (but could if we wanted to).
Leave the various revision numbers in this report when done.

If you rather prefer me to check it in, please let me know.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:40:04 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 21:40:04 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <495FD9B2.9020909@post.cz>
Message-ID: <495FDB31.2050704@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You can use that one that is already here: cp1250.py. It is the same 
> error with me.

Ok, then what are the exact steps to reproduce? What code base, what
patches applied, what user interaction in what order?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:49:48 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 21:49:48 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <495FDB31.2050704@v.loewis.de>
Message-ID: <495FDD7C.2050708@post.cz>


Pavel Kosina <geon at post.cz> added the comment:

Microsoft Windows XP [Verze 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\prg\Python30\Lib\idlelib>svn update    # from 
http://svn.python.org/projects/python/branches/py3k/Lib/idlelib
Restored 'AutoCompleteWindow.py'
Restored 'ToolTip.py'
Restored 'UndoDelegator.py'
Restored 'Bindings.py'
Restored '__init__.py'
Restored 'AutoComplete.py'
Restored 'configHandler.py'
Restored 'HyperParser.py'
Restored 'ColorDelegator.py'
Restored 'Delegator.py'
Restored 'ObjectBrowser.py'
Restored 'testcode.py'
Restored 'configSectionNameDialog.py'
Restored 'ZoomHeight.py'
Restored 'PyShell.py'
Restored 'ParenMatch.py'
Restored 'config-keys.def'
Restored 'Debugger.py'
Restored 'CREDITS.txt'
Restored 'configDialog.py'
Restored 'StackViewer.py'
Restored 'HISTORY.txt'
Restored 'SearchEngine.py'
Restored 'ReplaceDialog.py'
Restored 'ScriptBinding.py'
Restored 'ChangeLog'
Restored 'tabbedpages.py'
Restored 'keybindingDialog.py'
Restored 'configHelpSourceEdit.py'
Restored 'WidgetRedirector.py'
Restored 'GrepDialog.py'
Restored 'FormatParagraph.py'
Restored 'EditorWindow.py'
Restored 'help.txt'
Restored 'config-highlight.def'
Restored 'PyParse.py'
Restored 'README.txt'
Restored 'rpc.py'
Restored 'OutputWindow.py'
Restored 'aboutDialog.py'
Restored 'idle.bat'
Restored 'TODO.txt'
Restored 'config-main.def'
Restored 'IdleHistory.py'
Restored 'PathBrowser.py'
Restored 'IOBinding.py'
Restored 'WindowList.py'
Restored 'ScrolledList.py'
Restored 'ClassBrowser.py'
Restored 'FileList.py'
Restored 'CallTips.py'
Restored 'idle.py'
Restored 'CodeContext.py'
Restored 'textView.py'
Restored 'SearchDialogBase.py'
Restored 'CallTipWindow.py'
Restored 'SearchDialog.py'
Restored 'RemoteObjectBrowser.py'
Restored 'idlever.py'
Restored 'RemoteDebugger.py'
Restored 'TreeWidget.py'
Restored 'NEWS.txt'
Restored 'idle.pyw'
Restored 'run.py'
Restored 'config-extensions.def'
Restored 'AutoExpand.py'
Restored 'Percolator.py'
Restored 'dynOptionMenuWidget.py'
Restored 'extend.txt'
Restored 'MultiStatusBar.py'
Restored 'MultiCall.py'
Restored 'macosxSupport.py'
At revision 68230.

C:\prg\Python30\Lib\idlelib>patch < conv.diff
patching file IOBinding.py

C:\prg\Python30\Lib\idlelib>patch < idle_encoding_4.patch
patching file ScriptBinding.py
patching file IOBinding.py

-------------

Run IDLE - Open cp1250.py - confirm converting to utf8 - F5 (immediately, no change in code!) - error: see attached file
idleunicode1.jpg

All the other python code base is clean 3.0.
xpsp3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 22:57:46 2009
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Sat, 03 Jan 2009 21:57:46 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za>
Message-ID: <1231019866.73.0.864134770179.issue4718@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Attached patch for test_urllib, possible source of the "NO_PROXY" problem.

Added file: http://bugs.python.org/file12577/no_proxy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sat Jan  3 23:07:37 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 03 Jan 2009 22:07:37 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1231020457.17.0.0778461555708.issue4815@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see. Here is a revised patch. This sets the modified flag on the
buffer after conversion, so that you get asked to save it before running it.

Added file: http://bugs.python.org/file12578/conv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 23:07:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 22:07:50 +0000
Subject: [issue3638] Remove module level functions in _tkinter that depend on
	TkappObject
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1231020470.28.0.72793467575.issue3638@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Thanks Martin,

trunk: r68231 (blocked on py3k)
py3k: r68237
release30-maint: r68239

----------
resolution:  -> fixed
status: open -> closed
title: tkinter.mainloop() is meaningless and crash: remove it -> Remove module level functions in _tkinter that depend on TkappObject
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 23:15:14 2009
From: report at bugs.python.org (Yann Ramin)
Date: Sat, 03 Jan 2009 22:15:14 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231020914.07.0.940743572132.issue4753@psf.upfronthosting.co.za>


Changes by Yann Ramin <atrus at stackworks.net>:


----------
nosy: +theatrus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan  3 23:18:11 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 22:18:11 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1231020457.17.0.0778461555708.issue4815@psf.upfronthosting.co.za>
Message-ID: <495FE423.7020304@post.cz>


Pavel Kosina <geon at post.cz> added the comment:

Yes. Goooood jooooob. ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sat Jan  3 23:18:35 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 22:18:35 +0000
Subject: [issue3638] Remove module level functions in _tkinter that depend on
	TkappObject
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1231021115.7.0.355246258166.issue3638@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Uh, I forgot about the code removal in __init__ in the first commits.

r68242, r68244 now

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Jan  3 23:20:58 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Jan 2009 22:20:58 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1231021258.95.0.828601549163.issue2983@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Do you still need a review for this, Guilherme? If you just need a quick
code check I can see if I can make the time for this, but my tkinter
knowledge is lacking so it won't be very in-depth. Hopefully this is all
isolated enough that even if it is initially broken it won't be a big
deal if you just check it in.

And do you want this in 2.7 and 3.1, or out of simplicity just 3.1?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Sat Jan  3 23:31:58 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 22:31:58 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1231021258.95.0.828601549163.issue2983@psf.upfronthosting.co.za>
Message-ID: <ac2200130901031431w47331099g455f065126c56a57@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Do you still need a review for this, Guilherme? If you just need a quick
> code check I can see if I can make the time for this, but my tkinter
> knowledge is lacking so it won't be very in-depth. Hopefully this is all
> isolated enough that even if it is initially broken it won't be a big
> deal if you just check it in.
>

I was waiting more for an "Ok, commit" as I though Fredrik already did
a quick code check on it.
But of course you can look at it too if you want.

Also, would it be fine to leave its tests on lib-tk (2.7) and tkinter (3.1) ?

> And do you want this in 2.7 and 3.1, or out of simplicity just 3.1?
>

I would like both if I can decide on that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Sun Jan  4 00:01:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 23:01:36 +0000
Subject: [issue4718] wsgiref package totally broken
In-Reply-To: <1229945457.69.0.495711258596.issue4718@psf.upfronthosting.co.za>
Message-ID: <1231023696.88.0.872870518984.issue4718@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nice catch! I've committed the two patches and we'll see whether it
makes the buildbots feel better.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4718>
_______________________________________

From report at bugs.python.org  Sun Jan  4 00:06:18 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Jan 2009 23:06:18 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1231023978.08.0.43835302873.issue2983@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If Fredrik already reviewed it I don't see why you can't commit. If
something goes wrong you can always back the commit out.

As for the testing question, I am not sure I understand what you are
asking. Are you asking if the tests can stay integrated with tkinter's
existing tests?

Ans as for versions, put it into whatever versions you want to support.
I was just saying you can do 3.1 only if you don't want to the hassle of
supporting both versions. If you are up for it then please do both!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Sun Jan  4 00:23:37 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 03 Jan 2009 23:23:37 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1231023978.08.0.43835302873.issue2983@psf.upfronthosting.co.za>
Message-ID: <ac2200130901031523s5eecac7cu2e2b23798beb0631@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> As for the testing question, I am not sure I understand what you are
> asking. Are you asking if the tests can stay integrated with tkinter's
> existing tests?
>

There are no tests for tkinter, except for some few ones for _tkinter
basic functionality living on Lib/test/test_tcl.py
If it is ok I can start a test/ directory inside lib-tk and tkinter
(py3k), I would then prefix ttk file tests with a "ttk".

> Ans as for versions, put it into whatever versions you want to support.
> I was just saying you can do 3.1 only if you don't want to the hassle of
> supporting both versions. If you are up for it then please do both!

Perfect, both then :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Sun Jan  4 00:30:39 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 03 Jan 2009 23:30:39 +0000
Subject: [issue4824] test_cmd_line failure on Mac OS X for py3k
In-Reply-To: <18783.62745.773153.314589@montanaro.dyndns.org>
Message-ID: <18783.62745.773153.314589@montanaro.dyndns.org>


New submission from Skip Montanaro <skip at pobox.com>:

test_cmd_line.test_run_code fails for me on Mac OS X:

    % ./python.exe -bb  Lib/test/regrtest.py -v test_cmd_line
    test_cmd_line
    test_directories (test.test_cmd_line.CmdLineTest) ... ok
    test_optimize (test.test_cmd_line.CmdLineTest) ... ok
    test_q (test.test_cmd_line.CmdLineTest) ... ok
    test_run_code (test.test_cmd_line.CmdLineTest) ... FAIL
    test_run_module (test.test_cmd_line.CmdLineTest) ... ok
    test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
    test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
    test_usage (test.test_cmd_line.CmdLineTest) ... ok
    test_verbose (test.test_cmd_line.CmdLineTest) ... ok
    test_version (test.test_cmd_line.CmdLineTest) ... ok

    ======================================================================
    FAIL: test_run_code (test.test_cmd_line.CmdLineTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/skip/src/python/py3k/Lib/test/test_cmd_line.py", line 143, in test_run_code
        0)
    AssertionError: 1 != 0

    ----------------------------------------------------------------------
    Ran 10 tests in 1.282s

Manually running what that test executes shows the problem:

    % ./python.exe 
    Python 3.1a0 (py3k:68218, Jan  3 2009, 15:06:30) 
    [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import sys
    >>> sys.executable
    '/Users/skip/src/python/py3k/python.exe'
    >>> import subprocess
    >>> import sys
    >>> cmd_line = [sys.executable, '-E']
    >>> cmd_line.extend(['-c', "assert(ord('\xe9') == 0xe9)"])
    >>> cmd_line
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/skip/src/python/py3k/Lib/io.py", line 1488, in write
        b = encoder.encode(s)
      File "/Users/skip/src/python/py3k/Lib/encodings/ascii.py", line 22, in encode
        return codecs.ascii_encode(input, self.errors)[0]
    UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 68: ordinal not in range(128)
    >>> sys.getfilesystemencoding()
    'utf-8'
    >>> subprocess.call(cmd_line, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    1

If I execute that command from the shell prompt I do get a zero exit code no
matter what I try to mimic the scenario in the test:

    py3k% ./python.exe -E -c 'assert(ord("\xe9") == 0xe9)'
    py3k% echo $?
    0
    py3k% ./python.exe -E -c 'assert(ord("\xe9") == 0xe9)' > /tmp/trash 2>&1
    py3k% echo $?
    0
    py3k% ./python.exe -E -c 'assert(ord("\xe9") == 0xe9)' 2>&1 | cat > /dev/null
    py3k% echo $?
    0

I'm not sure where the problem lies.

----------
messages: 79023
nosy: skip.montanaro
severity: normal
status: open
title: test_cmd_line failure on Mac OS X for py3k

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4824>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:12:35 2009
From: report at bugs.python.org (MagnetoHydroDynamics)
Date: Sun, 04 Jan 2009 00:12:35 +0000
Subject: [issue4825] TypeError with complex.real() and complex.imag()
In-Reply-To: <1231027955.73.0.619900873026.issue4825@psf.upfronthosting.co.za>
Message-ID: <1231027955.73.0.619900873026.issue4825@psf.upfronthosting.co.za>


New submission from MagnetoHydroDynamics <karl at asmussen.ws>:

In both version 2.6.1 and 3.0 this issue exists:
N and M can be two numbers of any type.
>>> (N+Mj).real()
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    (N+Mj).real()
TypeError: 'float' object is not callable
>>> (N+Mj).imag()
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    (N+Mj).imag()
TypeError: 'float' object is not callable

----------
components: None
messages: 79024
nosy: MagnetoHydroDynamics
severity: normal
status: open
title: TypeError with complex.real() and complex.imag()
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4825>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:13:51 2009
From: report at bugs.python.org (MagnetoHydroDynamics)
Date: Sun, 04 Jan 2009 00:13:51 +0000
Subject: [issue4825] TypeError with complex.real() and complex.imag()
In-Reply-To: <1231027955.73.0.619900873026.issue4825@psf.upfronthosting.co.za>
Message-ID: <1231028031.82.0.915383131388.issue4825@psf.upfronthosting.co.za>


MagnetoHydroDynamics <karl at asmussen.ws> added the comment:

In both version 2.6.1 and 3.0 this issue exists:
N and M can be two numbers of any type.
>>> (N+Mj).real()
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    (N+Mj).real()
TypeError: 'float' object is not callable
>>> (N+Mj).imag()
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    (N+Mj).imag()
TypeError: 'float' object is not callable

It would be nice to have this fixed, preferably soon.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4825>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:17:35 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 04 Jan 2009 00:17:35 +0000
Subject: [issue1702551] distutils sdist does not exclude SVN/CVS files on
	Windows
Message-ID: <1231028255.42.0.792972506527.issue1702551@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Fixed in r68276.

I have added a test together with the patch, and slighty changed your fix.

It's applied in the trunk, and 2.6 as well (it will be forwardported
into 3.x as well)

Thanks for the feedback and the solution !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1702551>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:19:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Jan 2009 00:19:50 +0000
Subject: [issue1702551] distutils sdist does not exclude SVN/CVS files on
	Windows
Message-ID: <1231028390.41.0.116228136399.issue1702551@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Tarek, I don't know if you are already subscribed to the python-checkins
mailing list -- I've reviewed the commit and posted a reply with a minor
problem there.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1702551>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:29:16 2009
From: report at bugs.python.org (Pierre Bourdon)
Date: Sun, 04 Jan 2009 00:29:16 +0000
Subject: [issue4825] TypeError with complex.real() and complex.imag()
In-Reply-To: <1231027955.73.0.619900873026.issue4825@psf.upfronthosting.co.za>
Message-ID: <1231028956.75.0.677528695856.issue4825@psf.upfronthosting.co.za>


Pierre Bourdon <root at delroth.is-a-geek.org> added the comment:

I don't think this is a valid issue : real and imag are just properties
of complex objects, not methods !

----------
nosy: +delroth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4825>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:34:54 2009
From: report at bugs.python.org (Benoit Boissinot)
Date: Sun, 04 Jan 2009 00:34:54 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231029294.82.0.0361353973148.issue4753@psf.upfronthosting.co.za>


Changes by Benoit Boissinot <bboissin+pythonbugs at gmail.com>:


----------
nosy: +bboissin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:39:31 2009
From: report at bugs.python.org (MagnetoHydroDynamics)
Date: Sun, 04 Jan 2009 00:39:31 +0000
Subject: [issue4825] TypeError with complex.real() and complex.imag()
In-Reply-To: <1231027955.73.0.619900873026.issue4825@psf.upfronthosting.co.za>
Message-ID: <1231029571.48.0.477637933994.issue4825@psf.upfronthosting.co.za>


MagnetoHydroDynamics <karl at asmussen.ws> added the comment:

Nvm. I thought it was metods.

Requesting deletion.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4825>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:40:38 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 04 Jan 2009 00:40:38 +0000
Subject: [issue1702551] distutils sdist does not exclude SVN/CVS files on
	Windows
Message-ID: <1231029638.62.0.378265267488.issue1702551@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Georg, I think I am supposed to be registered since a few days but I
don't receive any mail yet. I'll ask...

I didn't use a raw string because '\.' is not an escape sequence,
so:

  >>> '\.svn' == '\\.svn' and '\.svn' == r'\.svn'
  True

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1702551>
_______________________________________

From report at bugs.python.org  Sun Jan  4 01:49:04 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 00:49:04 +0000
Subject: [issue4824] test_cmd_line failure on Mac OS X for py3k
In-Reply-To: <18783.62745.773153.314589@montanaro.dyndns.org>
Message-ID: <18784.1892.667609.910666@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Here is another data point.  I added some print calls to the subprocess
module and ran the key call from the interpreter:

    % ./python.exe 
    Python 3.1a0 (py3k:68218, Jan  3 2009, 15:06:30) 
    [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import subprocess
    >>> import sys
    >>> cmd_line = [sys.executable, '-E']>>> cmd_line.extend(['-c', "assert(ord('\xe9') == 0xe9)"])
    >>> subprocess.call(cmd_line, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    1 wait, returncode= None
    2 wait, pid= 4029 sts= 256
    5 _handle_exitstatus WIFEXITED
    3 wait, returncode= 1
    1
    >>> os.WIFEXITED(256)
    True
    >>> os.WEXITSTATUS(256)
    1
    >>> 256 & 255
    0

A return code of 256 seems to me like the exit code should be 0.  From my
Mac's wait(2) man page:

     WEXITSTATUS(status)
             If WIFEXITED(status) is true, evaluates to the low-order 8 bits
             of the argument passed to _exit(2) or exit(3) by the child.

What's with the WEXITSTATUS return value of 1?

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4824>
_______________________________________

From report at bugs.python.org  Sun Jan  4 02:04:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 Jan 2009 01:04:14 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1231031054.68.0.919851226774.issue3997@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sun Jan  4 03:00:51 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 04 Jan 2009 02:00:51 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231034451.72.0.0523187640754.issue4753@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

IIUC, this is what gcc 4.2.4 generates on a Celeron M for the code
Alexandre posted:
        movl    -272(%ebp), %eax
        movl    8(%ebp), %edx
        subl    -228(%ebp), %eax
        movl    %eax, 60(%edx)
        movl    -272(%ebp), %ecx
        movzbl  (%ecx), %eax
-
        addl    $1, %ecx
        movl    %ecx, -272(%ebp)
        movl    opcode_targets.9311(,%eax,4), %ecx
        movl    %eax, %ebx
-
        jmp     *%ecx


And this is what ICC 11.0 generates for (what I think is) the same bit:
        movl      360(%esp), %ecx
        movl      %esi, %edi
        subl      304(%esp), %edi
        movl      %edi, 60(%ecx)
        movzbl    (%esi), %ecx 
-
        movl      opcode_targets.2239.0.34(,%ecx,4), %eax
        incl      %esi
-
        jmp       ..B12.137     # Prob 100%
        # ..B12.137: jmp       *%eax  


Does this mean that icc handles register starvation better here?

FWIW, on this CPU, compiling with icc gives a 20% speed boost in pybench
regardless of this patch.

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 03:28:10 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sun, 04 Jan 2009 02:28:10 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231036090.6.0.103983847749.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

1st note: is that code from the threaded version? Note that you need to
modify the source to make it accept also ICC to try that.
In case you already did that, I guess the patch is not useful at all
with ICC since, as far as I can see, the jump is shared. It is vital to
this patch that the jump is not shared, something similar to
-fno-crossjumping should be found.

2nd note: the answer to your questions seems yes, ICC has less register
spills. Look for instance at:
       movl    -272(%ebp), %ecx
       movzbl  (%ecx), %eax
       addl    $1, %ecx

and
       movzbl    (%esi), %ecx
       incl      %esi

This represents the increment of the program counter after loading the
next opcode. In the code you posted, one can see that the program
counter is spilled to memory by GCC, but isn't by ICC. Either the spill
is elsewhere, or ICC is better here. And it's widely known that ICC has
a much better optimizer in many cases, and I remember that GCC register
allocator really needs improvement.

Finally, I'm a bit surprised by "addl $1, %ecx", since any peephole
optimizer should remove that; I'm not shocked just because I've never
seen perfect GCC output.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 03:29:10 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sun, 04 Jan 2009 02:29:10 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231036150.01.0.453840482426.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

Daniel, I forgot to ask for the compilation command line you used, since
they make a lot of difference. Can you post them? Thanks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 04:07:10 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 04 Jan 2009 03:07:10 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1231036090.6.0.103983847749.issue4753@psf.upfronthosting.co.za>
Message-ID: <2d75d7660901031907n580d9d4eu5e7cda5287650fd2@mail.gmail.com>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Paolo 'Blaisorblade' Giarrusso  wrote:
>
> 1st note: is that code from the threaded version? [...] It is vital to
> this patch that the jump is not shared, something similar to
> -fno-crossjumping should be found.

Yes, threaded version by unconditionally defining USE_THREADED_CODE
(old patch version :).

Ok,  I'll try to find a way to get at -fno-crossjumping behavior. BTW,
man gcc suggests using -fno-gcse for programs that use computed gotos
(couldn't fin

[...]
>  In the code you posted, one can see that the program
> counter is spilled to memory by GCC, but isn't by ICC. Either the spill
> is elsewhere, or ICC is better here.
I can [mail you|attach here] icc's output if you want to check the
overall code, it's about 1.9M with the code annotations.

> Finally, I'm a bit surprised by "addl $1, %ecx", since any peephole
> optimizer should remove that; I'm not shocked just because I've never
> seen perfect GCC output.

I'm glad to see the same issue in Alexandre's output, not my fault then :D

The command line I used (after a clean build with gcc) was:
icc  -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -w  -I.
-IInclude -I./Include   -DPy_BUILD_CORE  -S -fcode-asm -fsource-asm
-dA Python/ceval.c

(same as with gcc, except for warnings and -fcode-asm -fsource-asm).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 05:16:15 2009
From: report at bugs.python.org (xverify)
Date: Sun, 04 Jan 2009 04:16:15 +0000
Subject: [issue4826] exec() docstring bug about file objects
In-Reply-To: <1231042574.98.0.745471149157.issue4826@psf.upfronthosting.co.za>
Message-ID: <1231042574.98.0.745471149157.issue4826@psf.upfronthosting.co.za>


New submission from xverify <xverify at yahoo.com>:

exec() no longer accepts a file object but its docstring states otherwise.

----------
assignee: georg.brandl
components: Documentation
messages: 79036
nosy: georg.brandl, xverify
severity: normal
status: open
title: exec() docstring bug about file objects
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4826>
_______________________________________

From report at bugs.python.org  Sun Jan  4 05:51:14 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 04 Jan 2009 04:51:14 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231044674.89.0.486573368494.issue4753@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Paolo wrote:
> So, can you try dropping the switch altogether, using always computed
> goto and seeing how does the resulting code get compiled?

Removing the switch won't be possible unless we change the semantic
EXTENDED_ARG. In addition, I doubt the improvement, if any, would worth
the increased complexity.

> To be absolutely clear: x86_64 has more registers, so the rest of the
> interpreter is faster than x86, but dispatch still takes the same
> absolute time, which is 70% on x86_64, but only 50% on x86 (those are
> realistic figures);

I don't understand what you mean by "absolute time" here. Do you
actually mean the time spent interpreting bytecodes compared to the time
spent in the other parts of Python? If so, your figures are wrong for
CPython on x86-64. It is about 50% just like on x86 (when running
pybench). With the patch, this drops to 35% on x86-64 and to 45% on x86.

> In my toy interpreter, computing last_i for each dispatch doesn't give
> any big slowdown, but storing it in f->last_i gives a ~20% slowdown.

I patched ceval.c to minimize f->last_i manipulations in the dispatch
code.  On x86, I got an extra 9% speed up on pybench. However, the patch
is a bit clumsy and a few unit tests are failing. I will see if I can
improve it and open a new issue if worthwhile.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 06:35:24 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sun, 04 Jan 2009 05:35:24 +0000
Subject: [issue3087] Clean up Demos and Tools
In-Reply-To: <1213238540.5.0.535212077097.issue3087@psf.upfronthosting.co.za>
Message-ID: <1231047323.9.0.143817390834.issue3087@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

+1

In Tkinter there is still import Tkinter and not import tkinter.

----------
nosy: +geon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3087>
_______________________________________

From report at bugs.python.org  Sun Jan  4 07:50:43 2009
From: report at bugs.python.org (Jason Kankiewicz)
Date: Sun, 04 Jan 2009 06:50:43 +0000
Subject: [issue4827] optparse: Callback example 1 is confusing
In-Reply-To: <1231051843.8.0.720726802561.issue4827@psf.upfronthosting.co.za>
Message-ID: <1231051843.8.0.720726802561.issue4827@psf.upfronthosting.co.za>


New submission from Jason Kankiewicz <jkankiewicz at acm.org>:

"Callback example 1: trivial callback" reads

    Here?s an example of a callback option that takes no arguments, and
simply records that the option was seen:

        def record_foo_seen(option, opt_str, value, parser):
            parser.saw_foo = True

        parser.add_option("--foo", action="callback",
callback=record_foo_seen)

but the following paragraph

    Of course, you could do that with the store_true action.

is wrong because

        parser.add_option("--foo", action="store_true", dest="saw_foo")

would actually be duplicated by

        def record_foo_seen(option, opt_str, value, parser):
            parser.values.saw_foo = True

        parser.add_option("--foo", action="callback",
callback=record_foo_seen)

For example:
>>> from optparse import OptionParser
>>> parser = OptionParser()
>>> def record_foo_seen(option, opt_str, value, parser):
...     parser.saw_foo = True
...
>>> parser.add_option("--foo", action="callback", callback=record_foo_seen)
<Option at 0xab4f58: --foo>
>>> parser.parse_args(['--foo'])
(<Values at 0xabb0f8: {}>, [])
>>> parser = OptionParser()
>>> parser.add_option("--foo", action="store_true", dest="saw_foo")
<Option at 0xabb1e8: --foo>
>>> parser.parse_args(['--foo'])
(<Values at 0xabb1c0: {'saw_foo': True}>, [])
>>> parser = OptionParser()
>>> def record_foo_seen(option, opt_str, value, parser):
...     parser.values.saw_foo = True
...
>>> parser.add_option("--foo", action="callback", callback=record_foo_seen)
<Option at 0xabb508: --foo>
>>> parser.parse_args(['--foo'])
(<Values at 0xabb3f0: {'saw_foo': True}>, [])

----------
assignee: georg.brandl
components: Documentation
messages: 79039
nosy: georg.brandl, jkankiewicz
severity: normal
status: open
title: optparse: Callback example 1 is confusing
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4827>
_______________________________________

From report at bugs.python.org  Sun Jan  4 08:19:53 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 04 Jan 2009 07:19:53 +0000
Subject: [issue4811] invalid reST markup in several documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1231053593.44.0.597159523486.issue4811@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This patch includes some (sort of) checker for suspicious constructs 
that resembles markup that has leaked into the final output.

It's a new Builder for Sphinx, and works with the docutils nodes, not 
the source files directly.

"doc-Makefile.diff" updates both make.bat and the Makefile, adding a 
new target "suspicious".

The "ignored.csv" file contains the rules to discard false positives.

"builder.diff" updates builder.py in Sphinx, adding a new builder 
implemented in suspicious.py; the source code has some comments 
explaining how it's used.

Execute `make suspicious`, a "suspicious.csv" file is created in build/
suspicious containing one line per issue found.

Currently, the only relevant message I get is about the :makevar: role 
usage in c-api/init.rst -- looks like docutils doesn't properly 
processes it.

There is something I don't like in the code -- suspicious.py is 
generic, lives inside the Sphinx directory, but knows not to process 
the "documenting" directory inside Python [there are too much false 
positives there -- most of the examples contain actual reST markup]. 
But I don't know enough of Sphinx to make it better :(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4811>
_______________________________________

From report at bugs.python.org  Sun Jan  4 09:26:46 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Jan 2009 08:26:46 +0000
Subject: [issue4825] TypeError with complex.real() and complex.imag()
In-Reply-To: <1231027955.73.0.619900873026.issue4825@psf.upfronthosting.co.za>
Message-ID: <1231057606.21.0.0630999419651.issue4825@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4825>
_______________________________________

From report at bugs.python.org  Sun Jan  4 09:56:11 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 04 Jan 2009 08:56:11 +0000
Subject: [issue4811] invalid reST markup in several documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1231059371.08.0.366158863697.issue4811@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Added file: http://bugs.python.org/file12579/suspicious.rar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4811>
_______________________________________

From report at bugs.python.org  Sun Jan  4 11:09:06 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Sun, 04 Jan 2009 10:09:06 +0000
Subject: [issue4828] patch suggestion for webbrowser
Message-ID: <1231063746.09.0.618225413584.issue4828@psf.upfronthosting.co.za>


Changes by Yinon Ehrlich <yinoneh at users.sourceforge.net>:


----------
components: Library (Lib)
files: webbrowser.patch
keywords: patch
nosy: Yinon
severity: normal
status: open
title: patch suggestion for webbrowser
versions: Python 2.6
Added file: http://bugs.python.org/file12580/webbrowser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4828>
_______________________________________

From report at bugs.python.org  Sun Jan  4 11:13:19 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Sun, 04 Jan 2009 10:13:19 +0000
Subject: [issue4828] patch suggestion for webbrowser
In-Reply-To: <1231063999.69.0.0846570539702.issue4828@psf.upfronthosting.co.za>
Message-ID: <1231063999.69.0.0846570539702.issue4828@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

this will find applications/batch files  
ending with .com or .cmd too.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4828>
_______________________________________

From report at bugs.python.org  Sun Jan  4 11:25:00 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Jan 2009 10:25:00 +0000
Subject: [issue4811] invalid reST markup in several documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1231064700.62.0.314304927579.issue4811@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks very much! I've added this to the Python doc tools in r68290.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4811>
_______________________________________

From report at bugs.python.org  Sun Jan  4 12:17:18 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 04 Jan 2009 11:17:18 +0000
Subject: [issue4829] confusing error for file("foo", "w++")
In-Reply-To: <1231067838.12.0.558588021919.issue4829@psf.upfronthosting.co.za>
Message-ID: <1231067838.12.0.558588021919.issue4829@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

Specifying the '+' more than once while opening a file results in the
error "Must have exactly one of read/write/append mode". The attached
patch extends that with ".. and at most one optional plus".

Further, the patch checks these after the loop that parses the mode
string, avoiding some unnecessary gotos and saving a few lines of code
overall.

----------
components: Interpreter Core
files: python-2.7-fopen-mode-parsing.0.patch
keywords: patch
messages: 79043
nosy: eckhardt
severity: normal
status: open
title: confusing error for file("foo", "w++")
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12581/python-2.7-fopen-mode-parsing.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4829>
_______________________________________

From report at bugs.python.org  Sun Jan  4 12:25:38 2009
From: report at bugs.python.org (Cem Karan)
Date: Sun, 04 Jan 2009 11:25:38 +0000
Subject: [issue4830] regrtest.py -u largefile test_io fails on OS X 10.5.6
In-Reply-To: <1231068337.9.0.535376390894.issue4830@psf.upfronthosting.co.za>
Message-ID: <1231068337.9.0.535376390894.issue4830@psf.upfronthosting.co.za>


New submission from Cem Karan <cfkaran2+python at gmail.com>:

I'm running OS X 10.5.6 (uname -a == Darwin 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 
24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386) I get the following 
error after compiling Python 3.0.  Note that I have NOT installed it; I'm just trying 
to run the regression tests on the build.

Python-3.0 cfkaran2$ ./Lib/test/regrtest.py -u largefile test_io
  File "./Lib/test/regrtest.py", line 183
    print(msg, file=sys.stderr)
                   ^
SyntaxError: invalid syntax

I suspect that tester is not using the newly built python 3.0, but is using whatever 
is installed on the system, though I have not checked this at all.

----------
components: Tests
messages: 79044
nosy: ironsmith
severity: normal
status: open
title: regrtest.py -u largefile test_io fails on OS X 10.5.6
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4830>
_______________________________________

From report at bugs.python.org  Sun Jan  4 12:31:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Jan 2009 11:31:57 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1231068717.34.0.446309042013.issue4796@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Raymond,

Do you think it would be worth replacing the two uses of
conditional expressions in Decimal.from_float with if-else
statements?

Alex Goretoy pointed out (on c.l.p) that the trunk version of
decimal.py can no longer be imported into Python 2.4 (and 2.3).
I don't know how much this matters, but it seems to go against
the comments about 2.3 compatibility at the top of decimal.py.
I admit that I don't really understand the motivation for these
comments, or whether they're still relevant 4 versions on
from Python 2.3.

Of course, from_float still won't work with earlier versions
of Python, but having one Decimal method unavailable seems
like a lesser crime than making 'import decimal' fail.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sun Jan  4 12:38:15 2009
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Prante?=)
Date: Sun, 04 Jan 2009 11:38:15 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1231069095.65.0.172520893907.issue1628484@psf.upfronthosting.co.za>


J?rg Prante <joergprante at gmx.de> added the comment:

Hi Bob, thank you for your patch. I spent hours on Solaris 10 SPARC to
get almost the same analysis. Just a detail, I ended up patching
$LDFLAGS in the SunOS 5 part in the configure.in file (like other
architectures like Darwin have set their LDFLAGS there, too).

Now I'm hoping that the Python team will accept this patch. Otherwise it
will be very hard and complicated for everybody else to set up a build
process for a 64-bit Python together with 32-bit Python on Solaris.

----------
nosy: +jprante

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Jan  4 12:43:05 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 04 Jan 2009 11:43:05 +0000
Subject: [issue4706] try to build a C module,
	but don't worry if it doesn't work
In-Reply-To: <1229782192.75.0.491587462854.issue4706@psf.upfronthosting.co.za>
Message-ID: <1231069385.19.0.820030341764.issue4706@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I can see two cases here:

1/ a compiler is not found, and build_ext can't proceed
2/ a compiler is found but it fails

For 2/, I don't think it's wise to fail silently if a compiler is found
and the build fails, because that can hide an unexpected problem.

For 1/ I would go for a binary distribution, or for a source
distribution that is specific to Linux in your case, if the extensions
are specific to other platforms. The latter could be done in the same
setup.py if needed by declaring the extensions only on matching platforms.

But I can see the benefit of a source distribution with optional
extensions in general. In that case, I think this option would have to
be declared optionally for each extension to be able to fail properly if
one extension is mandatory.

----------
nosy: +tarek
priority:  -> normal
type:  -> feature request
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4706>
_______________________________________

From report at bugs.python.org  Sun Jan  4 12:56:21 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 04 Jan 2009 11:56:21 +0000
Subject: [issue4524] Build fails at running build_scripts
In-Reply-To: <1228405342.46.0.981738131113.issue4524@psf.upfronthosting.co.za>
Message-ID: <1231070181.59.0.348173170019.issue4524@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I will write an isolated test in distutils to reproduce this issue,

----------
assignee:  -> tarek
components: +Distutils
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4524>
_______________________________________

From report at bugs.python.org  Sun Jan  4 13:01:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 04 Jan 2009 12:01:24 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1231070484.18.0.697412734414.issue4394@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I have fixed issue4400, and I am back at work for this feature. 

I will propose it in Distutils-SIG to see what people think.

----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Sun Jan  4 13:36:35 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 12:36:35 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1231072595.93.0.319441964239.issue3783@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Hopefully I'm not picking at a scab here.  I updated the dbm.sqlite
module in the sandbox.  It now orders by rowid instead of by key.
(I saw no performance penalty for the small table sizes I was using
to ordering.  I switched from ordering by key to ordering by rowid
based on Gerhard's comment.

I got a big performance boost on writes by only committing once every
100 calls to __setitem__.  I still commit when deleting keys and 
explicitly commit when closing.

The main performance bottleneck now appears to be keys() and iterkeys().
I don't see how to make them any simpler.  Oddly enough, it seems
that iterkeys() is slower than keys().  Maybe it's just lack of sleep
but I can't see why this is so.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sun Jan  4 14:11:35 2009
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 04 Jan 2009 13:11:35 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231074695.92.0.651555942477.issue4753@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 14:14:17 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 13:14:17 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231074857.79.0.91001529339.issue4753@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I'm sure this is the wrong place to bring this up, but I had a
thought about simple JIT compilation coupled with the opcode
dispatch changes in this issue.

Consider this silly function:

    >>> def f(a, b):
    ...   result = 0
    ...   while b:
    ...     result += a
    ...     b -= 1
    ...   return result
    ... 

which compiles to

      2           0 LOAD_CONST               1 (0)
		  3 STORE_FAST               2 (result)

      3           6 SETUP_LOOP              32 (to 41)
	    >>    9 LOAD_FAST                1 (b)
		 12 JUMP_IF_FALSE           24 (to 39)
		 15 POP_TOP             

      4          16 LOAD_FAST                2 (result)
		 19 LOAD_FAST                0 (a)
		 22 INPLACE_ADD         
		 23 STORE_FAST               2 (result)

      5          26 LOAD_FAST                1 (b)
		 29 LOAD_CONST               2 (1)
		 32 INPLACE_SUBTRACT    
		 33 STORE_FAST               1 (b)
		 36 JUMP_ABSOLUTE            9
	    >>   39 POP_TOP             
		 40 POP_BLOCK           

      6     >>   41 LOAD_FAST                2 (result)
		 44 RETURN_VALUE        

What if you built and compiled a "Mini Me" version of
PyEval_EvalFrameEx on-the-fly which only contained the prologue and
epilog of the real function and a small switch statement which only
knew about the the byte-code instructions used by f()?  Would the
compiler be better able to optimize the code?  Would the
instructions' placement nearer to each other provide better cache
behavior?  Would branch prediction by CPU be improved?

Another possibility would be to eliminate the for(;;) ... switch
altogether and just inline the code for the individual instructions.
It would help if the body of each bytecode instruction was
implemented as a macro, e.g.:

    #define _POP_TOP() \
	PREDICTED(POP_TOP); \
	TARGET(POP_TOP) \
	v = POP(); \
	Py_DECREF(v); \
	FAST_DISPATCH();

The above function could (lots of hand-waving here) be "compiled" to
something like

    PyObject *
    _MiniMe(PyFrameObject *f, int throwflag)
    {
	_PyEVAL_FRAMEEX_PROLOG

	_LOAD_CONST(1)
	_STORE_FAST(2)
	_SETUP_LOOP(_41)
    _9:
	_LOAD_FAST(1)
	_JUMP_IF_FALSE(_39)
	_POP_TOP()
	_LOAD_FAST(2)
	_LOAD_FAST(0)
	_INPLACE_ADD()
	_STORE_FAST(2)
    _26:
	_LOAD_FAST(1)
	_LOAD_CONST(2)
	_INPLACE_SUBTRACT()
	_STORE_FAST(1)
	_JUMP_ABSOLUTE(_9)
    _39:
	_POP_TOP()
	_POP_BLOCK()
	_LOAD_FAST(2)
	_RETURN_VALUE()

	_PyEVAL_FRAMEEX_EPILOG
    }

and the resulting binary code saved as an attribute of the code
object.  Presumably there would be some decision made about whether
to compile a function into this form (maybe only after it's been
called N times?).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 14:17:05 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sun, 04 Jan 2009 13:17:05 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1231075025.37.0.0686854775996.issue4815@psf.upfronthosting.co.za>


Pavel Kosina <geon at post.cz> added the comment:

With this file  - hello.py (attached) - I should be also asked for
converting to utf8. When I open it, nothing changes, after making
changes and saving then the encodings is my windows standard cp1250 ....

Added file: http://bugs.python.org/file12582/hello.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sun Jan  4 14:21:18 2009
From: report at bugs.python.org (Ralph Corderoy)
Date: Sun, 04 Jan 2009 13:21:18 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231075278.48.0.889978003572.issue4753@psf.upfronthosting.co.za>


Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk> added the comment:

Regarding compressing the opcode table to make better use of cache; 
what if the most frequently occurring opcodes where placed together,
e.g. the opcodes were ordered by frequency, most frequent first.  Just
based on a one-off static analysis of a body of code.  A level one cache
line can be, what, 64 bytes == 16 32-bit pointers.

----------
nosy: +ralph.corderoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 14:22:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 Jan 2009 13:22:32 +0000
Subject: [issue4136] merge json library with simplejson 2.0.3
In-Reply-To: <1224194929.7.0.263636117378.issue4136@psf.upfronthosting.co.za>
Message-ID: <000e0cd6abb2df64c2045fa810dc@google.com>


Martin v. L?wis <martin at v.loewis.de> added the comment:

http://codereview.appspot.com/7311/diff/1/8
File Lib/json/decoder.py (right):

http://codereview.appspot.com/7311/diff/1/8#newcode55
Line 55: def py_scanstring(s, end, encoding=None, strict=True,
_b=BACKSLASH, _m=STRINGCHUNK.match):
This function should get some comments what all the various cases are
(preferably speaking with the terms of JSON spec, i.e. chars, char, ...)

http://codereview.appspot.com/7311/diff/1/8#newcode71
Line 71: _append(content)
# 3 cases: end of string, control character, escape sequence

http://codereview.appspot.com/7311/diff/1/8#newcode76
Line 76: msg = "Invalid control character {0!r} at".format(esc)
esc isn't assigned until a few lines later. Is this really correct?

http://codereview.appspot.com/7311/diff/1/8#newcode104
Line 104: raise ValueError
No message?

http://codereview.appspot.com/7311/diff/1/8#newcode107
Line 107: raise ValueError
No message?

http://codereview.appspot.com/7311/diff/1/8#newcode111
Line 111: m = unichr(uni)
What's the purpose of m?

http://codereview.appspot.com/7311/diff/1/8#newcode127
Line 127: nextchar = s[end:end + 1]
Why not s[end]? Add comment if this is necessary.

http://codereview.appspot.com/7311/diff/1/8#newcode132
Line 132: nextchar = s[end:end + 1]
Likewise. There are more places where it does slicing, but also places
where it does indexing, in this function.

http://codereview.appspot.com/7311/diff/1/8#newcode290
Line 290: following strings: -Infinity, Infinity, NaN.
This sounds like an incompatible change.

http://codereview.appspot.com/7311/diff/1/8#newcode317
Line 317: def raw_decode(self, s, idx=0):
That looks like an incompatible change

http://codereview.appspot.com/7311/diff/1/9
File Modules/_json.c (right):

http://codereview.appspot.com/7311/diff/1/9#newcode196
Line 196: output_size *= 2;
You might want to check for integer overflow here.

http://codereview.appspot.com/7311/diff/1/9#newcode215
Line 215: ascii_escape_str(PyObject *pystr)
Please attach a comment to each function, telling what the function
does.

http://codereview.appspot.com/7311/diff/1/9#newcode733
Line 733: "..."
Some text should probably be added here.

http://codereview.appspot.com/7311/diff/1/9#newcode1320
Line 1320: if ((idx + 3 < length) && str[idx + 1] == 'u' && str[idx + 2]
== 'l' && str[idx + 3] == 'l') {
Is this really faster than a strncmp?

http://codereview.appspot.com/7311/diff/1/9#newcode1528
Line 1528: PyTypeObject PyScannerType = {
I think scanner objects should participate in cyclic gc.

http://codereview.appspot.com/7311/diff/1/9#newcode2025
Line 2025: "make_encoder",       /* tp_name */
That is a confusing type name. How about "Encoder"?

http://codereview.appspot.com/7311

----------
title: merge json library with simplejson 2.0.4 -> merge json library with simplejson 2.0.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4136>
_______________________________________

From report at bugs.python.org  Sun Jan  4 14:22:40 2009
From: report at bugs.python.org (Ralph Corderoy)
Date: Sun, 04 Jan 2009 13:22:40 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231075360.1.0.666827736854.issue4753@psf.upfronthosting.co.za>


Changes by Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 14:38:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 Jan 2009 13:38:58 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1231075025.37.0.0686854775996.issue4815@psf.upfronthosting.co.za>
Message-ID: <4960BBF0.7000006@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> With this file  - hello.py (attached) - I should be also asked for
> converting to utf8.

Why that? This file is already encoded in utf-8 just fine. It is,
simultaneously, also encoded in ASCII, cp1250, cp1252, and nearly
any other encoding in use (as long as it is ASCII-based).

> When I open it, nothing changes, after making
> changes and saving then the encodings is my windows standard cp1250 ....

What did you do to find that out?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sun Jan  4 14:40:48 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sun, 04 Jan 2009 13:40:48 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231076448.48.0.957396810574.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

@Alexandre:
> > So, can you try dropping the switch altogether, using always computed
> > goto and seeing how does the resulting code get compiled?

> Removing the switch won't be possible unless we change the semantic
> EXTENDED_ARG. In addition, I doubt the improvement, if any, would worth
> the increased complexity.
OK, it's time that I post code to experiment with that - there is no
need to break EXTENDED_ARG. And the point is to fight miscompilations.

> Do you actually mean the time spent interpreting bytecodes compared to
the time spent in the other parts of Python? If so, your figures are
wrong for CPython on x86-64. It is about 50% just like on x86 (when
running pybench). With the patch, this drops to 35% on x86-64 and to 45%
on x86.

More or less, I mean that, but I was making an example, and I made up
reasonable figures.
70%, or even more, just for _dispatch_ (i.e. just for the mispredicted
indirect jump), is valid for real-world Smalltalk interpreters for
instance, or for the ones in "The Structure and Performance of Efficient
Interpreters".
But, when you say "intepreting opcodes", I do not know which part you
refer to, if just the computed goto or for the whole code in the
interpreter function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 15:00:09 2009
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Prante?=)
Date: Sun, 04 Jan 2009 14:00:09 +0000
Subject: [issue1529269] Python 2.5b2 fails to build on Solaris 10 (GCC
	Compiler)
Message-ID: <1231077609.22.0.794565048839.issue1529269@psf.upfronthosting.co.za>


J?rg Prante <joergprante at gmx.de> added the comment:

Modules/_ctypes/libffi/src/sparc/v8.S and
Modules/_ctypes/libffi/src/sparc/v9.S are SPARC assembler codes.

The python build process seems to pass the gcc compile flags to compile
these assembler source files.

It makes no sense if the debugging option -g is enabled, because C
source debugging code can not be generated in the case of assembler
code. The Solaris linker is also confused about this and might send the
relocation / alignment errors later.

So, as a workaround, just do not pass the gcc "-g" option to the python
build process when building with Solaris / gcc.

A clean solution would be to avoid gcc C compiler options being passed
to assembler source compiling in the python build process.

----------
nosy: +jprante

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529269>
_______________________________________

From report at bugs.python.org  Sun Jan  4 15:38:37 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sun, 04 Jan 2009 14:38:37 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231079917.58.0.180978359741.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

@Skip: if one decides to generate binary code, there is no need to use
switches. Inline threading (also known as "code copying" in some
research papers) is what you are probably looking for:

http://blog.mozilla.com/dmandelin/2008/08/27/inline-threading-tracemonkey-etc/

For references and background on threading techniques mentioned there, see:

http://en.wikipedia.org/wiki/Threaded_code
http://www.complang.tuwien.ac.at/forth/threaded-code.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 15:52:37 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sun, 04 Jan 2009 14:52:37 +0000
Subject: [issue4831] exec() behavior - revisited
In-Reply-To: <1231080757.34.0.371299910719.issue4831@psf.upfronthosting.co.za>
Message-ID: <1231080757.34.0.371299910719.issue4831@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

Please forgive me, but I'm really trying to wrap my brain around the 
behavior of exec() in Python 3.   Here's a quote from the documentation:

   "In all cases, if the optional parts are omitted, the code is
    executed in the current scope."

This is referring to the optional use of the globals/locals parameters 
and seems to indicate that if they're omitted the code executes in the 
scope where the exec() appeared.

Yet, this code fails:

def foo():
    exec("a = 42")
    print(a)         # NameError: a

Now, I realize that exec() became a function in Python 3.  However, 
regardless of that, is it really the intent that exec() not be allowed 
to ever modify any local variable of a function?   In other words, do I 
really have to do this?

def foo():
    ldict = locals()
    exec("a=42",globals(),ldict)
    a = ldict['a']
    print(a)

I submitted a bug report about this once before and it was immediately 
dismissed.   

I would appreciate some greater clarity on this matter this go around.  
Specifically, what is the approved way to have exec() modify the local 
environment of a function?

----------
components: Interpreter Core
messages: 79059
nosy: beazley
severity: normal
status: open
title: exec() behavior - revisited
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4831>
_______________________________________

From report at bugs.python.org  Sun Jan  4 15:54:18 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sun, 04 Jan 2009 14:54:18 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <4960BBF0.7000006@v.loewis.de>
Message-ID: <4960CD9D.7070802@post.cz>


Pavel Kosina <geon at post.cz> added the comment:

Martin v. L?wis napsal(a), dne 4.1.2009 14:39:
> Why that? This file is already encoded in utf-8 just fine. It is,
> simultaneously, also encoded in ASCII, cp1250, cp1252, and nearly
> any other encoding in use (as long as it is ASCII-based).
>   

Well I am not much experienced but this file is not real utf8. It is 
encoded in ascii, cp1250, cp1252, and many other but not in utf8. utf8 
has a special flag, special bytes inside  - as a special mark for 
editors. That is what this file doesnt have. Even after making change in 
it in IDLE, it does not became real utf8. I always check it in another 
editor, that can work with encoding very well - PSPad.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:13:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Jan 2009 15:13:14 +0000
Subject: [issue4831] exec() behavior - revisited
In-Reply-To: <1231080757.34.0.371299910719.issue4831@psf.upfronthosting.co.za>
Message-ID: <1231081994.64.0.319389448223.issue4831@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> Please forgive me, but I'm really trying to wrap my brain around the 
> behavior of exec() in Python 3.   Here's a quote from the documentation:

>    "In all cases, if the optional parts are omitted, the code is
>     executed in the current scope."

> This is referring to the optional use of the globals/locals parameters 
> and seems to indicate that if they're omitted the code executes in the 
> scope where the exec() appeared.

That's right, but in some cases the locals can't be changed.  I'll
document this better.

> Now, I realize that exec() became a function in Python 3.  However, 
> regardless of that, is it really the intent that exec() not be allowed 
> to ever modify any local variable of a function?   In other words, do I 
> really have to do this?

> def foo():
>     ldict = locals()
>     exec("a=42",globals(),ldict)
>     a = ldict['a']
>     print(a)

Yes, if you really need "a" as a local afterwards.

> I would appreciate some greater clarity on this matter this go around.  
> Specifically, what is the approved way to have exec() modify the local 
> environment of a function?

There is none.  To modify the locals of a function on the fly is not
possible without several consequences: normally, function locals are not
stored in a dictionary, but an array, whose indices are determined at
compile time from the known locales.  This collides at least with new
locals added by exec.  The old exec statement circumvented this, because
the compiler knew that if an exec without globals/locals args occurred
in a function, that namespace would be "unoptimized", i.e. not using the
locals array.  Since exec() is now a normal function, the compiler does
not know what "exec" may be bound to, and therefore can not treat is
specially.

----------
assignee:  -> georg.brandl
components: +Documentation -Interpreter Core
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4831>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:16:02 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sun, 04 Jan 2009 15:16:02 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>


New submission from Pavel Kosina <geon at post.cz>:

There should not be necessity to write filename *with extension* at the
saving dialog. It should be enough, at least on Windows, to put there
just "hello" and get "hello.py". It is really complication especially
for beginners. If they, as they are used to from another programs, put
there just "hello", it is saved without extension ".py" what have 2
result: they cannot see any icons at that file and they are not able to
run in, cause python.exe is bind with ".py".

Hoping its not duplicate I haven't found anything like this here.

----------
components: IDLE
messages: 79062
nosy: geon
severity: normal
status: open
title: idle filename extension
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:18:53 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sun, 04 Jan 2009 15:18:53 +0000
Subject: [issue4831] exec() behavior - revisited
In-Reply-To: <1231080757.34.0.371299910719.issue4831@psf.upfronthosting.co.za>
Message-ID: <1231082333.5.0.485185547161.issue4831@psf.upfronthosting.co.za>


David M. Beazley <beazley at users.sourceforge.net> added the comment:

One further followup just to make sure I'm clear.

Is it always safe to pass the result of locals() into exec and extract 
the result as shown in my example?  

Since I'm writing about this in a book, I just want to make absolutely 
certain I know what's going on and that I don't tell people something 
that's completely bogus.

Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4831>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:23:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Jan 2009 15:23:39 +0000
Subject: [issue4831] exec() behavior - revisited
In-Reply-To: <1231080757.34.0.371299910719.issue4831@psf.upfronthosting.co.za>
Message-ID: <1231082619.2.0.631582651481.issue4831@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, the dictionary will always contain "a" afterwards.

However, a cleaner way would be to use locals().copy(), or, if you don't
need current locals in the exec'd string, just a fresh dict.

In scopes not using the optimized locals, there may be some other
effects when using the dict returned by locals() directly:
* in module scopes, the dictionary returned by locals() is the same as
the globals() one
* in class scopes, the locals() dict is actually the local scope of the
class

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4831>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:26:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Jan 2009 15:26:03 +0000
Subject: [issue4506] 3.0 make test failures on Solaris 10
In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local>
Message-ID: <1231082763.86.0.737119503906.issue4506@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

autoconf checks for isinf and isnan fixed in r68299.
I also added a check for isfinite, which should really be used in 
preference to finite:  isfinite is standard in C99, while finite doesn't 
seem to be part of any standard.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4506>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:30:53 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Jan 2009 15:30:53 +0000
Subject: [issue4826] exec() docstring bug about file objects
In-Reply-To: <1231042574.98.0.745471149157.issue4826@psf.upfronthosting.co.za>
Message-ID: <1231083053.84.0.911456618492.issue4826@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks! Fixed in r68301.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4826>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:38:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 15:38:35 +0000
Subject: [issue4830] regrtest.py -u largefile test_io fails on OS X 10.5.6
In-Reply-To: <1231068337.9.0.535376390894.issue4830@psf.upfronthosting.co.za>
Message-ID: <1231083515.17.0.0276615422959.issue4830@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, you must indeed use the newly built python, that is "./python -m
test.regrtest [any arguments]".

Out of curiosity, why did you specifically run test_io? Any problem on
your platform?

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4830>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:39:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 15:39:21 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1231083561.29.0.175407989738.issue1628484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file10527/DigiLink_esig_logo.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:39:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 15:39:25 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1231083565.68.0.251887450257.issue1628484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file10525/DigiLink_esig_logo.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:39:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 15:39:30 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1231083570.16.0.909051931449.issue1628484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:39:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 15:39:35 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1231083575.28.0.616195066613.issue1628484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:39:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 15:39:40 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1231083580.38.0.779929446014.issue1628484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Jan  4 16:39:44 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 15:39:44 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1231083584.39.0.16030434224.issue1628484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Jan  4 17:04:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 Jan 2009 16:04:33 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <4960CD9D.7070802@post.cz>
Message-ID: <4960DE0E.9070805@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> utf8 has a special flag

No, it doesn't.

> as a special mark for editors.

That's the BOM, or UTF-8 signature. It's optional, and UTF-8-encoded
files typically do *not* have the UTF-8 signature.

> Even after making change in 
> it in IDLE, it does not became real utf8. 

Your understanding of UTF-8 is incorrect.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sun Jan  4 17:27:56 2009
From: report at bugs.python.org (David Moss)
Date: Sun, 04 Jan 2009 16:27:56 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1231086476.85.0.118602079039.issue3959@psf.upfronthosting.co.za>


David Moss <drkjam at gmail.com> added the comment:

> David, in the event of netaddr's complete or partial inclusion, 
> are you +1 with this and the maintenance of an ip/net library 
> in Python?

Yes, I would be very happy to help with this.

> If there's going to be lots of discussion, perhaps it should be 
> taken to python-dev?

Good idea.

Peter M. and the ipaddr contributors, are you all happy to proceed in
accordance with Duncan's suggestions? If so, let's kick off a thread on
python-dev to get the ball rolling and see what we can come up with.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Sun Jan  4 18:09:29 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Sun, 04 Jan 2009 17:09:29 +0000
Subject: [issue4833] Explicit directories for zipfiles
In-Reply-To: <1231088968.72.0.101458538333.issue4833@psf.upfronthosting.co.za>
Message-ID: <1231088968.72.0.101458538333.issue4833@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

We have an issue with the Python cheeseshop which is probably an issue
with Python itself as well.

When we create a zip file with standard linux tools ('zip os-zipped.zip
*'), uploading it works fine. But if we use the zipfile module from
Python and try to upload the result to the cheeseshop, we get this error
message:

" Error unpacking zipfile:[Errno 2] No such file or directory: 
u'/data/packagedocs/Pympler/_sources/index.txt'"

Turns out that the Python-zipped version does not include explicit
directories. The OS-zipped version contains "directory/,
directory/asizeof.txt", the Python-zipped file only
"directory/asizeof.txt". Digging deeper, Python has no way to explicitly
add directories to a zip file.

It would be useful to have an option which allows the explicit creation
of directories inside of zip files. This would help when working with
applications which do not create directories if they are not explicitly
specified.

----------
components: Library (Lib)
messages: 79070
nosy: schuppenies
severity: normal
status: open
title: Explicit directories for zipfiles
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4833>
_______________________________________

From report at bugs.python.org  Sun Jan  4 18:38:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 17:38:27 +0000
Subject: [issue4830] regrtest.py -u largefile test_io fails on OS X 10.5.6
In-Reply-To: <F30326C8-C299-47A1-A581-9344659E8E6C@gmail.com>
Message-ID: <1231090716.7073.3.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Do you know how to get python to  
> run from the locally built directory without installing it?

Well, precisely as I told you, but unfortunately it seems it doesn't
work for you.
I'm no Mac OS X user, so I advise you search the tracker for similar
problems, it seems the build procedure on Mac hasn't been polished yet
for Python 3.0.

(in any case, you can't run Python 3.0 scripts with Python 2.x, because
there have been a few syntax changes)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4830>
_______________________________________

From report at bugs.python.org  Sun Jan  4 18:39:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Jan 2009 17:39:42 +0000
Subject: [issue3638] Remove module level functions in _tkinter that depend on
	TkappObject
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1231090782.23.0.0114563426721.issue3638@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

gpolo: Nice patches, good job and thanks ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sun Jan  4 19:03:21 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Jan 2009 18:03:21 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1231092201.55.0.846586340445.issue4010@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

May I propose a patch. The patch is only for linker flags(LDFLAGS). If
is accepted I will prepare another one for compiler flags.
The patch is not minimal. It is mostly cleanup patch.

For minimal patch - only change in Makefile.pre.in is enough.
Cleanup patch remove work-arounds for the issue.

Added file: http://bugs.python.org/file12583/py-issue-4010.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Sun Jan  4 19:08:01 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 18:08:01 +0000
Subject: [issue4834] Trouble configuring with icc on Mac OS X 10.5
In-Reply-To: <18784.64250.252843.484595@montanaro.dyndns.org>
Message-ID: <18784.64250.252843.484595@montanaro.dyndns.org>


New submission from Skip Montanaro <skip at pobox.com>:

I get this error when trying to configure with Intel's icc on my Mac (Intel,
10.5.6, Xcode 3.1.2):

    >> configure:10332: checking size of size_t
    >> configure:10637: icc -o conftest -g -O2   conftest.c  >&5
    >> ld: library not found for -lgcc_s

After a couple notes to python-dev and a little bit of sleuthing with -v I
discovered that it was generating -lgcc_s instead of -lgcc_s.10.5 in the ld
line.  I narrowed the problem down to this code in configure.in:

            # Calculate the right deployment target for this build.
            #
            cur_target=`sw_vers -productVersion | sed 's/\(10\.[[0-9]]*\).*/\1/'`
            if test ${cur_target} '>' 10.2; then
                    cur_target=10.3
            fi
            if test "${UNIVERSAL_ARCHS}" = "all"; then
                    # Ensure that the default platform for a 4-way
                    # universal build is OSX 10.5, that's the first
                    # OS release where 4-way builds make sense.
                    cur_target='10.5'
            fi
            CONFIGURE_MACOSX_DEPLOYMENT_TARGET=${MACOSX_DEPLOYMENT_TARGET-${cur_target}}

            # Make sure that MACOSX_DEPLOYMENT_TARGET is set in the 
            # environment with a value that is the same as what we'll use
            # in the Makefile to ensure that we'll get the same compiler
            # environment during configure and build time.
            MACOSX_DEPLOYMENT_TARGET="$CONFIGURE_MACOSX_DEPLOYMENT_TARGET"
            export MACOSX_DEPLOYMENT_TARGET
            EXPORT_MACOSX_DEPLOYMENT_TARGET=''

The test of cur_target against 10.2 seems suspicious.  This code dates from
r65061 (checked in by Benjamin last July) which states:

  #3381 fix framework builds on 10.4

Maybe it should be 

            if test ${cur_target} '>' 10.2 -a ${cur_target} '<' 10.5 ; then
                    cur_target=10.3
            fi

(which works).

Skip

----------
messages: 79074
nosy: skip.montanaro
severity: normal
status: open
title: Trouble configuring with icc on Mac OS X 10.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4834>
_______________________________________

From report at bugs.python.org  Sun Jan  4 19:11:43 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 18:11:43 +0000
Subject: [issue4835] SIZEOF_SOCKET_T not defined
In-Reply-To: <18784.64475.338807.986695@montanaro.dyndns.org>
Message-ID: <18784.64475.338807.986695@montanaro.dyndns.org>


New submission from Skip Montanaro <skip at pobox.com>:

Compiling with Intel's icc I get lots of remarks like this:

    icc -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I../Include   -DPy_BUILD_CORE -o Parser/acceler.o ../Parser/acceler.c
    ../Include/longobject.h(35): remark #193: zero used for undefined preprocessing identifier "SIZEOF_SOCKET_T"
      #if SIZEOF_SOCKET_T <= SIZEOF_LONG
          ^

This is only defined in Modules/socketmodule.h.  It should probably be
defined somewhere else if it's to be referenced by longobject.h.

Skip

----------
messages: 79075
nosy: skip.montanaro
severity: normal
status: open
title: SIZEOF_SOCKET_T not defined

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4835>
_______________________________________

From report at bugs.python.org  Sun Jan  4 19:15:20 2009
From: report at bugs.python.org (skillybob)
Date: Sun, 04 Jan 2009 18:15:20 +0000
Subject: [issue4836] Idle Hangs on Wxit Button
Message-ID: <1231092920.48.0.00559753673602.issue4836@psf.upfronthosting.co.za>


Changes by skillybob <skillybob2 at gmail.com>:


----------
components: IDLE
nosy: skillybob
severity: normal
status: open
title: Idle Hangs on Wxit Button
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________

From report at bugs.python.org  Sun Jan  4 19:22:13 2009
From: report at bugs.python.org (skillybob)
Date: Sun, 04 Jan 2009 18:22:13 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231093333.6.0.679938116402.issue4836@psf.upfronthosting.co.za>
Message-ID: <1231093333.6.0.679938116402.issue4836@psf.upfronthosting.co.za>


New submission from skillybob <skillybob2 at gmail.com>:

Bring up IDLE and type in any program. 
Run the module and it runs just fine. 
Try to use the Exit button of the running program and it hangs.
Pressing a second time will bring up a Windows dialog message that the
program is not responding . Click to kill the program and it return to
IDLE .  I have tried the programs with drPython and it works just fine .
I'm using Windows XP SP3 - Python 2.6.1 - and wxPython 2.8 (unicode) 
I have reinstalled Python 2.6.2 and 2.5.4 with no success - 
Any suggestions????

----------
title: Idle Hangs on Wxit Button -> Idle Hangs on exit Button

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________

From report at bugs.python.org  Sun Jan  4 19:52:43 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 04 Jan 2009 18:52:43 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231095163.82.0.00627768954618.issue4753@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

> Removing the switch won't be possible unless we change the semantic
> EXTENDED_ARG. In addition, I doubt the improvement, if any, would worth
> the increased complexity.

Nevermind what I have said. I managed to remove switch pretty easily by
moving opcode fetching in the FAST_DISPATCH macro and abstracting the
control flow of the switch. There is no speed difference on pybench on
x86; on x86-64, the code is slower due to the opcode fetching change.

> I patched ceval.c to minimize f->last_i manipulations in the dispatch
> code.  On x86, I got an extra 9% speed up on pybench. However, the
> patch is a bit clumsy and a few unit tests are failing. I will see
> if I can improve it and open a new issue if worthwhile.

Nevermind that too. I found out f->last_i can be accessed anytime via
frame.getlineno(). So, you cannot really change how f->last_i is used
like I did.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 20:17:39 2009
From: report at bugs.python.org (Somelauw)
Date: Sun, 04 Jan 2009 19:17:39 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231096659.96.0.217779490253.issue4676@psf.upfronthosting.co.za>


Somelauw <Somelauw at yahoo.com> added the comment:

I have found a way to reproduce this error:

\\\\
Open the idle
Hold down shift:
   Press up 3 times
   Hold [fn] (on laptop)
   Press the home key
Idle closes for no reason
////

Any help?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Sun Jan  4 20:21:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Jan 2009 19:21:27 +0000
Subject: [issue4824] test_cmd_line failure on Mac OS X for py3k
In-Reply-To: <18783.62745.773153.314589@montanaro.dyndns.org>
Message-ID: <1231096887.47.0.36476489332.issue4824@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is this the same issue as issue 4388?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4824>
_______________________________________

From report at bugs.python.org  Sun Jan  4 20:29:58 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 04 Jan 2009 19:29:58 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231097398.24.0.00107285569259.issue4753@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

> I managed to remove switch pretty easily by moving opcode fetching
> in the FAST_DISPATCH macro and abstracting the control flow of the
> switch.

Here is the diff against threadceval5.patch.

Added file: http://bugs.python.org/file12584/abstract-switch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan  4 20:33:03 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 19:33:03 +0000
Subject: [issue4824] test_cmd_line failure on Mac OS X for py3k
In-Reply-To: <18783.62745.773153.314589@montanaro.dyndns.org>
Message-ID: <1231097583.43.0.580326049874.issue4824@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Yeah, looks like it.  Closing.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4824>
_______________________________________

From report at bugs.python.org  Sun Jan  4 20:56:33 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Jan 2009 19:56:33 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1231098993.84.0.159056276806.issue4010@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

correct patch uploaded

Added file: http://bugs.python.org/file12585/py-issue-4010.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Sun Jan  4 20:56:43 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Jan 2009 19:56:43 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1231099003.45.0.796195084529.issue4010@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file12583/py-issue-4010.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Sun Jan  4 21:06:54 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 04 Jan 2009 20:06:54 +0000
Subject: [issue4837] Omits MACHINE and DEBUG when building tix8.4.3
In-Reply-To: <1231099614.05.0.848880488218.issue4837@psf.upfronthosting.co.za>
Message-ID: <1231099614.05.0.848880488218.issue4837@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Currently, to install tix we need long command like this.

nmake -f python.mak TCL_MAJOR=8 TCL_MINOR=5 TCL_PATCH=2 MACHINE=IX86 
DEBUG=0 INSTALL_DIR=..\..\tcltk install

This patch enables us to omit MACHINE and DEBUG. (Precisely, can omit 
MACHINE if CPU is i386)

This patch is for http://svn.python.org/projects/external/tix-8.4.3.1

----------
components: Build
files: python_mak_in_tix.patch
keywords: patch
messages: 79083
nosy: ocean-city
priority: low
severity: normal
status: open
title: Omits MACHINE and DEBUG when building tix8.4.3
versions: 3rd party
Added file: http://bugs.python.org/file12586/python_mak_in_tix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4837>
_______________________________________

From report at bugs.python.org  Sun Jan  4 21:13:19 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Jan 2009 20:13:19 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1231099999.67.0.237787825037.issue1628484@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Jan  4 21:20:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 04 Jan 2009 20:20:15 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1231100415.81.0.261111907606.issue4796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Do you think it would be worth replacing the two uses of
> conditional expressions in Decimal.from_float with if-else
> statements?

Yes, please.

> Of course, from_float still won't work with earlier versions
> of Python, but having one Decimal method unavailable seems
> like a lesser crime than making 'import decimal' fail.

Right.  I don't see an easy way around that short of having
a conditional compilation, allowing use of alternative slow
code multiplying the float repeatedly by two to build-up
the float digits.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sun Jan  4 21:24:09 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 04 Jan 2009 20:24:09 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1231100649.56.0.34333613687.issue1180@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
_______________________________________

From report at bugs.python.org  Sun Jan  4 22:10:14 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 04 Jan 2009 21:10:14 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231103414.58.0.687994462401.issue4676@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I can't reproduce this with py3k on linux, but I do get a traceback in
the terminal used to launch idle:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/ajaksu/py3k/Lib/tkinter/__init__.py", line 1399, in __call__
    return self.func(*args)
  File "/home/ajaksu/py3k/Lib/idlelib/MultiCall.py", line 165, in handler
    r = l[i](event)
  File "/home/ajaksu/py3k/Lib/idlelib/EditorWindow.py", line 315, in
home_callback
    if self.text.compare(first,">",last):
  File "/home/ajaksu/py3k/Lib/tkinter/__init__.py", line 2844, in compare
    self._w, 'compare', index1, op, index2))
_tkinter.TclError: expected boolean value but got ""

That only happens sometimes happens, pressing home while holding shift
down does nothing but print the traceback. Else, pressing 'home' holding
shift alternates: start of line, start of indented block.

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Sun Jan  4 22:39:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Jan 2009 21:39:43 +0000
Subject: [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1231105183.29.0.692438467602.issue4272@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patches have been committed, thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________

From report at bugs.python.org  Sun Jan  4 23:15:13 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sun, 04 Jan 2009 22:15:13 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231107313.31.0.796511569639.issue4751@psf.upfronthosting.co.za>


Changes by Lukas Lueg <knabberknusperhaus at yahoo.de>:


Removed file: http://bugs.python.org/file12533/hashopenssl_threads-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sun Jan  4 23:25:07 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sun, 04 Jan 2009 22:25:07 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231107907.08.0.993374442892.issue4751@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

I've modified haypo's patch as commented. The object's lock should be
free 99.9% of the time so we try non-blocking first and can thereby skip
 releasing and re-locking the gil (to avoid a deadlock).

Added file: http://bugs.python.org/file12587/hashlibopenssl_small_lock-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sun Jan  4 23:27:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Jan 2009 22:27:01 +0000
Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86
In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za>
Message-ID: <1231108021.68.0.0341622878581.issue4575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looking at this again, I don't like my solution.

I think it would be better to fix Py_IS_INFINITY directly, putting all the 
complication into one place;  then users of Py_IS_INFINITY don't have to 
spend time worrying about whether they should be calling Py_FORCE_DOUBLE 
or not.

The fixed Py_IS_INFINITY will likely be slower, but this only matters on 
platforms that don't provide isinf, isnan;  it seems that Solaris is the 
only such platform in common use.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4575>
_______________________________________

From report at bugs.python.org  Sun Jan  4 23:37:57 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Jan 2009 22:37:57 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231108677.29.0.0750609351152.issue4751@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12542/hashlibopenssl_small_lock-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sun Jan  4 23:38:01 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Jan 2009 22:38:01 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231108681.35.0.630013303036.issue4751@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12554/hashlibopenssl_small_lock-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Sun Jan  4 23:38:51 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 Jan 2009 22:38:51 +0000
Subject: [issue4834] Trouble configuring with icc on Mac OS X 10.5
In-Reply-To: <18784.64250.252843.484595@montanaro.dyndns.org>
Message-ID: <1231108731.71.0.664907128284.issue4834@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think this is a bug. The change actually dates from r45800; I
believe the intention is that the Python binaries work on 10.3 and
newer, unless you use 10.2 or older to build them (in which case the
deployment target is set to the build machine version).

So I propose to reject this report as invalid.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4834>
_______________________________________

From report at bugs.python.org  Sun Jan  4 23:51:13 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Jan 2009 22:51:13 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <495629E8.1080408@egenix.com>
Message-ID: <200901042351.39426.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The fact that Python 2.x also accepts Unicode ASCII strings 
> where strings are normally expected is intended to help with 
> the migration to Unicode

I hate this behaviour. It doesn't help migration, it's the opposite! Sometimes 
it works (ASCII), and somtimes it fails (just one non-ASCII character). And 
then we will read "Unicode sucks!" because people doesn't understand the 
error.

> In Python 3.x, it's probably better to use bytes throughout the
> API.

I propose to reject unicode in Python 3.x and display a warning for Python 
2.x. A warning to prepare the migration... not to Unicode, but to Python3 ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Sun Jan  4 23:57:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Jan 2009 22:57:10 +0000
Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86
In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za>
Message-ID: <1231109830.06.0.642786551926.issue4575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tim, I'm in need of some advice on Py_IS_INFINITY.  It's currently
implemented (on platforms that don't provide isinf) as

#define Py_IS_INFINITY(X) ((X) && (X)*0.5 == (X))

I'd like to rewrite it as something like:

#define Py_IS_INFINITY_D(X) ((X) < -DBL_MAX || (X) > DBL_MAX)
#define Py_IS_INFINITY_F(X) ((X) < -FLT_MAX || (X) > FLT_MAX)
#define Py_IS_INFINITY(X) (sizeof(X) == sizeof(double) ? Py_IS_INFINITY_D(X) : Py_IS_INFINITY_F(X))

Are there any hidden (or obvious) numerical pitfalls with
this approach?

The reason for the rewrite is that the current Py_IS_INFINITY
can give false positives on x86 for values that are
pretending to be doubles, but are actually coming from an
80-bit x87 register.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4575>
_______________________________________

From report at bugs.python.org  Mon Jan  5 00:01:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Jan 2009 23:01:22 +0000
Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86
In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za>
Message-ID: <1231110082.21.0.312437174688.issue4575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

s/false positives/false negatives/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4575>
_______________________________________

From report at bugs.python.org  Mon Jan  5 00:14:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 Jan 2009 23:14:40 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1231110880.81.0.856041246482.issue4614@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks about right.

I believe it is a bug that md_state isn't automatically freed; m_free
should be used to release any resources stored inside md_state (or any
other resources that the module might hold). So please remove the note
on releasing md_state.

----------
assignee: loewis -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Mon Jan  5 00:14:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Jan 2009 23:14:42 +0000
Subject: [issue4575] Py_IS_INFINITY defect causes test_cmath failure on x86
In-Reply-To: <1228653764.46.0.349797077595.issue4575@psf.upfronthosting.co.za>
Message-ID: <1231110882.09.0.391549325425.issue4575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Answering my own question, there *are* pitfalls: (X) > DBL_LONG_MAX will 
evaluate to true for some finite extended precision values that are *just* 
larger than DBL_LONG_MAX, but nevertheless round to DBL_LONG_MAX rather 
than infinity.

Another not-so-bright idea down the drain...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4575>
_______________________________________

From report at bugs.python.org  Mon Jan  5 00:16:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 Jan 2009 23:16:30 +0000
Subject: [issue4838] md_state is not released
In-Reply-To: <1231110990.47.0.0796872141326.issue4838@psf.upfronthosting.co.za>
Message-ID: <1231110990.47.0.0796872141326.issue4838@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

module_dealloc should free md_state if it is non-zero, after m_free was
called.

----------
messages: 79095
nosy: loewis
priority: release blocker
severity: normal
status: open
title: md_state is not released
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4838>
_______________________________________

From report at bugs.python.org  Mon Jan  5 00:20:37 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Jan 2009 23:20:37 +0000
Subject: [issue4614] Document PyModule_Create()
In-Reply-To: <1228856807.3.0.093975807386.issue4614@psf.upfronthosting.co.za>
Message-ID: <1231111237.82.0.706808477772.issue4614@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, fixed up and committed as r68327.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4614>
_______________________________________

From report at bugs.python.org  Mon Jan  5 00:34:42 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 23:34:42 +0000
Subject: [issue4834] Trouble configuring with icc on Mac OS X 10.5
In-Reply-To: <1231108731.71.0.664907128284.issue4834@psf.upfronthosting.co.za>
Message-ID: <18785.18319.80166.656869@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Martin> I don't think this is a bug. The change actually dates from
    Martin> r45800; I believe the intention is that the Python binaries work
    Martin> on 10.3 and newer, unless you use 10.2 or older to build them
    Martin> (in which case the deployment target is set to the build machine
    Martin> version).

    Martin> So I propose to reject this report as invalid.

I don't see how Python can require an optional piece of Xcode.  I only build
Python for my own use.  I shouldn't be forced to build exeutables which will
run on a version of the operating system I no longer have.  I think the code
in configure.in has to be smarter and detect that the presence or absence of
the 10.3 compatibility bits in Xcode.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4834>
_______________________________________

From report at bugs.python.org  Mon Jan  5 01:16:25 2009
From: report at bugs.python.org (pmoody)
Date: Mon, 05 Jan 2009 00:16:25 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1231086476.85.0.118602079039.issue3959@psf.upfronthosting.co.za>
Message-ID: <8517e9350901041616y3b5dc334t4f91328d22090a46@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

> Good idea.
>
> Peter M. and the ipaddr contributors, are you all happy to proceed in
> accordance with Duncan's suggestions? If so, let's kick off a thread on
> python-dev to get the ball rolling and see what we can come up with.

I'm fine with this. But as Duncan mentioned, some guidance from the
benevolent powers that be on what exactly they're looking for before
we launch into a bunch of work would be appreciated.

Cheers,
/peter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Mon Jan  5 01:36:55 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 05 Jan 2009 00:36:55 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8517e9350901041616y3b5dc334t4f91328d22090a46@mail.gmail.com>
Message-ID: <49615624.8080401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm fine with this. But as Duncan mentioned, some guidance from the
> benevolent powers that be on what exactly they're looking for before
> we launch into a bunch of work would be appreciated.

I think Guido's original message summarizes that: a module that
fills a gap for address manipulations... In addition, it should
have all the organisational qualities (happy user base, determined
maintainers, copyright forms, documentation, tests). As to what
precisely its API should be - that is for the experts (i.e. you)
to determine. I personally think performance is important, in
addition to a well-designed, useful API. Conformance to PEP 8
is also desirable.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Mon Jan  5 02:35:59 2009
From: report at bugs.python.org (Bob Ippolito)
Date: Mon, 05 Jan 2009 01:35:59 +0000
Subject: [issue4136] merge json library with simplejson 2.0.3
In-Reply-To: <1224194929.7.0.263636117378.issue4136@psf.upfronthosting.co.za>
Message-ID: <1231119359.08.0.253225844206.issue4136@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

By "next patch" I'm referring to a currently nonexistent patch that 
would merge the json library with simplejson 2.0.7 (svn trunk at the 
moment). I may have time to create it next weekend.

---

http://codereview.appspot.com/7311/diff/1/8
File Lib/json/decoder.py (right):

http://codereview.appspot.com/7311/diff/1/8#newcode55
Line 55: def py_scanstring(s, end, encoding=None, strict=True,
_b=BACKSLASH, _m=STRINGCHUNK.match):
Commented in the next patch.


http://codereview.appspot.com/7311/diff/1/8#newcode71
Line 71: _append(content)
Commented in the next patch


http://codereview.appspot.com/7311/diff/1/8#newcode76
Line 76: msg = "Invalid control character {0!r} at".format(esc)
This is a bug in the exception handling code, fixed in the next patch.


http://codereview.appspot.com/7311/diff/1/8#newcode104
Line 104: raise ValueError
Exception is caught at the except block and re-raised with a message.
Next patch unrolls this so it's not confusing.


http://codereview.appspot.com/7311/diff/1/8#newcode107
Line 107: raise ValueError
Exception is caught at the except block and re-raised with a message.
Next patch unrolls this so it's not confusing.


http://codereview.appspot.com/7311/diff/1/8#newcode111
Line 111: m = unichr(uni)
Renamed m to char in the next patch.


http://codereview.appspot.com/7311/diff/1/8#newcode127
Line 127: nextchar = s[end:end + 1]
commented in next patch (only once). s[end] can raise an IndexError with
bad input, s[end:end+1] returns an empty string on underflow, which is
caught later with a more helpful error message.


http://codereview.appspot.com/7311/diff/1/8#newcode132
Line 132: nextchar = s[end:end + 1]
commented in next patch (only once). s[end] can raise an IndexError with
bad input, s[end:end+1] returns an empty string on underflow, which is
caught later with a more helpful error message.


http://codereview.appspot.com/7311/diff/1/8#newcode290
Line 290: following strings: -Infinity, Infinity, NaN.
Not practically speaking. The documented purpose of this callback is
"This can be used to raise an exception if invalid JSON numbers are
encountered.". I've never seen it used to handle None, True, False in a
different manner. That was more of an implementation detail than
anything else, and that is fixed by this patch. Existing implementations
of this callback will simply have dead code since they will never be
called with "null", "true" or "false" anymore.


http://codereview.appspot.com/7311/diff/1/8#newcode317
Line 317: def raw_decode(self, s, idx=0):
It is a compatible change.


http://codereview.appspot.com/7311/diff/1/9
File Modules/_json.c (right):

http://codereview.appspot.com/7311/diff/1/9#newcode196
Line 196: output_size *= 2;
_PyString_Resize checks for integer overflow, so it would explode there
just fine. The next patch changes this slightly to avoid unnecessary
calls to _PyString_Resize when the size didn't actually change, but
doesn't do any explicit integer overflow checking


http://codereview.appspot.com/7311/diff/1/9#newcode215
Line 215: ascii_escape_str(PyObject *pystr)
Done in the next patch


http://codereview.appspot.com/7311/diff/1/9#newcode733
Line 733: "..."
Done in the next patch.


http://codereview.appspot.com/7311/diff/1/9#newcode1320
Line 1320: if ((idx + 3 < length) && str[idx + 1] == 'u' && str[idx + 2]
== 'l' && str[idx + 3] == 'l') {
Probably not, but strncmp doesn't work for PyUnicode and the same code
is repeated there.


http://codereview.appspot.com/7311/diff/1/9#newcode1528
Line 1528: PyTypeObject PyScannerType = {
I don't think it's possible to cause a cycle using the documented APIs,
since the encoder is created and thrown away behind the scenes and never
passed to user code. Someone else can write that patch if it's
necessary.

http://codereview.appspot.com/7311/diff/1/9#newcode2025
Line 2025: "make_encoder",       /* tp_name */
It's not a type that's ever exposed to user code, make_encoder is
somewhat less confusing because that's the name it's exposed as. I'll
change it anyway though, it doesn't really matter since this is all
private API.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4136>
_______________________________________

From report at bugs.python.org  Mon Jan  5 02:50:32 2009
From: report at bugs.python.org (Clinton Roy)
Date: Mon, 05 Jan 2009 01:50:32 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1231120232.15.0.299761425621.issue3585@psf.upfronthosting.co.za>


Clinton Roy <clinton.roy at gmail.com> added the comment:

Is there anything I can do to move this forward at all?

cheers,

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Mon Jan  5 02:56:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 01:56:19 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1231120579.19.0.681538707816.issue4626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The function decode_str() (Parser/tokenizer.c) is responsible to 
detect the encoding using the BOM or the cookie ("coding: xxx"). 
decode_str() reencodes also the text to utf-8 if the encoding is 
different than utf-8. I think that we can just skip this function if 
the input text is already unicode (utf-8). Attached patch implements 
this idea.

The patch introduces a new compiler flag (PyCF_IGNORE_COOKIE) and a 
new parser flag (PyPARSE_IGNORE_COOKIE). The new compiler flag is set 
by source_as_string() when the input is a PyUnicode object. "Ignore 
cookie" is maybe not the best name for this flag.

With my patch, the first Brett's example displays:
   $ ./python com2.py
   Traceback (most recent call last):
     File "com2.py", line 3, in <module>
       compile(source, '<test>', 'exec')
     File "<test>", line 2
       ? = '?'
         ^
   SyntaxError: invalid character in identifier

The error cursor is not at the right column (bug related to the issue 
2382 or introduced by my patch?).

The patch changes the public API: PyTokenizer_FromString() prototype 
changed to get a new argument. I don't like changing public API. The 
new argument should be a bit vector (flags) instead of a single bit 
(ignore_cookie). We can avoid changing the public API by creating a 
new function (eg. "PyTokenizer_FromUnicode" ;-)). 

There are some old PyPARSE_xxx constants in Include/parsetok.h that 
might be removed. PyPARSE_WITH_IS_KEYWORD value is 3 which is strange 
since flags is a bit vector (changed with | and tested by &). But 
PyPARSE_WITH_IS_KEYWORD is a dead constant (written in #if 
0...#endif).

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file12588/tokenizer_ignore_cookie.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Mon Jan  5 02:56:50 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 01:56:50 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1231120610.58.0.64449301692.issue4626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, I attached the wrong file :-p

Added file: http://bugs.python.org/file12589/tokenizer_ignore_cookie-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Mon Jan  5 02:56:55 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 01:56:55 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1231120615.59.0.0464116978309.issue4626@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12588/tokenizer_ignore_cookie.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Mon Jan  5 03:01:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 02:01:48 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1231120579.19.0.681538707816.issue4626@psf.upfronthosting.co.za>
Message-ID: <200901050302.20621.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> With my patch, the first Brett's example displays:
>    ...
>        ? = '?'
>          ^
>    SyntaxError: invalid character in identifier
>
> The error cursor is not at the right column (bug related to the issue
> 2382 or introduced by my patch?).

I tried py3k_adjust_cursor_at_syntax_error_v2.patch (issue #2382) and the 
cursor is displayed at the right column:

   $ ./python com2.py
   Traceback (most recent call last):
     ...
     File "<test>", line 2
       ? = '?'
       ^

So it's not a new bug ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Mon Jan  5 03:39:46 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Mon, 05 Jan 2009 02:39:46 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231123186.23.0.540731132493.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

@alexandre: if you add two labels per opcode and two dispatch tables,
one before (like now) and one after the parameter fetch (where we have
the 'case'), you can keep the same speed.
And under the hood we also had two dispatch tables before, with the
switch, so it's not a big deal; finally, the second table is only used
in the slow path (i.e. EXTENDED_ARG, or when additional checks are needed).

About f->last_i, when I have time I want to try optimizing it. Somewhere
you can be sure it's not going to be used.
But you have some changes about that in the abstract-switch patch, I
think that was not intended?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Mon Jan  5 04:02:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 05 Jan 2009 03:02:09 +0000
Subject: [issue4839] Reminder: Please Respond to Manas's Invitation
In-Reply-To: <b3bec428998712158eb2652ed8b7d065@localhost.localdomain>
Message-ID: <1231124529.74.0.158436949107.issue4839@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4839>
_______________________________________

From report at bugs.python.org  Mon Jan  5 05:24:27 2009
From: report at bugs.python.org (Charles Hans)
Date: Mon, 05 Jan 2009 04:24:27 +0000
Subject: [issue4840] Compile dbm in Ubuntu
In-Reply-To: <1231129467.43.0.877411679563.issue4840@psf.upfronthosting.co.za>
Message-ID: <1231129467.43.0.877411679563.issue4840@psf.upfronthosting.co.za>


New submission from Charles Hans <cwhann at gmail.com>:

I tried and failed in compile python 3.0 in ubuntu 8.10. Then I found
the scripts in setup.py use "gdbm/ndbm.h" while in ubuntu 8.10 it should
be gdbm-ndbm.h. So I made the following change which make the compiling ok:


setup.py

787c787
<                   and find_file("gdbm/ndbm.h", inc_dirs, []) is not None):
---
>                   and find_file("gdbm-ndbm.h", inc_dirs, []) is not None):
790c790
<                                        libraries = ['gdbm'] ) )
---
>                                        libraries = ['gdbm',
'gdbm_compat'] ) )


Modules/_dbmodule.c

22c22
< #include <gdbm/ndbm.h>
---
> #include <gdbm-ndbm.h>

----------
components: Library (Lib)
messages: 79107
nosy: cwhan
severity: normal
status: open
title: Compile dbm in Ubuntu
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4840>
_______________________________________

From report at bugs.python.org  Mon Jan  5 06:51:46 2009
From: report at bugs.python.org (Terry Helge)
Date: Mon, 05 Jan 2009 05:51:46 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231093333.6.0.679938116402.issue4836@psf.upfronthosting.co.za>
Message-ID: <1231134706.08.0.961614705997.issue4836@psf.upfronthosting.co.za>


Terry Helge <skillybob2 at gmail.com> added the comment:

Additional testing -- apparently this is only happening when I run a
program that imports pyGame. If I run IDLE and do not import, it
functions properly .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________

From report at bugs.python.org  Mon Jan  5 07:32:12 2009
From: report at bugs.python.org (Terry Helge)
Date: Mon, 05 Jan 2009 06:32:12 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231093333.6.0.679938116402.issue4836@psf.upfronthosting.co.za>
Message-ID: <1231137132.69.0.0222392673052.issue4836@psf.upfronthosting.co.za>


Terry Helge <skillybob2 at gmail.com> added the comment:

Additional testing - ran programs that call (import) pyGame using
drPython and everything works fine ... just when using IDLE and pyGame
am I getting this action. Rats!!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________

From report at bugs.python.org  Mon Jan  5 07:44:10 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 05 Jan 2009 06:44:10 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1231137850.19.0.539138296604.issue4757@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

The current behaviour may help the majority by ignorance and cause weird
errors for others. We tell people that Python distincts between Text and
Data but actually treat it all the same by implicit encoding.

Modules that only operate on Bytes should reject Unicode-objects in
Python3; it's a matter of 3 lines to display a warning in Python 2.
Those modules that usually operate on Text but have single functions
that operate on Bytes should display a warning but not enforce explicit
encoding.

Also see #4821 and #4818 where unicode already got rejected by the
openssl-driven classes but silently accepted by the build-in ones.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Jan  5 09:20:13 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Jan 2009 08:20:13 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231143613.5.0.378833969324.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will spend a while mulling this over and taking it under advisement.

Initially, I am disinclined for several reasons.

1.  For many use cases, r>n is an error condition that should not pass
silently.

2.  While it's possible to make definitions of comb/perm that define the
r>n case as having an empty result, many definitions do not.  See the
wikipedia article on permutations:

"""
In general the number of permutations is denoted by P(n, r), nPr, or
sometimes P_n^r, where:

    * n  is the number of elements available for selection, and
    * r  is the number of elements to be selected (0 ? r ? n).

For the case where r = n  it has just been shown that P(n, r) = n!. The
general case is given by the formula:

    P(n, r) = n! / (n-r)!.
"""

That discussion is typical and I think it important the number of items
returned matches the formula (which fails when r>n because (n-r)! would
call for a negative factorial).

Also see the wikipedia article on combinations (the "choose" function)
which also expresses a factorial formula that fails for r>n.  No mention
is made for special handling for r>n.

3. For cases where you need a more inclusive definition that assigns a
zero length result to cases where r>n, the workaround is easy. 
Moreover, in such cases, there is some advantage to being explicit about
those cases being handled.  In the example provided by the OP, the
explicit workaround is:

   all(triangle_respected(*triple) for triple in
itertools.combinations(group, 3) if len(group)>=3)

or if you factor-out the unvarying constant expression in the inner-loop:

   len(group)>=3 or all(triangle_respected(*triple) for triple in
itertools.combinations(group, 3))

For other cases, it may be preferable to write your own wrapper:

   def myperm(pool, r=None):
      'custom version of perm returning an empty iterator when r>n'
      if r is not None and r > len(pool):
          return iter([])
      return itertools.permutations(pool, r)

I like this because it is explicit about its intended behavior but
doesn't slow-down the common case where some work actually gets done.

4. Don't want to break any existing code that relies on the ValueError
being thrown.  It's too late to change this for 2.6 and 3.0 and possibly
for 2.7 and 3.1 without having a deprecation period.  While this hasn't
been out long, it will have been once 2.7 is released.  Code that relies
on the ValueError may be hard to spot because it is implicitly relying
on the ValueError aborting the program for invalid input (invalid in the
sense of how the result is being used).

5. I personally find the r>n case to be weird and would have a hard time
explaining it to statistics students who are counting permutations and
relating the result back to the factorial formulas.

On the flip side, I do like Mark's thought that the r>n case being empty
doesn't muck-up the notion of combinations as returning all "r-length
subsequences of elements from the input iterable."  Also, I can see a
parallel in the string processing world where substring searches using
__contains__ simply return False instead of raising an exception when
the substring is longer that the string being searched.

Those are my initial thoughts.  Will ponder it a bit more this week.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Mon Jan  5 09:48:27 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 05 Jan 2009 08:48:27 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1231145307.48.0.697546387567.issue3745@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Seems that this problem is being taken care of in issue #4751.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Mon Jan  5 10:27:15 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 05 Jan 2009 09:27:15 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231147635.59.0.019903590017.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ping.
Amaury, any thoughts?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan  5 10:29:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Jan 2009 09:29:45 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1231147785.2.0.539165401236.issue3585@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks fine to me. I have however some questions to ask to
someone more used to pkgconfig:

- Do all unix-like system support pkg-config?

- Is $(LIBDIR)/pkgconfig the only choice for installing this file?

- Shouldn't this file be installed only if the pkg-config utility is
present, or if the directory $(LIBDIR)/pkgconfig already exists?

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Mon Jan  5 10:47:36 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 05 Jan 2009 09:47:36 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1231148856.76.0.111772004281.issue3745@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

solved in #4818 and #4821

----------
nosy: +ebfe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Mon Jan  5 10:54:01 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Jan 2009 09:54:01 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231149241.78.0.639597907807.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Quick notes so I don't forget:

The two main pure python equivalents in the docs would need to be
updated with the new special cases (currently they raise IndexError for
r>n).  The other two pure python equivalents would automatically handle
the proposed new cases.

The Mathematica definition of permutations does not discuss or allow for
the r>n case, http://mathworld.wolfram.com/Permutation.html .  One of
the other tools that actually lists permutations and takes a second
argument (most do not) is in Mathematica,
http://reference.wolfram.com/mathematica/ref/Permutations.html .  It is
unclear from their docs whether the r>n case is supported as a
zero-length output or as an error condition.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Mon Jan  5 10:59:44 2009
From: report at bugs.python.org (David Zaslavsky)
Date: Mon, 05 Jan 2009 09:59:44 +0000
Subject: [issue1309567] linecache module returns wrong results
Message-ID: <1231149584.25.0.411687340361.issue1309567@psf.upfronthosting.co.za>


David Zaslavsky <diazona+py at ellipsix.net> added the comment:

I just had the same problem in a call to inspect.findsource() 
(actually my code calls inspect.stack() which calls ... which calls 
findsource()). The code object passed to findsource() had a filename 
of "database/__init__.py" which is the correct filename relative to 
sys.path, so in this case a simple fix would have worked: delete line 
82 of linecache.py
 82        basename = os.path.split(filename)[1]
and use filename instead of basename for the rest of the function. (Or 
for a quick hack, change line 82 to just "basename = filename")

I'm using Python 2.5.2 but the relevant code in linecache.py also 
exists in 3.0 (just checked).

----------
nosy: +diazona
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309567>
_______________________________________

From report at bugs.python.org  Mon Jan  5 11:18:54 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 05 Jan 2009 10:18:54 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1231150734.4.0.861776814212.issue3677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Okay, I've tested the patch and made some beauty fixes.
Can we have this in, please?

Added file: http://bugs.python.org/file12591/not_use_stat_in_import_on_windows.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Mon Jan  5 11:29:09 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Jan 2009 10:29:09 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231151349.73.0.606035790931.issue4293@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- The things_to_do static variable should be declared as "volatile": it
is read by the main loop without any lock.
(by the way, could you rename it to something like "pendingcalls_to_do"?)

- in the old Py_MakePendingCalls function, the "#ifdef WITH_THREAD" part
is not useful now. 

- the "XXX" comments should probably be rewritten.

A note to people concerned by performance: the additional lock is used
only when there is an actual pending call to process. The main loop only
regularly checks the "things_to_do static" volatile static variable, and
the patch does not change this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan  5 11:29:49 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 05 Jan 2009 10:29:49 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

In _fileio.c, there is the following comment: "Returns 0 on success,
errno (which is < 0) on failure." The problem here is the claim that
errno ever was less than zero, which is simply wrong.

You can see this being a problem with the following few lines:

import os, io
fd = os.open( "some existing file", os.O_RDONLY)
s1 = os.fdopen(fd)
s2 = io.open(fd)
os.close(fd)
s1.close()
s2.close()

The call to close() pulls the file from under the feet of the two stream
objects, but only the one opened with os.fdopen() actually detects that.
For the second one, errno is set, but to a positive value which isn't
detected correctly.

----------
components: Interpreter Core
messages: 79120
nosy: eckhardt
severity: normal
status: open
title: io's close() not handling errors correctly
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jan  5 11:32:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 10:32:40 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

int('3L') is still valid in Python 3.x.  Presumably this is unintentional.  
Is there any possibility of changing this for 3.0.1 or 3.1?

----------
components: Interpreter Core
messages: 79121
nosy: marketdickinson
severity: normal
status: open
title: int('3L') still valid in Python 3.0
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan  5 11:33:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 10:33:30 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231151610.16.0.562018606814.issue4842@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file12592/issue4842.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan  5 11:37:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 10:37:39 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1231123186.23.0.540731132493.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231151869.7067.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 05 janvier 2009 ? 02:39 +0000, Paolo 'Blaisorblade' Giarrusso a
?crit :
> About f->last_i, when I have time I want to try optimizing it. Somewhere
> you can be sure it's not going to be used.

There are lots of places which can call into arbitrary Python code. A
few opcodes could be optimized for sure.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Mon Jan  5 11:44:27 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Jan 2009 10:44:27 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <200901042351.39426.victor.stinner@haypocalc.com>
Message-ID: <4961E488.4060202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-04 23:51, STINNER Victor wrote:
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> The fact that Python 2.x also accepts Unicode ASCII strings 
>> where strings are normally expected is intended to help with 
>> the migration to Unicode
> 
> I hate this behaviour. It doesn't help migration, it's the opposite! Sometimes 
> it works (ASCII), and somtimes it fails (just one non-ASCII character). And 
> then we will read "Unicode sucks!" because people doesn't understand the 
> error.

Well, that's your opinion.

The feature was added to get people
work with Unicode at all, since otherwise we would have had to do
all the Unicode porting we're doing now for Python 3 at the time
Unicode was introduced - which was in version Python 1.6, eight years
ago.

At the time the Python community was a lot smaller and there wasn't
all that much interest in Unicode anyway - the Unicode support I wrote
for Python 1.6 was partially financed by HP which needed it for an
application they had written in Python.

See the introduction in PEP 100 for the motivation behind the design
decisions:

http://www.python.org/dev/peps/pep-0100/

>> In Python 3.x, it's probably better to use bytes throughout the
>> API.
> 
> I propose to reject unicode in Python 3.x and display a warning for Python 
> 2.x. A warning to prepare the migration... not to Unicode, but to Python3 ;-)

Fair enough.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Jan  5 11:51:17 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 05 Jan 2009 10:51:17 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231152677.47.0.669612033592.issue4841@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

This adds a test that the close() correctly fails with an IOError.

----------
keywords: +patch
Added file: http://bugs.python.org/file12593/python-2.7-fileio-close-test.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jan  5 12:03:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Jan 2009 11:03:45 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231153425.29.0.0972109171981.issue4842@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I would call this a bug.  Guido, do you concur?

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan  5 12:06:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 11:06:32 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231153592.22.0.745131663716.issue4842@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This patch currently causes test_pickle to fail (and test_random, but that 
failure is also pickle related).  Am investigating.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan  5 12:19:52 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 05 Jan 2009 11:19:52 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231154392.48.0.755281594305.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Good points.
Any suggestion where to document the new functionality?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan  5 12:58:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Jan 2009 11:58:24 +0000
Subject: [issue4843] copytree improvments
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

In one sentence: 

Let's enhance shutil.copytree so we can drop distutils.[dir_util/file_util]

In details:

I am currently studying what could be removed from Distutils in order to
rely
on what is available in the standard library.

I have a concern about distutils.dir_util and distutils.file_util modules.

Distutils implements its own file and directory copy functions there, that
could be replaced by shutil ones, except four small features:

- verbose : each time a file is copied a "source -> target" is displayed
  in the output.
- dry_run : nothing is really copied
- update : each file will only be copied if they don't exist in the
  target path or if they are newer
- the copy_tree function returns the list of files copied (or that
  should have been copied when dry_run is True).

I think shutil could benefit from these small features, and            
       
distutils code could be refactored to use them.                        
       
                  
Here's a small proposal for distutils.copytree::                       
       
        
    copytree(src, dst, symlinks=False, ignore=None) -> None            
       
                
becomes:    
                
    copytree(src, dst, symlinks=False, ignore=None, update=False, 
             verbose=False, dry_run=False, logger=None) -> list of
copied files
            
where:          
                                                                       
       
- update    
 - if False, copytree behaves as usual: if os.path.samefile(source,
target) is True it raise an error                                      
                  
 - if True, the file is copied only if it's newer or doesn't exists,
otherwise it doesn't raise

- logger
  - if None, logger is set to logging.info

- verbose: if True, a logger.info("source -> target") call is made on
each copy

- dry_run: if True, the files are not really copied

Last, the function returns a tuple of copied files.

>From there, distutils can work with shutil.copytree, shutil.copyfile and
shutil.copy2


Pro's:
 - distutils can rely on this function and its specialized modules dissapear
 - shutil.copytree becomes more powerful
 - less redundancy in the sdtlib

Con's:
 - the API signature is getting a bit complex
 - distutils use case might not be common enough

----------
components: Library (Lib)
messages: 79129
nosy: tarek
severity: normal
status: open
title: copytree improvments
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Mon Jan  5 12:58:56 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Jan 2009 11:58:56 +0000
Subject: [issue4843] copytree improvments
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1231156736.77.0.686383775044.issue4843@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components: +Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:03:23 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Jan 2009 12:03:23 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <d38f5330901021938q43239b4fw349ac09d4e4bee47@mail.gmail.com>
Message-ID: <4961F708.8080901@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-03 04:38, Alexander Belopolsky wrote:
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Fri, Jan 2, 2009 at 10:54 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>
>> Also note that by removing the extern "C" declarations, you not only
>> changes the exported symbol names of functions, but also those of
>> exported globals.
>>
> What are " exported globals" other than "exported symbol names of
> functions"?  AFAIK, C++ does not mangle non-function symbols.

GCC doesn't appear to do so, but there's no guarantee that other
C++ compilers won't touch these symbols:

http://en.wikipedia.org/wiki/Name_mangling

>> Those would also have to get declared in the header files, to prevent
>> their names from being mangled (causing the exported C API to change).
> 
> I believe .c files should only contain static functions and functions
> that are declared in an included header file.  If a function that is
> not advertised in a header, it is not part of API and it is a fair
> game to mangle it.  The only exception is the module init functions
> that are part of the ABI rather than API.

That's right, but I was referring to non-function globals.
These would have to be declared in the header files as well to
prevent their names from being mangled.

OTOH, those globals will often not be accessed directly from other
object files - only through functions providing an interface to
them. Still, this would have to be checked.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:06:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 12:06:03 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231157163.52.0.100323972249.issue4842@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the issue with pickle:  with this patch, the pickle of a long using 
pickle protocol 0 under 2.x can't be read by Python 3.x, because (1) the 
pickled long includes a trailing L, and (2) unpickling goes via a call to 
PyLong_FromString.

Maybe the simplest thing is to continue to let int('3L') be valid.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:11:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Jan 2009 12:11:45 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231157505.57.0.654071106617.issue4293@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, I could not find these functions documented anywhere :-(
If you want to start to write some, a good place could be in
http://docs.python.org/c-api/init.html (Doc/c-api/init.rst, maybe after
the PyGILState_ functions)

At the very least, a short sentence in whatsnew/2.7.rst would be
appreciated.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:17:17 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Mon, 05 Jan 2009 12:17:17 +0000
Subject: [issue4774] threding, bsddb and double free or corruption (fasttop)
In-Reply-To: <1230592853.0.0.0445648356303.issue4774@psf.upfronthosting.co.za>
Message-ID: <1231157837.39.0.702950872644.issue4774@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Alain, I can not reproduce this issue in current bsddb code (as running
under Python 2.6.1 and Berkeley DB 4.7.25). Since Python 2.5 branch has
been marked as "security fixes only", this bug would be an "out of date"
one.

Please, confirm that this bug is not present in Python 2.6.1 or, if you
need to run Python 2.5, please install an updated pybsddb library and
check it.

I will wait your comments for a week or two. Then mark this issue as
"out of date", if you don't indicate the contrary.

Thanks for your time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4774>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:22:11 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 12:22:11 +0000
Subject: [issue1672332] cPickle can pickle,
	but cannot unpickle on 64bit machines
Message-ID: <1231158131.65.0.592773779587.issue1672332@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm seeing this too on OS X, with Python 2.6.

Python 2.6.1+ (release26-maint:68182M, Jan  2 2009, 23:13:43) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cPickle
>>> cPickle.dumps(1e-307)
'F9.9999999999999991e-308\n.'
>>> cPickle.loads(_)
9.9999999999999991e-308
>>> cPickle.dumps(1e-308)
'F9.9999999999999991e-309\n.'
>>> cPickle.loads(_)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float

Same results on trunk, and (using pickle instead of cPickle, and 
specifying protocol 0 explicitly) for 3.x.

I'll see if I can figure out where this is coming from.

----------
assignee:  -> marketdickinson
nosy: +marketdickinson
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:32:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 12:32:26 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231158746.22.0.869539198241.issue4842@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If it breaks pickle it may also break user-defined data formats. I think
it is fine to continue support it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:36:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 12:36:45 +0000
Subject: [issue4843] copytree improvments
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1231159005.62.0.240745393714.issue4843@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I suggest a more generic and powerful API change:

    copytree(src, dst, symlinks=False, ignore=None) -> None            
       
becomes:    
                
    copytree(src, dst, symlinks=False, ignore=None, callback=None) -> None

where callback, if not None, is called with each (filename, src_dir,
dst_dir) and can return either True or False depending on whether the
copy must really occur or not.

Then you should be able implement the four distutils option in terms of
the callback.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:53:22 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Jan 2009 12:53:22 +0000
Subject: [issue4843] copytree improvments
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1231160002.67.0.950303836901.issue4843@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the tip Antoine,

That made me realize that 'ignore' is sufficient to address all cases in
distutils ! (it's a callable that does what you described in callback)

So I am transforming this ticket into a refactoring for distutils.

What classifier should I use in the ticket type ? (I was looking for
"refactoring")

----------
assignee:  -> tarek
components:  -Library (Lib)
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:54:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Jan 2009 12:54:02 +0000
Subject: [issue4843] make distutils use shutil
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1231160042.17.0.0110809598583.issue4843@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
title: copytree improvments -> make distutils use shutil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Mon Jan  5 13:58:02 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 05 Jan 2009 12:58:02 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231160282.31.0.739841298761.issue4676@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:01:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 13:01:13 +0000
Subject: [issue4843] make distutils use shutil
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1231160473.53.0.239249634891.issue4843@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know, perhaps "resource usage" - although it's probably meant
for runtime resources rather than source code resources. Not a big deal
anyway.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4843>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:05:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 13:05:11 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231160711.91.0.872170137288.issue4841@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Strangely enough, it works in py3k.

----------
nosy: +pitrou
priority:  -> critical
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:38:30 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 13:38:30 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231162710.75.0.0296281202921.issue4841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

In Python 3.x, internal_close() returns -1 on error (close() returns a 
negative value) and 0 on success. It tests if close() returns a 
negative

In Python 2.x, internal_closes() returns the errno value of close() on 
error, or 0 on success. fileio_close() tests if the error value is 
negative instead of not null or at least strict positive.

Python 3.x code looks better. I tried to backport the internal_close() 
changes but I get a segfault :-p

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:41:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 13:41:19 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231162879.48.0.621657869515.issue4841@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:42:34 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 13:42:34 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231162954.15.0.715946540539.issue4841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

In Python 3.x, internal_close() returns -1 on error (if close() 
returns a negative value) and 0 on success.

In Python 2.x, internal_closes() returns the errno value of close() on 
error, or 0 on success. fileio_close() tests if the error value is 
negative instead of if it's not null or at least it's strict positive.

Python 3.x code looks better. I tried to backport the internal_close() 
changes but I get a segfault on PyErr_WriteUnraisable() :-p (close() 
error in fileio_dealloc)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:44:07 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 05 Jan 2009 13:44:07 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231163047.5.0.569309198208.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, here is a revised, patch.
It now contains rudimentary documentation, which probably needs to be 
proofread by the official documentation lords.

Added file: http://bugs.python.org/file12594/xmlrpc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:49:36 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 13:49:36 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231163376.72.0.835880074327.issue4676@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Somelauw: Are you running Windows, Linux, other?

The bug may be related to a special key with no binding: no mapping in 
the kernel, in your Windows/Xorg configuration or in python Tk module. 
The key is not shift+

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:49:46 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 13:49:46 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231163386.79.0.421553425646.issue4676@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:50:05 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Jan 2009 13:50:05 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231163405.33.0.955299943215.issue4842@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Consider marking the 'L' code as deprecated and removing it in 3.1;
otherwise, this artifact may hang around forever.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:50:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 13:50:25 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231163425.81.0.10395730341.issue4676@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Somelauw: Are you running Windows, Linux, other?

The bug may be related to a special key with no binding: no mapping in 
the kernel, in your Windows/Xorg configuration or in python Tk module. 
The key is maybe not shift+home but strange combinaison related to 
your laptop special keys.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:58:56 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 13:58:56 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1231163936.67.0.838071125829.issue4821@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This patch is a duplicate of #3745.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Mon Jan  5 14:59:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 13:59:08 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231163948.52.0.645002642504.issue4293@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Would it be possible to rework your code so as not to define two
versions of Py_AddPendingCall() and Py_MakePendingCalls(), only putting
`#ifdef WITH_THREAD` sections where it's necessary? Or would it make the
code too quirky?

Also, it would be nice to have a test for this specific feature (e.g.
using a dedicated function in the _testcapi module), but perhaps it
isn't a showstopper either.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan  5 15:00:40 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 14:00:40 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1231164040.02.0.618731814617.issue4821@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, it's not a duplicate /o\ But it may solves #3745 (reject unicode 
in sha256).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Mon Jan  5 15:03:08 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 05 Jan 2009 14:03:08 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231164188.22.0.711983399984.issue4841@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

I have a patch here which passes the proposed change to the tests in
trunk. A few notes up front though, since the patch isn't good yet:

1. The handling of the error in internal_close() isn't really good. What
I'm also not sure about is whether it is correct to set the error there,
the old code sometimes did set an error as reaction to internal_close()
failing and sometimes not.
2. There is one place in dircheck() where I think that the error should
be ignored, but I'm not sure about that.
3. This patch fixes another issue, and that is that internal_close()
would call close() even if 'closefd' was not set. This e.g. happens when
__init__ is called explicitly. This case is missing a test though.
4. I wonder if internal_close() should reset only the 'fd' field or if
it should also reset 'readable', 'writable', 'seekable', too, i.e. apart
from 'weakreflist' do the same as fileio_new() does.

Added file: http://bugs.python.org/file12595/python-2.7-fileio-close-fix.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Mon Jan  5 15:07:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 14:07:16 +0000
Subject: [issue1672332] cPickle can pickle,
	but cannot unpickle on 64bit machines
Message-ID: <1231164436.78.0.749780931301.issue1672332@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The problem comes down to the platform strtod:  on some systems,
strtod sets errno to ERANGE on underflow.  The load_float function in
Modules/cPickle.c calls PyOS_ascii_strtod and then raises ValueError
if that call sets errno.

I suggest replacing the call to PyOS_ascii_strtod with a call to
PyFloat_FromString instead.  This would make cPickle behave identically
to pickle, and would also fix the problem on Windows where 1e-310 is
dumped as 0.0.  (PyFloat_FromString goes out of its way to use atof 
instead of strtod to deal with this case.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Mon Jan  5 15:21:11 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 05 Jan 2009 14:21:11 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231165271.06.0.763523039023.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ah, I forgot the test code in my patch.  I submit a separate patch to 
add that code.
Also, reworking things to have single function definitions is in my 
opinion too messy.  I started doing things that way, but the code 
becomes hard to read and therefore to understand and verify.

Added file: http://bugs.python.org/file12596/testcapi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan  5 15:56:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 14:56:18 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231167378.53.0.129777968454.issue4293@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A few comments about the test:
- it should be a method of TestCAPI; we try to unittest everywhere,
although there is some old code which predates that
- the implementation would be stressed better if each callback was added
from a separate thread, rather than adding them all at once; it will
also make the C function in _testcapi simpler (and you can do the sleep
in the Python code in test_capi.py)
- if you want the list operation in your callback to be atomic, it
should append() something to the list rather than increment its first
element; then you just have to test for the len() of the list
- in _pending_callback(), you must use Py_XDECREF(r), not Py_DECREF,
since r can be NULL

I will look at the ceval part of the patch later :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan  5 15:58:07 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 05 Jan 2009 14:58:07 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231167487.7.0.0251249587995.issue4676@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

It would be nice if the OP could confirm that the bug described by
Daniel is the same one as he gets. I can reproduce it on linux on all
the versions I marked, but didn't have time to fix it yet.

To the OP: If you are running Windows, try starting IDLE on the prompt,
reproduce the error, and check if anything is printed back to you.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Mon Jan  5 16:19:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 15:19:00 +0000
Subject: [issue1672332] cPickle cannot unpickle subnormal floats on some
	machines
Message-ID: <1231168740.74.0.730040659597.issue1672332@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Change title;  this has nothing to do with 64 bit.

----------
title: cPickle can pickle, but cannot unpickle on 64bit machines -> cPickle cannot unpickle subnormal floats on some machines

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Mon Jan  5 16:24:11 2009
From: report at bugs.python.org (Yngve AAdlandsvik)
Date: Mon, 05 Jan 2009 15:24:11 +0000
Subject: [issue4844] ZipFile doesn't range check in _EndRecData()
In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>
Message-ID: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>


New submission from Yngve AAdlandsvik <ymgve at start.no>:

If you have a .zip file with an incomplete "End of Central Directory" 
record, _EndRecData() will throw a struct.error:

D:\c64workdir\Ultimate_Mag_Archive>e:ziptest.py "old - 
Ultimate_Mag_Archive"
Handling A-z\0\64times01-double.zip
Traceback (most recent call last):
  File "E:\wwwroot\c64db\tools\ziptest.py", line 48, in <module>
    ok = handle_file(data, rel_filename)
  File "E:\wwwroot\c64db\tools\ziptest.py", line 19, in handle_file
    z = zipfile.ZipFile(cStringIO.StringIO(data), "r")
  File "C:\Python26\lib\zipfile.py", line 698, in __init__
    self._GetContents()
  File "C:\Python26\lib\zipfile.py", line 718, in _GetContents
    self._RealGetContents()
  File "C:\Python26\lib\zipfile.py", line 728, in _RealGetContents
    endrec = _EndRecData(fp)
  File "C:\Python26\lib\zipfile.py", line 219, in _EndRecData
    endrec = list(struct.unpack(structEndArchive, recData))
struct.error: unpack requires a string argument of length 22

The fix is to include a check to see if there is data enough for the 
whole record before attempting to unpack.

----------
components: Library (Lib)
messages: 79155
nosy: ymgve
severity: normal
status: open
title: ZipFile doesn't range check in _EndRecData()
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4844>
_______________________________________

From report at bugs.python.org  Mon Jan  5 16:28:18 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 05 Jan 2009 15:28:18 +0000
Subject: [issue4844] ZipFile doesn't range check in _EndRecData()
In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>
Message-ID: <1231169298.14.0.680998270832.issue4844@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

please attach 64times01-double.zip if possible

----------
nosy: +ebfe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4844>
_______________________________________

From report at bugs.python.org  Mon Jan  5 16:31:35 2009
From: report at bugs.python.org (Somelauw)
Date: Mon, 05 Jan 2009 15:31:35 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231169495.0.0.0258720882326.issue4676@psf.upfronthosting.co.za>


Somelauw <Somelauw at yahoo.com> added the comment:

I'm using windows XP home edition SP2

Yes, my error message is similair to the one of ajaksu2 when I run the 
IDLE on the commandline. (when opened from windows explorer, it justs 
closes)
Also problem 2 is similair.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Mon Jan  5 16:36:03 2009
From: report at bugs.python.org (Yngve AAdlandsvik)
Date: Mon, 05 Jan 2009 15:36:03 +0000
Subject: [issue4844] ZipFile doesn't range check in _EndRecData()
In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>
Message-ID: <1231169763.71.0.950093413097.issue4844@psf.upfronthosting.co.za>


Yngve AAdlandsvik <ymgve at start.no> added the comment:

Here is the file. Note that this can be reproduced with any zip file if 
you delete the last byte of the file.

Added file: http://bugs.python.org/file12597/64times01-double.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4844>
_______________________________________

From report at bugs.python.org  Mon Jan  5 17:00:40 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 16:00:40 +0000
Subject: [issue4845] warnings system and inspect module disagree about
In-Reply-To: <1231171240.01.0.534546346997.issue4845@psf.upfronthosting.co.za>
Message-ID: <1231171240.01.0.534546346997.issue4845@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Here's a transcript demonstrating the disagreement:

  exarkun at charm:~$ mkdir warningexample
  exarkun at charm:~$ cd warningexample/
  exarkun at charm:~/warningexample$ mkdir foo
  exarkun at charm:~/warningexample$ touch foo/__init__.py
  exarkun at charm:~/warningexample$ cat > foo/bar.py
  import warnings
  def foo():
        warnings.warn("foo")
  exarkun at charm:~/warningexample$ python -c 'import foo.bar'
  exarkun at charm:~/warningexample$ mv foo bar
  exarkun at charm:~/warningexample$ python -c 'import bar.bar; bar.bar.foo()'
  bar/bar.py:3: UserWarning: foo
    warnings.warn("foo")
  exarkun at charm:~/warningexample$ python -c 'import bar.bar, inspect;
print inspect.getabsfile(bar.bar.foo)'
  /home/exarkun/warningexample/foo/bar.py
  exarkun at charm:~/warningexample$ 

Notice that the warning is emitted for the file bar/bar.py but the
inspect module claims that the function which emitted the warning is
defined in /home/exarkun/warningexample/foo/bar.py.  It seems that the
warning system has somehow noticed that the .pyc file has the wrong
source file listed and has figured out the correct file name, whereas
the inspect module is blindly following the contents of the .pyc file.

It would be great if the inspect module were at least as good at
figuring out filenames as the warnings system.

----------
components: Library (Lib)
messages: 79159
nosy: exarkun
severity: normal
status: open
title: warnings system and inspect module disagree about
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4845>
_______________________________________

From report at bugs.python.org  Mon Jan  5 17:09:20 2009
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 05 Jan 2009 16:09:20 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>
Message-ID: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

When I use Py_UNICODE_ISSPACE() in my C++ extension, I got following error.

test.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) unsigned char const * const _Py_ascii_whitespace"
(__imp_?_Py_ascii_whitespace@@3QBEB) referenced in function "struct
_object * __cdecl fff(struct _object *,struct _object *)"
(?fff@@YAPAU_object@@PAU1 at 0@Z)

Py_ascii_whitespace defined in unicodeobject.h should be enclosed by
'extern "C" {' block for C++ support.

Tested with Python 2.6.1/VS2008 express.

----------
messages: 79160
nosy: ishimoto
severity: normal
status: open
title: Py_UNICODE_ISSPACE causes linker error
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 17:40:21 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 16:40:21 +0000
Subject: [issue4845] warnings system and inspect module disagree about
In-Reply-To: <1231171240.01.0.534546346997.issue4845@psf.upfronthosting.co.za>
Message-ID: <1231173621.16.0.0892471452842.issue4845@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Perhaps even more disconcerting is the disagreement between
inspect.getabsfile(f) and inspect.getabsfile(inspect.getmodule(f)).  The
latter agrees with the warnings system, unlike the former which just
looks at the filename in the .pyc.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4845>
_______________________________________

From report at bugs.python.org  Mon Jan  5 17:43:59 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Jan 2009 16:43:59 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <4961F708.8080901@egenix.com>
Message-ID: <496238CC.2070207@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-05 13:03, Marc-Andre Lemburg wrote:
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> On 2009-01-03 04:38, Alexander Belopolsky wrote:
>> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>>
>> On Fri, Jan 2, 2009 at 10:54 AM, Marc-Andre Lemburg
>> <report at bugs.python.org> wrote:
>>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>>
>>> Also note that by removing the extern "C" declarations, you not only
>>> changes the exported symbol names of functions, but also those of
>>> exported globals.
>>>
>> What are " exported globals" other than "exported symbol names of
>> functions"?  AFAIK, C++ does not mangle non-function symbols.
> 
> GCC doesn't appear to do so, but there's no guarantee that other
> C++ compilers won't touch these symbols:
> 
> http://en.wikipedia.org/wiki/Name_mangling

Issue #4846 is a good example of a situation where such name mangling
causes problems even for non-function symbols.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Mon Jan  5 17:44:56 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Jan 2009 16:44:56 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>
Message-ID: <49623906.4090205@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-05 17:09, Atsuo Ishimoto wrote:
> New submission from Atsuo Ishimoto <ishimoto at gembook.org>:
> 
> When I use Py_UNICODE_ISSPACE() in my C++ extension, I got following error.
> 
> test.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) unsigned char const * const _Py_ascii_whitespace"
> (__imp_?_Py_ascii_whitespace@@3QBEB) referenced in function "struct
> _object * __cdecl fff(struct _object *,struct _object *)"
> (?fff@@YAPAU_object@@PAU1 at 0@Z)
> 
> Py_ascii_whitespace defined in unicodeobject.h should be enclosed by
> 'extern "C" {' block for C++ support.

Agreed. There already is such a block in unicodeobject.h, so perhaps
a little rearranging could do the trick.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 17:54:52 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jan 2009 16:54:52 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>
Message-ID: <1231174492.35.0.939560243619.issue4846@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 17:55:36 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Jan 2009 16:55:36 +0000
Subject: [issue4845] warnings system and inspect module disagree about
In-Reply-To: <1231171240.01.0.534546346997.issue4845@psf.upfronthosting.co.za>
Message-ID: <1231174536.69.0.271249370292.issue4845@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a duplicate of issue1180193. Does the patch there correct your
problem?

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> broken pyc files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4845>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:03:24 2009
From: report at bugs.python.org (jaywalker)
Date: Mon, 05 Jan 2009 17:03:24 +0000
Subject: [issue4847] csv fails when file is opened in binary mode
In-Reply-To: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>
Message-ID: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>


New submission from jaywalker <jaywalkie at yahoo.com>:

The following code from the documentation fails:
#################
import csv
reader = csv.reader(open("eggs.csv", "rb"))
for row in reader:
    print(row)
#####################
The output is:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in <module>
_csv.Error: iterator should return strings, not bytes (did you open the
file in text mode?)


It works as expected in python 2.6

----------
components: Library (Lib)
messages: 79165
nosy: jaywalker
severity: normal
status: open
title: csv fails when file is opened in binary mode
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:05:59 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 17:05:59 +0000
Subject: [issue4847] csv fails when file is opened in binary mode
In-Reply-To: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>
Message-ID: <1231175159.67.0.355537908917.issue4847@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Do you expect to be able to read CSV as bytes or just to fix the 
documentation example?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:11:11 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 17:11:11 +0000
Subject: [issue1180193] broken pyc files
Message-ID: <1231175471.58.0.711115087308.issue1180193@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This is causing problems for me as well.  The attached patch no longer
applies cleanly to trunk.  I've attached an updated version which
addresses the conflicts.  The new behavior fixes the issues I have with
the current behavior.  It'd be great to have it applied.

> If code objects grew a __module__ attribute (which functions already
> have), wouldn't it be just a matter of falling back on 
> sys.modules[my_code_object.__module__].__file__ when
> my_code_object.co_filename points to a non-existent file?

It'd be nice if it wasn't necessary to check to see if co_filename
referred to an existing file.  Can we have a solution which creates one
definitive, correct way to determine the source file?

----------
keywords: +patch
nosy: +exarkun
Added file: http://bugs.python.org/file12598/update_co_filename.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180193>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:12:23 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 17:12:23 +0000
Subject: [issue4845] warnings system and inspect module disagree about
In-Reply-To: <1231171240.01.0.534546346997.issue4845@psf.upfronthosting.co.za>
Message-ID: <1231175543.53.0.290060448027.issue4845@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

After updating the patch there so that it can be applied, it does seem
to address my issue.  I added a comment there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4845>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:15:58 2009
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 05 Jan 2009 17:15:58 +0000
Subject: [issue4848] MacPython build script uses Carbon and MacOS modules
	slated for removal
In-Reply-To: <1231175758.14.0.180038218422.issue4848@psf.upfronthosting.co.za>
Message-ID: <1231175758.14.0.180038218422.issue4848@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

The build script for a Mac OS installer, in
Mac/BuildScript/build-installer.py, currently requires OS 10.4 and
Python 2.3.  At some point it will have to be ported to a newer version
of Python (and Mac OS).  It uses a number of modules which are slated
for future removal, particularly Carbon and MacOS.  These modules are
only used in the function "setIcon".  They can be replaced with a call
to a Cocoa method via PyObjC.  The "setIcon" function using PyObjC would
look like this:

def setIcon(folder, imagefile):

    try:

        import os, AppKit

        AppKit.NSApplicationLoad()      # initialize Cocoa

        return
AppKit.NSWorkspace.sharedWorkspace().setIcon_forFile_options_(
            AppKit.NSImage.alloc().initWithContentsOfFile_(imagefile),
            os.path.abspath(folder), 0)

    except ImportError:
        return False

----------
components: Build, Macintosh
messages: 79169
nosy: janssen
priority: low
severity: normal
status: open
title: MacPython build script uses Carbon and MacOS modules slated for removal
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4848>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:19:12 2009
From: report at bugs.python.org (jaywalker)
Date: Mon, 05 Jan 2009 17:19:12 +0000
Subject: [issue4847] csv fails when file is opened in binary mode
In-Reply-To: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>
Message-ID: <269075.27562.qm@web111115.mail.gq1.yahoo.com>


jaywalker <jaywalkie at yahoo.com> added the comment:

In an unlikely scenario:
say one of the fields has an embedded \r. For instance "blahblah\r" is the value of the first column. Now open this file in text mode. What happens to this '\r' even before csv.reader sees it? If it remains intact, no problem. If it is converted to a newline in any platform, and that newline is not exactly \r, does this not introduce a problem?

Just curious...

Thanks.

----- Original Message ----
From: STINNER Victor <report at bugs.python.org>
To: jaywalkie at yahoo.com
Sent: Monday, January 5, 2009 12:05:59 PM
Subject: [issue4847] csv fails when file is opened in binary mode

STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Do you expect to be able to read CSV as bytes or just to fix the 
documentation example?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:23:45 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 17:23:45 +0000
Subject: [issue4847] csv fails when file is opened in binary mode
In-Reply-To: <269075.27562.qm@web111115.mail.gq1.yahoo.com>
Message-ID: <200901051824.07275.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> say one of the fields has an embedded \r. For instance "blahblah\r" is the
> value of the first column. Now open this file in text mode. What happens to
> this '\r' even before csv.reader sees it?

I used rarely the CSV format, but it sounds strange to have a newline 
character in a column. Newlines characters (\r and \n) are reserved to mark 
the end of the line. Can you produce such file to test? :-)

I guess that the csv modules does something like readline().split(";").

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:29:54 2009
From: report at bugs.python.org (jaywalker)
Date: Mon, 05 Jan 2009 17:29:54 +0000
Subject: [issue4847] csv fails when file is opened in binary mode
In-Reply-To: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>
Message-ID: <279018.16745.qm@web111108.mail.gq1.yahoo.com>


jaywalker <jaywalkie at yahoo.com> added the comment:

make it '\r\n', if you want. Such files can be easily generated on windows text editors, or even linux ones nowadays. Upon reading, if the file is opened in text mode, this will probably be converted to \n even on linux by python (I may be wrong). Thus, \r gets lost.

Not a biggie, but you never know ;0)

----- Original Message ----
From: STINNER Victor <report at bugs.python.org>
To: jaywalkie at yahoo.com
Sent: Monday, January 5, 2009 12:23:45 PM
Subject: [issue4847] csv fails when file is opened in binary mode

STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> say one of the fields has an embedded \r. For instance "blahblah\r" is the
> value of the first column. Now open this file in text mode. What happens to
> this '\r' even before csv.reader sees it?

I used rarely the CSV format, but it sounds strange to have a newline 
character in a column. Newlines characters (\r and \n) are reserved to mark 
the end of the line. Can you produce such file to test? :-)

I guess that the csv modules does something like readline().split(";").

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:41:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 17:41:57 +0000
Subject: [issue1180193] broken pyc files
Message-ID: <1231177317.31.0.366542970909.issue1180193@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As Armin said, I think it's safer and simpler not to rewrite the pyc
file when the filenames have been changed.
(if you thing changing the filenames can have a significant performance
impact, you may want to benchmark it)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180193>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:47:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Jan 2009 17:47:21 +0000
Subject: [issue4847] csv fails when file is opened in binary mode
In-Reply-To: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>
Message-ID: <1231177641.01.0.307418275065.issue4847@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can avoid the newline translation problem by using the newline
parameter in open(). Set it to '' (the empty string) and any CR and LF
characters should remain intact.

As for the original problem, IMHO it is a documentation bug.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:49:17 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 17:49:17 +0000
Subject: [issue1180193] broken pyc files
Message-ID: <1231177757.46.0.372425851457.issue1180193@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

New version of the patch which doesn't rewrite pyc files attached.

Added file: http://bugs.python.org/file12599/update_co_filename.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180193>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:51:29 2009
From: report at bugs.python.org (jaywalker)
Date: Mon, 05 Jan 2009 17:51:29 +0000
Subject: [issue4847] csv fails when file is opened in binary mode
In-Reply-To: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>
Message-ID: <625225.52668.qm@web111106.mail.gq1.yahoo.com>


jaywalker <jaywalkie at yahoo.com> added the comment:

I think what you suggest makes most sense. 
Thanks.

----- Original Message ----
From: Antoine Pitrou <report at bugs.python.org>
To: jaywalkie at yahoo.com
Sent: Monday, January 5, 2009 12:47:21 PM
Subject: [issue4847] csv fails when file is opened in binary mode

Antoine Pitrou <pitrou at free.fr> added the comment:

You can avoid the newline translation problem by using the newline
parameter in open(). Set it to '' (the empty string) and any CR and LF
characters should remain intact.

As for the original problem, IMHO it is a documentation bug.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

From report at bugs.python.org  Mon Jan  5 18:54:51 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jan 2009 17:54:51 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>
Message-ID: <1231178091.58.0.0746939027873.issue4846@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I believe attached issue4846.diff should fix the problem, but I don't 
have access to the affected platform (Windows?), so I did not test it.

I also wonder whether it would be more appropriate to redefine PyAPI_* 
macros to declare API symbols with extern "C" when compiled under C++?  
This seems to be a better approach than cluttering all header files with 
#ifdef __cplusplus and worrying about the scope of extern "C" {} 
wrappers.

Note that I considered whether _Py_ascii_whitespace declaration should 
be done inside if !defined(HAVE_USABLE_WCHAR_T) .. directive and 
concluded that it should not.  My reasoning is as follows: _Py_ascii_whitespace must be defined unconditionally in the .c file 
because when python core is compiled, it is not known how an extension 
module would define HAVE_USABLE_WCHAR_T.  While it is not strictly 
necessary to bring _Py_ascii_whitespace definition in an extension 
module that has "USABLE_WCHAR_T", there is little to be gained from 
hiding it because it is visible to the linker.  Thus for the common uses 
there is little practical difference between the two options but 
unconditional declaration requires less code.  On the other hand in the 
context of issue4805, having unconditional declaration would allow 
removing extern "C" wrappers from unicodeobject.c without loosing C++ 
compilability of python core.

----------
keywords: +patch
Added file: http://bugs.python.org/file12600/issue4846.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 19:04:07 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 05 Jan 2009 18:04:07 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>
Message-ID: <1231178647.21.0.807233698856.issue4846@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

You beat me by 10 minutes, Alexander, otherwise I'd have had a similar
patch, except moving the declaration. I agree with your rationale
though, so yours is even better.

Concerning including the extern "C" in the PyAPI_* macros, I had the
same idea and think that that it would unclutter code a bit.

----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 19:12:42 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Jan 2009 18:12:42 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231179162.31.0.159078968126.issue3582@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- Isn't CreateThread even better?

- Using TLS functions is a good idea, beware though that the number of
TLS slots cannot exceed 1088 on Windows. This should at least be documented.
OTOH since there is only one call to PyThread_create_key in the codebase
(for the GIL), and I found only one more through the Google Code Search,
it's probably not worth the trouble.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Mon Jan  5 19:24:38 2009
From: report at bugs.python.org (Paul Nasrat)
Date: Mon, 05 Jan 2009 18:24:38 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1231179878.57.0.0309602178299.issue3959@psf.upfronthosting.co.za>


Changes by Paul Nasrat <pnasrat at googlemail.com>:


----------
nosy: +pnasrat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Mon Jan  5 19:25:40 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 05 Jan 2009 18:25:40 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231179940.61.0.317619586909.issue3582@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

No, CreateThread() is not a suitable replacement, because it lacks 
some initialisations of the C library, as explained in the MSDN: 
http://msdn.microsoft.com/en-us/library/ms682453(VS.85).aspx

----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Mon Jan  5 19:31:29 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 05 Jan 2009 18:31:29 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1231180289.06.0.730834220485.issue3997@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks nearly fine. AFAICT, care must be taken to always write
a ZIP64 end-of-cd record whenever an end-of-cd field overflows; I think
this patch is missing the condition centDirSize > ZIP64_LIMIT.

----------
assignee:  -> amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Mon Jan  5 19:55:47 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jan 2009 18:55:47 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <496238CC.2070207@egenix.com>
Message-ID: <d38f5330901051055y5434dcf5ie607552188ec198b@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Jan 5, 2009 at 11:43 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
>> GCC doesn't appear to do so, but there's no guarantee that other
>> C++ compilers won't touch these symbols:
>>
>> http://en.wikipedia.org/wiki/Name_mangling
>
> Issue #4846 is a good example of a situation where such name mangling
> causes problems even for non-function symbols.
>

You are right, I did not know that fact about MS compilers.   I am not
sure what this means to the isue of removing extern "C" from the .c
files, though.  Note that properly declared in header files global
symbols will not be affected, but only semi-private vars such as for
example allocs counters in Objects/object.c.

The allocs counters (tuple_zero_allocs, fast_tuple_allocs,
quick_int_allocs, quick_neg_int_allocs) present a case where it is
really hard to justify a change that is only motivated by C++
compilability.   Note that currently they are not getting extern "C"
at the point of definition (Objects/tupleobject.c and
Objects/intobject.c) but do at the point of declaration
(Objects/object.c).  Moving them to a header file would require
renaming with a _Py_ prefix.  Affected applications are really
esoteric: MS C++ compilation with -DCOUNT_ALLOCS.

I find it hard to get motivated to do a more thorough review of the
code searching for affected non-function symbols.  My original
motivation was just the curiosity as to why extern "C"  were added to
.c files.  I got my questions answered and I believe these
declarations serve no valid purpose, particularly inside the files
that no longer valid C++.

I see little to be gained in refining the patch further to support
non-g++ compilers.  It does not look like there is much interest in
C++ compilability to begin with.  Despite my posting to c++-sig
mailing list, no one has subscribed to this issue so far.   Maybe we
should ask on the python-list as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:08:35 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 19:08:35 +0000
Subject: [issue4849] instantiating and populating xml.dom.minidom.Element is
	cumbersome
In-Reply-To: <1231182515.38.0.572857860756.issue4849@psf.upfronthosting.co.za>
Message-ID: <1231182515.38.0.572857860756.issue4849@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

In order to create an element with an attribute and a child, this is
necessary:

    e = Element("foo")
    e.setAttribute("bar", "baz")
    e.appendChild(quux)

It would be preferable if Element.__init__ accepted two additional
parameters to shorten this:

    e = Element("foo", attributes={"bar": "baz"}, children=[quux])

It may also be preferable to have a third new parameter, attributesNS,
to parallel the Element.setAttributeNS method.  This would accept a dict
mapping namespaceURI and qualifiedName to an attribute value.

----------
components: Library (Lib)
messages: 79183
nosy: exarkun
severity: normal
status: open
title: instantiating and populating xml.dom.minidom.Element is cumbersome
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4849>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:08:41 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Mon, 05 Jan 2009 19:08:41 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231182521.13.0.338093478501.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

Update:

I requested a test ftp account from edgecast. The tech's response was
that he would file a request for it.  Will update.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:10:45 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jan 2009 19:10:45 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231178647.21.0.807233698856.issue4846@psf.upfronthosting.co.za>
Message-ID: <d38f5330901051110t70a87d85y4fb016141bc99f6f@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Not that it would matter on a two-line patch, but I find it useful to
add myself to the "nosy" list without any comments as so as I find the
issue interesting even if I have nothing to contribute at the moment.
This way I am more likely to notice when someone posts a patch before
duplicating the effort.

> Concerning including the extern "C" in the PyAPI_* macros, I had the
> same idea and think that that it would unclutter code a bit.

This would be a bigger change and getting it right would require
expertise with non-standard declarations  (__declspec(..) etc) that I
don't have.   Ulrich, you seem to be a Windows expert, can you suggest
a patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:14:45 2009
From: report at bugs.python.org (darrenr)
Date: Mon, 05 Jan 2009 19:14:45 +0000
Subject: [issue4794] garbage collector blocks and takes worst-case linear time
	wrt number of objects
In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za>
Message-ID: <1231182885.32.0.192674222703.issue4794@psf.upfronthosting.co.za>


darrenr <python-roundup at dranalli.com> added the comment:

I ask because in my opinion a three-second pause on a modern machine is
significant for any program with any sort of interactivity--significant
enough to warrant a warning in the documentation. Python is a great
language and I think it deserves an incremental implementation of
garbage collection.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4794>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:21:30 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Jan 2009 19:21:30 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1231183290.95.0.615124565518.issue3959@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I've been on vacation and unable to follow this, and won't have time to
catch up now. Note that I have no vested interest in Google's module
except knowing it has many happy users (I have never used it myself --
but Collin Winter has and he tells me it's great).

Since I haven't used either module and am not particularly interested in
this functionality, I'm withdrawing myself from the set of experts who
can decide which is better.

Duncan McGreggor asked some questions on python-dev; here are my responses:

>  * do we want to limit it to IP (i.e. no EUI/MAC support)?

I don't want to exclude EUI/MAC support, but it seems quit a separate
(and much more specialized) application area, so it's probably best to
keep it separate (even if it may make sense to use a common (abstract
or concrete) base class or just have similar APIs).

>  * do we want a single module or is a package acceptable?

I don't care either way.

>  * other thoughts?

How about a merger?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:25:10 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Jan 2009 19:25:10 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231183510.58.0.186388496302.issue3582@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You are right. 
(My dream is someday to completely get rid of this msvcrt stuff. Only
pure Win32 API)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:34:59 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 05 Jan 2009 19:34:59 +0000
Subject: [issue4794] garbage collector blocks and takes worst-case linear time
	wrt number of objects
In-Reply-To: <1231182885.32.0.192674222703.issue4794@psf.upfronthosting.co.za>
Message-ID: <496260E0.6000906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Python is a great
> language and I think it deserves an incremental implementation of
> garbage collection.

Python's cyclic garbage collector is incremental. If you can provide
a specific patch to replace it with something "better", please submit
it as a separate issue to the tracker. If you can hire somebody to
implement such a thing, go right ahead. Otherwise, I think there is
little that can be done. Python gets all of its contributions from
volunteers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4794>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:45:16 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Jan 2009 19:45:16 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>
Message-ID: <1231184716.73.0.686328292677.issue4846@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Fixed in r68344 on trunk.

Backport and forward-port candidate.

----------
keywords: +26backport -patch
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:45:21 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Jan 2009 19:45:21 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231184721.06.0.0456633895374.issue4842@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

After reading all that I still think we should fix this now, and fix
pickle so that it can read (and write?) 2.x pickles.  This is much less
visible than cmp() still being present in 3.0, and we've already decided
to kill that in 3.0.1, so we can kill int('3L') as well.

----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:49:40 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Jan 2009 19:49:40 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231178091.58.0.0746939027873.issue4846@psf.upfronthosting.co.za>
Message-ID: <49626452.6070207@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-05 18:54, Alexander Belopolsky wrote:
> I also wonder whether it would be more appropriate to redefine PyAPI_* 
> macros to declare API symbols with extern "C" when compiled under C++?  
> This seems to be a better approach than cluttering all header files with 
> #ifdef __cplusplus and worrying about the scope of extern "C" {} 
> wrappers.

This is standard practice, but of course has to be done with some
care.

In general, only macro and type definitions should live outside
the extern "C" sections, #includes must live outside those sections.

Changing the PyAPI_* macros would help with this, but I'm not sure whether
that's a catch-all solution. If it's not, then it's better to stick
with the extern "C" sections.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:57:17 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 05 Jan 2009 19:57:17 +0000
Subject: [issue4846] Py_UNICODE_ISSPACE causes linker error
In-Reply-To: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>
Message-ID: <1231185437.27.0.78160227694.issue4846@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

Actually, providing the patch for PyAPI_Data/PyAPI_Func wouldn't be so 
hard, but there are lots of headers that need to be changed, i.e. all 
their existing extern "C" clauses removed. What I would do is build 
the Python shared library as it is and then use e.g. depends.exe 
(www.dependencywalker.com) to make sure the symbols before and after 
are the same.

That's a different issue though and it's not pressing. Is it possible 
to clone this issue and make it a feature request (Include extern"C" 
in PyAPI_* macros)?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________

From report at bugs.python.org  Mon Jan  5 20:58:24 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 05 Jan 2009 19:58:24 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <d38f5330901051055y5434dcf5ie607552188ec198b@mail.gmail.com>
Message-ID: <4962665E.2030504@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-05 19:55, Alexander Belopolsky wrote:
> The allocs counters (tuple_zero_allocs, fast_tuple_allocs,
> quick_int_allocs, quick_neg_int_allocs) present a case where it is
> really hard to justify a change that is only motivated by C++
> compilability.   Note that currently they are not getting extern "C"
> at the point of definition (Objects/tupleobject.c and
> Objects/intobject.c) but do at the point of declaration
> (Objects/object.c).  Moving them to a header file would require
> renaming with a _Py_ prefix.  Affected applications are really
> esoteric: MS C++ compilation with -DCOUNT_ALLOCS.

For completeness, all exported symbols in Python should have a _Py_
prefix, even if they only get exported in certain debug builds.

> I find it hard to get motivated to do a more thorough review of the
> code searching for affected non-function symbols.  My original
> motivation was just the curiosity as to why extern "C"  were added to
> .c files.  I got my questions answered and I believe these
> declarations serve no valid purpose, particularly inside the files
> that no longer valid C++.

Like I mentioned earlier on: those declarations did serve a purpose
for early MS VC++ versions (at least AFAIR). It may well be the case
that they are no longer needed nowadays, but then they don't hurt
much either.

Given that you can build Python as library on Unix and as DLL on
Windows, there doesn't appear to be any need to actually be able
to build Python itself using a C++ compiler. Simply using the
header files and linking against those libraries should do the
trick in most cases.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Mon Jan  5 21:00:30 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 05 Jan 2009 20:00:30 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1231185630.52.0.501603701447.issue3959@psf.upfronthosting.co.za>


Changes by Adam Olsen <rhamph at gmail.com>:


----------
nosy: +Rhamphoryncus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Mon Jan  5 21:02:14 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 05 Jan 2009 20:02:14 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231185734.42.0.746471339144.issue4676@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Patch against trunk attached.
It fixes only the first problem reported, and I can't reproduce the
second one.

----------
keywords: +patch
Added file: http://bugs.python.org/file12601/issue_4676.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Mon Jan  5 21:31:59 2009
From: report at bugs.python.org (Terry Helge)
Date: Mon, 05 Jan 2009 20:31:59 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231093333.6.0.679938116402.issue4836@psf.upfronthosting.co.za>
Message-ID: <1231187519.81.0.624587074793.issue4836@psf.upfronthosting.co.za>


Terry Helge <skillybob2 at gmail.com> added the comment:

Additional testing  - tried programs on a different computer with a
fresh copy of Python and pyGame - same results 
Program will not close(hangs) in IDLE  - but will close with drPython
Go Figure.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________

From report at bugs.python.org  Mon Jan  5 21:36:55 2009
From: report at bugs.python.org (gumpy)
Date: Mon, 05 Jan 2009 20:36:55 +0000
Subject: [issue4840] Compile dbm in Ubuntu
In-Reply-To: <1231129467.43.0.877411679563.issue4840@psf.upfronthosting.co.za>
Message-ID: <1231187815.61.0.981180541573.issue4840@psf.upfronthosting.co.za>


gumpy <gumpy2k7 at gmail.com> added the comment:

I believe this is already fixed. #4483

----------
nosy: +gumpy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4840>
_______________________________________

From report at bugs.python.org  Mon Jan  5 21:45:21 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 05 Jan 2009 20:45:21 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231093333.6.0.679938116402.issue4836@psf.upfronthosting.co.za>
Message-ID: <1231188321.12.0.563019508524.issue4836@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Can you add some example ?
Is the bug new to python 2.6 ?

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________

From report at bugs.python.org  Mon Jan  5 21:47:29 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 05 Jan 2009 20:47:29 +0000
Subject: [issue4840] Compile dbm in Ubuntu
In-Reply-To: <1231129467.43.0.877411679563.issue4840@psf.upfronthosting.co.za>
Message-ID: <1231188449.85.0.872891395918.issue4840@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4840>
_______________________________________

From report at bugs.python.org  Mon Jan  5 21:48:46 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jan 2009 20:48:46 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <1231188525.86.0.28964443261.issue4850@psf.upfronthosting.co.za>
Message-ID: <1231188525.86.0.28964443261.issue4850@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

quick_int_allocs, quick_neg_int_allocs, tuple_zero_allocs, and 
fast_tuple_allocs are exported in -DCOUNT_ALLOCS builds.  They should get 
a conventional _Py_ prefix.  Also since tp_allocs is now Py_ssize_t, these 
should be redefined as Py_ssize_t as well.  See msg79194 .

----------
components: Interpreter Core
messages: 79199
nosy: belopolsky
severity: normal
status: open
title: Change type and add _Py_ prefix to COUNT_ALLOCS variables
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Mon Jan  5 21:49:18 2009
From: report at bugs.python.org (Terry Helge)
Date: Mon, 05 Jan 2009 20:49:18 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231188321.12.0.563019508524.issue4836@psf.upfronthosting.co.za>
Message-ID: <ef4249160901051249q10f60d1dqa14c2cf0285f2021@mail.gmail.com>


Terry Helge <skillybob2 at gmail.com> added the comment:

I'm not sure if the bug is in Python(IDLE) or pyGame - I'm pretty new to
this . I'm still checking out various things - thanks for your interest!

On Mon, Jan 5, 2009 at 2:45 PM, Guilherme Polo <report at bugs.python.org>wrote:

>
> Guilherme Polo <ggpolo at gmail.com> added the comment:
>
> Can you add some example ?
> Is the bug new to python 2.6 ?
>
> ----------
> nosy: +gpolo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4836>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090105/b29a9adc/attachment.txt>

From report at bugs.python.org  Mon Jan  5 22:05:22 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 05 Jan 2009 21:05:22 +0000
Subject: [issue4844] ZipFile doesn't range check in _EndRecData()
In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>
Message-ID: <1231189522.4.0.190515968256.issue4844@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12603/issue4844.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4844>
_______________________________________

From report at bugs.python.org  Mon Jan  5 22:06:27 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jan 2009 21:06:27 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <4962665E.2030504@egenix.com>
Message-ID: <d38f5330901051305n317e8a7ate5ce38312cecf153@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Jan 5, 2009 at 2:58 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> For completeness, all exported symbols in Python should have a _Py_
> prefix, even if they only get exported in certain debug builds.
>
I actually agree, but I felt that doing this as a part of this patch
would make it even less likely to be accepted.   There is another
change that needs to be done to the alloc counts - namely changing the
type from int to Py_ssize_t and %d to %zd in print formats.  I will
submit that as a separate issue.  (See issue4850.)

The only downside of having them is that a #ifdef __cplusplus
instruction strongly suggests that a file is intended to be valid C++,
which is currently not the case.

> Given that you can build Python as library on Unix and as DLL on
> Windows, there doesn't appear to be any need to actually be able
> to build Python itself using a C++ compiler. Simply using the
> header files and linking against those libraries should do the
> trick in most cases.

So what is your position on the proposed patch?  Is it worthwhile to
track down the remaining symbols that may be affected by removal of
extern "C" from .c files?  What is your opinion on the original patch
(c++-patch.diff) which restores C++ compilability but does not touch
these declarations?

I think using C++ as a lint variant from time to time is a good
exercise to catch some corner issues as I hope this patch
demonstrates.  I don't think this should be a requirement on every
submission, but once an effort is made to restore C++ compilability,
such changes should be applied unless there are valid concerns against
them.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Mon Jan  5 22:43:55 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Mon, 05 Jan 2009 21:43:55 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231191835.63.0.356817896531.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

Edgecast.com support created a test ftp account for the purpose of
troubleshooting this issue. Please email me (chris.mahan at gmail.com) and
I'll forward you the login info.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Mon Jan  5 23:00:10 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 22:00:10 +0000
Subject: [issue4851] xml.dom.minidom.Element.cloneNode fails with
	AttributeError
In-Reply-To: <1231192810.66.0.263343969898.issue4851@psf.upfronthosting.co.za>
Message-ID: <1231192810.66.0.263343969898.issue4851@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

It seems impossible to clone an Element created without a document:

  >>> Element('foo').cloneNode(False)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python2.5/xml/dom/minidom.py", line 211, in cloneNode
      return _clone_node(self, deep, self.ownerDocument or self)
    File "/usr/lib/python2.5/xml/dom/minidom.py", line 1814, in _clone_node
      if node.ownerDocument.isSameNode(newOwnerDocument):
  AttributeError: 'NoneType' object has no attribute 'isSameNode'

The documentation claims that cloneNode was fixed for releases
"subsequent" to 2.0, but this doesn't appear to be true.

http://docs.python.org/library/xml.dom.minidom.html#xml.dom.minidom.Node.cloneNode

A similar issue occurs when attempting to import a node into a document
(something I tried as a work-around for this failure):

  >>> d.importNode(e, False)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python2.5/xml/dom/minidom.py", line 1737, in importNode
      return _clone_node(node, deep, self)
    File "/usr/lib/python2.5/xml/dom/minidom.py", line 1814, in _clone_node
      if node.ownerDocument.isSameNode(newOwnerDocument):
  AttributeError: 'NoneType' object has no attribute 'isSameNode'

----------
components: Library (Lib)
messages: 79203
nosy: exarkun
severity: normal
status: open
title: xml.dom.minidom.Element.cloneNode fails with AttributeError
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4851>
_______________________________________

From report at bugs.python.org  Mon Jan  5 23:39:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 05 Jan 2009 22:39:40 +0000
Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories
	properly
In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za>
Message-ID: <1231195180.04.0.535859360579.issue4710@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a version of the patch that rationalizes usage of os.sep, fixes
a few bugs with r2, and adds a test case.

----------
keywords: +needs review
nosy: +loewis
Added file: http://bugs.python.org/file12604/dir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4710>
_______________________________________

From report at bugs.python.org  Mon Jan  5 23:40:31 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 22:40:31 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231195231.53.0.850566480696.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, some news about this bug (I tested the ftp test account): the 
problem is that the data socket is not closed when self.voidresp() is 
called. I can't see close() syscall before the call to 
self.voidresp(). SocketIO.close() does nothing: it does not really 
close the socket, just the file. And socket.close() does also nothing 
because there is still an io reference... the closed file :-/ The io 
reference counter is only updated when the file is destroyed.
   conn = <create a socket>
   # conn._io_refs=0
   fp = conn.makefile('r', encoding=self.encoding)
   # conn._io_refs=1
   ...
   fp.close()    # only set fp.closed to True
   conn.close()  # only set conn._closed to True
   # conn._io_refs=1 and the socket (file descriptor) is still open
   del fp
   # conn._io_refs=0 -> the socket is finally closed!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Mon Jan  5 23:40:36 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 05 Jan 2009 22:40:36 +0000
Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories
	properly
In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za>
Message-ID: <1231195236.42.0.772773756247.issue4710@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Added file: http://bugs.python.org/file12605/zipdir.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4710>
_______________________________________

From report at bugs.python.org  Mon Jan  5 23:51:26 2009
From: report at bugs.python.org (Gregor Kopka)
Date: Mon, 05 Jan 2009 22:51:26 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1231195886.34.0.986885567758.issue4301@psf.upfronthosting.co.za>


Gregor Kopka <mailfrom-bugs.python.org at kopka.net> added the comment:

I ran into this shortly but was able to overcome it by patching
/Lib/logging/__init__.py:

43-44:
     import threading
+    import multiprocessing
 except ImportError:

270-271:
             self.process = os.getpid()
+            self.processName = multiprocessing.current_process()._name
         else:

(and some info about %(processName)s into the docstring) to make it
usable for me.

After that the following works like intended:


import multiprocessing
import logging
logging.basicConfig(level=logging.DEBUG, format='%(asctime)s
%(processName)s %(threadName)s %(levelname)s  %(message)s')

# omit next line to get only what your code is logging
logger = multiprocessing.get_logger()

def f():
    logging.info('info from subprocess')

if __name__ == '__main__':
    logging.info('info from main process')
    p = multiprocessing.Process(target=f)
    p.start()
    p.join()


Surely no perfect solution, but the monkey-patching in
multiprocessing.util._check_logger_class() dosn't seem to do the trick.

Other option is to not use %(processName)s in logging format, but
%(process)s instead - then it works without patching the logging module
(but you get numeric process IDs):


import multiprocessing

import logging
logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(process)s
%(threadName)s %(levelname)s  %(message)s')

# omit next line to get only what your code is logging
logger = multiprocessing.get_logger()

def f():
    logging.info('info from subprocess')

if __name__ == '__main__':
    logging.info('info from main process')
    p = multiprocessing.Process(target=f)
    p.start()
    p.join()


2009-01-05 23:48:02,046 4000 MainThread INFO  info from main process
2009-01-05 23:48:02,187 3968 MainThread INFO  child process calling
self.run()
2009-01-05 23:48:02,187 3968 MainThread INFO  info from subprocess
2009-01-05 23:48:02,187 3968 MainThread INFO  process shutting down
2009-01-05 23:48:02,187 3968 MainThread DEBUG  running all "atexit"
finalizers with priority >= 0
2009-01-05 23:48:02,187 3968 MainThread DEBUG  running the remaining
"atexit" finalizers
2009-01-05 23:48:02,203 3968 MainThread INFO  process exiting with
exitcode 0
2009-01-05 23:48:02,203 4000 Dummy-1 INFO  process shutting down
2009-01-05 23:48:02,203 4000 Dummy-1 DEBUG  running all "atexit"
finalizers with priority >= 0
2009-01-05 23:48:02,203 4000 Dummy-1 DEBUG  running the remaining
"atexit" finalizers

----------
nosy: +Gregor_Kopka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:04:08 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:04:08 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231196648.64.0.444112987169.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch: SocketIO.close() decrements the io reference of its socket, so 
socket.close() will really close the socket.

About the FTP server ftp2.edgecastcdn.net, it looks like the server 
doesn't write "226 Transfert completed" until the data socket is 
really closed. The server says that it's running EdgeFTPD 1.1. nmap 
says that the ftp server is ProFTPD 1.2.10 running on Linux 2.6.

----------
keywords: +patch
Added file: http://bugs.python.org/file12606/socket_real_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:06:26 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jan 2009 23:06:26 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <1231188525.86.0.28964443261.issue4850@psf.upfronthosting.co.za>
Message-ID: <1231196786.24.0.32603248713.issue4850@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch is fairly straightforward with only one caveat: instead 
of prefixing unlist_types_without_objects flag with _Py_, I made it 
static.  This may not be the right thing if it is intended to be 
accessible from third party modules (it is not used outside of object.c 
in python code).  I am not sure how it is supposed to be used because it 
appears to be always 0. (Maybe the intent is to change it manually in 
specialized builds or in debugger.)

I am not proposing to move declarations to header files with this patch.  
That change would cause a massive recompile for everyone and if a 
decision is made that globals' declarations belong to header files, this 
should probably be done it one sweep with issue4805 .

----------
keywords: +patch
nosy: +lemburg
Added file: http://bugs.python.org/file12607/issue4850.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:08:14 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:08:14 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231196894.42.0.594150422714.issue4791@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12606/socket_real_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:08:31 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:08:31 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231196911.15.0.351613211797.issue4791@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file12608/socket_real_close-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:12:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:12:38 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231197158.45.0.496655159087.issue3826@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #4791 is exaclty the same problem (io reference in SocketIO): I 
proposed another patch (decrement the io reference but keep the 
self._sock object unchanged).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:13:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:13:47 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231197227.47.0.726175218471.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #3826 is the same issue and has already patch with 2 unit tests. 
The patch is different: it uses "del self._sock".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:25:15 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:25:15 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231197915.06.0.0497669744721.issue3826@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Comment about issue3826_gps05.diff:
 - I don't like "magical" attributes (sometimes it does exist, 
sometimes not) even if it's a protected attribute (_sock) => use 
self._sock=None?
 - fileno() returns a fixed value whereas the socket.fileno() 
returns -1 when the socket is closed => returns -1 or raise an error 
if the socket is closed?
 - I'm not sure that your test is really working: read a closed socket 
may raise an error because of the test on self._closed, not because 
the low level socket is closed => use fileno() to check if the socket 
is closed or not

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:28:51 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Jan 2009 23:28:51 +0000
Subject: [issue4852] Cleanup old stuff from pythread.h
In-Reply-To: <1231198131.15.0.910339238584.issue4852@psf.upfronthosting.co.za>
Message-ID: <1231198131.15.0.910339238584.issue4852@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

This patch removes four functions from pythread.h, which have been 
unusable for ages:
- PyThread_exit_prog is excluded by a #ifndef, and the NO_EXIT_PROG 
symbol is defined in the same file.
- PyThread__PyThread_exit_thread appears in the .h but is not defined 
anywhere. OTOH the different thread implementations define 
PyThread__exit_thread but it is not exposed anywhere (since r12178...)

Better remove unused code...

----------
files: thread_cleanup.patch
keywords: needs review, patch, patch
messages: 79212
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Cleanup old stuff from pythread.h
versions: Python 2.7
Added file: http://bugs.python.org/file12609/thread_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4852>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:29:47 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 05 Jan 2009 23:29:47 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231198187.71.0.537669615904.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

from #python-dev discussion.

agreed, magic attributes are annoying.  also, my gps05 patch continues
to return the old fileno even after the underlying socket has been
closed.  that is a problem.

I like your patch in #4791 but lets keep both sets of our unit tests.

Also, I think the SocketIO.fileno mathod should change to:

  def fileno(self):
    no = self._sock.fileno()
    if no == -1:
      raise IOError("no file descriptor, socket is closed.")

io.IOBase.fileno already raises IOError when no file descriptor is
associated with a file so this behavior seems reasonable and more
pythonic than returning a magic -1.

thoughts?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:34:21 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:34:21 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231198461.49.0.72728430696.issue3826@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Also, I think the SocketIO.fileno mathod should change to: (...)

Since SocketIO.fileno() just calls self._sock.fileno(), it would be 
easier (and better) to fix socket.socket(). But since socket.fileno() 
calls socket._fileno() we can just fix it correctly once in 
socketmodule.c ;-) And instead IOError, I would prefer socket.error.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:34:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 23:34:26 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231198466.7.0.23466659172.issue4842@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I guess that makes this a release blocker for 3.0.1, then.

Here's a second patch, complementary to the first, that fixes pickling of 
longs so that pickle protocol 0 in Python 3.0.1 and later behaves 
identically to pickle protocol 0 in Python 2.x.  Namely:

 - an 'L' is always appended on output, and
 - an 'L' is permitted, but not required, on input

This keeps compatibility both with 2.x and with 3.0.0.

issue4842_pickle.patch should be applied before issue4842.patch.

----------
priority:  -> release blocker
stage:  -> patch review
Added file: http://bugs.python.org/file12610/issue4842_pickle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:43:46 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:43:46 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231199026.41.0.541217341461.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch:
 - Change _socket.fileno() behaviour: raise socket.error("I/O 
operation on closed socket") (instead of returning -1) if the socket 
is closed
 - Change SocketIO.fileno(): raise a socket.error("I/O operation on 
closed socket") if the file is closed, even if the socket is still 
open

TODO: Check all operations on closed _socket, socket or SocketIO and 
make sure that it raises also an error.

exakrun on IRC:
   What's the fascination with -1?
   Isn't this Python?  How about an exception? Or at least a different 
type... None, perhaps?
   Returning -1 is what you would do in a language like C where you 
*can't* do something nice.

Added file: http://bugs.python.org/file12611/socket_real_close-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:43:50 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:43:50 +0000
Subject: [issue4791] retrlines('LIST') and dir hang at end of listing in
	ftplib (python3.0)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231199030.48.0.409430182517.issue4791@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12608/socket_real_close-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:45:16 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jan 2009 23:45:16 +0000
Subject: [issue4791] ftplib.retrlines('LIST') hangs at the end of listing
	(SocketIO.close() doesn't close the socket)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231199116.79.0.059386512988.issue4791@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: retrlines('LIST') and dir hang at end of listing in ftplib (python3.0) -> ftplib.retrlines('LIST') hangs at the end of listing (SocketIO.close() doesn't close the socket)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:48:31 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Jan 2009 23:48:31 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231199311.96.0.618999978154.issue3826@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 00:49:11 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Jan 2009 23:49:11 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231199351.53.0.717457969962.issue4842@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Tue Jan  6 01:31:04 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 00:31:04 +0000
Subject: [issue4853] I/O operation on closed socket: improve the error message
In-Reply-To: <1231201863.3.0.481342348653.issue4853@psf.upfronthosting.co.za>
Message-ID: <1231201863.3.0.481342348653.issue4853@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I don't like the current behaviour of Python on closed socket:

>>> import socket
>>> s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.close()
>>> s.fileno()
-1
>>> s.getsockname()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: [Errno 9] Bad file descriptor

Some operations are still allowed whereas the other raise an ugly 
error message. Most (or all) operation on a closed socket should be 
blocked by a socket.error.

My patch raises a socket.error("I/O operation on closed socket") for 
most operations except:
 - close(): it call be called twice (or more) (keep current behaviour)
 - gettimeout(): should we raise an error?
 - setblocking(), settimeout(): should we raise an error? Maybe yes 
for setter but no for getter which would be inconsistent with 
getpeername()...

The io library already has this behaviour: read(), write(), flush(), 
etc. are blocked by a ValueError("I/O operation on closed file") (see 
IOBase._check_closed in the io library).

Issue #4791 changes the behaviour of closed SocketIO object: fileno() 
method raise a socket.error if it's closed even if the socket is still 
open.

----------
files: socket_error_closed.patch
keywords: patch
messages: 79217
nosy: haypo
severity: normal
status: open
title: I/O operation on closed socket: improve the error message
versions: Python 3.0
Added file: http://bugs.python.org/file12612/socket_error_closed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4853>
_______________________________________

From report at bugs.python.org  Tue Jan  6 01:39:40 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 00:39:40 +0000
Subject: [issue4791] ftplib.retrlines('LIST') hangs at the end of listing
	(SocketIO.close() doesn't close the socket)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231202380.15.0.834821770645.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created a separated patch to block operation on closed socket: Issue 
#4853.

So I simplified the patch to change on Modules/socketmodule.c and I 
reused self._checkClosed() in SocketIO.

Added file: http://bugs.python.org/file12613/socket_real_close-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 01:39:45 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 00:39:45 +0000
Subject: [issue4791] ftplib.retrlines('LIST') hangs at the end of listing
	(SocketIO.close() doesn't close the socket)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231202385.6.0.542699684032.issue4791@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12611/socket_real_close-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:06:24 2009
From: report at bugs.python.org (Christopher Mahan)
Date: Tue, 06 Jan 2009 01:06:24 +0000
Subject: [issue4791] ftplib.retrlines('LIST') hangs at the end of listing
	(SocketIO.close() doesn't close the socket)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231203984.15.0.396237387761.issue4791@psf.upfronthosting.co.za>


Christopher Mahan <chris.mahan at gmail.com> added the comment:

edgecast support said the ftp server is ProFTPD version 1.3.1.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:09:24 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:09:24 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231204164.21.0.865111516988.issue3826@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I spent two hours on this issue and here are some notes...

(1) SocketIO.close() have to call self._sock._decref_socketios() to 
allow the socket to call _real_close()

s = socket...
f = s.makefile()
f.close()  # only close the "file view"
s.close() <= close the socket here

(2) SocketIO.close() have to break its reference to allow the socket 
to be closed

s = socket...
f = s.makefile()
del s      # there is still one reference (f._sock)
f.close() <= the garbage collector will close the socket here

(3) operations on a closed SocketIO should be blocked

s = socket...
f = s.makefile()
f.close()
f.fileno() => error!

So issue3826_gps05.diff have two bugs:
 - point (1)
 - point (3): can be fixed by adding self._check_closed() (and so we 
don't need the local copy of fileno)

Added file: http://bugs.python.org/file12614/socket_real_close-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:09:58 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:09:58 +0000
Subject: [issue4791] ftplib.retrlines('LIST') hangs at the end of listing
	(SocketIO.close() doesn't close the socket)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231204198.13.0.378937840712.issue4791@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12613/socket_real_close-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:13:32 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:13:32 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231204412.44.0.941953810525.issue3826@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

socket_real_close-5.patch: my own patch developed for the issue #4791 
(which is exactly the same problem) to fix SocketIO:
 - set self._sock=None on close
 - update the io reference count directly in close() (but also in 
destructor)
 - add a regression test

You may merge my patch with gps's patch (which has different tests).

See also issue #4853 to block all operations on closed socket in the 
low level API (socketmodule.c).

Added file: http://bugs.python.org/file12615/socket_real_close-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:15:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:15:10 +0000
Subject: [issue4791] ftplib.retrlines('LIST') hangs at the end of listing
	(SocketIO.close() doesn't close the socket)
In-Reply-To: <1230728461.13.0.270652897235.issue4791@psf.upfronthosting.co.za>
Message-ID: <1231204510.56.0.176823773572.issue4791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm closing this issue because it's a duplicate of #3826, issue with a 
longer history and more details about the different problems of 
closing a socket.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4791>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:15:40 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:15:40 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231204540.63.0.146349760972.issue3826@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12614/socket_real_close-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:18:45 2009
From: report at bugs.python.org (=?utf-8?q?s=C3=A9bastien_martini?=)
Date: Tue, 06 Jan 2009 01:18:45 +0000
Subject: [issue4854] gnu_get_libc_version() returns bad number on Ubuntu 64
	bits
In-Reply-To: <1231204725.41.0.336629965086.issue4854@psf.upfronthosting.co.za>
Message-ID: <1231204725.41.0.336629965086.issue4854@psf.upfronthosting.co.za>


New submission from s?bastien martini <seb at dbzteam.org>:

System: Ubuntu 8.10 Desktop AMD 64
Processor: Intel Core i7
Python: 2.5.2

While raw C code:

#include <gnu/libc-version.h>
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
  printf("GNU libc version: %s\n", gnu_get_libc_version());
  return 0;
}

prints:
GNU libc version: 2.8.90

Python ctypes seems to bug:
$ python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:29:17) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, ctypes, ctypes.util
>>> sys.version
'2.5.2 (r252:60911, Oct  5 2008, 19:29:17) \n[GCC 4.3.2]'
>>> sys.platform
'linux2'
>>> LIBC = ctypes.cdll.LoadLibrary(ctypes.util.find_library('c'))
>>> LIBC
<CDLL 'libc.so.6', handle 7f6d83122958 at 7f6d82fe8210>
>>> LIBC.gnu_get_libc_version()
-2109473701

----------
assignee: theller
components: ctypes
messages: 79223
nosy: smartini, theller
severity: normal
status: open
title: gnu_get_libc_version() returns bad number on Ubuntu 64 bits
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4854>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:31:14 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:31:14 +0000
Subject: [issue4847] csv fails when file is opened in binary mode
In-Reply-To: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>
Message-ID: <1231205474.53.0.665479256854.issue4847@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Short patch fixing the examples + the description of reader() and 
writer() (remove the "b" flag sentence: it's wrong, we need unicode!). 
I hope that I didn't break the documentation (i tried "make text" and 
i didn't get any warning).

----------
keywords: +patch
Added file: http://bugs.python.org/file12616/csv_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4847>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:33:35 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:33:35 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1231205615.94.0.654154648235.issue4676@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:35:07 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:35:07 +0000
Subject: [issue4136] merge json library with simplejson 2.0.3
In-Reply-To: <1224194929.7.0.263636117378.issue4136@psf.upfronthosting.co.za>
Message-ID: <1231205707.76.0.128840610094.issue4136@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4136>
_______________________________________

From report at bugs.python.org  Tue Jan  6 02:38:09 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 01:38:09 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <4961E488.4060202@egenix.com>
Message-ID: <200901060238.39558.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > I propose to reject unicode in Python 3.x and display a warning for
> > Python 2.x. A warning to prepare the migration... not to Unicode, but to
> > Python3 ;-)
>
> Fair enough.

The patch for Python 3.x is already attached to this issue. We might only 
apply this one and leave Python 2.x unchanged. Can someone review the patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Tue Jan  6 04:06:31 2009
From: report at bugs.python.org (=?utf-8?q?s=C3=A9bastien_martini?=)
Date: Tue, 06 Jan 2009 03:06:31 +0000
Subject: [issue4854] gnu_get_libc_version() returns bad number on Ubuntu 64
	bits
In-Reply-To: <1231204725.41.0.336629965086.issue4854@psf.upfronthosting.co.za>
Message-ID: <1231211191.54.0.969956622045.issue4854@psf.upfronthosting.co.za>


s?bastien martini <seb at dbzteam.org> added the comment:

Ooops, my mistake, there is nothing wrong, this report can be closed, sorry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4854>
_______________________________________

From report at bugs.python.org  Tue Jan  6 04:41:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 06 Jan 2009 03:41:25 +0000
Subject: [issue4854] gnu_get_libc_version() returns bad number on Ubuntu 64
	bits
In-Reply-To: <1231204725.41.0.336629965086.issue4854@psf.upfronthosting.co.za>
Message-ID: <1231213285.93.0.246550947362.issue4854@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4854>
_______________________________________

From report at bugs.python.org  Tue Jan  6 05:44:56 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 06 Jan 2009 04:44:56 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231217096.22.0.450994019659.issue4753@psf.upfronthosting.co.za>


Changes by Jeffrey Yasskin <jyasskin at gmail.com>:


----------
nosy: +collinwinter, jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Tue Jan  6 05:49:20 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 06 Jan 2009 04:49:20 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1231217360.34.0.0251532519151.issue4819@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Some more for both 2. and 3.0:

- 'as' is now a keyword 
- 'with' is now a keyword 
- @ is now a valid token 
- 0o for octal and 0b for binary numbers
- sets
- str.format
- BaseException

I am sure I missed a lot, but the core language sections should be 
fairly easy to update.  The library part seems to be a major project.

It would be nice to reformat it in ReST as well.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:01:45 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:01:45 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
Message-ID: <1231218105.65.0.396713191476.issue4617@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't think this has much to do with try/except.  That it works in 2.6
but not in 3.0 isn't a big deal; the semantics of variables used in
except clauses has changed dramatically.

It has to do with deletion of a variable that's held in a cell for
reference by an inner function, like this:

def outer():
  x = 0
  def inner(): return x
  del x  # SyntaxError

I suspect (but do not know for sure) that the reason this is considered
a SyntaxError is that the implementer of cells punted on the 'del'
implementation and inserted a SyntaxError instead.  (You can tell it's a
pass-two SyntaxError because it doesn't mention a line number.)

I think it's fine to fix this in 2.7 and 3.1, but I don't see it as a
priority given that this has always been this way (and despite that it
now affects try/except).  It will probably require a new opcode.

I don't see a reason to declare this a release blocker just because the
try/except code is affected, and I don't think try/except needs to be
changed to avoid this.

----------
assignee: gvanrossum -> 
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:02:42 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:02:42 +0000
Subject: [issue2897] include structmember.h in Python.h
In-Reply-To: <1210977912.97.0.641461512834.issue2897@psf.upfronthosting.co.za>
Message-ID: <1231218162.05.0.267294780791.issue2897@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2897>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:02:53 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:02:53 +0000
Subject: [issue2897] include structmember.h in Python.h
In-Reply-To: <1210977912.97.0.641461512834.issue2897@psf.upfronthosting.co.za>
Message-ID: <1231218173.8.0.329153608574.issue2897@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2897>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:03:40 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:03:40 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1231218220.49.0.938105313872.issue2226@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm not going to get to this.

----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:03:49 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:03:49 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1231218229.03.0.51508102773.issue2226@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:04:50 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:04:50 +0000
Subject: [issue2772] Add PendingDeprecationWarning for % formatting
In-Reply-To: <1210083250.98.0.889504486731.issue2772@psf.upfronthosting.co.za>
Message-ID: <1231218290.08.0.787060551121.issue2772@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Not it.

----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2772>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:04:58 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:04:58 +0000
Subject: [issue2772] Add PendingDeprecationWarning for % formatting
In-Reply-To: <1210083250.98.0.889504486731.issue2772@psf.upfronthosting.co.za>
Message-ID: <1231218298.14.0.728744131375.issue2772@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2772>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:05:23 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:05:23 +0000
Subject: [issue1708] improvements for linecache
In-Reply-To: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za>
Message-ID: <1231218323.34.0.265205077309.issue1708@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:05:29 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:05:29 +0000
Subject: [issue1708] improvements for linecache
In-Reply-To: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za>
Message-ID: <1231218329.55.0.128046660678.issue1708@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:06:06 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:06:06 +0000
Subject: [issue2073] asynchat push always sends 512 bytes (ignoring
	ac_out_buffer_size)
In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>
Message-ID: <1231218366.08.0.8319168322.issue2073@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2073>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:06:10 2009
From: report at bugs.python.org (wolfy)
Date: Tue, 06 Jan 2009 05:06:10 +0000
Subject: [issue4855] Popen with Shell=True should return the command
Message-ID: <1231218370.85.0.274309430706.issue4855@psf.upfronthosting.co.za>


Changes by wolfy <wolfgang_a_h at gmx.at>:


----------
nosy: wolfy
severity: normal
status: open
title: Popen with Shell=True should return the command

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4855>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:06:14 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:06:14 +0000
Subject: [issue2073] asynchat push always sends 512 bytes (ignoring
	ac_out_buffer_size)
In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>
Message-ID: <1231218374.17.0.624806505003.issue2073@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2073>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:06:29 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:06:29 +0000
Subject: [issue1772833] -q (quiet) option for python interpreter
Message-ID: <1231218389.08.0.529890077101.issue1772833@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772833>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:06:53 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:06:53 +0000
Subject: [issue614557] LookupError etc. need API to get the key
Message-ID: <1231218413.15.0.349881702411.issue614557@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue614557>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:07:13 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Jan 2009 05:07:13 +0000
Subject: [issue1911] webbrowser.open firefox 3 issues
In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za>
Message-ID: <1231218433.8.0.897555256297.issue1911@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1911>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:22:10 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 06 Jan 2009 05:22:10 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <1231188525.86.0.28964443261.issue4850@psf.upfronthosting.co.za>
Message-ID: <1231219330.59.0.135067362134.issue4850@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Martin,

Can you comment on whether unlist_types_without_objects should be global?  
Svn blame point to you for introducing it.

Thanks.

$ svn blame Objects/object.c | grep  unlist_types_without_objects
 45527 martin.v.loewis int unlist_types_without_objects;

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:31:14 2009
From: report at bugs.python.org (Mark Miller)
Date: Tue, 06 Jan 2009 05:31:14 +0000
Subject: [issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips
	instead of mipsel)
In-Reply-To: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za>
Message-ID: <1231219874.65.0.558189322498.issue4305@psf.upfronthosting.co.za>


Mark Miller <mark at mirell.org> added the comment:

It's actually due to the merge of the libffi3 branch back in March,
which removed the logic for configure to deal with MIPS in
fficonfig.py.in. I've attached a patch which allows the build to work
correctly on the QEMU instance of the MIPSEL machine I have.

----------
keywords: +patch
nosy: +mirell
Added file: http://bugs.python.org/file12617/mips-ffi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4305>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:40:25 2009
From: report at bugs.python.org (wolfy)
Date: Tue, 06 Jan 2009 05:40:25 +0000
Subject: [issue4855] Popen with Shell=True should return the command's PID,
	not the shell's
In-Reply-To: <1231220425.64.0.851147644427.issue4855@psf.upfronthosting.co.za>
Message-ID: <1231220425.64.0.851147644427.issue4855@psf.upfronthosting.co.za>


New submission from wolfy <wolfgang_a_h at gmx.at>:

When using proc = Popen() with the parameter "shell=True", the returned 
proc-object's Process ID (PID) obtained by reading "proc.pid" is the 
one of the shell that was created.

This gets very cumbersome, when the newly created process shall be 
signalled later on.
It is very rare that one needs to signal the shell instead of the newly 
started executable.

Moreover, sending a signal to the shell does (for some reason) not get 
propagated to the child (=the executable/command), so the shell is quit/
terminated/killed/whatever and the command's thread is kept alive.

Using 'shell=False' is not an option in case the originating process 
has more code to execute, e.g. in order to communicate with the newly 
started process via pipes (i.e. using proc.stdout.readline() or 
similar), because in that case Python uses os.execvp() for the command, 
which re-uses (and therefore blocks) the current thread of control in 
which the Popen was issued.

Starting another thread with fork() is also not an option, as the Popen 
will be executed in a different thread, which makes it difficult to 
pass the reference to the proc-object back into the original thread 
where it is needed for the inter-process-communication.

All examples I found on the net which use pipes to communicate between 
current and newly started command use of course 'shell=True', I did not 
however find any simple way to get the child's PID (aside from issuing 
a 'ps --ppid <PPID> -o pid=' and reading it's output, as I did, which 
is far from elegant).

So, there should be one of these alternative possibilities/behaviours 
in case of 'Popen(...,shell=True...)':

1) proc gets a new field or method child_pid/child_pid() which returns 
the command's PID. proc.pid behaves as before
2) Signalling the shell's process notifies all children with the same 
signal. proc.pid behaves as before 
3) proc.pid returns the command's PID (instead of the shell's)
4) There is some simple command to query all the childs PIDs of a 
process when passing in the PPID (parent PID). proc.pid behaves as 
before

...with 1) being the most up to 4) being the least desireable.

I hope I did not overlook any such possibility, but searching around on 
the net and in the tracker turned up nothing useful.

I really do think this should be more intuitive.

----------
title: Popen with Shell=True should return the command -> Popen with Shell=True should return the command's PID, not the shell's
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4855>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:41:56 2009
From: report at bugs.python.org (wolfy)
Date: Tue, 06 Jan 2009 05:41:56 +0000
Subject: [issue4855] Popen(..., shell=True,
	...) should allow simple access to the command's PID
In-Reply-To: <1231220425.64.0.851147644427.issue4855@psf.upfronthosting.co.za>
Message-ID: <1231220516.51.0.636987684336.issue4855@psf.upfronthosting.co.za>


Changes by wolfy <wolfgang_a_h at gmx.at>:


----------
title: Popen with Shell=True should return the command's PID, not the shell's -> Popen(..., shell=True,...) should allow simple access to the command's PID

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4855>
_______________________________________

From report at bugs.python.org  Tue Jan  6 06:42:16 2009
From: report at bugs.python.org (Mark Miller)
Date: Tue, 06 Jan 2009 05:42:16 +0000
Subject: [issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips
	instead of mipsel)
In-Reply-To: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za>
Message-ID: <1231220536.74.0.138155751428.issue4305@psf.upfronthosting.co.za>


Mark Miller <mark at mirell.org> added the comment:

Adding this as affecting the 2.6 branch as well, since I initially
tested on a 2.6.1 tarball with this problem.

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4305>
_______________________________________

From report at bugs.python.org  Tue Jan  6 09:28:35 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 06 Jan 2009 08:28:35 +0000
Subject: [issue4855] Popen(..., shell=True,
	...) should allow simple access to the command's PID
In-Reply-To: <1231220425.64.0.851147644427.issue4855@psf.upfronthosting.co.za>
Message-ID: <1231230515.34.0.440652674959.issue4855@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This really belongs to python-list rather than the tracker.  It is not 
correct that with shell=False Popen reuses the thread of control of the 
calling process.  You seem to be confusing blocking and reusing the 
thread of control.  Popen always creates a new thread of control using a 
fork() call.  The  proc.stdout.readline() will block until the process 
produces a full line of output, which is what anyone would expect.

It is not clear what you are trying to achieve.  Here is an example 
session:

>>> from subprocess import *
>>> p = Popen(['sleep', '10000'])
>>> p.kill()
>>> p.wait()
-9

or using a different signal (SIGINT = 2):

>>> p = Popen(['sleep', '10000'])
>>> p.send_signal(2)
>>> p.wait()
-2

The wait function blocks until the process terminates and returns the 
status (negative of the signal number in case of exit on signal).  What 
else are you trying to achieve?

Your proposals don't make much sense:

1) "child_pid()"  - what should it return if the shell command spawns 
more than one process? For example if the command contains |'s or 
multiple &'s?

2) "Signalling the children of the shell" - read the manual page for 
your shell.  Foreground processes receive most of the signals that way.  
Background processes only get a SIGHUP.

3) "proc.pid returns the command's PID" - there is no such thing: a 
command can create any number of processes.

4) "simple command to query all the childs PIDs" - without 
reimplementing shell in python to parse the command string, it is 
impossible to tell which subprocesses are spawned by a given Popen call.  
A function that returns all children of the given process can be 
written, but will be expensive on most systems because it will require a  
search over the entire process table.

In short, this report is invalid.

----------
components: +Extension Modules
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4855>
_______________________________________

From report at bugs.python.org  Tue Jan  6 09:39:47 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 06 Jan 2009 08:39:47 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231231187.1.0.258700906022.issue3582@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

I do have an issue with the patch's startup code. The prototype for 
the thread entry should be "DWORD WINAPI function(PVOID);". The 
important distinction is the WINAPI part, which resolves to __stdcall 
but doesn't have to. I know that some CE targets actually #define 
__cdecl __stdcall or vice versa, but using WINAPI always works. I'd 
then also change the comment to "...to adapt between our function 
signature and the one used by _createthreadex", as the internally used 
one doesn't mention __cdecl.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Tue Jan  6 09:55:47 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 06 Jan 2009 08:55:47 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

There are several checks like "GetVersion() < 0x80000000" that try to 
determine whether there is support for the WCHAR versions of the win32 
API. Since all support for MS Windows 95, 98 and ME has been dropped, 
all supported systems support those APIs. Also, I need that cleanup as 
preparation for porting Python to MS Windows CE, so that I don't have 
to clone/port code for obsolete systems there. I'll be providing 
patches here.

----------
components: Interpreter Core
messages: 79237
nosy: eckhardt
severity: normal
status: open
title: Remove checks for win NT
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Tue Jan  6 10:03:51 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 06 Jan 2009 09:03:51 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231232631.84.0.496831809734.issue3582@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

No, the startup function for beginthreadex() must be __stdcall.  From 
the docs:

start_address
Start address of a routine that begins execution of a new thread. For 
_beginthread, the calling convention is either __cdecl or __clrcall; 
for _beginthreadex, it is either __stdcall or __clrcall.

(__clrcall is for managed code which doesn't apply).

Do not confuse beginthreadex() with CreateThread even though they have 
similar arguments.  The former is for use with programs using the crt.

See http://msdn.microsoft.com/en-us/library/kdzttdcb.aspx for details.

Amaury, Where did you find the value 1088 for maximum TLS slots?  The 
documentation mentions the error condidion TLS_OUT_OF_INDEXES (which I 
should check for, I suppose), but nothing else.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Tue Jan  6 10:08:35 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 06 Jan 2009 09:08:35 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231232915.92.0.622655044783.issue3582@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

You're right, Kristj?n, sorry for the noise. Shouldn't make claims 
before being fully awake....

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Tue Jan  6 10:19:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 06 Jan 2009 09:19:07 +0000
Subject: [issue4855] Popen(..., shell=True,
	...) should allow simple access to the command's PID
In-Reply-To: <1231220425.64.0.851147644427.issue4855@psf.upfronthosting.co.za>
Message-ID: <1231233547.32.0.540618117946.issue4855@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

As Alexander says: a shell command can spawn any number of subprocesses,
or none at all (if e.g. only shell builtins are called).

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4855>
_______________________________________

From report at bugs.python.org  Tue Jan  6 10:31:30 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 06 Jan 2009 09:31:30 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231234290.3.0.424700928921.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Thanks.
What do you mean by making the test a method of TestCAPI?  I have found 
no such class.  Are you talking about the python part or the c part?

Also, atomicity in the callback is not required, as the callback is 
never interrupted implicitly.  In fact, that would make it quite 
useless.  I'll add that to the documentation.

As for your other suggestions, they're noted, I'll try having more 
threads.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Tue Jan  6 10:54:19 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Jan 2009 09:54:19 +0000
Subject: [issue2897] include structmember.h in Python.h
In-Reply-To: <1210977912.97.0.641461512834.issue2897@psf.upfronthosting.co.za>
Message-ID: <1231235659.55.0.296792211212.issue2897@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Martin, do you want to make the call on this one?

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2897>
_______________________________________

From report at bugs.python.org  Tue Jan  6 11:00:26 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Jan 2009 10:00:26 +0000
Subject: [issue2772] Add PendingDeprecationWarning for % formatting
In-Reply-To: <1210083250.98.0.889504486731.issue2772@psf.upfronthosting.co.za>
Message-ID: <1231236026.01.0.864173910504.issue2772@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am closing this one.  It is pointless and counter-productive unless
there is a firm decision that % formatting is definitely going away (and
migration tools have been developed).  Right now, it looks like there is
some chance that it might pull through for a few versions.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2772>
_______________________________________

From report at bugs.python.org  Tue Jan  6 11:09:15 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 06 Jan 2009 10:09:15 +0000
Subject: [issue2897] include structmember.h in Python.h
In-Reply-To: <1210977912.97.0.641461512834.issue2897@psf.upfronthosting.co.za>
Message-ID: <1231236555.44.0.187214070401.issue2897@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I agree with Alexander; the header shouldn't be included into Python.h
as-is.

I would propose to eliminate it eventually, with the following steps:
1. move PyMemberDef and the function declarations into object.h
2. (simultaneously) introduce properly-prefixed macros in object.h
3. deprecate structmember.h
4. remove it

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2897>
_______________________________________

From report at bugs.python.org  Tue Jan  6 11:27:57 2009
From: report at bugs.python.org (Dominique Wahli)
Date: Tue, 06 Jan 2009 10:27:57 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1231237677.67.0.560612943722.issue3872@psf.upfronthosting.co.za>


Dominique Wahli <dwahli at gmail.com> added the comment:

What happened ???

I'm pretty sure the fix was committed in 2.6.0 and, as saying by Amaury
in comments, the test script running fine.

In 2.6.1 test is broken.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Tue Jan  6 11:28:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 06 Jan 2009 10:28:12 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <1231188525.86.0.28964443261.issue4850@psf.upfronthosting.co.za>
Message-ID: <1231237692.4.0.0451821958035.issue4850@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Making it static is fine. I don't recall what kind of customization I
did when I introduced it.

I'm skeptical about the entire issue, though. Why is it that these
variables should be prefixed? I disagree that all names need to be
prefixed: those only present in certain debug builds need not.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 11:31:03 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Jan 2009 10:31:03 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <1231237692.4.0.0451821958035.issue4850@psf.upfronthosting.co.za>
Message-ID: <496332D3.4060907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-06 11:28, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> Making it static is fine. I don't recall what kind of customization I
> did when I introduced it.
> 
> I'm skeptical about the entire issue, though. Why is it that these
> variables should be prefixed? I disagree that all names need to be
> prefixed: those only present in certain debug builds need not.

For completeness and to make things easier for all developers,
all exported symbols should be prefixed with _Py or Py - regardless
of how their export is enabled.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 11:42:10 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Jan 2009 10:42:10 +0000
Subject: [issue4805] Make python code compilable with a C++ compiler
In-Reply-To: <d38f5330901051305n317e8a7ate5ce38312cecf153@mail.gmail.com>
Message-ID: <4963357E.1040900@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-05 22:06, Alexander Belopolsky wrote:
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>> Given that you can build Python as library on Unix and as DLL on
>> Windows, there doesn't appear to be any need to actually be able
>> to build Python itself using a C++ compiler. Simply using the
>> header files and linking against those libraries should do the
>> trick in most cases.
> 
> So what is your position on the proposed patch?  Is it worthwhile to
> track down the remaining symbols that may be affected by removal of
> extern "C" from .c files?  What is your opinion on the original patch
> (c++-patch.diff) which restores C++ compilability but does not touch
> these declarations?
> 
> I think using C++ as a lint variant from time to time is a good
> exercise to catch some corner issues as I hope this patch
> demonstrates.  I don't think this should be a requirement on every
> submission, but once an effort is made to restore C++ compilability,
> such changes should be applied unless there are valid concerns against
> them.

I agree with using C++ compatibility as additional means of checking
for correctness of the code. The type casts you have added in the
patch should definitely make it into the trunk.

Making sure that all exported private symbols get a _Py prefix and
a declaration in the header files that adds a comment explaining their
private nature is also a good idea.

I'm not sure about removing the extern "C" declarations altogether.
We'd need further testing with non-G++ compilers to see whether we
still need them or not. With the above fixes, I doubt that we still
need them nowadays.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4805>
_______________________________________

From report at bugs.python.org  Tue Jan  6 12:55:02 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 06 Jan 2009 11:55:02 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1231242902.84.0.953431501639.issue4856@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

+1

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Tue Jan  6 12:56:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Jan 2009 11:56:29 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1231242989.58.0.473834395822.issue2121@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Mark]
> inputs with a special real or imaginary component.  On balance, I'd 
> support making complex('nan + nan*j') do the right thing.

Having thought about this a bit more, I take this back.  Some reasons are 
given below.

[David]
> - complex(repr(..)) roundtrip should work, whatever the value of complex 
is

I disagree. *Why* do you think it should work?  It fails for many other 
types:

>>> def roundtrip(x): return type(x)(repr(x))
... 
>>> roundtrip("abc")
"'abc'"
>>> roundtrip([1,2,3])
['[', '1', ',', ' ', '2', ',', ' ', '3', ']']
>>> roundtrip((1,))
('(', '1', ',', ')')
>>> roundtrip(Fraction(1, 2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in roundtrip
  File "/Users/dickinsm/python_source/trunk/Lib/fractions.py", line 73, in 
__new__
    raise ValueError('Invalid literal for Fraction: %r' % input)
ValueError: Invalid literal for Fraction: 'Fraction(1, 2)'
>>> roundtrip(Decimal(1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in roundtrip
  File "/Users/dickinsm/python_source/trunk/Lib/decimal.py", line 545, in 
__new__
    "Invalid literal for Decimal: %r" % value)
  File "/Users/dickinsm/python_source/trunk/Lib/decimal.py", line 3721, in 
_raise_error
    raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: "Decimal('1')"


In general, type(repr(x)) == x only works for simple types (ints, floats), 
not compound types like lists, strings, tuples, ...  I think it's 
reasonable to regard complex as such a compound type.

There *is* a general Python guideline that eval(repr(x)) == x should work 
where possible.  Note that this fails even for floats:

>>> eval(repr(float('nan')))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'nan' is not defined


The *real* problem here is that repr(complex) is a mess when it comes to 
niceties like signed zeros, infinities and nans:

>>> complex(-0., 0.)  # throws away sign of 0 on real part
0j
>>> eval(repr(complex(2., -0.)))  # throws away sign on imag. part
(2+0j)
>>> nan = float('nan')
>>> complex(0, nan)
nan*j
>>> nan*j  # can't even eval this...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'j' is not defined
>>> nan*1j # not much better: real part should be 0, not nan
(nan+nan*j)
>>> inf = float('inf')
>>> inf*1j  # ouch: nan in real part!
(nan+inf*j)


I think the *right* solution is to define repr of a complex number
z to be:

"complex(%r, %r)" % (z.real, z.imag)

but that's not possible before the mythical, compatibility-breaking, 
Python 4.0.  And even then your desired complex(repr(z)) roundtripping 
wouldn't work, though eval(repr(z)) would.

While we're daydreaming, another possibility is to follow C99's lead, and 
introduce a type of 'imaginary' numbers, and make 1j be an imaginary 
literal rather than a complex literal.  That solves some of the above 
eval(repr(.)) problems.  Again, I don't see how this could happen before 
4.0, and I'm not even sure that it's desirable.

In the circumstances, repr does the best it can, which is to output a 
whole expression which more-or-less describes the given complex number, 
and will usually eval back to the right thing.  I think it's not the 
business of the complex() constructor to parse such expressions.

To summarize:  it's a mess.  I'd recommend that you and/or numpy don't use 
repr for roundtrip-capable conversions to string.  Instead, output the 
real and imaginary parts separately, and use float-from-string and the 
complex-from-pair-of-floats constructors to reconstruct.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Tue Jan  6 13:05:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Jan 2009 12:05:02 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1231243502.69.0.274334307403.issue2121@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Christian, any comments?  Is it okay to close this as a 'won't fix'?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Tue Jan  6 13:17:12 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 06 Jan 2009 12:17:12 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1231244232.6.0.176653650924.issue4856@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

This patch removes all calls to win32's GetVersion() where they are used
to detect NT. In posixmodule.c it was used by a wrapper function that
cached the result, which then also became obsolete.

----------
keywords: +patch
Added file: http://bugs.python.org/file12618/python-2.7-win9x-wchar-checks.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Tue Jan  6 13:28:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 06 Jan 2009 12:28:21 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <496332D3.4060907@egenix.com>
Message-ID: <49634E62.3000109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> For completeness

I don't think completeness is a useful thing to have here.

> and to make things easier for all developers,

It is not easier, but more difficult. It now requires a change,
whereas leaving things as-is requires no change.

> all exported symbols should be prefixed with _Py or Py - regardless
> of how their export is enabled.

Ah - but they aren't exported symbols.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:01:32 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Jan 2009 13:01:32 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <49634E62.3000109@v.loewis.de>
Message-ID: <49635629.9020405@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-06 13:28, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> For completeness
> 
> I don't think completeness is a useful thing to have here.
> 
>> and to make things easier for all developers,
> 
> It is not easier, but more difficult. It now requires a change,
> whereas leaving things as-is requires no change.

Sure it does: consistent rules always make things easier, since
they avoid doubt.

>> all exported symbols should be prefixed with _Py or Py - regardless
>> of how their export is enabled.
> 
> Ah - but they aren't exported symbols.

I'm only referring to exported symbols. Static globals, of course,
don't need such a prefix.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:11:18 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 06 Jan 2009 13:11:18 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231247478.35.0.427876904137.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, I have addressed the issues raised about testcapi.  A new file has 
been submitted.

Added file: http://bugs.python.org/file12619/testcapi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:11:54 2009
From: report at bugs.python.org (jura)
Date: Tue, 06 Jan 2009 13:11:54 +0000
Subject: [issue4857] syntax: no unpacking in augassign
In-Reply-To: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>
Message-ID: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>


New submission from jura <jura05 at narod.ru>:

the following code produces syntax error:
>>> (x, y) += 1
While this is documented in
http://docs.python.org/3.0/reference/simple_stmts.html#augmented-assignment-statements
("An augmented assignment evaluates the target (which, unlike normal
?ssignment statements, cannot be an unpacking)..."),
the syntax specification doesn't reflect this:
http://docs.python.org/3.0/reference/simple_stmts.html#grammar-token-augmented_assignment_stmt
http://docs.python.org/3.0/reference/grammar.html

----------
assignee: georg.brandl
components: Documentation
messages: 79256
nosy: georg.brandl, jura05
severity: normal
status: open
title: syntax: no unpacking in augassign
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4857>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:16:42 2009
From: report at bugs.python.org (Cournapeau David)
Date: Tue, 06 Jan 2009 13:16:42 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1231247802.46.0.346574528499.issue2121@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

> I disagree. *Why* do you think it should work?  It fails for many other 
> types:

I don't understand the rationale: why not making something work better
if possible ? Also, I don't understand the comparison with Decimal or
Fraction; there is a big difference between making the roundtrip not
possible at all for a type, and making it possible only for some values.

> I think the *right* solution is to define repr of a complex number
> z to be:

Why ? I don't understand those examples: maybe I am missing your
argument, but I understand it as we should not fix one bug because there
are another bugs related to inf and nan in complex. For me, something like:

a = complex(0)
a *= float('inf') * 1j
-> a = nan+nanj

Is really not desirable. That's actually a more serious bug than this
one. Are you saying that python does not care about inf/nan for complex
numbers ? If so, be it, but it would a bit unfortunate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:18:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 13:18:48 +0000
Subject: [issue4857] syntax: no unpacking in augassign
In-Reply-To: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>
Message-ID: <1231247928.79.0.686801835956.issue4857@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of the grammar:
  target          ::=  identifier | ...
  target_list     ::=  target ("," target)* [","]
  assignment_stmt ::=  (target_list "=")+ ...
  augmented_assignment_stmt ::=  target augop ...
  augop                     ::=  "+=" | ...

So there is only one possible target for "... += ..." and multiple 
targets for "... = ..".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4857>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:22:03 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 06 Jan 2009 13:22:03 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <49635629.9020405@egenix.com>
Message-ID: <49635AF9.3000505@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm only referring to exported symbols. Static globals, of course,
> don't need such a prefix.

Ok, the symbols in question are not exported from pythonxy.dll.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:23:39 2009
From: report at bugs.python.org (jura)
Date: Tue, 06 Jan 2009 13:23:39 +0000
Subject: [issue4857] syntax: no unpacking in augassign
In-Reply-To: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>
Message-ID: <1231248219.12.0.750263865375.issue4857@psf.upfronthosting.co.za>


jura <jura05 at narod.ru> added the comment:

Yes, but
target ::= identifier | "(" target_list ")" | ...
so (x,y) seems to be a valid target.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4857>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:33:24 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 13:33:24 +0000
Subject: [issue4857] syntax: no unpacking in augassign
In-Reply-To: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>
Message-ID: <1231248804.79.0.682518665526.issue4857@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh yes! I didn't see "(" target_list ")" | "[" target_list "]", sorry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4857>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:38:21 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 13:38:21 +0000
Subject: [issue3826] Problem with SocketIO for closing the socket
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231249101.42.0.240360870062.issue3826@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
priority: critical -> release blocker
title: BaseHTTPRequestHandler depends on GC to close connections -> Problem with SocketIO for closing the socket

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan  6 14:45:45 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Jan 2009 13:45:45 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <49635AF9.3000505@v.loewis.de>
Message-ID: <49636086.2010104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-06 14:22, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> I'm only referring to exported symbols. Static globals, of course,
>> don't need such a prefix.
> 
> Ok, the symbols in question are not exported from pythonxy.dll.

Right, because for MS VC you have to explicitly mark symbols for
DLL export which is done via the PyAPI_* macros.

However, they are still exported from the object files, so can cause
name clashes with other libraries you link with.

On Unix, libpythonX.X.a always includes those symbols and they
are also in the global symbol namespace when running the executable
and dynamically loading other libraries.

Even production builds contain a few such symbols which require
the _Py or Py prefix (or need to be made static) - these are for
Python 2.6 and 2.7:

* asdl_int_seq_new
* asdl_seq_new

Here's the grep line I used for that:

nm libpython2.6.a | egrep ' [TD] ([^P_]|P[^y]|_[^P])' | sort

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 15:30:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Jan 2009 14:30:08 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231252208.9.0.0693571413394.issue4753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

FWIW, I have made a quick attempt at removing the f->f_lasti assignment
in the few places where it could be removed, but it didn't make a
difference on my machine. The problem being that there are very few
places where it is legitimate to remove the assignment (even a call to
Py_DECREF can invoke arbitrary external code through destructors, so
even a very simple opcode such as POP_TOP needs the f->f_lasti assignment).

Another approach would be to create agregate opcodes, e.g.
BINARY_ADD_FAST would combine LOAD_FAST and BINARY_ADD. That's
orthogonal to the current issue though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Tue Jan  6 15:57:58 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 06 Jan 2009 14:57:58 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <49634E62.3000109@v.loewis.de>
Message-ID: <d38f5330901060657u688953c0r2df5c7e22fc94af8@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 6, 2009 at 7:28 AM, Martin v. L?wis <report at bugs.python.org> wrote:
..
> It is not easier, but more difficult. It now requires a change,
> whereas leaving things as-is requires no change.

I actually agree with Martin on this one.  I would not touch this if
not for the Py_ssize_t vs. int issue.  I am only +0 on renaming: if
type change and format spec changes go in, renaming is cost free.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 16:44:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Jan 2009 15:44:31 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1231256671.19.0.950298096215.issue2121@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

As Christian says, it's about not increasing code complexity without a 
good reason.  For me, it's also about mental complexity:  the set of valid 
inputs to the complex constructor should be small, and should be easy to 
understand and to describe.

The addition of the '*1j' part of the expression bothers me particularly,
as does allowing complex('j') to be valid.


I have a compromise proposal:

1. For nans and infs, get rid of the * on output:  change repr so that 
e.g., repr(complex(0, nan)) is simply 'nanj', and repr(complex(inf,-inf)) 
is '(inf-infj)'.  (Yes, I know it looks ugly, but bear with me.)

2. On input, allow strings of the form "complex-string" or "(complex-
string)" where (in pseudo BNF):

sign ::= '+' | '-'
real-part ::= float-string
imag-part ::= float-string 'j'
complex-string ::= real-part [sign imag-part] | imag-part

and float-string is any string currently accepted by float
(excluding leading or trailing whitespace).  Nothing else would be 
permitted.  (Well, okay, we still have to allow whitespace around the 
complex string, both inside and outside the parentheses.)

I think this would simplify the parsing, and remove need for special 
casing of nans and infs.  It might even allow the code to become simpler, 
by sharing some of it with stuff in floatobject.c.

The above would allow double signs:  e.g. '2+-1j', with the first sign 
being the one explicitly described above and the second being part of the 
float-string.  I don't think this is a terrible thing, if it simplifies 
parsing.  It might even be helpful.  For example: "%r+%rj" % (z.real, 
z.imag) would always be valid input.

The current 'nan*j' is certainly more attractive than 'nanj', but it's 
just too suggestive of the actual expression float('nan')*1j, which it 
turns out doesn't produce the same thing.

If you could come up with a patch that does something like this I'd take a 
look.


By the way, "0 + inf*1j" giving nan + inf*j isn't really a bug;  it's 
pretty much unavoidable:  1j is really complex(0, 1), and when multiplying 
by inf we get complex(inf*0, inf*1).  With the usual IEEE 754 semantics 
inf*0 is nan.

I think it's exactly to fix this sort of behaviour that C99 introduced its 
imaginary type (see Annex G of the standard).  It doesn't seem to have 
caught on, though:  I don't think gcc implements this, and I'd be very 
surprised if Visual Studio does.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Tue Jan  6 16:53:48 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Jan 2009 15:53:48 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <d38f5330901060657u688953c0r2df5c7e22fc94af8@mail.gmail.com>
Message-ID: <49637E8A.6000905@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-06 15:57, Alexander Belopolsky wrote:
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Tue, Jan 6, 2009 at 7:28 AM, Martin v. L?wis <report at bugs.python.org> wrote:
> ..
>> It is not easier, but more difficult. It now requires a change,
>> whereas leaving things as-is requires no change.
> 
> I actually agree with Martin on this one.  I would not touch this if
> not for the Py_ssize_t vs. int issue.  I am only +0 on renaming: if
> type change and format spec changes go in, renaming is cost free.

I don't follow you: those symbols are not meant for public use anyway,
so we can easily change them without any "costs". The same goes for any
of the private, but still exported symbols in the API, ie. all _Py*
APIs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 17:05:00 2009
From: report at bugs.python.org (Cournapeau David)
Date: Tue, 06 Jan 2009 16:05:00 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1231257900.98.0.221802927218.issue2121@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

@ Mark

Concerning float('inf') * 1j: you're right, my rambling did not make any
sense, sorry.

I agree that adding complexity may be a good reason to warrant an
arbitrary feature; actually, I did not manage to handle nan/inf at first
because of the complexity :) But as I mentioned in a previous comment, I
think my patch simplifies the parsing as well. I suggested to split the
patch in to: one whithout any new feature (no handling of nan/inf), and
then anoter handling nan/inf on the top of it. Would that be acceptable ?

Also, how should I proceed to share implementation between floatobject.c
and complexobject.c ? Would creating a new file for the common code be
acceptable ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Tue Jan  6 17:06:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Jan 2009 16:06:03 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231257963.24.0.41851450627.issue4293@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, the test patch is fine!

Now looking at the main patch, some comments:
- you removed "volatile" from pendingfirst and pendinglast, is it really
safe?
- what if pending_lock is not initialized when Py_AddPendingCall is
called? I know it's unlikely, but imagine someone calling that function
just after the interpreter has been initialized
- the documentation should mention that the GIL must not be held when
Py_AddPendingCall is called, otherwise there can be a deadlock (is it a
change from previous versions by the way?)
- you should check the return value of PyThread_allocate_lock() for NULL
- is your implementation reentrant? that is, registering a callback from
a callback. There is no need for it to be, but if it aims to be, then it
should perhaps be documented and tested :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Tue Jan  6 17:12:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Jan 2009 16:12:49 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231258369.15.0.268133742726.issue4293@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, forget what I said about the GIL, it looks fine. Perhaps some
comments should be added to clarify that matter, however.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Tue Jan  6 17:27:09 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 06 Jan 2009 16:27:09 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <49637E8A.6000905@egenix.com>
Message-ID: <d38f5330901060826n204906b9lc98cdf8f53e7f994@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 6, 2009 at 10:53 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> I don't follow you: those symbols are not meant for public use anyway,
> so we can easily change them without any "costs". The same goes for any
> of the private, but still exported symbols in the API, ie. all _Py*
> APIs.

This is the same that I said: "renaming is cost free" if it is done
together with the type change.  Martin was right that there is cost
associated with any change.  The benefit of "completeness" for a
specialized build would not justify even having this discussion IMO.
On the other hand since the type change needs to be done in order to
make the code correct on a 64 bit platform and compile without
warnings with gcc,  a patch is needed anyways.  Since we are already
paying the cost of change, renaming is free.  There is no disagreement
between you and me here.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Tue Jan  6 17:28:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Jan 2009 16:28:37 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1231259317.98.0.612729239825.issue2121@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

David, at this point, I recommend dropping this one.  It has become a
time waster.  Possibly, there is a refactoring of the code that makes
parsing a bit simpler or shares some common code but it is not worth
destabilizing the battle-tested code and risking the introduction of
subtle new parsing errors.

----------
priority: normal -> low
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Tue Jan  6 17:35:43 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Jan 2009 16:35:43 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1231259743.5.0.00755346648078.issue2121@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, I'm somewhat uncomfortable with your proposal also.  It changes
what the parser will accept and the potential benefits are almost nil. 
Also, putting NaNs and Infs in complex numbers is probably not something
that should be pursued.  I see no utility in pairs like (NaN, 3.0) or
(-2.0, Inf).  The whole request is use case challenged.  AFAICT, the
current implementation suffice for real cases and there is no compelling
need to rearrange and redesign this code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Tue Jan  6 18:42:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Jan 2009 17:42:28 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231263748.42.0.709815016498.issue4751@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks fine to me, apart from one point: the return value of
PyThread_allocate_lock() should be checked for NULL, and the error
either propagated or cleared.

(I'd also suggest lowering HASHLIB_GIL_MINSIZE to 2048 or 4196)

Gregory, what's your take?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Tue Jan  6 18:59:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Jan 2009 17:59:48 +0000
Subject: [issue1180193] broken pyc files
Message-ID: <1231264788.17.0.463373453269.issue1180193@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> accepted
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180193>
_______________________________________

From report at bugs.python.org  Tue Jan  6 19:07:23 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 06 Jan 2009 18:07:23 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231265243.53.0.576308734061.issue4751@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

hashlibopenssl_small_lock-4.diff looks good to me.

I also agree that HASHLIB_GIL_MINSIZE should be lowered to 2048.

Commit it, and please backport it to trunk before closing this bug.

----------
nosy:  -gps
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Tue Jan  6 19:32:06 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 18:32:06 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231266726.34.0.106187422687.issue4751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch:
 - change HASHLIB_GIL_MINSIZE to 2048 bytes
 - update hashlib documentation: add a note about the 2048 GIL limit
 - write a small test just for more sure that the GIL cases are tested 
(GIL released during object creation or on update)

Added file: http://bugs.python.org/file12620/hashlibopenssl_small_lock-5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Tue Jan  6 19:36:02 2009
From: report at bugs.python.org (darrenr)
Date: Tue, 06 Jan 2009 18:36:02 +0000
Subject: [issue4794] garbage collector blocks and takes worst-case linear time
	wrt number of objects
In-Reply-To: <1230752086.58.0.537070994703.issue4794@psf.upfronthosting.co.za>
Message-ID: <1231266962.19.0.503607777237.issue4794@psf.upfronthosting.co.za>


darrenr <python-roundup at dranalli.com> added the comment:

Regardless of the type of algorithm used by the garbage collector that
currently exists in Python, its worst-case performance is undesirable. I
have some interest in implementing a garbage collector for Python with
improved performance characteristics but don't really have the time for
it. Hopefully someone does. In any case thanks for hearing me out.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4794>
_______________________________________

From report at bugs.python.org  Tue Jan  6 20:12:24 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 06 Jan 2009 19:12:24 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1231269144.63.0.392601915425.issue3976@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The proposed patch appears to give up sorting by key,value altogether if 
there are a few incomparable items.  It would be better to group items by 
type and sort within each group.  For example, 
pprint({1:1,2:2,A():3,A():4}) should print int:int items in order.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Tue Jan  6 20:17:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Jan 2009 19:17:28 +0000
Subject: [issue1180193] broken pyc files
Message-ID: <1231269448.86.0.0953975584293.issue1180193@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed to trunk and py3k, and backported to 2.6 and 3.0. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180193>
_______________________________________

From report at bugs.python.org  Tue Jan  6 20:24:36 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Tue, 06 Jan 2009 19:24:36 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231269876.3.0.969004875245.issue4751@psf.upfronthosting.co.za>


Changes by Lukas Lueg <knabberknusperhaus at yahoo.de>:


Removed file: http://bugs.python.org/file12587/hashlibopenssl_small_lock-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Tue Jan  6 20:25:48 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Tue, 06 Jan 2009 19:25:48 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231269948.76.0.146439635388.issue4751@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

PyThread_allocate_lock can fail without interference. object->lock will
stay NULL and the GIL is simply not released.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Tue Jan  6 21:06:16 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Tue, 06 Jan 2009 20:06:16 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>


New submission from Lukas Lueg <knabberknusperhaus at yahoo.de>:

MD5 is one of the most popular cryptographic hash-functions around,
mainly for it's good performance and availability throughout
applications and libraries. The MD5 algorithm is currently implemented
in python as part of the hashlib-module and (in more general terms) as
part of SSL in the ssl-module. However, concerns about the security of
MD5 have risen during the last few years. In 2007 a practical attack to
create collisions in the compression-function has been released and on
12/31/2008 US-CERT issued a note to warn about the general insecurity of
MD5 (http://www.kb.cert.org/vuls/id/836068).


I propose and strongly suggest to start deprecate direct support for MD5
during this year and completly remove support for it afterwards.

 * MD5 is a cryptographic hash function, it's reason for being is
security. By means of current hardware and attack vectors it's a matter
of hours to create collisions and fool MD5 hashes. The reason for being
has come to an end.
 * Python runs an uncountable number of exposed user interfaces on the
web. Usually the programmers rely on the security of the backing
libraries. Python can't provide this with MD5.
 * The functionality of MD5 can be easily replaced by using other hashes
that are supported by python (e.g. SHA1). They supply compareable
performance but are not binary-compatible (yay).
 * Programmers use MD5 in python without the need for it's cryptographic
attributes (e.g. creating unique indexes). Keeping MD5 for this use
however devaluates overall security of python for the good of few.


I'd like to start a discussion about this. Please keep in mind that -
although MD5 is currently still very popular and python's support for it
is justifed by demand - it's existence will come to an end soon.

We should now act and give people time to update their implementations. 


In a rough cut:

 - Patch haslib to throw a DeprecationWarning, starting during the first
half of 2009.
 - Update documentation not to use MD5 for security reasons
 - Remove MD5 from python in 2010.
 - Keep accordance to PEP 4


Goodbye MD5 and thanks for all the fish.

----------
components: Extension Modules
messages: 79281
nosy: ebfe
severity: normal
status: open
title: Deprecation of MD5
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Tue Jan  6 21:17:53 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Jan 2009 20:17:53 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <4963BC6F.50104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-06 21:06, Lukas Lueg wrote:
> MD5 is one of the most popular cryptographic hash-functions around,
> mainly for it's good performance and availability throughout
> applications and libraries. The MD5 algorithm is currently implemented
> in python as part of the hashlib-module and (in more general terms) as
> part of SSL in the ssl-module. However, concerns about the security of
> MD5 have risen during the last few years. In 2007 a practical attack to
> create collisions in the compression-function has been released and on
> 12/31/2008 US-CERT issued a note to warn about the general insecurity of
> MD5 (http://www.kb.cert.org/vuls/id/836068).
> 
> 
> I propose and strongly suggest to start deprecate direct support for MD5
> during this year and completly remove support for it afterwards.

A strong -1 on that idea.

MD5 is in wide-spread use as hash function. It can no longer
be considered a cryptographic hash function, but still serves its
purpose as fast, easy to use general purpose hash function well.

Removing it from Python would cripple Python for no apparent reason.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Tue Jan  6 21:20:35 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Jan 2009 20:20:35 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <1231273235.46.0.283757792945.issue4858@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Because MD5 is used widely, Python needs to support it, if only to be
able to verify MD5 signatures when offered.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Tue Jan  6 21:32:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Jan 2009 20:32:47 +0000
Subject: [issue1708] improvements for linecache
In-Reply-To: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za>
Message-ID: <1231273967.8.0.630513260453.issue1708@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looking at the patch, the recorded seek points will probably be wrong if
some newlines were translated (e.g. '\r\n' -> '\n') when reading the file.

I'm also not sure not what the use case for very big files is. linecache
is primarily used for printing tracebacks, the API isn't really
general-purpose.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708>
_______________________________________

From report at bugs.python.org  Tue Jan  6 21:33:15 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 06 Jan 2009 20:33:15 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <1231273995.2.0.45825932829.issue4858@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The hashlib docs already mention the problems with md5 et al via a
bright red:

"Warning

Some algorithms have known hash collision weaknesses, see the FAQ at the
end."

thanks for closing this.  not gonna happen.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Tue Jan  6 21:52:31 2009
From: report at bugs.python.org (David Watson)
Date: Tue, 06 Jan 2009 20:52:31 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

The pwd (and spwd and grp) modules deal with data from
/etc/passwd (and/or other sources) that can be supplied by users
on the system.  Specifically, users can often change the data in
their GECOS fields without the OS requiring that it conform to a
specific encoding, and given some automated account signup
system, it's conceivable that arbitrary data could even be placed
in the username field.

This causes a problem since the functions in these modules try to
decode the data into str objects, and if a user has placed data
in /etc/passwd, say, that does not conform to the relevant
encoding, the function will raise UnicodeDecodeError and thus
prevent the program from learning the relevant mapping between
username and UID, etc. (or crash the program if it wasn't
expecting this).  For a system program written in Python, this
can amount to a denial of service attack, especially if the
program uses the get*all() functions.

Currently, the pwd module tries to decode the string fields using
the Unicode-escape codec, i.e. like a Python string literal, and
this can fail when given an invalid backslash escape.  You can
see this by running chfn(1), entering something like "\ux" in one
of the fields, and then calling pwd.getpwnam(yourname) or
pwd.getpwall().  Perhaps the use of this codec is a mistake,
given that spwd and grp decode the string fields as UTF-8, but
chfn could also be used to enter non-UTF-8 data in the GECOS
field.  You can see similar failures in the grp and spwd modules
after adding a user with a non-UTF-8 name (do something like
"useradd $'\xff'" in bash).

A debug build of Python also reports a reference counting error
in grp (count goes to -1) when its functions fail on non-UTF-8
data; what I think is going on is that in mkgrent(),
PyStructSequence_SET_ITEM steals the reference to "w", meaning
the second "Py_DECREF(w)" shouldn't be there.  Also, getpwall()
and getgrall() leave file descriptors open when they fail, since
they don't call end*ent() in this case.  The attached minor.diff
fixes both of these problems, I think.

I've also written a patch (bytes.diff, attached) that would add
new functions pwd.getpwnamb(), etc. (analogous to os.getcwdb())
to return bytes objects for the text fields, thus avoiding these
problems - what do you think?  The patch also makes pwd's
original string functions use UTF-8 like the other modules.

Alternatively or in addition, a quick "fix" for the GECOS problem
might be for the pwd module to decode the text fields as Latin-1,
since in the absence of backslash escapes this is what the
Unicode-escape encoding is equivalent to.  This would at least
block any DoS attempts using the GECOS field (or attempts to add
extra commas with \x2c, etc.) without changing the behaviour
much.  The attached latin1.diff does this.

----------
components: Extension Modules
files: bytes.diff
keywords: patch
messages: 79286
nosy: baikie
severity: normal
status: open
title: pwd, spwd, grp functions vulnerable to denial of service
type: security
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12621/bytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Tue Jan  6 21:53:32 2009
From: report at bugs.python.org (David Watson)
Date: Tue, 06 Jan 2009 20:53:32 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231275212.53.0.484962701384.issue4859@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file12622/minor.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Tue Jan  6 21:54:18 2009
From: report at bugs.python.org (David Watson)
Date: Tue, 06 Jan 2009 20:54:18 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231275258.64.0.439818416449.issue4859@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file12623/latin1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Tue Jan  6 22:25:55 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 06 Jan 2009 21:25:55 +0000
Subject: [issue816929] term.h present but cannot be compiled
Message-ID: <1231277155.29.0.0263512386214.issue816929@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was corrected a long time ago in r37372

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> configure not able to find ncurses/curses in Solaris 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue816929>
_______________________________________

From report at bugs.python.org  Tue Jan  6 22:27:44 2009
From: report at bugs.python.org (umaxx)
Date: Tue, 06 Jan 2009 21:27:44 +0000
Subject: [issue1708] improvements for linecache
In-Reply-To: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za>
Message-ID: <1231277264.54.0.308595734385.issue1708@psf.upfronthosting.co.za>


umaxx <umaxx at oleco.net> added the comment:

> Looking at the patch, the recorded seek points will probably be wrong if
> some newlines were translated (e.g. '\r\n' -> '\n') when reading the file.

ack, this could be a problem.

> I'm also not sure not what the use case for very big files is. 

this is easy to answer: i used it for example for parsing (still
growing) big log files from mail servers. parsing the whole file first
time, and than later: starting from line xyz+1 (xyz was the last line
recorded after first time parsing) *without* parsing the whole file
again. especially very useful for growing log files >1GB

just try to get linenumber 1234567 from a 2,3GB log file with the
current linecache implementation :)
the main idea behind the patch is to cache the seek points to save a lot
of time on big files.

> linecache is primarily used for printing tracebacks, the API 
> isn't really general-purpose.

i know :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708>
_______________________________________

From report at bugs.python.org  Tue Jan  6 22:41:43 2009
From: report at bugs.python.org (Jeremy Olexa)
Date: Tue, 06 Jan 2009 21:41:43 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1231278103.78.0.320421554721.issue4026@psf.upfronthosting.co.za>


Jeremy Olexa <darkside at gentoo.org> added the comment:

This also happens with Python 2.5.2 (not the latest 2.5 series, I know)
on AIX 6.1.

----------
nosy: +darkside

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Tue Jan  6 22:42:24 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Tue, 06 Jan 2009 21:42:24 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <1231278143.97.0.56315692048.issue4858@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

As I already said to Raymond: At least we should update the
documentation. The "FAQ" currently linked is from 2005.

The CERT-Advisory from provides a clean and simple language: "In 2008,
researchers demonstrated the practical vulnerability [...] We are
currently unaware of a practical solution to this problem. *Do not use
the MD5 algorithm*."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Tue Jan  6 22:42:23 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 06 Jan 2009 21:42:23 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231278143.97.0.179151263666.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

1) volatile is not required when access is guarded by locks.
2) pendingcalls_to_do is initialized to 1, so the very first thing that 
the interpreter does (after executing one bytecode, I init _PyTicker to 
0 now) is to initialize this lock.  Creating a lock really must be done 
by one well known startup thread only.  There is a lot of functions in 
the python API that don't work until after python initialization 
(without that being explicitly documented), Py_AddPendingCall() is one 
of them.  Btw, there is no generic "init" function for the ceval.c 
module.  And PyEval_InitThreads isn't really suitable since we must 
have the lock, even if we haven't initialized the threads, to guard us 
against reentrancy during signal delivery.  For extra safety, I have 
added a NULL test in Py_AddPendingCall().
3)Py_AddPendingCall() can be called with our without the GIL. 
4)I've added a check in Py_MakePendingCalls().  In PyEval_ReInitThreads 
there is no way to do anything sensible in the case of error.
5)Yes it is reentrant.  The pending_lock is only held for a short while 
while we pop a callback off the queue.  However, because even during 
that short while a signal can be delivered which causes 
Py_AddPendingCall() to be called, the latter function fails if it 
doesn't acquire the lock in a reasonable amount of time.  This would 
cause a signal to be lost, and not a deadlock.  This hasn't changed 
from the old implementation.

I have also added a flag to make sure that we don't execute pending 
calls recursively, (async notifications is so much better) and 
explained it better in the docs.

Added file: http://bugs.python.org/file12624/pendingalls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Tue Jan  6 22:44:11 2009
From: report at bugs.python.org (Noufal)
Date: Tue, 06 Jan 2009 21:44:11 +0000
Subject: [issue4860] js_output wrong for cookies with " characters
In-Reply-To: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>
Message-ID: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>


New submission from Noufal <noufal at nibrahim.net.in>:

If a cookie is created with a " character in the content, the js_output
which is emitted is bad javascript. eg.
>>> import Cookie
>>> c=Cookie.Cookie('Customer="WILE_E_COYOTE"; Version=1; Path=/acme')
>>> print c
Set-Cookie: Customer="WILE_E_COYOTE"; Path=/acme; Version=1
>>> print c.js_output()

        <script type="text/javascript">
        <!-- begin hiding
        document.cookie = "Customer="WILE_E_COYOTE"; Path=/acme; Version=1";
        // end hiding -->
        </script>
        
>>> 

Also, the test_cookie tests (test_load) explicitly checks for this
(wrong) output.

I have attached a patch that seems to fix this or at the very least
produces the same Cookie settings whether the cookie is set using the
header or using javascript (I've verified this on firefox on Linux).

----------
components: Library (Lib), Tests
files: cookie.patch
keywords: patch
messages: 79292
nosy: noufal
severity: normal
status: open
title: js_output wrong for cookies with " characters
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12625/cookie.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4860>
_______________________________________

From report at bugs.python.org  Tue Jan  6 22:59:13 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Jan 2009 21:59:13 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231278143.97.0.56315692048.issue4858@psf.upfronthosting.co.za>
Message-ID: <4963D42E.3020705@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-06 22:42, Lukas Lueg wrote:
> Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:
> 
> As I already said to Raymond: At least we should update the
> documentation. The "FAQ" currently linked is from 2005.
>
> The CERT-Advisory from provides a clean and simple language: "In 2008,
> researchers demonstrated the practical vulnerability [...] We are
> currently unaware of a practical solution to this problem. *Do not use
> the MD5 algorithm*."

That's a correct statement for cryptographic work based on MD5.

However, it's not true with respect to using MD5 as fast general
purpose hash algorithm in non-crypto applications, so I think the
warning on http://docs.python.org/library/hashlib.html is sufficient.

Note that the various SHA implementations are also starting to
get some heat lately, so it's only a question of time until these
get excluded from the set of cryptographic hash functions:

http://en.wikipedia.org/wiki/SHA1
http://en.wikipedia.org/wiki/Cryptographic_hash_function

also see:

http://en.wikipedia.org/wiki/Hash_function

"""
Hash functions are related to (and often confused with) checksums, check digits,
fingerprints, randomizing functions, error correcting codes, and cryptographic
hash functions. Although these concepts overlap to some extent, each has its own
uses and requirements.
"""

It might be a good idea to remove the word "secure" from the
hashlib documentation, since security of these algorithms is
always limited to a certain period of time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Tue Jan  6 23:02:52 2009
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 06 Jan 2009 22:02:52 +0000
Subject: [issue4861] fix problems with ctypes.util.find_library
In-Reply-To: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>
Message-ID: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

there are some problems with ctypes.util.find_library(), which I would
like to see fixed on active branches.

 - find_library is not robust, if either objdump or gcc are not
   installed. fixed by raising an exception if the tools are not
   found. Is OSError the correct type for this exception?

 - ldconfig -p already prints the shared object name. afaics there
   is no need to call objdump again.

 - the regexp to scan the ldconfig -p output is wrong for
   architectures where libraries of more than one abi type are
   installed, e.g. having ix86 libs on a x86_64 system. Having
   only the library installed which doesn't match the python
   executable lets find_library find the wrong library. Note that
   the patch is only correct under the assumption that the python
   executable is unstalled for the "main" abi.

patch attached, ok to check in?

----------
assignee: theller
components: ctypes
files: ctypes-findlib.diff
keywords: patch, patch
messages: 79294
nosy: doko, theller
severity: normal
status: open
title: fix problems with ctypes.util.find_library
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12626/ctypes-findlib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4861>
_______________________________________

From report at bugs.python.org  Tue Jan  6 23:10:05 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Tue, 06 Jan 2009 22:10:05 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <1231279805.46.0.0725864851095.issue4858@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

> It might be a good idea to remove the word "secure" from the
> hashlib documentation, since security of these algorithms is
> always limited to a certain period of time.

I'm sorry, was that a boy attempted humor ? [Misuse quote from DH3: Check]

Anyway, in fact that might be a good idea: Reflect that the hashlib
module includes hash functions for the sake of compatibility and
interoperability and not everlasting security.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Tue Jan  6 23:13:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Jan 2009 22:13:37 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <1231280017.13.0.53699491197.issue4858@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Secure hash or cryptographic hash is the correct term and I think we
should leave that in, if only to make the original intent clear and to
make them easier to search for.

I propose adding a sentence to the first paragraph noting that the level
of security varies by algorithm and that over time some of the
algorithms are being found to have possible cryptographic weaknesses or
exploits.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Tue Jan  6 23:39:24 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Jan 2009 22:39:24 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231279805.46.0.0725864851095.issue4858@psf.upfronthosting.co.za>
Message-ID: <4963DD99.2090906@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-06 23:10, Lukas Lueg wrote:
> Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:
> 
>> It might be a good idea to remove the word "secure" from the
>> hashlib documentation, since security of these algorithms is
>> always limited to a certain period of time.
> 
> I'm sorry, was that a boy attempted humor ? [Misuse quote from DH3: Check]

No, it's the reality of life and one of the reasons why digitally
signed data needs to be resigned every few years in order to keep
the data secured and the legal status of the signature intact.

Note that SHA-0 and -1 were broken in 2005:

    http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html

In Germany, the BSI which corresponds to the NSA in the US, publishes
a list of algorithms each year that are deemed safe, including their
expiration year:

    http://www.bundesnetzagentur.de/enid/Veroeffentlichungen/Algorithmen_sw.html
    (in German)

They regard SHA-1 as expired by the end of this year. For SHA-2 functions
they give 2015 as expiry date.

The NSA has similar guidelines:

    http://csrc.nist.gov/groups/ST/hash/statement.html

They currently suggest using SHA-2 functions for crypto applications,
but are also running a new contest for SHA-3:

    http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html

> Anyway, in fact that might be a good idea: Reflect that the hashlib
> module includes hash functions for the sake of compatibility and
> interoperability and not everlasting security.

BTW: Not sure what Deer Hunter 3 has to do with all this ;-)

    http://www.planetdeerhunter.com/dh3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Wed Jan  7 01:21:17 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Jan 2009 00:21:17 +0000
Subject: [issue4862] utf-16 BOM is not skipped after seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

First write a utf-16 file with its signature:

>>> f1 = open('utf16.txt', 'w', encoding='utf-16')
>>> f1.write('0123456789')
>>> f1.close()

Then read it twice:

>>> f2 = open('utf16.txt', 'r', encoding='utf-16')
>>> print('read1', ascii(f2.read()))
read1 '0123456789'
>>> f2.seek(0)
0
>>> print('read2', ascii(f2.read()))
read2 '\ufeff0123456789'

The second read returns the BOM!
This is because the zero in seek(0) is a "cookie" which contains both the position 
and the decoder state. Unfortunately, state=0 means 'endianness has been determined: 
native order'.

maybe a suggestion: handle seek(0) as a special value which calls decoder.reset().
The patch implement this idea.

----------
files: io_utf16.patch
keywords: patch
messages: 79299
nosy: amaury.forgeotdarc
priority: critical
severity: normal
status: open
title: utf-16 BOM is not skipped after seek(0)
versions: Python 3.0
Added file: http://bugs.python.org/file12627/io_utf16.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4862>
_______________________________________

From report at bugs.python.org  Wed Jan  7 05:06:09 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 07 Jan 2009 04:06:09 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1231301169.81.0.109798125276.issue3823@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Jan  7 06:56:11 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 07 Jan 2009 05:56:11 +0000
Subject: [issue4863] deprecate/delete distutils.mwerkscompiler...
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <18788.17382.220573.660720@montanaro.dyndns.org>


New submission from Skip Montanaro <skip at pobox.com>:

I was just poking around the distutils documentation and came across the
distutils.mwerkscompiler module.  Surely that can't be useful anymore, can
it?  The doc reads, in its entirety:

    Contains MWerksCompiler, an implementation of the abstract CCompiler
    class for MetroWerks CodeWarrior on the pre-Mac OS X Macintosh. Needs
    work to support CW on Windows or Mac OS X.

So the only place it used to work was on pre-Mac OS X, which Python doesn't
support any longer and "will need work" for Windows or Mac OS X which
presumably nobody has done.  This module should be deprecated in 3.1 and
removed in 3.2.

Skip

----------
messages: 79300
nosy: skip.montanaro
severity: normal
status: open
title: deprecate/delete distutils.mwerkscompiler...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4863>
_______________________________________

From report at bugs.python.org  Wed Jan  7 07:04:35 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 07 Jan 2009 06:04:35 +0000
Subject: [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Currently, test_msvc9compiler fails on VC6 with following message.

//////////////////////////////////////////

Traceback (most recent call last):
  File "test_distutils.py", line 17, in <module>
    test_main()
  File "test_distutils.py", line 13, in test_main
    test.test_support.run_unittest(distutils.tests.test_suite())
  File "e:\python-dev\trunk\lib\test\test_support.py", line 710, in 
run_unittest

    _run_suite(suite)
  File "e:\python-dev\trunk\lib\test\test_support.py", line 693, in 
_run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\trunk\lib\distutils\tests\test_msvc9compiler.py", 
line 16,
 in test_no_compiler
    from distutils.msvc9compiler import query_vcvarsall
  File "e:\python-dev\trunk\lib\distutils\msvc9compiler.py", line 281, 
in <modul
e>
    raise DistutilsPlatformError("VC %0.1f is not supported by this 
module" % VE
RSION)
DistutilsPlatformError: VC 6.0 is not supported by this module

//////////////////////////////////////////

I think attached patch will fix this. Is this fix appropriate?

Thank you.

----------
components: Tests
files: test_msvc9compiler.patch
keywords: easy, needs review, patch
messages: 79301
nosy: ocean-city
severity: normal
status: open
title: test_msvc9compiler fails on VC6
versions: Python 2.7
Added file: http://bugs.python.org/file12628/test_msvc9compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4864>
_______________________________________

From report at bugs.python.org  Wed Jan  7 07:10:41 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 07 Jan 2009 06:10:41 +0000
Subject: [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231308641.88.0.489596361006.issue4864@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file12628/test_msvc9compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4864>
_______________________________________

From report at bugs.python.org  Wed Jan  7 07:10:50 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 07 Jan 2009 06:10:50 +0000
Subject: [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231308650.65.0.809336975302.issue4864@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file12629/test_msvc9compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4864>
_______________________________________

From report at bugs.python.org  Wed Jan  7 08:35:43 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 07 Jan 2009 07:35:43 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231313743.16.0.723815305377.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

@pitrou:
<ranting mode>
Argh, reference counting hinders even that?
</ranting mode>
I just discovered another problem caused by refcounting.

Various techniques allow to create binary code from the interpreter
binary, by just pasting together the code for the common interpreters
cases and producing calls to the other. But, guess what, on most
platforms (except plain x86, but including x86_64 and maybe x86 for the
shared library case) this does not work if the copied code includes
function calls (on x86_64 that's due to RIP-relative addressing, and on
similar issues on other platforms).

So, Python could not even benefit from that! That's a real pity...
I'll have to try with subroutine threading, to see if that's faster than
indirect threading on current platforms or if it is still slower.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan  7 09:16:20 2009
From: report at bugs.python.org (Terry Helge)
Date: Wed, 07 Jan 2009 08:16:20 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231093333.6.0.679938116402.issue4836@psf.upfronthosting.co.za>
Message-ID: <1231316180.78.0.965474674241.issue4836@psf.upfronthosting.co.za>


Terry Helge <skillybob2 at gmail.com> added the comment:

Problem solved - I need to add an additional command to any program that
calls pyGame.  pygame.quit ()
One of those little undocumented things that pop up now and then

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________

From report at bugs.python.org  Wed Jan  7 09:35:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Jan 2009 08:35:56 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231093333.6.0.679938116402.issue4836@psf.upfronthosting.co.za>
Message-ID: <1231317356.14.0.609829861756.issue4836@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is even documented:
http://www.pygame.org/wiki/FrequentlyAskedQuestions#In%20IDLE%20why%20does%20the%20Pygame%20window%20not%20close%20correctly?

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________

From report at bugs.python.org  Wed Jan  7 09:39:38 2009
From: report at bugs.python.org (Terry Helge)
Date: Wed, 07 Jan 2009 08:39:38 +0000
Subject: [issue4836] Idle Hangs on exit Button
In-Reply-To: <1231317356.14.0.609829861756.issue4836@psf.upfronthosting.co.za>
Message-ID: <ef4249160901070039q4f276373m39037ea3eccb818e@mail.gmail.com>


Terry Helge <skillybob2 at gmail.com> added the comment:

Yes, you are correct. My lack of experience is showing. Thanks for your
interest.

On Wed, Jan 7, 2009 at 2:35 AM, Amaury Forgeot d'Arc <report at bugs.python.org
> wrote:

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> This is even documented:
>
> http://www.pygame.org/wiki/FrequentlyAskedQuestions#In%20IDLE%20why%20does%20the%20Pygame%20window%20not%20close%20correctly
> ?
>
> ----------
> nosy: +amaury.forgeotdarc
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4836>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4836>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090107/115cd755/attachment-0001.txt>

From report at bugs.python.org  Wed Jan  7 09:47:45 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 07 Jan 2009 08:47:45 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1231318065.8.0.621184773109.issue4856@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

+1. I've tested this patch on win2k & vc6, and worked correctly.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Wed Jan  7 09:54:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Jan 2009 08:54:50 +0000
Subject: [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231318490.16.0.276161052289.issue4864@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't like this catch-all approach. What if no compiler is installed
at all?
I suggest to use a test like
    distutils.msvccompiler.get_build_version() >= 8.0
(this is how msvccompiler imports the msvc9compiler module)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4864>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:13:05 2009
From: report at bugs.python.org (Thomas Finley)
Date: Wed, 07 Jan 2009 09:13:05 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231319585.54.0.585622531628.issue4816@psf.upfronthosting.co.za>


Thomas Finley <tfinley at gmail.com> added the comment:

Hi Raymond, thanks for your well reasoned and thorough reply.  Just a
couple small thoughts... I'll borrow your numbers if you don't mind.

1. I'd ask you to discount this argument.  There are many situations in
the Python library where empty results are possible return values. 
There are likewise many places in mathematics where a set as defined
winds up being empty.  And sure, absolutely, sometimes this empty result
will be an error condition.  However, right off the top of my head, I
can't really think of any other place in the Python library where an
empty returned iterator/list is automatically assumed to necessarily be
an error.

The closest I can think of right now might be key/index errors on dicts
and sequences... but that's a user explicitly asking for exactly one
element, in which case non-existence would be bad.

In a larger sense, if a result computed by a function is sensible and
well defined in itself, it doesn't seem even possible for a function to
anticipate what answers might be considered error conditions by calling
code.  Potentially any return value for any function might be an error
for some user code.  So... the question then becomes, is the empty
result a sensible and well defined answer.  And here we differ again I
see.  :D

2. OK on perms.  If you don't mind, I'm going to talk about combinations
since that was my real motivation.

    Also see the wikipedia article on combinations (the
    "choose" function) which also expresses a factorial
    formula that fails for r>n. No mention is made for
    special handling for r>n.

Hmmm.  Are you looking at the definition of "choose function" under
Wikipedia?
     http://en.wikipedia.org/wiki/Choose_function
Notice the material after the "and," after the first part of the
definition, in case you missed it in your first reading.  So, this is
the def I was taught through high school and undergrad, perhaps the same
for Mark judging from his reply.  You were taught it was undefined?  It
does sort of complicate some other defs that rely on binomial
coefficients though, I'd think, but I guess you could make those work
with little effort.  It's not as though subtly different but
incompatible definitions of basic terms are that uncommon in math...
never knew the binomial coef was in that category though.  You teach
stats I take it?  I suppose you'd know then... never heard of it, but
that doesn't mean much.  Oh well.  (You can perhaps feel my pain at
seeing the current behavior, given my understanding.)

3. For your "replacement" myperm (let's say mycomb), if you insert a
"pool=tuple(iterable)" into the beginning, you'll have my fix, statement
for statement.  You advance this as desirable, while to my eye it was
nasty enough to motivate me to submit my first patch to Python.  So, you
can imagine we have a slight difference of opinion.  ;)  Let's see if I
can't present my view effectively...

Saying the fix is more explicit suggests there's something implicit
about the concise solution.  If the choose function is defined for those
values, then itertools.combinations is just unnecessarily forcing code
to treat something as a special case even when it's not.  So, I'd be
careful to draw a distinction between "more verbose" and "more explicit."

4. Can't really speak to that.  It's probably worth changing
documentation in any event, even if you reject the patch.  The provided
equiv code and the actual behavior in this "error case" differ anyway as
you noted in your second reply.  Also, this error condition isn't
evident from the documentation without reading and parsing the source code.

A third and extraneous comment, if you do wind up changing the docs
anyway, perhaps a shorter recursive solution would be easier to
understand?  Maybe it's just me since I'm sort of a functional type of
guy, but I found the equivalent code a little hard to parse.

5. Yeah.  Actually, I'm pretty sure that's why the choose function is
defined piecewise, since negative factorials are undefined as you say.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:18:25 2009
From: report at bugs.python.org (Jukka Laurila)
Date: Wed, 07 Jan 2009 09:18:25 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1231319905.28.0.263491103532.issue3329@psf.upfronthosting.co.za>


Jukka Laurila <jukka.p.laurila at nokia.com> added the comment:

Brett is right. Macroing the memory allocator is a better choice than
forcing indirection on all platforms. We did this on Python for S60,
using the macros PyCore_{MALLOC,REALLOC,FREE}_FUNC for interpreter's
allocations, and then redirected those to a mechanism that allows to set
the allocator at runtime. 

Sorry we don't have a clean patch at present for this change only, but
in case anyone's interested the full source is at
https://garage.maemo.org/frs/?group_id=854

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:22:05 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 07 Jan 2009 09:22:05 +0000
Subject: [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231320125.89.0.156467859995.issue4864@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file12629/test_msvc9compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4864>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:23:22 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 09:23:22 +0000
Subject: [issue4862] utf-16 BOM is not skipped after seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <1231320202.9.0.86320050895.issue4862@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4862>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:31:25 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 07 Jan 2009 09:31:25 +0000
Subject: [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231320685.55.0.767395315412.issue4864@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> I don't like this catch-all approach.

I agree with you. Lib/distutils/msvc9compiler.py still only have one 
top level DistutilsPlatformError,

VERSION = get_build_version()
if VERSION < 8.0:
    raise DistutilsPlatformError("VC %0.1f is not supported by this 
module" % VERSION)

but it's not guranteed in future. How abount the new patch?

Added file: http://bugs.python.org/file12631/test_msvc9compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4864>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:33:52 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 09:33:52 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <49636086.2010104@egenix.com>
Message-ID: <496476FD.6090906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> However, they are still exported from the object files, 

Ah. Those are "global symbols", not "exported symbols"; "export"
is a concept specific to Win32.

> so can cause
> name clashes with other libraries you link with.

See, and in this specific case, they can't, because they are used
only in a debug build. Furthermore, they all have names that are
unlikely to collide. Even if they get a _Py_ prefix, there could
still be a conflict.

> Even production builds contain a few such symbols which require
> the _Py or Py prefix (or need to be made static) - these are for
> Python 2.6 and 2.7:
> 
> * asdl_int_seq_new
> * asdl_seq_new

No. They don't require the Py_ prefix, because they already
have the asdl_ prefix.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:37:20 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 09:37:20 +0000
Subject: [issue4860] js_output wrong for cookies with " characters
In-Reply-To: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>
Message-ID: <1231321040.35.0.47792030225.issue4860@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch looks correct but it breaks the unit test: updated patch 
fixes Lib/test/test_cookie.py.

----------
nosy: +haypo
Added file: http://bugs.python.org/file12632/cookie-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4860>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:38:33 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Jan 2009 09:38:33 +0000
Subject: [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231321113.89.0.155484759802.issue4864@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is good.

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4864>
_______________________________________

From report at bugs.python.org  Wed Jan  7 10:49:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 07 Jan 2009 09:49:57 +0000
Subject: [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231321797.28.0.173247673218.issue4864@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r68373.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4864>
_______________________________________

From report at bugs.python.org  Wed Jan  7 11:11:24 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 07 Jan 2009 10:11:24 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231323084.12.0.856775034742.issue4753@psf.upfronthosting.co.za>


Changes by Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com>:


Added file: http://bugs.python.org/file12633/abstract-switch-reduced.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan  7 11:12:53 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 07 Jan 2009 10:12:53 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231323173.56.0.567666243513.issue4753@psf.upfronthosting.co.za>


Changes by Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com>:


Added file: http://bugs.python.org/file12634/restore-old-oparg-load.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan  7 11:14:51 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 10:14:51 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <49648097.5030704@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I propose and strongly suggest to start deprecate direct support for MD5
> during this year and completly remove support for it afterwards.

-1. Stopping usage of md5 should be the user's choice, not Python's.

>  * MD5 is a cryptographic hash function, it's reason for being is
> security. By means of current hardware and attack vectors it's a matter
> of hours to create collisions and fool MD5 hashes. The reason for being
> has come to an end.

I think you misunderstand the kind of problem that has been detected.
It is still *not* possible to produce a colliding text within
reasonable, when given the md5 hash. So when md5 is used as the trap
function for password storage, it's use remains perfectly safe.

Likewise, md5 is still well capable of detecting corruption of binary
files (e.g. during downloads), and will remain in use for this
application for many more years.

It is only in the context of digital signatures that the "chosen prefix"
attack can be demonstrated successfully.

>  * Python runs an uncountable number of exposed user interfaces on the
> web. Usually the programmers rely on the security of the backing
> libraries. Python can't provide this with MD5.

That's like saying "Mercedes drivers rely on efficient operation of the
motor. By putting water into the tank, the motor fails to deliver. So
let's put a ban on the usage of water in cars."

>  * The functionality of MD5 can be easily replaced by using other hashes
> that are supported by python (e.g. SHA1). They supply compareable
> performance but are not binary-compatible (yay).

In some case, yes, replacement is easy. In other cases, replacement is
not so easy. For example, for password hashes, you cannot simply rehash
all passwords - because you typically don't know what they are.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Wed Jan  7 11:16:50 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 10:16:50 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231323410.11.0.90400620339.issue4859@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Any decision on this issue should be deferred until a PEP has been
written and accepted that decides on usage of bytes in Unix APIs.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Wed Jan  7 11:26:46 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 07 Jan 2009 10:26:46 +0000
Subject: [issue4861] fix problems with ctypes.util.find_library
In-Reply-To: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>
Message-ID: <49648368.7040004@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

Matthias Klose schrieb:
> there are some problems with ctypes.util.find_library(), which I would
> like to see fixed on active branches.
> 
>  - find_library is not robust, if either objdump or gcc are not
>    installed. fixed by raising an exception if the tools are not
>    found. Is OSError the correct type for this exception?

Sure.

>  - ldconfig -p already prints the shared object name. afaics there
>    is no need to call objdump again.

>  - the regexp to scan the ldconfig -p output is wrong for
>    architectures where libraries of more than one abi type are
>    installed, e.g. having ix86 libs on a x86_64 system. Having
>    only the library installed which doesn't match the python
>    executable lets find_library find the wrong library. Note that
>    the patch is only correct under the assumption that the python
>    executable is unstalled for the "main" abi.

I have to trust you that this is the right approach since I don't have
much experience on linux.  Also I have not tested the patch.

What I do not like too much in your patch is 'import platform'
since that pulls in a lot of stuff. Would it be possible to
replace 'platform.machine()' with 'os.uname()[4]' ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4861>
_______________________________________

From report at bugs.python.org  Wed Jan  7 11:29:59 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 10:29:59 +0000
Subject: =?utf-8?q?[issue4863]_deprecate/delete=09distutils.mwerkscompiler...?=
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <49648425.9000208@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So the only place it used to work was on pre-Mac OS X, which Python doesn't
> support any longer and "will need work" for Windows or Mac OS X which
> presumably nobody has done.  This module should be deprecated in 3.1 and
> removed in 3.2.

I would actually remove it right away in 2.7/3.1.

----------
nosy: +loewis
title: deprecate/delete distutils.mwerkscompiler... -> deprecate/delete	distutils.mwerkscompiler...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4863>
_______________________________________

From report at bugs.python.org  Wed Jan  7 12:02:32 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 11:02:32 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231326152.66.0.35912129791.issue4859@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

baikie: Open a separated issue for the refcount error and fd leak.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Wed Jan  7 12:05:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 11:05:48 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231326348.71.0.322963871966.issue4859@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> it's conceivable that arbitrary data could even be 
> placed in the username field.

On Ubuntu, it's not possible to create an user with a non-ASCII name:

$ sudo adduser ? --no-create-home
adduser: To avoid problems, the username should consist only of
letters, digits, underscores, periods, at signs and dashes, and not
start with a dash (as defined by IEEE Std 1003.1-2001). For
compatibility with Samba machine accounts $ is also supported at 
the end of the username

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Wed Jan  7 12:09:44 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 07 Jan 2009 11:09:44 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231326584.85.0.96895234526.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

I finally implemented my suggestion for the switch elimination.
On top of threadedceval5.patch, apply abstract-switch-reduced.diff and
then restore-old-oparg-load.diff to test it.

This way, only computed goto's are used. I would like who had
miscompilation problems, or didn't get advantage from the patch, to try
compiling and benchmarking this version.

I've also been able to reenable static prediction (PREDICT_*) on top of
computed gotos, and that may help CPU prediction even more (the BTB for
the computed goto will be used to predict the 2nd most frequent target);
obviously it may instead cause a slowdown, I'd need stats on opcode
frequency to try guessing in advance (I'll try gathering them later
through DYNAMIC_EXECUTION_PROFILE).

Apply reenable-static-prediction.diff on top of the rest to get this.

I'll have to finish other stuff before closing everything to run
pybench, I can't get stable timings otherwise, so it'll take some time
(too busy, sorry). However I ran the check for regressions and they show
none.

====
abstract-switch-reduced.diff is the fixed abstract-switch.diff -
actually there was just one hunk which changed the handling of f_lasti,
and that looked extraneous. See the end of the message.

--- a/Python/ceval.c    Thu Jan 01 23:54:01 2009 +0100
+++ b/Python/ceval.c    Sun Jan 04 14:21:16 2009 -0500
@@ -1063,12 +1072,12 @@
                }

        fast_next_opcode:
-               f->f_lasti = INSTR_OFFSET();

                /* line-by-line tracing support */

                if (_Py_TracingPossible &&
                    tstate->c_tracefunc != NULL && !tstate->tracing) {
+                       f->f_lasti = INSTR_OFFSET();
                        /* see maybe_call_line_trace
                           for expository comments */
                        f->f_stacktop = stack_pointer;

Added file: http://bugs.python.org/file12635/reenable-static-prediction.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan  7 12:30:41 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 11:30:41 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231327841.3.0.949817677105.issue4859@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About pwd, we have 7 fields:
 - username: the regex looks like ? [a-zA-Z0-9_.@]
[a-zA-Z0-9_.@\/]*$? ?, so it's ASCII only
 - password: ASCII only? on my Ubuntu, /etc/passwd uses "x" for all 
passwords, and /etc/shadow uses MD5 hash with a like 
like "$1$x6vJEXyc$" (MD5 marker + salt)
 - user identifier: integer (ASCII)
 - main group identifier: integer (ASCII)
 - GECOS: user text
 - shell: filename
 - home directory: filename

We can expect GECOS and filenames to be encoded in the "default system 
locale" (eg. latin-1 or UTF-8). An user is allowed to change its GECOS 
field. If the user account use a different locale and set a non-ASCII 
GECOS, decoding the string (to unicode) will fail.

Your patch latin1.diff is wrong: the charset is not always latin-1 or 
always utf-8: it depends on the system default charset. You should use 
sys.getfilesystemencoding() or locale.getpreferredencoding() to get 
the right encoding. If you used latin-1 as automagic charset to get 
text as bytes, it's not the good solution: use the bytes type to get 
real bytes (as you implemented with your get*b() functions).

The situation is similar to the bytes/unicode filename debate (see 
issue #3187). I think that we can consider that a system correctly 
configured will use the same locale for all users accounts => use 
unicode. But for compatibility with old systems mixing different 
locales / or new system with locale problems => use bytes.

The default should be unicode, but we need to be able get all fields 
as bytes. Example:
  pwd.getpwnam(str) -> str fields (and integers for uid/gid)
  pwd.getpwnamb(bytes) -> bytes fields (and integers for uid/gid)

We have already bytes/unicode functions using the "b" suffix: 
os.getpwd()->str and os.getpwdb()->bytes.

Note: The GECOS field problem was already reported in issue #3023 (by 
baikie).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Wed Jan  7 12:33:30 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 11:33:30 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231328010.77.0.418956193567.issue4859@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> For a system program written in Python, this
> can amount to a denial of service attack, especially 
> if the program uses the get*all() functions

I don't think that it can be called a "denial of service attack".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Wed Jan  7 12:38:05 2009
From: report at bugs.python.org (=?utf-8?q?Sever_B=C4=83ne=C8=99iu?=)
Date: Wed, 07 Jan 2009 11:38:05 +0000
Subject: [issue4263] BufferedWriter non-blocking overage
In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>
Message-ID: <1231328285.41.0.250809923509.issue4263@psf.upfronthosting.co.za>


Sever B?ne?iu <banesiu.sever at gmail.com> added the comment:

> Anyway :) Practically, the test does work on both py3k and another
> implementation, so I don't see any urgency to remove anything from it.
Indeed, it doesn't hurt keeping it.

For completeness' sake I've updated your tests to cover the pre-flush
condition existent in the python implementation. Theoretically this
should be the desired behavior in any other implementation.

Added file: http://bugs.python.org/file12636/nonblocking2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4263>
_______________________________________

From report at bugs.python.org  Wed Jan  7 12:46:50 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 11:46:50 +0000
Subject: [issue4862] utf-16 BOM is not skipped after seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <1231328810.61.0.792806559105.issue4862@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This is because the zero in seek(0) is a "cookie" 
> which contains both the position and the decoder state. 
> Unfortunately, state=0 means 'endianness has been determined:
> native order'.

The problem is maybe that TextIOWrapper._pack_cookie() can create a 
cookie=0. Example to create a non-null value, replace:
    def _pack_cookie(self, position, ...):
        return (position | (dec_flags<<64) | ...
    def _unpack_cookie(self, bigint):
        rest, position = divmod(bigint, 1<<64)
        ...
by
    def _pack_cookie(self, position, ...):
        return (1 | (position<<1) | (dec_flags<<65) | ...
    def _unpack_cookie(self, bigint):
        if not (bigint & 1):
           raise ValueError("invalid cookie")
        bigint >>= 1
        rest, position = divmod(bigint, 1<<64)
        ...

Why the cookie is an integer and not an object with attributes?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4862>
_______________________________________

From report at bugs.python.org  Wed Jan  7 13:03:29 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Jan 2009 12:03:29 +0000
Subject: [issue4862] utf-16 BOM is not skipped after seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <1231329809.26.0.384916212438.issue4862@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> The problem is maybe that TextIOWrapper._pack_cookie() 
> can create a cookie=0

But only when position==0.
And in this case, at the beginning of the stream, it makes sense to
reset everything to its initial value: zero for the various counts, and
call decoder.reset()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4862>
_______________________________________

From report at bugs.python.org  Wed Jan  7 13:07:04 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 12:07:04 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231330024.89.0.219820749615.issue4842@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I like the new patches: break int("3L") but keep pickle compatibility. 
I already noticed the "L" suffix problem when I was hacking the long 
type in Python 3.x (eg. by using GMP instead of builtin library).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Wed Jan  7 13:38:53 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 12:38:53 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231164188.22.0.711983399984.issue4841@psf.upfronthosting.co.za>
Message-ID: <200901071339.27330.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> 1. The handling of the error in internal_close() isn't really good. What
> I'm also not sure about is whether it is correct to set the error there,
> the old code sometimes did set an error as reaction to internal_close()
> failing and sometimes not.

internal_close() is used in:
 - fileio_close(): raise an IOError(errno) on internal_close() failure
 - dircheck(): ignore internal_close() failure, whereas Python 3.x raise 
   a IOError(errno) on internal_close() failure
 - file_init(): catch internal_close() failure but don't set an exception,
   whereas Python 3.x set a IOError(errno)
 - fileio_dealloc(): PySys_WriteStderr(...) in Python 2.x,
   PyErr_WriteUnraisable(self) in Python 3.x

But Python 2.x all errors are ignored because the test (errno < 0) is wrong...

I always prefer Python 3.x behaviour: internal_close() is responsible to raise 
an exception.

> 2. There is one place in dircheck() where I think that the error should
> be ignored, but I'm not sure about that.

I rarely a good idea to ignore errors, I prefer to raise a different error if 
the file can not be closed.

> 3. This patch fixes another issue, and that is that internal_close()
> would call close() even if 'closefd' was not set. This e.g. happens when
> __init__ is called explicitly. This case is missing a test though.

Python 3.x is also affected by this issue: file_init() and dircheck() ignore 
self->closefd.

passwd = open("/etc/passwd")
f = _FileIO(fd, closefd=False)
f.__init__(fd, closefd=False) => close passwd file!

> 4. I wonder if internal_close() should reset only the 'fd' field or if
> it should also reset 'readable', 'writable', 'seekable', too, i.e. apart
> from 'weakreflist' do the same as fileio_new() does.

seekable(), readable() and writable() raise an error if the file is closed. I 
think it's fine to leave the internal attributes unchanged.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Wed Jan  7 13:51:02 2009
From: report at bugs.python.org (Karsten Petersen)
Date: Wed, 07 Jan 2009 12:51:02 +0000
Subject: [issue4865] system wide site-packages dir not used on Mac OS X
In-Reply-To: <1231332662.33.0.831675111419.issue4865@psf.upfronthosting.co.za>
Message-ID: <1231332662.33.0.831675111419.issue4865@psf.upfronthosting.co.za>


New submission from Karsten Petersen <kapet at kapet.de>:

[Guido asked me to file this as an issue.]

On Mac OS X Apple has configured the system provided Python to also
search this global site-packages directory:
   /Library/Python/<version>/site-packages/

This allows users to install their own system-wide packages there (and
not have them to drop into /System/Library/Frameworks/Python....../).

Unfortunately if you install Python from python.org (or pythonmac.org)
it is not searching this path, it only searches the site-packages
directory _within_ its own framework:
  /Library/Frameworks/Python...../
That directory is of course not searched by the Apple provided Python.

This is an issue for addon package installers (think PIL or numpy): 
There is no single path that will be found by both the system provided
Python and a Python installed from python.org.  This makes most/all (?)
of the pre-built packages on pythonmac.org unusable with the version of
Python Apple ships although there is no version conflict or such - it
simply installs stuff in the "wrong" directories.

Many people who tried to install PIL for Django or App Engine stumbled
into this.  The system provided Python version was fine.  But compiling
PIL is hard.  So they installed PIL from pythonmac.org.  That couldn't
be found by Python.  Now some people manually copied stuff around, some
created symlinks, some installed a second Python 2.5.  (The lucky ones
picked a Python download from python.org, the not so lucky ones
installed the 2.5.0 release from pythonmac.org...)

I've attached a diff of a stock Python 2.5.1 library against what I
found on my Apple Mac OS X 10.5 (Leopard) system.  I've dropped changes
that are not related to the path.

----------
components: Library (Lib), Macintosh
files: apple.diff
keywords: patch
messages: 79329
nosy: kapet
severity: normal
status: open
title: system wide site-packages dir not used on Mac OS X
type: behavior
Added file: http://bugs.python.org/file12637/apple.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4865>
_______________________________________

From report at bugs.python.org  Wed Jan  7 13:59:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jan 2009 12:59:01 +0000
Subject: [issue4862] utf-16 BOM is not skipped after seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <1231333141.17.0.860846830035.issue4862@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, there are other problems with utf-16, e.g. when opening an
existing file for appending, the BOM is written again:

>>> f = open('utf16.txt', 'w', encoding='utf-16')
>>> f.write('abc')
3
>>> f.close()
>>> f = open('utf16.txt', 'a', encoding='utf-16')
>>> f.write('def')
3
>>> f.close()
>>> open('utf16.txt', 'r', encoding='utf-16').read()
'abc\ufeffdef'


Who said TextIOWrapper was sane? :-o

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4862>
_______________________________________

From report at bugs.python.org  Wed Jan  7 14:11:07 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Wed, 07 Jan 2009 13:11:07 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231333867.8.0.565724195508.issue4841@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

>> 4. I wonder if internal_close() should reset only the 'fd' field
>> or if it should also reset 'readable', 'writable', 'seekable'
>
> seekable(), readable() and writable() raise an error if the file
> is closed. I think it's fine to leave the internal attributes
> unchanged.

That's not what I'm concerned about. What I'm concerned about is this:

f = _FileIO(open("some text file"))
print f.seekable()
f.__init__(open("some pipe"))
print f.seekable()

The cached value whether the file was seekable survives the __init__ 
call but is actually wrong then. Of course, one could also reset the 
value in __init__. Whether the file is readable or writable is 
different, since those values are supplied via the mode string and the 
code by the user and not determined automatically.


I think that I just found another buglet, too: when supplying a file 
descriptor, dircheck() isn't actually called. os.open() under 2.5 on 
Debian/Linux at least allows opening '.', trunk under MS Windows fails 
with "permission denied".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4841>
_______________________________________

From report at bugs.python.org  Wed Jan  7 15:04:40 2009
From: report at bugs.python.org (ganderson)
Date: Wed, 07 Jan 2009 14:04:40 +0000
Subject: [issue4866] Code to remove in parsetok?
Message-ID: <1231337080.92.0.440917680493.issue4866@psf.upfronthosting.co.za>


Changes by ganderson <g.anderson at tuttoniente.net>:


----------
components: Interpreter Core
nosy: ganderson
severity: normal
status: open
title: Code to remove in parsetok?
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4866>
_______________________________________

From report at bugs.python.org  Wed Jan  7 15:06:50 2009
From: report at bugs.python.org (ganderson)
Date: Wed, 07 Jan 2009 14:06:50 +0000
Subject: [issue4866] Code to remove in parsetok?
In-Reply-To: <1231337210.42.0.763391145355.issue4866@psf.upfronthosting.co.za>
Message-ID: <1231337210.42.0.763391145355.issue4866@psf.upfronthosting.co.za>


New submission from ganderson <g.anderson at tuttoniente.net>:

At the lines 99 .. 103, there are the message on Python 2.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4866>
_______________________________________

From report at bugs.python.org  Wed Jan  7 15:37:23 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Jan 2009 14:37:23 +0000
Subject: [issue4866] Code to remove in parsetok?
In-Reply-To: <1231337210.42.0.763391145355.issue4866@psf.upfronthosting.co.za>
Message-ID: <1231339043.1.0.102362076099.issue4866@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The code is excluded from compilation with a
    #ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD

There is no __future__ feature in 3.0 for the moment, but the code stays
here as a placeholder, to remind developers what they need to do to
support __future__ flags that change the behavior of the lexer.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4866>
_______________________________________

From report at bugs.python.org  Wed Jan  7 15:41:22 2009
From: report at bugs.python.org (jice)
Date: Wed, 07 Jan 2009 14:41:22 +0000
Subject: [issue4867] crash in ctypes when passing a string to a function
	without defining argtypes
In-Reply-To: <1231339282.89.0.0934088116939.issue4867@psf.upfronthosting.co.za>
Message-ID: <1231339282.89.0.0934088116939.issue4867@psf.upfronthosting.co.za>


New submission from jice <jice.nospam at gmail.com>:

This code works in python 2.5 & 2.6 :
>>> import ctypes
>>> lib=ctypes.cdll['./libtcod.so']
>>> lib.TCOD_console_init_root(80,50,'test',0)
 1

In python 3.0, it crashes in _CallProc (callproc.c, line 1136) :
 if (atypes[i]->type == FFI_TYPE_STRUCT
atypes[i] == NULL here because when there is no argtypes, the default
converter (ConvParam) does not set ffi_type for string parameters if
HAVE_USABLE_WCHAR_T is FALSE.

To make it work, I have to define the argtypes for the function :
>>> import ctypes
>>> lib=ctypes.cdll['./libtcod.so']
>>> from ctypes import *
>>> lib.TCOD_console_init_root.argtypes=[c_int,c_int,c_char_p,c_uint]
>>> lib.TCOD_console_init_root(80,50,'test',0)
 1

I've compiled python 3.0 on a standard Ubuntu 8.04 and the test_ctypes
unit test works fine.

----------
assignee: theller
components: ctypes
messages: 79334
nosy: jice, theller
severity: normal
status: open
title: crash in ctypes when passing a string to a function without defining argtypes
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4867>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:09:28 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 07 Jan 2009 15:09:28 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1231313743.16.0.723815305377.issue4753@psf.upfronthosting.co.za>
Message-ID: <18788.50596.725069.269695@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Paolo> Various techniques allow to create binary code from the
    Paolo> interpreter binary, by just pasting together the code for the
    Paolo> common interpreters cases and producing calls to the other. But,
    Paolo> guess what, on most platforms (except plain x86, but including
    Paolo> x86_64 and maybe x86 for the shared library case) this does not
    Paolo> work if the copied code includes function calls (on x86_64 that's
    Paolo> due to RIP-relative addressing, and on similar issues on other
    Paolo> platforms).

I don't understand.  I know little or nothing about the details of various
instruction set architectures or linkage methods.  Can you break it down
into a simple example?

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:18:14 2009
From: report at bugs.python.org (Noufal)
Date: Wed, 07 Jan 2009 15:18:14 +0000
Subject: [issue4860] js_output wrong for cookies with " characters
In-Reply-To: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>
Message-ID: <1231341494.95.0.733606802886.issue4860@psf.upfronthosting.co.za>


Noufal <noufal at nibrahim.net.in> added the comment:

A lot of the cookie tests need to be updated. A separate bug was filed
regarding this. http://bugs.python.org/issue3788. 

I'm working on that now and will apply your patch there as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4860>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:24:47 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 07 Jan 2009 15:24:47 +0000
Subject: [issue1622010] Tcl/Tk auto-expanding window
Message-ID: <1231341887.08.0.659378878723.issue1622010@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I can't reproduce this on python 2.4.4 (or any newer version) using 
windows vista, so this is either specific to the tk included in python 
2.4.2 or tk and your specific os version.

If you still have this problem, report it at http://sourceforge.net/projects/tktoolkit as it is not caused by Tkinter 
specifically.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1622010>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:25:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jan 2009 15:25:04 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Here is a patch to speedup utf8 decoding. On a 64-bit build, the maximum
speedup is around 30%, and on a 32-bit build around 15%. (*)

The patch may look disturbingly trivial, and I haven't studied the
assembler output, but I think it is explained by the fact that having a
separate loop counter breaks the register dependencies (when the 's'
pointer was incremented, other operations had to wait for the
incrementation to be committed).

[side note: utf8 encoding is still much faster than decoding, but it may
be because it allocates a smaller object, regardless of the iteration count]

The same principle can probably be applied to the other decoding
functions in unicodeobject.c, but first I wanted to know whether the
principle is ok to apply. Marc-Andr?, what is your take?


(*) the benchmark I used is:

./python -m timeit -s "import
codecs;c=codecs.utf_8_decode;s=b'abcde'*1000" "c(s)"

More complex input also gets a speedup, albeit a smaller one (~10%):

./python -m timeit -s "import
codecs;c=codecs.utf_8_decode;s=b'\xc3\xa9\xe7\xb4\xa2'*1000" "c(s)"

----------
components: Interpreter Core
files: utf8decode.patch
keywords: patch
messages: 79338
nosy: lemburg, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Faster utf-8 decoding
type: performance
versions: Python 3.1
Added file: http://bugs.python.org/file12638/utf8decode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:25:15 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Jan 2009 15:25:15 +0000
Subject: [issue4860] js_output wrong for cookies with " characters
In-Reply-To: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>
Message-ID: <1231341915.67.0.167768384264.issue4860@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The characters <>& should also be escaped.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4860>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:31:39 2009
From: report at bugs.python.org (Jeremy Olexa)
Date: Wed, 07 Jan 2009 15:31:39 +0000
Subject: [issue4026] fcntl extension fails to build on AIX 6.1
In-Reply-To: <1223022763.11.0.245770368063.issue4026@psf.upfronthosting.co.za>
Message-ID: <1231342299.7.0.717592018121.issue4026@psf.upfronthosting.co.za>


Jeremy Olexa <darkside at gentoo.org> added the comment:

I have now confirmed that the fix described here[1] works as desired. I
don't know if this is proper or not but it matches what inkblotter said.

[1]: http://www.ibm.com/developerworks/forums/thread.jspa?threadID=226339

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4026>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:39:00 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 07 Jan 2009 15:39:00 +0000
Subject: [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <1231342740.57.0.161555497588.issue4858@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

For the record, I'm with Martin -- there are many existing uses that we
can't just legislate away.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4858>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:42:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jan 2009 15:42:41 +0000
Subject: [issue4025] C99 comments in Python 2.6 break build on AIX 6.1
In-Reply-To: <1223021705.78.0.0680927211456.issue4025@psf.upfronthosting.co.za>
Message-ID: <1231342961.12.0.364443752155.issue4025@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems everything has been fixed in the 2.6 branch and in trunk.
Andrew, can you do a quick SVN checkout and test it?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4025>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:44:01 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 07 Jan 2009 15:44:01 +0000
Subject: [issue814654] 'import Tkinter' causes windows missing-DLL popup
Message-ID: <1231343041.82.0.66084383606.issue814654@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

The bug mentioned by the OP doesn't occur with the newer installers, 
closing.

----------
nosy: +gpolo
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue814654>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:49:55 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Jan 2009 15:49:55 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <496476FD.6090906@v.loewis.de>
Message-ID: <d38f5330901070749h44ae6b4bk18948db57b435156@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Jan 7, 2009 at 4:33 AM, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> .. Furthermore, they all have names that are
> unlikely to collide. Even if they get a _Py_ prefix, there could
> still be a conflict.
>

My main interest in this patch are the type and %d to %zd change, but
by throwing in the name change, I unintentionally made it more
controversial.   Would it help if I resubmit the patch without name
changes or is this something that a committer can take care of if the
patch is partially accepted?

I already stated that I am only +0 on the name change and that "+" is
mostly motivated by the fact that I already made the changes in my
sandbox.   Other than that, I don't think it matters.   Let's stop
here and refocus the type change.

>> Even production builds contain a few such symbols which require
>> the _Py or Py prefix (or need to be made static) - these are for
>> Python 2.6 and 2.7:
>>
>> * asdl_int_seq_new
>> * asdl_seq_new
>
> No. They don't require the Py_ prefix, because they already
> have the asdl_ prefix.

That's true, but asdl_ prefix is not a well-known prefix reserved for
Python symbols.  Someone who is debugging linker errors and sees
something like "asdl_seq_new: symbol not found" will be hard pressed
to realize that he/she forgot to link python library or linked an old
version.

Also a grep through nm output that Marc-Andre did is a good check to
run from time to time and there is no reason to have false positives.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Wed Jan  7 16:59:38 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 07 Jan 2009 15:59:38 +0000
Subject: [issue1222721] tk + setlocale problems...
Message-ID: <1231343978.41.0.678629281442.issue1222721@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

The problem with the backspace key was fixed in python 2.6 when using 
the windows installer at least.
I didn't check yet if it is specific to tcl/tk or if it involves 
tkinter.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222721>
_______________________________________

From report at bugs.python.org  Wed Jan  7 17:17:01 2009
From: report at bugs.python.org (Keith Briggs)
Date: Wed, 07 Jan 2009 16:17:01 +0000
Subject: [issue4869] random.expovariate(0.0)
In-Reply-To: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>
Message-ID: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>


New submission from Keith Briggs <kbriggs at users.sourceforge.net>:

random.expovariate(lambd) should handle lambd=0 cleanly, and probably
return a FP infinity.

At the moment it gives:

ZeroDivisionError: float division

----------
components: Extension Modules
messages: 79346
nosy: kbriggs
severity: normal
status: open
title: random.expovariate(0.0)
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4869>
_______________________________________

From report at bugs.python.org  Wed Jan  7 17:41:06 2009
From: report at bugs.python.org (jice)
Date: Wed, 07 Jan 2009 16:41:06 +0000
Subject: [issue4867] crash in ctypes when passing a string to a function
	without defining argtypes
In-Reply-To: <1231339282.89.0.0934088116939.issue4867@psf.upfronthosting.co.za>
Message-ID: <1231346466.98.0.326048562758.issue4867@psf.upfronthosting.co.za>


jice <jice.nospam at gmail.com> added the comment:

Moving the ffi_type affectation before the pre-processor directive seems
to work :

648d647
< #ifdef HAVE_USABLE_WCHAR_T
649a649
> #ifdef HAVE_USABLE_WCHAR_T

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4867>
_______________________________________

From report at bugs.python.org  Wed Jan  7 18:06:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jan 2009 17:06:26 +0000
Subject: [issue4869] random.expovariate(0.0)
In-Reply-To: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>
Message-ID: <1231347986.63.0.106289567847.issue4869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

An exponential distribution with parameter 0 isn't an exponential distribution any more.  On the real line, there isn't
even a limiting distribution as the parameter approaches 0.

Is there really any use for having expovariate degenerate this way?
It seems much more likely that a call to random.expovariate(0) is
caused by a bug somewhere, so should raise an exception.  Which is exactly 
what it does already.

The proposed change would also not be in keeping with the philosophy 
behind most of Python's mathematics, which is to raise exceptions rather 
than returning exceptional (nan, inf) results.  (Think of it as IEEE 754 
will the invalid, overflow and division-by-zero signals all being 
trapped.)

----------
components: +Library (Lib) -Extension Modules
nosy: +marketdickinson
type:  -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4869>
_______________________________________

From report at bugs.python.org  Wed Jan  7 18:15:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jan 2009 17:15:41 +0000
Subject: [issue4869] random.expovariate(0.0)
In-Reply-To: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>
Message-ID: <1231348541.64.0.406664149042.issue4869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I would suggest adding a note to the documentation stating clearly that 
the parameter should be nonzero.  The documentation is also unclear on 
whether a negative parameter value is permitted, although the current code 
works exactly the way that I'd expect for a negative parameter.

If a negative parameter is permitted then the last sentence of the 
docstring:

"""... Returned values range from 0 to positive infinity."""

is inaccurate, since values range from 0 to negative infinity in that 
case.  If it's not supposed to be permitted then perhaps the docstring 
should mention that the parameter should be positive?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4869>
_______________________________________

From report at bugs.python.org  Wed Jan  7 18:21:34 2009
From: report at bugs.python.org (Keith Briggs)
Date: Wed, 07 Jan 2009 17:21:34 +0000
Subject: [issue4869] random.expovariate(0.0)
In-Reply-To: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>
Message-ID: <1231348894.07.0.840966481574.issue4869@psf.upfronthosting.co.za>


Keith Briggs <kbriggs at users.sourceforge.net> added the comment:

That's all true - the only thing in favour of my suggestion is that to
allow lambda=0 is sometimes useful in simulations, meaning that it's
infinite time to the next event, i.e. it never occurs.  A FP infinity
would do this without requiring a special case.

At least the documentation should state the restrictions on lambda.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4869>
_______________________________________

From report at bugs.python.org  Wed Jan  7 18:39:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jan 2009 17:39:59 +0000
Subject: [issue4869] random.expovariate(0.0)
In-Reply-To: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>
Message-ID: <1231349999.23.0.955749791697.issue4869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> to allow lambda=0 is sometimes useful in simulations, meaning that it's
> infinite time to the next event, i.e. it never occurs.

Thanks; that makes sense.  If 1./0. returned inf then expovariate would 
already do what you want.  But rightly or wrongly, Python just doesn't 
work that way.

Incidentally, if expovariate had been written to take the mean as its 
argument (instead of the reciprocal of the mean) then this would be easy:  
just provide a parameter of float('inf') and everything would work.  (And 
a parameter of 0 would give a point distribution at 0, which again seems 
perfectly sound.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4869>
_______________________________________

From report at bugs.python.org  Wed Jan  7 18:41:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 17:41:10 +0000
Subject: [issue4865] system wide site-packages dir not used on Mac OS X
In-Reply-To: <1231332662.33.0.831675111419.issue4865@psf.upfronthosting.co.za>
Message-ID: <1231350070.46.0.21312009725.issue4865@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IIUC, you are not the author of the patch (in the sense that you wrote
the new code), but rather created a diff between Apple's code and
Python's. In this case, we cannot accept the patch - it needs to be
contributed by the authors (i.e. Apple).

Furthermore, I fail to see how this patch can affect the places were
Python searches for site-packages - it only deals with Python code that
might need adjustment if Python would search in this other location.

Please correct me if I'm wrong.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4865>
_______________________________________

From report at bugs.python.org  Wed Jan  7 18:45:57 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 17:45:57 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231350357.64.0.85747926897.issue4868@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please upload it to Rietveld?

I'm skeptical about changes that merely rely on the compiler's register
allocator to do a better job. This kind of change tends to pessimize the
code for other compilers, and also may pessimize it for future versions
of the same compiler.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Wed Jan  7 18:54:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jan 2009 17:54:53 +0000
Subject: [issue4869] random.expovariate(0.0)
In-Reply-To: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>
Message-ID: <1231350893.45.0.657484326294.issue4869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Doc fixes in r68378.  Closing.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4869>
_______________________________________

From report at bugs.python.org  Wed Jan  7 18:58:36 2009
From: report at bugs.python.org (Karsten Petersen)
Date: Wed, 07 Jan 2009 17:58:36 +0000
Subject: [issue4865] system wide site-packages dir not used on Mac OS X
In-Reply-To: <1231332662.33.0.831675111419.issue4865@psf.upfronthosting.co.za>
Message-ID: <1231351116.36.0.166655495794.issue4865@psf.upfronthosting.co.za>


Karsten Petersen <kapet at kapet.de> added the comment:

Sorry, I should have made this clear:  I am NOT proposing to add this
patch.  I meant this more to show what related changes were done by
Apple.  Some of these clearly wouldn't even work like this if applied to
a Python not installed in /System/Library/Frameworks/...

IMHO the most interesting piece of that diff is the change to site.py
which makes it look into /Library/Python/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4865>
_______________________________________

From report at bugs.python.org  Wed Jan  7 19:05:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jan 2009 18:05:19 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231351519.42.0.0637043822805.issue4868@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As I said I don't think it's due to register allocation, but simply
avoiding register write-to-read dependencies by using separate variables
for the loop count and the pointer. I'm gonna try under Windows (in a
virtual machine, but it shouldn't make much difference since the
workload is CPU-bound).

I've open a Rietveld issue here: http://codereview.appspot.com/11681

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Wed Jan  7 19:11:44 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 07 Jan 2009 18:11:44 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

As came out here:
http://groups.google.it/group/comp.lang.python/browse_thread/thread/7d5b96f9bacb03d3?hl=it#
...the ssl module does not provide any facility to disable SSL version
2. This is very important when writing SSLv3/TLSv1 compatible servers.

----------
components: Library (Lib)
messages: 79357
nosy: giampaolo.rodola, janssen
severity: normal
status: open
title: ssl module is missing SSL_OP_NO_SSLv2
type: security
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Wed Jan  7 19:29:50 2009
From: report at bugs.python.org (Chris Lasher)
Date: Wed, 07 Jan 2009 18:29:50 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1231352990.82.0.646062138903.issue3244@psf.upfronthosting.co.za>


Changes by Chris Lasher <chris.lasher at gmail.com>:


----------
nosy: +gotgenes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Wed Jan  7 19:30:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jan 2009 18:30:50 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231353050.78.0.485732734519.issue4868@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ha, the patch makes things slower on MSVC. The patch can probably be
rejected, then.

(and interestingly, MSVC produces 40% faster code than gcc on my
mini-bench, despite the virtual machine overhead)

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Wed Jan  7 19:32:49 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 07 Jan 2009 18:32:49 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <496476FD.6090906@v.loewis.de>
Message-ID: <4964F54F.3080808@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-07 10:33, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> However, they are still exported from the object files, 
> 
> Ah. Those are "global symbols", not "exported symbols"; "export"
> is a concept specific to Win32.

Not at all. .so share libs and .a libs on Unix provide exports
just as well.

>> so can cause
>> name clashes with other libraries you link with.
> 
> See, and in this specific case, they can't, because they are used
> only in a debug build. Furthermore, they all have names that are
> unlikely to collide. Even if they get a _Py_ prefix, there could
> still be a conflict.
>
>> Even production builds contain a few such symbols which require
>> the _Py or Py prefix (or need to be made static) - these are for
>> Python 2.6 and 2.7:
>>
>> * asdl_int_seq_new
>> * asdl_seq_new
> 
> No. They don't require the Py_ prefix, because they already
> have the asdl_ prefix.

Oh please. The convention is that *all* Python exported symbols
should start with either _Py or Py. That's an old convention which
was introduced with the Great Renaming in Python 1.4.

The above symbols violate this convention, as do any symbols
that get additionally exported in debug builds or any other
variant build of Python.

I consider it a bug that Python still exports symbols that
do not follow the convention. This makes it harder to tell
whether a symbol originated in Python or some other extension
or linked object/library file.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Wed Jan  7 19:35:14 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 07 Jan 2009 18:35:14 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <4964F5DE.5020408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-07 16:25, Antoine Pitrou wrote:
> New submission from Antoine Pitrou <pitrou at free.fr>:
> 
> Here is a patch to speedup utf8 decoding. On a 64-bit build, the maximum
> speedup is around 30%, and on a 32-bit build around 15%. (*)
> 
> The patch may look disturbingly trivial, and I haven't studied the
> assembler output, but I think it is explained by the fact that having a
> separate loop counter breaks the register dependencies (when the 's'
> pointer was incremented, other operations had to wait for the
> incrementation to be committed).
> 
> [side note: utf8 encoding is still much faster than decoding, but it may
> be because it allocates a smaller object, regardless of the iteration count]
> 
> The same principle can probably be applied to the other decoding
> functions in unicodeobject.c, but first I wanted to know whether the
> principle is ok to apply. Marc-Andr?, what is your take?

I'm +1 on anything that makes codecs faster :-)

However, the patch should be checked with some other compilers
as well, e.g. using MS VC++.

> (*) the benchmark I used is:
> 
> ./python -m timeit -s "import
> codecs;c=codecs.utf_8_decode;s=b'abcde'*1000" "c(s)"
> 
> More complex input also gets a speedup, albeit a smaller one (~10%):
> 
> ./python -m timeit -s "import
> codecs;c=codecs.utf_8_decode;s=b'\xc3\xa9\xe7\xb4\xa2'*1000" "c(s)"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Wed Jan  7 19:43:08 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 18:43:08 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <d38f5330901070749h44ae6b4bk18948db57b435156@mail.gmail.com>
Message-ID: <4964F7B9.3080906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> My main interest in this patch are the type and %d to %zd change, but
> by throwing in the name change, I unintentionally made it more
> controversial.   Would it help if I resubmit the patch without name
> changes or is this something that a committer can take care of if the
> patch is partially accepted?

I think it is indeed better to focus on this part of the patch only.

I just reviewed it, and I think it is incorrect: We cannot assume that
the CRT supports %zd, therefore, PY_FORMAT_SIZE_T has to be used.

I fixed it, and removed the _Py_ prefixing, and committed the result
as r68381.

> Also a grep through nm output that Marc-Andre did is a good check to
> run from time to time and there is no reason to have false positives.

make smelly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Wed Jan  7 19:43:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 18:43:28 +0000
Subject: [issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
In-Reply-To: <1231188525.86.0.28964443261.issue4850@psf.upfronthosting.co.za>
Message-ID: <1231353808.09.0.570152444742.issue4850@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4850>
_______________________________________

From report at bugs.python.org  Wed Jan  7 20:07:01 2009
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 07 Jan 2009 19:07:01 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1231355221.93.0.0201798145956.issue4870@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Actually, that's not quite true.  Specifying TLSv1 or SSLv3 on the
server side will disable SSLv2.  However, there's currently no way to
specify SSLv3 *or* TLSv1 *but not* SSLv2.  This looks easy to fix; I'll
add another entry to the list of protocol versions, which when selected
will cause the server to use SSLv23, but will cause SSLv2 clients to be
rejected.

----------
assignee:  -> janssen
resolution:  -> accepted
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Wed Jan  7 20:10:35 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Jan 2009 19:10:35 +0000
Subject: [issue4869] random.expovariate(0.0)
In-Reply-To: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>
Message-ID: <1231355435.77.0.443379098833.issue4869@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with Mark.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4869>
_______________________________________

From report at bugs.python.org  Wed Jan  7 20:15:24 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 07 Jan 2009 19:15:24 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1231355724.37.0.677155354015.issue4870@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> Actually, that's not quite true.  
> Specifying TLSv1 or SSLv3 on the
> server side will disable SSLv2.

There are use cases like FTPS where it is desirable that servers support
SSLv3 *and* TLSv1.
To do that by using OpenSSL SSLv23 protocol must be specified and SSLv2
must be explicitly disabled afterward.
As far as I've understood, using SSLv23 on the server sides means that
when the client connects it could decide whether using SSLv2, SSLv3 or
TLSv1.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Wed Jan  7 20:26:44 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 07 Jan 2009 19:26:44 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231356404.56.0.674391317339.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

@skip:
In simple words, the x86 call:
  call 0x2000
placed at address 0x1000 becomes:
  call %rip + 0x1000

RIP holds the instruction pointer, which will be 0x1000 in this case
(actually, I'm ignoring the detail that when executing the call, RIP
points to the first byte of the next instruction).

If I execute the same instruction from a different location (i.e.
different RIP), things will break. So, only code for opcodes without
real calls, nor access to globals can be copied like this (inlines are OK).
With refcounting, not even POP_TOP is safe since it can call
destructors. DUP_TOP is still safe, I guess.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan  7 21:03:46 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Jan 2009 20:03:46 +0000
Subject: [issue1303434] Please include pdb with windows distribution
Message-ID: <1231358626.73.0.76622140953.issue1303434@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1303434>
_______________________________________

From report at bugs.python.org  Wed Jan  7 21:06:25 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Jan 2009 20:06:25 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231358785.43.0.321946188952.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

1.  This is the most important issue.  Is the r>n case typically an
error in the user's program or thought process.  If so, then the utility
of a ValueError can be weighed against the utility of other cases where
you want combs/perms to automatically handle the r>n cases with an empty
output.  These use cases are what I'm mulling over this week.

2. I see your wikipedia link.  The one I was looking at was:
   http://en.wikipedia.org/wiki/Combination

3. I wasn't clear on the issue of explictness.  The potential problem
that it isn't immediately obvious to me what comb/perm does when r>n, so
if I see code that isn't explictly handling that case, I have to lookup
what comb/perm does do to make sure the code works.

In the math module, it is a virtue that math.sqrt(-1) raises a
ValueError.  In the cmath module, it is a virtue that it does not.  The
latter case is distinguished because the programmer has explicitly
requested a routine that can handle complex numbers -- that is a good
clue that the surrounding code was designed to handle the complex result.

4. Not too worried about this one.  Essentially the thought is that code
that wasn't designed with the r>n case in mind probably benefits from
having a ValueError raised when that condition is encountered.
   
5. This one bugs me a bit.  It is nice to have all the factorial   
formulas just work and not have a piecewise definition.

BTW, we don't really have a difference of opinion.  My mind is open.  I
aspire to pick the option that is the best for most users including
students and novice users.  The trick in language design is to
anticipate use cases and to understand that people have differing world
views (i.e. it is a perfectly reasonable point-of-view that taking n
things r at a time makes no sense when r is greater than n).

In choosing, there is some bias toward sticking the API as it was
released.  Changing horses in midstream always causes a headache for
some user somewhere.

Am still thinking this one through and will let you know in a week or
so.  I also want to continue to research into how this is handled in
other libraries and other languages.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 21:20:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Jan 2009 20:20:02 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231359602.84.0.201850272776.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Another thought before I forget:  The piecewise definition of the choose
function or for binomial coefficients suggests that supporting the r>n
case should be accompanied by supporting the r<0 case.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 21:26:25 2009
From: report at bugs.python.org (Glade Diviney)
Date: Wed, 07 Jan 2009 20:26:25 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>


New submission from Glade Diviney <gladed at sybase.com>:

If a password is supplied using zpifile.read(objName, password), a 
TypeError occurs:

  File "C:\Program Files\Python30\lib\zipfile.py", line 420, in __init__
    self._UpdateKeys(p)
  File "C:\Program Files\Python30\lib\zipfile.py", line 424, in 
_UpdateKeys
    self.key0 = self._crc32(c, self.key0)
  File "C:\Program Files\Python30\lib\zipfile.py", line 413, in _crc32
    return ((crc >> 8) & 0xffffff) ^ self.crctable[(crc ^ ch) & 0xff]
TypeError: unsupported operand type(s) for ^: 'int' and 'str'

This is resolved in zipfile.py by replacing this line in __init__:
             self._UpdateKeys(ord(p))

----------
components: Library (Lib)
messages: 79368
nosy: gladed
severity: normal
status: open
title: zipfile can't decrypt
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Wed Jan  7 21:35:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jan 2009 20:35:01 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231360501.87.0.83319736973.issue4816@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> 5. This one bugs me a bit.  It is nice to have all the factorial
> formulas just work and not have a piecewise definition.

IIRC, in the 'Concrete Mathematics' book, Knuth and co use something
like

(n choose k) = (n-to-the-k-falling)/k!

to get around this:  this definition works for all k >= 0 and all
integers (or even real numbers) n.  Here x-to-the-k-falling means
x * (x-1) * ... * (x-k+1).  See:

http://mathworld.wolfram.com/FallingFactorial.html

> Another thought before I forget:  The piecewise definition of the
> choose function or for binomial coefficients suggests that
> supporting the r>n case should be accompanied by supporting 
> the r<0 case.

I'd say not:  in the context of sets of combinations/permutations,
(rather than just defining the nCr or nPr symbols) r has a
definite meaning as a cardinality:   "enumerate all subsets of
iter of cardinality r" and so it makes sense to me to restrict to
the case where r is nonnegative.

(If we were talking about the integer-valued function nCr, then I'd
agree.)

My own guess would be that having combinations(range(n), r)
give the empty iterator for r > n is the right thing in the
vast majority of situations, even (especially?) where the
programmer hasn't anticipated the possibility of r > n.
I have yet to see a case where it's useful to raise ValueError.

I have access to the Magma algebra package at work;  I'll
check tomorrow or Friday to see what that does.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 21:58:16 2009
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 07 Jan 2009 20:58:16 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231361896.88.0.714056171645.issue4816@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

Mathematica returns an empty list.

In[1]:= Permutations[{1,2},{1}]

Out[1]= {{1}, {2}}

In[2]:= Permutations[{1,2},{4}]

Out[2]= {}

In[3]:=

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 22:02:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Jan 2009 21:02:40 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231362160.74.0.678308326757.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

David, thanks for the data point.  What does it return for 

 In[1]:= Permutations[{a, b, c}, {-1}]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 22:08:55 2009
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 07 Jan 2009 21:08:55 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231362535.6.0.185505008141.issue4816@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

Mathematica indicates for the user to define it later.  An error.

In[3]:= Permutations[{1,2},{-2}]

Permutations::nninfseq: 
   Position 2 of Permutations[{1, 2}, {-2}]
     must be All, Infinity, a non-negative integer, or a List whose 
first
     element (required) is a non-negative integer, second element 
(optional)
     is a non-negative integer or Infinity, and third element (optional) 
is a
     nonzero integer.

Out[4]= Permutations[{1, 2}, {-2}]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 22:10:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jan 2009 21:10:16 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231362616.43.0.645953276392.issue4816@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Results from Magma, Sage and Gap:

Magma provides functions "Subsets(S, k)" and "Permutations(S, k)".  From 
the documentation:

Subsets(S, k) : The set of subsets of the set S of size k. If k is 
larger than the cardinality of S then the result will be empty.

Permutations(S, k) : The set of permutations (stored as sequences) of 
each of the subsets of the set S of cardinality k.

GAP has the same behaviour: even if you've never encountered GAP before, 
it's fairly Pythonesque, so the following extract from a GAP 4 REPL
means exactly what you think it does:

gap> Combinations([1,2,3,4], 3);
[ [ 1, 2, 3 ], [ 1, 2, 4 ], [ 1, 3, 4 ], [ 2, 3, 4 ] ]
gap> Combinations([1,2,3,4], 5);
[  ]

Permutations work the same way (but the function is called 
Arrangements):

gap> Arrangements([1,2,3,4], 3);
[ [ 1, 2, 3 ], [ 1, 2, 4 ], [ 1, 3, 2 ], [ 1, 3, 4 ], [ 1, 4, 2 ], 
  [ 1, 4, 3 ], [ 2, 1, 3 ], [ 2, 1, 4 ], [ 2, 3, 1 ], [ 2, 3, 4 ], 
  [ 2, 4, 1 ], [ 2, 4, 3 ], [ 3, 1, 2 ], [ 3, 1, 4 ], [ 3, 2, 1 ], 
  [ 3, 2, 4 ], [ 3, 4, 1 ], [ 3, 4, 2 ], [ 4, 1, 2 ], [ 4, 1, 3 ], 
  [ 4, 2, 1 ], [ 4, 2, 3 ], [ 4, 3, 1 ], [ 4, 3, 2 ] ]
gap> Arrangements([1,2,3,4], 5);
[  ]

Combinations([1,2,3,4], -1) gives an error.  Interestingly, 
Arrangements([1,2,3,4], -1) returns the empty list.

GAP also has a NrCombinations function returning the number of 
combinations:

gap> NrCombinations([1,2,3,4], 5);
0
gap> NrCombinations([1,2,3,4], -1);
0

My Sage installation currently seems to be broken, but from the 
documentation it looks as though it just steals the functions from GAP.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 22:16:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jan 2009 21:16:32 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231362992.37.0.0595471669706.issue4816@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Got Sage working again.  It also returns an empty list for r > n.  For r 
negative, Combinations returns an empty list and Permutation gives an 
error.

sage: Combinations(range(4), 6)
Combinations of [0, 1, 2, 3] of length 6
sage: Combinations(range(4), 6).list()
[]
sage: Permutations(range(4), 6).list()
[]
sage: Combinations(range(4), -1).list()
[]
sage: Permutations(range(4), -1).list()
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
[... traceback snipped ...]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 22:55:32 2009
From: report at bugs.python.org (nqiang)
Date: Wed, 07 Jan 2009 21:55:32 +0000
Subject: [issue4872] Python will not co-exist with MFC (memory leak)
In-Reply-To: <1231365332.46.0.804752973069.issue4872@psf.upfronthosting.co.za>
Message-ID: <1231365332.46.0.804752973069.issue4872@psf.upfronthosting.co.za>


New submission from nqiang <NQIANG at WMAINC.COM>:

The following code will cause memory leak in debug mode using visual 
studio 2008/2005
Comment out either MFC related (CString s) or Python related PY_XX. 
Then there will be no memory leak.

#include <python.h>
#include <afx.h>


int _tmain(int argc, _TCHAR* argv[])
{
	Py_Initialize();
	Py_Finalize();
	CString	s;
	return 0;
}

----------
messages: 79375
nosy: nqiang
severity: normal
status: open
title: Python will not co-exist with MFC (memory leak)
type: resource usage
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4872>
_______________________________________

From report at bugs.python.org  Wed Jan  7 23:27:09 2009
From: report at bugs.python.org (David Watson)
Date: Wed, 07 Jan 2009 22:27:09 +0000
Subject: [issue4859] pwd, spwd, grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231367229.21.0.836514245925.issue4859@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

> baikie: Open a separated issue for the refcount error and fd leak.

OK.  It does affect 2.x as well, come to think of it.

> On Ubuntu, it's not possible to create an user with a non-ASCII
> name:
>
> $ sudo adduser ? --no-create-home
>
> adduser: To avoid problems, the username should consist only of...

Well, good for Ubuntu :)  But you can still add one with the
lower-level useradd command, and not everyone uses Ubuntu.

> Your patch latin1.diff is wrong

Yes, I know it's "wrong" - I just thought of it as a stopgap
measure until some sort of bytes functionality is added (since
pwd already decodes everything as Latin-1, but tries to interpret
backslash escapes).  But yeah, if it's going to be changed later,
then I suppose there's not much point.

> I don't think that it can be called a "denial of service attack".

It depends on how the program uses these functions.  Obviously
Python itself is only vulnerable to a DoS if the interpreter
crashes or something, but what I'm saying is that there should be
a way for Python programs to access the password database that is
not subject to denial of service attacks.  If someone changes
their GECOS field they can make pwd.getpwall() fail for another
user's program, and if the program relies on pwd.getpwall()
working, then that's a DoS.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4859>
_______________________________________

From report at bugs.python.org  Wed Jan  7 23:27:50 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 07 Jan 2009 22:27:50 +0000
Subject: [issue4872] Python will not co-exist with MFC (memory leak)
In-Reply-To: <1231365332.46.0.804752973069.issue4872@psf.upfronthosting.co.za>
Message-ID: <1231367270.07.0.028331059043.issue4872@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

How do you know that there is a memory leak? 

I find it very unlikely that this interaction could cause a memory leak
(although it is plausible that in this case, not all memory is returned
to the system - which is something different from a memory leak).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4872>
_______________________________________

From report at bugs.python.org  Wed Jan  7 23:30:47 2009
From: report at bugs.python.org (David Watson)
Date: Wed, 07 Jan 2009 22:30:47 +0000
Subject: [issue4873] Refcount error and file descriptor leaks in pwd,
	grp modules
In-Reply-To: <1231367446.48.0.542903635557.issue4873@psf.upfronthosting.co.za>
Message-ID: <1231367446.48.0.542903635557.issue4873@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

When investigating issue #4859 I found that when pwd.getpwall()
and grp.getgrall() fail due to decoding errors, they leave open
file descriptors referring to the passwd and group files, since
they don't call the end*ent() functions in this case.  Also, the
grp.* functions have a reference counting error when they fail in
this way - a debug build reports that an object's reference count
goes to -1.  What I think happens is that in mkgrent(),
PyStructSequence_SET_ITEM steals the reference to "w", meaning
that the "Py_DECREF(w)" call shouldn't be made afterwards.  The
attached diff fixes both of these problems, I think, and applies
to the 2.x and 3.x branches.

----------
components: Extension Modules
files: minor.diff
keywords: patch
messages: 79378
nosy: baikie
severity: normal
status: open
title: Refcount error and file descriptor leaks in pwd, grp modules
type: resource usage
Added file: http://bugs.python.org/file12639/minor.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4873>
_______________________________________

From report at bugs.python.org  Wed Jan  7 23:37:12 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Jan 2009 22:37:12 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231367832.68.0.73664727724.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Data point:  Microsoft Excel's PERMUT() and COMBIN() return #NUM! for
r>n or r<0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 23:40:35 2009
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 07 Jan 2009 22:40:35 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231368035.59.0.0889379924472.issue4816@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

I try to "not know" excel.  Does it have any other means to represent an 
empty set?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Wed Jan  7 23:53:06 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Jan 2009 22:53:06 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231368786.08.0.38348460169.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Excel is returning the count, not the set itself.  So, it could have
chosen to return zero.

The HP32SII also has nCr and nPr functions that return INVALID DATA for
r>n or r<0.

The Combinatorics section of CRC Standard Mathematical Formulae (30th
edition) defines nCr and nPr only for 0 <= r <= n.  The same is true in
Harris and Stocker's Handbook of Mathematics and Computational science.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 00:26:42 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Jan 2009 23:26:42 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231370802.92.0.398419127866.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Summary of functions/definitions expected to return a number:           

  r>n       r<0       Source
--------- ----------  ------------------------------
error      error      MS Excel PERMUT() and COMBIN() 
error      error      HP32SII nPr and nCr    
undefined  undefined  CRC Combinatoric definitions   
undefined  undefined  Handbook of Mathematics and Computational Science  
undefined  undefined  Wolfram:  
http://mathworld.wolfram.com/Permutation.html
zero       zero       http://en.wikipedia.org/wiki/Choose_function  
undefined  undefined  http://en.wikipedia.org/wiki/Combination   
undefined  undefined  http://en.wikipedia.org/wiki/Permutation   
zero       undefined  Knuth's choose function in Concrete Mathematics    
zero       zero       GAP's nrCombinations()


Summary for tools that return the individual subsets:           

  r>n       r<0       Source
--------- ----------  ------------------------------
emptylist  error      Mathematica
emptylist  unknown    Magma
emptylist  error      GAP Combinations
emptylist  emptylist  GAP Arrangements
emptylist  emptylist  Sage Combinations
emptylist  error      Sage Permutations

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 00:35:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Jan 2009 23:35:16 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231371316.1.0.383348780696.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

David, I know the OPs position and Mark's opinion.  What is your
recommendation for the r>n case and the r<0 case?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 00:48:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jan 2009 23:48:16 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The following function calls should raise a TypeError instead. Encoding
functions are fine (they only accept str).

>>> import codecs
>>> codecs.utf_8_decode('aa')
('aa', 2)
>>> codecs.utf_8_decode('??')
('??', 4)
>>> codecs.latin_1_decode('??')
('????', 4)

----------
components: Extension Modules
messages: 79384
nosy: pitrou
priority: release blocker
severity: normal
status: open
title: decoding functions in _codecs module accept str arguments
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan  8 01:43:36 2009
From: report at bugs.python.org (Ryan Kelly)
Date: Thu, 08 Jan 2009 00:43:36 +0000
Subject: [issue4875] find_library can return directories instead of files
In-Reply-To: <1231375416.63.0.958079386255.issue4875@psf.upfronthosting.co.za>
Message-ID: <1231375416.63.0.958079386255.issue4875@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

On win32, ctypes.util.find_library uses os.path.exists() to check for
potential library files.  This means it is quite happy to return a
directory instead of a file, if one happens to exist with the
appropriate name somewhere in the search path.  Can this please be
changed to use os.path.isfile() instead of os.path.exists()?

----------
assignee: theller
components: ctypes
messages: 79385
nosy: rfk, theller
severity: normal
status: open
title: find_library can return directories instead of files
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4875>
_______________________________________

From report at bugs.python.org  Thu Jan  8 01:48:43 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 00:48:43 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231375723.84.0.484182125342.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attached an updated patch which expands the tests and docs.
Handles the r>n case with an empty result.
Leaves the r<0 case as a ValueError.

Am thinking that if we do this, it should be treated as a bug and posted
to 2.6 and 3.0.

Added file: http://bugs.python.org/file12640/combperm.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 01:59:08 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jan 2009 00:59:08 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1231376348.79.0.674683880763.issue4874@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch replacing "s*" parsing format by "y*" for:
 - utf_7_decode()
 - utf_8_decode()
 - utf_16_decode()
 - utf_16_le_decode()
 - utf_16_be_decode()
 - utf_16_ex_decode()
 - utf_32_decode()
 - utf_32_le_decode()
 - utf_32_be_decode()
 - utf_32_ex_decode()
 - unicode_escape_decode()
 - raw_unicode_escape_decode()
 - latin_1_decode()
 - ascii_decode()
 - charmap_decode()
 - mbcs_decode()

Using run_tests.sh, all tests are ok (with 19 skipped tests). I guess 
that there is not tests for all these functions :-/

Note: codecs documentation was already correct:

.. method:: Codec.decode(input[, errors])
   (...)
   *input* must be a bytes object or one which provides the read-only 
character
   buffer interface -- for example, buffer objects and memory mapped 
files.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file12641/_codecs_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:03:41 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jan 2009 01:03:41 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231376621.85.0.663548797252.issue4871@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The key is a bytes string or an unicode string? Using bytes, each 
element is an int instead of a str.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:03:53 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 08 Jan 2009 01:03:53 +0000
Subject: [issue4688] GC optimization: don't track simple tuples and dicts
In-Reply-To: <1229557269.64.0.0932795571555.issue4688@psf.upfronthosting.co.za>
Message-ID: <1231376633.74.0.925551470458.issue4688@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4688>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:05:22 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jan 2009 01:05:22 +0000
Subject: [issue4867] crash in ctypes when passing a string to a function
	without defining argtypes
In-Reply-To: <1231339282.89.0.0934088116939.issue4867@psf.upfronthosting.co.za>
Message-ID: <1231376722.12.0.467167590098.issue4867@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you please generate an unified diff (svn diff, diff -u, etc.)?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4867>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:10:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jan 2009 01:10:27 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1231377027.6.0.779262394693.issue4814@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Your patch looks correct.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:16:01 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 08 Jan 2009 01:16:01 +0000
Subject: [issue2262] Helping the compiler avoid memory references in
	PyEval_EvalFrameEx
In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za>
Message-ID: <1231377361.56.0.311949854907.issue2262@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2262>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:23:33 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 08 Jan 2009 01:23:33 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231377813.98.0.872090506298.issue4753@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:29:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jan 2009 01:29:25 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1231378165.67.0.455309786131.issue1068268@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Since Python 2.5 only accept security fixes, you should update your 
patch to Python trunk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:47:26 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 01:47:26 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231379246.14.0.329372292632.issue4816@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file12642/combperm2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:47:31 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 01:47:31 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231379251.94.0.623513042444.issue4816@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12640/combperm.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:53:49 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 08 Jan 2009 01:53:49 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1231379629.44.0.768441658284.issue4814@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I'm sorry, I realized right now that settimeout() should be used also
*before* invoking accept(), to avoid the client to stall in case the
server does not establish any connection.
The second patch in attachment does that by using settimeout() straight
into FTP.makeport() method.

Added file: http://bugs.python.org/file12643/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Thu Jan  8 02:59:10 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 08 Jan 2009 01:59:10 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231379950.98.0.105750471544.issue4816@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

I had thought highly of the "mull it over for a week" plan.  After a 
week we'd decide to follow Stephen Wolfram's lead, which seems to be the 
current patch.  I haven't yet used the python permutations iterator, 
although I used to have a script that solved word JUMBLE puzzles with a 
mathematica | spell pipeline.  Now I look up words using a sorted 
anagram dictionary.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 03:20:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 02:20:17 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231381217.89.0.520922930359.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks David. Looks like we're all in agreement.
Turns out, I did a weeks worth of mulling today ;-)
Accepting the proposal with the following rationale:

1. There exist some valid use cases where r>n.
2. Returning an empty list is the expected outcome with two of the
current pure python versions (the ones that filter results from
product() based on their length, uniqueness and sort).
3. It is consist with the notion of 'all subsets of length r ...'
4. It corresponds to the piecewise definitions of the choose function
and binomial coefficient.
5. It matches the battle-tested APIs of all of the major mathematics
tools we looked at (Mathematica, Magma, GAP, and Sage.
6. The recipe for combinations_with_replacement() is well defined and
useful in cases where r>n -- it is desirable that all the variants of
this function keep their APIs in-sync.
7. The three other posters here all agree on it :-)

Weighing against it:
1. The ValueError version has already been released.
2. There may be use cases where r>n represents an error so that raising
a ValueError would be helpful.
3. The length of the comb/perm doesn't correspond to the non-piecewise,
factorial based functions that are so ubiquitous (MS Excel, HP32SII, CRC
handbook, Handbook of Mathematics, wikipedia's entries for Combination
and Permutation, and GAP's nrCombinations() function).

----------
resolution:  -> accepted
versions: +Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 03:26:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 08 Jan 2009 02:26:53 +0000
Subject: [issue4876] Incorrect detection of module as local
In-Reply-To: <1231381613.0.0.23916695518.issue4876@psf.upfronthosting.co.za>
Message-ID: <1231381613.0.0.23916695518.issue4876@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

There is an unfortunate interaction of two fixers to be observed in
django. django.util.text.py contains

from htmlentitydefs import name2codepoint

This gets fixed to

from .html.entities import name2codepoint

because there is also a local module django.util.html. This is
incorrect; it should have converted it to

from html.entities import name2codepoint

As a workaround, I now run

   name2codepoint = __import__('html.entities').entities.name2codepoint

on ImportError of the (converted) import statement. Is there a better
work-around?

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 79395
nosy: loewis
severity: normal
status: open
title: Incorrect detection of module as local

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4876>
_______________________________________

From report at bugs.python.org  Thu Jan  8 03:44:35 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 02:44:35 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231382675.05.0.645949827741.issue4816@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file12644/combperm3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 03:44:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 02:44:40 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231382680.42.0.392074367326.issue4816@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12642/combperm2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 04:02:41 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 08 Jan 2009 03:02:41 +0000
Subject: [issue4876] Incorrect detection of module as local
In-Reply-To: <1231381613.0.0.23916695518.issue4876@psf.upfronthosting.co.za>
Message-ID: <1231383761.9.0.898445394978.issue4876@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Should we just run the import fixer (fixes stdlib module names) after
the import fixer (fixes sibling imports)?

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4876>
_______________________________________

From report at bugs.python.org  Thu Jan  8 04:03:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 03:03:43 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231383823.05.0.423526273341.issue4868@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening and attaching a more ambitious patch, based on the
optimization of runs of ASCII characters. This time the speedup is much
more impressive, up to 75% faster on pure ASCII input -- actually faster
than latin1.

The worst case (tight interleaving of ASCII and non-ASCII chars) shows a
8% slowdown.

(performance measured with gcc and MSVC)

----------
resolution: rejected -> 
status: closed -> open
Added file: http://bugs.python.org/file12645/utf8decode3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 04:03:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 03:03:52 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231383832.32.0.351335195716.issue4868@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12638/utf8decode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 06:01:16 2009
From: report at bugs.python.org (Steve Howard)
Date: Thu, 08 Jan 2009 05:01:16 +0000
Subject: [issue4877] xml.parsers.expat ParseFile() causes segmentation fault
	when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>


New submission from Steve Howard <dev at gostevehoward.com>:

In Python 2.5.4 built from unmodified source:

showard at showardlt:~/src/Python-2.5.4$ ./python
Python 2.5.4 (r254:67916, Jan  7 2009, 20:28:41) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.parsers import expat
>>> f=open('/tmp/foo')
>>> p=expat.ParserCreate()
>>> f.close()
>>> p.ParseFile(f)
Segmentation fault

The error is in the control flow in xmlparse_ParseFile()
(Modules/pyexpat.c:1000).  When passed a real file object that's been
closed, PyFile_Check() returns true, but then PyFile_AsFile() returns 0
(since f_fp on the file object is set to zero when the file is closed).
 So the local 'fp' is set to 0, and 'readmethod' is left as NULL.  The
conditional at 1033 then fails, and the call to readinst() at 1041
passes readmethod=NULL, leading eventually to a segfault in
PyObject_Call at Objects/abstract.c:1860.

I think it's present in 2.6 as well, but I'm not sure.  It seems to have
been fixed by chance in 3.0 because Guido removed the first branch in
xmlparse_ParseFile altogether in an unrelated change a while ago.

The attached patch simply checks for fp == 0 and raises an exception.  I
don't know if it's the proper solution but you get the idea.

Built with the attached patch:

showard at showardlt:~/src/Python-2.5.4$ ./python
Python 2.5.4 (r254:67916, Jan  7 2009, 20:28:41) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.parsers import expat
>>> f=open('/tmp/foo')
>>> p=expat.ParserCreate()
>>> f.close()   
>>> p.ParseFile(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: attempting to parse closed file

----------
components: XML
files: pyexpat_segfault_on_closed_file.patch
keywords: patch
messages: 79398
nosy: showard
severity: normal
status: open
title: xml.parsers.expat ParseFile() causes segmentation fault when passed a closed file object
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file12646/pyexpat_segfault_on_closed_file.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4877>
_______________________________________

From report at bugs.python.org  Thu Jan  8 06:09:34 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 05:09:34 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231391374.43.0.282213359156.issue4816@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file12647/combperm4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 06:09:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 05:09:40 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231391380.29.0.526963053461.issue4816@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12644/combperm3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 06:21:33 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Jan 2009 05:21:33 +0000
Subject: [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1231392093.31.0.254817330196.issue4816@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r68394 
Will forward port in a day or two.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4816>
_______________________________________

From report at bugs.python.org  Thu Jan  8 07:17:46 2009
From: report at bugs.python.org (Senthil)
Date: Thu, 08 Jan 2009 06:17:46 +0000
Subject: [issue4707] round() shows undocumented behaviour
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1231395466.51.0.605832799333.issue4707@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I also think that documentation should be improved for 
round(number, [ndigits]). The doc/help says, ndigits can be negative,
but does not really say what it means to be negative. 

It can be confusing to anyione. Take the following example:
>>> round(26.5,1)
26.5
>>> round(26.5,-1)
30.0

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Thu Jan  8 08:17:01 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 08 Jan 2009 07:17:01 +0000
Subject: [issue4876] Incorrect detection of module as local
In-Reply-To: <1231381613.0.0.23916695518.issue4876@psf.upfronthosting.co.za>
Message-ID: <1231399021.68.0.0729096640115.issue4876@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That should work, yes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4876>
_______________________________________

From report at bugs.python.org  Thu Jan  8 09:33:54 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jan 2009 08:33:54 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1231403634.58.0.249219214874.issue4814@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12552/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Thu Jan  8 10:29:21 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 08 Jan 2009 09:29:21 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231376348.79.0.674683880763.issue4874@psf.upfronthosting.co.za>
Message-ID: <4965C76C.3000802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-08 01:59, STINNER Victor wrote:
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Patch replacing "s*" parsing format by "y*" for:
>  - utf_7_decode()
>  - utf_8_decode()
>  - utf_16_decode()
>  - utf_16_le_decode()
>  - utf_16_be_decode()
>  - utf_16_ex_decode()
>  - utf_32_decode()
>  - utf_32_le_decode()
>  - utf_32_be_decode()
>  - utf_32_ex_decode()
>  - latin_1_decode()
>  - ascii_decode()
>  - charmap_decode()
>  - mbcs_decode()

These are fine.

>  - unicode_escape_decode()
>  - raw_unicode_escape_decode()

These changes are in line with their C API codec interfaces as well,
but those particular codecs could well also be made to work on Unicode
input, since unescaping can well be applied to Unicode as well.

I'll probably open a new item for this.

> Using run_tests.sh, all tests are ok (with 19 skipped tests). I guess 
> that there is not tests for all these functions :-/

The mbcs codec is only available on Windows.

All others are tested by test_codecs.py.

Which ones are skipped in your case ?

> Note: codecs documentation was already correct:
> 
> .. method:: Codec.decode(input[, errors])
>    (...)
>    *input* must be a bytes object or one which provides the read-only 
> character
>    buffer interface -- for example, buffer objects and memory mapped 
> files.

That's not entirely correct: codecs are allowed to accept any
object type and can also return any object type. It up to them
to decide, e.g. a codec may accept both bytes and Unicode input
and always generate Unicode output when decoding.

I guess I have to review those doc changes...

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan  8 10:37:12 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 08 Jan 2009 09:37:12 +0000
Subject: [issue4867] crash in ctypes when passing a string to a function
	without defining argtypes
In-Reply-To: <1231339282.89.0.0934088116939.issue4867@psf.upfronthosting.co.za>
Message-ID: <1231407432.59.0.789045731295.issue4867@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The patch is fine, no need for another diff.

----------
resolution:  -> accepted
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4867>
_______________________________________

From report at bugs.python.org  Thu Jan  8 10:44:54 2009
From: report at bugs.python.org (Juha Rantanen)
Date: Thu, 08 Jan 2009 09:44:54 +0000
Subject: [issue4878] post installer script's message is not shown to user with
	bdist_wininst
In-Reply-To: <1231407894.66.0.157123159421.issue4878@psf.upfronthosting.co.za>
Message-ID: <1231407894.66.0.157123159421.issue4878@psf.upfronthosting.co.za>


New submission from Juha Rantanen <juha.rantanen at iki.fi>:

1. Create installer with bdist_wininst with python version 2.5
2. Install it to 2.6 Python. 
3. The post installer message is not shown to user in the installer window.
4. Remove the installation from add/remove programs.
5. Messages coming from removing are not shown to the user.


This same happens if the installer is created with python 2.6 and it is
installed to 2.5 Python. See attached project, which can be used to
create the installer which contains post installer script.

----------
components: Distutils
files: simple.zip
messages: 79404
nosy: rantanen
severity: normal
status: open
title: post installer script's message is not shown to user with bdist_wininst
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12648/simple.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4878>
_______________________________________

From report at bugs.python.org  Thu Jan  8 11:01:35 2009
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 08 Jan 2009 10:01:35 +0000
Subject: [issue4867] crash in ctypes when passing a string to a function
	without defining argtypes
In-Reply-To: <1231339282.89.0.0934088116939.issue4867@psf.upfronthosting.co.za>
Message-ID: <1231408895.17.0.817440176224.issue4867@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Fixed in release30-maint, rev. 68402 and py3k, rev. 68401.
Thanks for the patch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4867>
_______________________________________

From report at bugs.python.org  Thu Jan  8 11:43:56 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Jan 2009 10:43:56 +0000
Subject: [issue4879] Allo buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

This is related to issue 4336.  While that issue finally revolved around 
fixing the Nagle problem for xmlrpc and other http clients, here I 
propose to fix another performance bottleneck with xmlrpc, reading the 
HTTP Headers.
HTTPResponse creates a socket.fileobject() with zero buffering which 
means that the readline() operations used to read the headers become 
very inefficient since individual socket.recv() calls are used for each 
character.
The reason for this is to support users who subsequently do 
socket.recv() on the underlying socket, and so we don't want to read too 
much of the headers. Note that there is no example of this in the 
standard library.
In the provided patch, I have removed some vestigial code from 
xmrlpclib.py which attempted to use recv() even though it never did 
(because the connection has been closed when HTTPConnection returns the 
response).  Even so, Guido has expressed his concern that we need to 
keep the support for this recv() behaviour in place.
Therefore, I have added a new optional argument, nobuffer=True, which 
users that promise not to call recv() can set to false.  This will then 
cause the generated fileobject from HTTPResponse to have default 
buffering, greatly increasing the performance of the reading of the 
headers.

----------
components: Library (Lib)
files: nobuffer.patch
keywords: patch, patch
messages: 79406
nosy: krisvale
severity: normal
status: open
title: Allo buffering for HTTPResponse
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12649/nobuffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Thu Jan  8 11:49:01 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Jan 2009 10:49:01 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1231411741.85.0.242157196009.issue4336@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Reopening this, since I am not entirely happy with the implementation 
that was checked in.  Please see my comments from Dec 5th onwards.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Thu Jan  8 13:13:48 2009
From: report at bugs.python.org (=?utf-8?q?J._David_Ib=C3=A1=C3=B1ez?=)
Date: Thu, 08 Jan 2009 12:13:48 +0000
Subject: [issue1202] zlib.crc32() and adler32() return value
In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za>
Message-ID: <1231416828.32.0.321438355884.issue1202@psf.upfronthosting.co.za>


J. David Ib??ez <jdavid at itaapy.com> added the comment:

I believe I have hit this bug. With Python 2.6.1 in a Gentoo Linux
64 bits.

This code:

  from zipfile import ZipFile
  inzip = ZipFile('Document.odt')
  outzip = ZipFile('out.zip', 'w')
  for f in inzip.infolist():
      if f.filename != 'content.xml':
          print f.filename, '(CRC: %s)' % f.CRC
          outzip.writestr(f, inzip.read(f.filename))
  outzip.close()

Produces this output:

  ...
  styles.xml (CRC: 3930581528)
  test_odt.py:10: DeprecationWarning: 'l' format requires -2147483648 <=
number <= 2147483647
    outzip.writestr(f, inzip.read(f.filename))
  ...

The CRC is not a 32bits signed, and then the module struct complains,
here:

  zipfile.py:1098
  self.fp.write(struct.pack("<lLL", zinfo.CRC, zinfo.compress_size,

Apparently 'struct.pack' expects 'zinfo.CRC' to be a 32 signed it,
which is not.

I can attach the 'Document.odt' file if you want.

----------
nosy: +jdavid at itaapy.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1202>
_______________________________________

From report at bugs.python.org  Thu Jan  8 14:11:22 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 08 Jan 2009 13:11:22 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231420282.49.0.531733594931.issue4868@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Very nice! It seems that you can get slightly faster by not copying the
initial char first: 's' is often already aligned at the beginning of the
string, but not after the first copy... Attached patch
(utf8decode4.patch) changes this and may enter the fast loop on the
first character.

Does this idea apply to the encode function as well?

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file12650/utf8decode4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 14:50:51 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 08 Jan 2009 13:50:51 +0000
Subject: [issue4862] utf-16 BOM is not skipped after seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <496604B8.6070900@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-07 01:21, Amaury Forgeot d'Arc wrote:
> First write a utf-16 file with its signature:
> 
>>>> f1 = open('utf16.txt', 'w', encoding='utf-16')
>>>> f1.write('0123456789')
>>>> f1.close()
> 
> Then read it twice:
> 
>>>> f2 = open('utf16.txt', 'r', encoding='utf-16')
>>>> print('read1', ascii(f2.read()))
> read1 '0123456789'
>>>> f2.seek(0)
> 0
>>>> print('read2', ascii(f2.read()))
> read2 '\ufeff0123456789'
> 
> The second read returns the BOM!
> This is because the zero in seek(0) is a "cookie" which contains both the position 
> and the decoder state. Unfortunately, state=0 means 'endianness has been determined: 
> native order'.
> 
> maybe a suggestion: handle seek(0) as a special value which calls decoder.reset().
> The patch implement this idea.

This is a problem with the utf_16.py codec, not the io layer.
Opening a file in append mode is something that the io layer
would have to handle, since the codec doesn't know anything about
the underlying file mode.

Using .reset() will not help. The code for the StreamReader
and StreamWriter in utf_16.py will have to be modified to undo
the adjustment of the .encode() and .decode() method after using
.seek(0).

Note that there's also the case .seek(1) - I guess this must
be considered as resulting in undefined behavior.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4862>
_______________________________________

From report at bugs.python.org  Thu Jan  8 15:32:53 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Jan 2009 14:32:53 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1231425173.74.0.0141261102404.issue4879@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
title: Allo buffering for HTTPResponse -> Allow buffering for HTTPResponse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Thu Jan  8 15:56:30 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 08 Jan 2009 14:56:30 +0000
Subject: [issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
In-Reply-To: <1231426590.2.0.669134378939.issue4880@psf.upfronthosting.co.za>
Message-ID: <1231426590.2.0.669134378939.issue4880@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

there's probably a better way to do this (or a better reason), but
LONG_MIN and LONG_MAX end up as the wrong constant types when compiling
python2.5.2 under wine (don't ask...)

PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
    if ((long)ival >= (long)LONG_MIN && (long)ival <= (long)LONG_MAX)
    {
        return PyInt_FromLong((long)ival);
    }
    return _PyLong_FromSsize_t(ival);
}

----------
messages: 79411
nosy: lkcl
severity: normal
status: open
title: PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4880>
_______________________________________

From report at bugs.python.org  Thu Jan  8 15:59:09 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 08 Jan 2009 14:59:09 +0000
Subject: [issue4861] fix problems with ctypes.util.find_library
In-Reply-To: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>
Message-ID: <1231426749.37.0.937562334777.issue4861@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

new version of the patch using os instead of platform, and selecting the
correct library for biarch platforms, tested on ia64, sparc, s390,
amd64, ppc64. unsure if there's a better way to find out if the
executable is 32 or 64bit.

Added file: http://bugs.python.org/file12651/ctypes-findlib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4861>
_______________________________________

From report at bugs.python.org  Thu Jan  8 16:00:07 2009
From: report at bugs.python.org (Jason Tishler)
Date: Thu, 08 Jan 2009 15:00:07 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1231426807.24.0.868071160572.issue2233@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

Sorry for the delay, but I was on vacation and then recovering from 
vacation...

You are correct that my initial patch does not handle the case when 
DESTDIR is not specified.  Your suggestion will work, but seems hacky.

What about adding the defaulting of DESTDIR to "/" to my initial 
patch?  This seems cleaner.  See my second patch for the details.

If this approach is acceptable, then feel free to move the defaulting 
of DESTDIR to a more appropriate place in Makefile.pre.in.  I wasn't 
sure where to put this change.

Added file: http://bugs.python.org/file12652/Makefile.pre.in.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Thu Jan  8 16:02:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 08 Jan 2009 15:02:38 +0000
Subject: [issue4861] fix problems with ctypes.util.find_library
In-Reply-To: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>
Message-ID: <1231426958.07.0.755714604818.issue4861@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This seems to be a partial duplicate of 3383.  A suggestion on that
ticket was to look for objdump in PATH and then try /usr/sbin.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4861>
_______________________________________

From report at bugs.python.org  Thu Jan  8 16:03:05 2009
From: report at bugs.python.org (Pablo Castagnino)
Date: Thu, 08 Jan 2009 15:03:05 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>


New submission from Pablo Castagnino <pablo.castagnino at gmail.com>:

Something in python's timezone handling needs to be
updated. Python does not take into account 'daylight saving' clock time
changes.

The thing is my clock time is correct. If you
ask anyone here for the time, they will tell you it's X. However, Python
believes (correct) current time is X + 1 hour. In fact, this is the case
most of the time, but because of 'daylight saving' measures, official
time has been changed. So, without a doubt, this needs to be fixed.

A solution could be adding the possibility to set a 'daylight saving'
option which helps dealing with this. So, if I set this option to 3600
secs, then Python could +/- this remainder to the, let's call it,
'expected current time' according to the timezone.

----------
components: Library (Lib)
messages: 79415
nosy: earendili510
severity: normal
status: open
title: Python's timezon handling: daylight saving option
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Thu Jan  8 16:22:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 15:22:32 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231420282.49.0.531733594931.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231428165.11860.28.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Attached patch
> (utf8decode4.patch) changes this and may enter the fast loop on the
> first character.

Thanks!

> Does this idea apply to the encode function as well?

Probably, although with less efficiency (a long can hold 1, 2 or 4
unicode characters depending on the build).
The unrolling part also applies to simple codecs such as latin1.
Unrolling PyUnicode_DecodeLatin1 a bit (4 copies per iteration) makes it
twice faster on non-tiny strings. I'll experiment with utf16.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 16:35:46 2009
From: report at bugs.python.org (alec resnick)
Date: Thu, 08 Jan 2009 15:35:46 +0000
Subject: [issue4882] Behavior of backreferences to named groups in regular
	expressions unclear
In-Reply-To: <1231428946.66.0.0747408022841.issue4882@psf.upfronthosting.co.za>
Message-ID: <1231428946.66.0.0747408022841.issue4882@psf.upfronthosting.co.za>


New submission from alec resnick <aresnickety at gmail.com>:

I recently learned about named groups in Python regular expressions. 
Almost all the documentation I've found online explains what they are
and give a simple example of how to use them.  I was trying to use the
variables outside of the original regex, later in the code.  Nowhere in
the documentation I found after a couple hours of searching was it
mentioned that named groups can only be backreferenced _within_ the pattern.

In particular, the sections at
http://www.amk.ca/python/howto/regex/#SECTION000530000000000000000 and
the description of the (?P<name>) behavior at
http://docs.python.org/library/re.html could be modified to make it
clear that the named capture does not create a variable usable outside
of the pattern.

I would be happy to alter the documentation appropriately.

----------
assignee: georg.brandl
components: Documentation
messages: 79417
nosy: aresnick, georg.brandl
severity: normal
status: open
title: Behavior of backreferences to named groups in regular expressions unclear
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4882>
_______________________________________

From report at bugs.python.org  Thu Jan  8 16:46:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Jan 2009 15:46:25 +0000
Subject: [issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
In-Reply-To: <1231426590.2.0.669134378939.issue4880@psf.upfronthosting.co.za>
Message-ID: <1231429585.08.0.0887871601872.issue4880@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Interesting.  How many of those casts are actually necessary to make 
things work?  Have you figured out more precisely why this is failing?
E.g., is it somehow that LONG_MIN ends up being an unsigned constant?

It seems to me that a better fix would be to fix LONG_MIN and LONG_MAX 
somewhere in the configuration files;  there are bound to be more uses of 
LONG_MIN and LONG_MAX in the source that are going to cause problems.

P.S.  Looking at your python-dev messages, does len([1, 2]) really return 
1L?  Not 2L?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4880>
_______________________________________

From report at bugs.python.org  Thu Jan  8 16:47:33 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 08 Jan 2009 15:47:33 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1231429653.11.0.548314411557.issue3383@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

I think 4861 provides a solution for this issue. I don't see any system
where objdump is in /sbin or /usr/sbin.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Thu Jan  8 17:13:38 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 08 Jan 2009 16:13:38 +0000
Subject: [issue4883] Compiling python 2.5.2 under Wine on linux.
In-Reply-To: <1231431218.3.0.0118570431179.issue4883@psf.upfronthosting.co.za>
Message-ID: <1231431218.3.0.0118570431179.issue4883@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

messy patches which get python 2.5.2 compiling - and producing
python.exe.so - under wine.

the setup.py is presently _wholly_ unsuited to use for building
the modules - get_sysconfig("srcdir") returns None because...
it's supposed to!

but, the actual libpython2.5.a and the actual python.exe _are_
successfully built - and, amazingly, useable.

----------
components: Build
files: f
messages: 79420
nosy: lkcl
severity: normal
status: open
title: Compiling python 2.5.2 under Wine on linux.
versions: Python 2.5
Added file: http://bugs.python.org/file12653/f

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4883>
_______________________________________

From report at bugs.python.org  Thu Jan  8 17:19:26 2009
From: report at bugs.python.org (Glade Diviney)
Date: Thu, 08 Jan 2009 16:19:26 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231431566.03.0.491640373792.issue4871@psf.upfronthosting.co.za>


Glade Diviney <gladed at sybase.com> added the comment:

In this case under test, the password string had been clipped from a 
filename, so I suppose it would have been Unicode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Thu Jan  8 17:40:57 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 08 Jan 2009 16:40:57 +0000
Subject: [issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
In-Reply-To: <1231426590.2.0.669134378939.issue4880@psf.upfronthosting.co.za>
Message-ID: <1231432857.7.0.412783459683.issue4880@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

oh, duh - 2L not 1L yes you're right :)

yeh i believe it's likely to be because in PC/pyconfig.h LONG_MAX is
#defined to 7fffffff not 7fffffffL i'll double-check.

you're right that would make life a looot easier.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4880>
_______________________________________

From report at bugs.python.org  Thu Jan  8 17:41:02 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Thu, 08 Jan 2009 16:41:02 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231432862.04.0.642888391885.issue4871@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

This is basically the same problem as with other bytes-orientated modules.

The choice is either to reject unicode and force the caller to use
.encode() on all his strings (so 'password' is an instance of bytes and
'ch' an instance of int). I'd prefer that.

Or to check if 'password' is a unicode-object and encode to default
within zipfile.

----------
nosy: +ebfe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Thu Jan  8 17:47:56 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 08 Jan 2009 16:47:56 +0000
Subject: [issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
In-Reply-To: <1231426590.2.0.669134378939.issue4880@psf.upfronthosting.co.za>
Message-ID: <1231433276.23.0.40331939398.issue4880@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

.... hmmm... noo, it's already #defined to 0x7fffffffL in
both PC/pyconfig.h _and_ in /usr/include/wine/msvcrt/limits.h

so .... this works (Include/pyports.h)

#ifdef __WINE__  /* weird: you have to typecast 0x7fffffffL to long */
#undef LONG_MAX
#undef LONG_MIN
#define LONG_MAX ((long)0x7FFFFFFFL)
#define LONG_MIN ((long)(-LONG_MAX-1))
#else
#ifndef LONG_MAX
#if SIZEOF_LONG == 4
#define LONG_MAX 0X7FFFFFFFL
#elif SIZEOF_LONG == 8
#define LONG_MAX 0X7FFFFFFFFFFFFFFFL
#else
#error "could not set LONG_MAX in pyport.h"
#endif
#endif

#ifndef LONG_MIN
#define LONG_MIN (-LONG_MAX-1)
#endif

#endif /* __WINE__ */

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4880>
_______________________________________

From report at bugs.python.org  Thu Jan  8 17:50:49 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jan 2009 16:50:49 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231433449.29.0.0841568895258.issue4871@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> check if 'password' is a unicode-object 
> and encode to default within zipfile. 

Hmmm... what is the default charset? :-) I think that the charset 
depends on the OS and the user locale...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Thu Jan  8 17:59:36 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Thu, 08 Jan 2009 16:59:36 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231433976.17.0.180872410984.issue4871@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

The default encoding is UTF8. Even without that there should be no
problems while staying in the same environment as the
character->translation is the same.

However it violates the rule of least surprise to see zipfile throwing
CRC errors because the password is something like 'u????n' and encoded
by some locale-changing-nitwit in korea...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Thu Jan  8 18:06:39 2009
From: report at bugs.python.org (Kevin Watters)
Date: Thu, 08 Jan 2009 17:06:39 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231434399.74.0.0987652868374.issue4868@psf.upfronthosting.co.za>


Changes by Kevin Watters <kevinwatters at gmail.com>:


----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 18:17:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 08 Jan 2009 17:17:38 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1231435058.86.0.24279299806.issue3383@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I think Antoine meant (and I was just copying him) /bin or /usr/bin. 
The specific case where I encountered the failure was one where PATH was
not set to anything.  The fix in the patch attached to this ticket would
make it much easier to track down why the failure happened, but it
wouldn't fix it.  I guess I'd be satisfied with this, but of course I'd
be happier if it actually worked. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Thu Jan  8 19:21:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 08 Jan 2009 18:21:39 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1231438899.04.0.0294804074681.issue4394@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok, I had one +1 from distutils-SIG, so I am updating this patch to
commit it in 2.7 and 3.1.

----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Thu Jan  8 20:08:15 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 08 Jan 2009 19:08:15 +0000
Subject: [issue4884] Work around gethostbyaddr_r bug
In-Reply-To: <1231441695.4.0.529827841073.issue4884@psf.upfronthosting.co.za>
Message-ID: <1231441695.4.0.529827841073.issue4884@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

glibc until 2.10 has a bug in gethostbyaddr_r that assumes the buffer
argument is 8-byte aligned
(http://sources.redhat.com/ml/libc-alpha/2009-01/msg00000.html). gcc
seems to always provide such alignment for the call in
socketmodule.c:socket_gethostbyaddr(), but llvm-gcc (possibly only HEAD,
not 2.4) does not, which causes a segfault in test_socket.py. The llvm
bug investigating the problem is http://llvm.org/bugs/show_bug.cgi?id=3233.

The attached patch specifies the alignment so that llvm-gcc and unfixed
glibcs work together.

I'll commit this tomorrow if there are no objections.

----------
components: Extension Modules
files: fix_gethostbyaddr.patch
keywords: patch
messages: 79429
nosy: collinwinter, jyasskin
severity: normal
stage: patch review
status: open
title: Work around gethostbyaddr_r bug
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12654/fix_gethostbyaddr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4884>
_______________________________________

From report at bugs.python.org  Thu Jan  8 20:20:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 19:20:20 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231442420.08.0.995016614065.issue4868@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Attached patch adds acceleration for latin1 and utf16 decoding as well. 

All three codecs (utf8, utf16, latin1) are now in the same ballpark
performance-wise on favorable input: on my machine, they are able to
decode at almost 1GB/s.

(unpatched, it is between 150 and 500MB/s. depending on the codec)

Added file: http://bugs.python.org/file12655/decode5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 20:27:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 19:27:39 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231442859.06.0.306244062919.issue4868@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(PS : performance measured on UCS-2 and UCS-4 builds with gcc, and under
Windows with MSVC)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 20:37:38 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 08 Jan 2009 19:37:38 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231442420.08.0.995016614065.issue4868@psf.upfronthosting.co.za>
Message-ID: <496655FF.3030209@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Attached patch adds acceleration for latin1 and utf16 decoding as well. 
> 
> All three codecs (utf8, utf16, latin1) are now in the same ballpark
> performance-wise on favorable input: on my machine, they are able to
> decode at almost 1GB/s.
> 
> (unpatched, it is between 150 and 500MB/s. depending on the codec)
> 
> Added file: http://bugs.python.org/file12655/decode5.patch

A few style comments:

 * please use indented #pre-processor directives whenever possible, e.g.
   #if
   # define
   #else
   # define
   #endif

 * the conditions should only accept SIZE_OF_LONG == 4 and 8 and
   fail with an #error for any other value

 * you should use unsigned longs instead of signed ones

 * please use spaces around arithmetic operators, e.g. not a+b, but
   a + b

 * when calling functions with lots of parameters, put each parameter on
   a new line (e.g. for unicode_decode_call_errorhandler())

Please also add a comment somewhere to the bit masks explaining what
they do and how they are used. Verbose comments are always good to
have when doing optimizations such as these. Have a look at the
dictionary implementation for what I mean by this.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 21:18:13 2009
From: report at bugs.python.org (ndbecker)
Date: Thu, 08 Jan 2009 20:18:13 +0000
Subject: [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>


New submission from ndbecker <ndbecker2 at gmail.com>:

I'd like to suggest some improvements from mmap

1) mmap assign to slice only accepts a string.  This is unfortunate,
because AFAIK a string can only be created by copying data, and this is
wasteful for large data transfers.  mmap should accept any object
supporting buffer protocol as well as string.

2) buffer (mmap_obj) gives a read_only buffer.  There should be a way to
make this read_write.  I suggest 'as_buffer' member.

3) mmap_obj does not support weak ref.  This is needed for proper
lifetime management using boost::python

----------
components: Library (Lib)
messages: 79433
nosy: ndbecker
severity: normal
status: open
title: mmap enhancement request
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4885>
_______________________________________

From report at bugs.python.org  Thu Jan  8 21:38:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 20:38:01 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231447081.62.0.822569717399.issue4868@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Marc-Andre, this patch should address your comments.

Added file: http://bugs.python.org/file12656/decode6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 21:40:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 20:40:11 +0000
Subject: [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <1231447211.57.0.982711260348.issue4885@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As for 2), the buffer() function is deprecated and is replaced in 3.0 by
new object called memoryview() (together with a revamped internal API
for taking and releasing buffers).

----------
nosy: +pitrou
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4885>
_______________________________________

From report at bugs.python.org  Thu Jan  8 21:42:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 08 Jan 2009 20:42:06 +0000
Subject: [issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
In-Reply-To: <1231426590.2.0.669134378939.issue4880@psf.upfronthosting.co.za>
Message-ID: <1231447326.15.0.560856759043.issue4880@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think you should study the preprocessor output to find out what
LONG_MAX really expands to, at the point where it is used.

In any case, I'm tempted to close this as "works for me" - 0x7FFFFFFFL
is definitely a long constant in all compilers I know of.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4880>
_______________________________________

From report at bugs.python.org  Thu Jan  8 21:44:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 08 Jan 2009 20:44:35 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231447475.91.0.960582134502.issue4881@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you provide more details? What is the specific Python source code
that you are running, what operating system you run it one, what time
zone has been configured into your system, what output do you get, what
output do you expect?

Python definitely does support daylight saving time already just fine.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Thu Jan  8 21:55:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 20:55:38 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231448138.03.0.998422167344.issue4751@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There is still a potential problem.
Figure the following:
- thread A executes ENTER_HASHLIB while lock is NULL; therefore, thread
A has released the GIL and doesn't hold any lock
- thread B enters EVP_update with a large buffer (it can be there, since
A doens't hold the GIL)
- thread B allocates the lock, releases the GIL, and allocates the lock
- thread A continues running and arrives at LEAVE_HASHLIB; there,
self->lock is not NULL anymore, so it tries to release it; since it
hasn't acquired it before, this may block forever (depending on the
platform I assume)

To remove this possibility, the macros should probably look like:

    #define ENTER_HASHLIB(obj) \
        { \
            int __lock_exists = ((obj)->lock) != NULL; \
            if (__lock_exists) { \
                if (!PyThread_acquire_lock((obj)->lock, 0)) { \
                    Py_BEGIN_ALLOW_THREADS \
                    PyThread_acquire_lock((obj)->lock, 1); \
                    Py_END_ALLOW_THREADS \
                } \
            }

    #define LEAVE_HASHLIB(obj) \
            if (__lock_exists) { \
                PyThread_release_lock((obj)->lock); \
            } \
        }

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  8 21:59:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 20:59:46 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231448386.71.0.241117332317.issue4751@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, nevermind what I said. The GIL isn't released if obj->lock isn't
there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:03:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 21:03:49 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231448629.28.0.0649377254838.issue4751@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Haypo's last patch is ok. If you want it to be in 2.7 too, however,
you'll have to provide another patch (I won't do it myself).

----------
resolution:  -> accepted
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:18:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 21:18:14 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231449494.86.0.33579693857.issue4751@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed to py3k in r68411. Please tell me if you intend to do a patch
for 2.7. Otherwise, you/I can close the issue.

----------
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:21:26 2009
From: report at bugs.python.org (Michael Yang)
Date: Thu, 08 Jan 2009 21:21:26 +0000
Subject: [issue4886] test/regrtest.py contains error on __import__
In-Reply-To: <1231449686.43.0.781017317614.issue4886@psf.upfronthosting.co.za>
Message-ID: <1231449686.43.0.781017317614.issue4886@psf.upfronthosting.co.za>


New submission from Michael Yang <yangofzeal at gmail.com>:

I want to use the included test.regrtest (located in 
$pythondir/lib/python[ver]/test) to regression test some of my own 
scripts located in directory myDir.  The script has some nice 
configurability features to skip some tests based on machine 
configurations, etc. that a vanilla unittest suite doesn't include 
automatically.  However, it seems that the script regrtest.py has an 
error following the __import__ line.

Here's my setup:

/sample.py
/myDir
    /__init__.py
    /test_file1.py
    /test_file2.py
    /...

in sample.py:

{{{
#!python
#!/usr/bin/env python
import test.regrtest as rt
rt.main(tests = ['myDir.test_file1','myDir.test_file2'], \
quiet = False, verbose = True)
}}}

running sample.py yields:

{{{
#!sh
myDir.test_file1
myDir.test_file1 skipped -- No module named myDir.test_file1
myDir.test_file2
myDir.test_file2 skipped -- No module named myDir.test_file2
2 tests skipped:
    myDir.test_file1 myDir.test_file2
2 skips unexpected on win32:
    myDir.test_file1 myDir.test_file2
}}}

This is due to the code snippet in regrtest.py around line 554:

{{{
#!python
...
            if test.startswith('test.'):
                abstest = test
            else:
                # Always import it from the test package
                abstest = 'test.' + test
            the_package = __import__(abstest, globals(), locals(), [])
            the_module = getattr(the_package, test)
...
}}}

should be changed to:
{{{
#!python
...
            if test.startswith('test.'):
                abstest = test
                modName = test[len('test.'):]
            else:
                # Always import it from the test package
                abstest = 'test.' + test
                modName = test
            the_package = __import__(abstest, globals(), locals(), [])
            the_module = getattr(the_package, modName)
...
}}}

This way, the the_module will correctly find the module name in 
'the_package'.

A further recommendation: the main() module should be able to work with 
test directories with name other than 'test.*'.  Otherwise, users 
wishing to use the main() on other directories will have to name them 
'test.'  Depending on the user's directory's position in sys.path 
(before or after $pythondir/lib/python[ver]), regrtest.main() will 
either fail due to the 'from test import ...' statements being shadowed 
by the user's 'test' directory or the user's 'test' directory being 
shadowed by the standard library's.

----------
components: Library (Lib)
messages: 79442
nosy: msyang
severity: normal
status: open
title: test/regrtest.py contains error on __import__
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4886>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:21:45 2009
From: report at bugs.python.org (Michael Yang)
Date: Thu, 08 Jan 2009 21:21:45 +0000
Subject: [issue4886] test/regrtest.py contains error on __import__
In-Reply-To: <1231449686.43.0.781017317614.issue4886@psf.upfronthosting.co.za>
Message-ID: <1231449706.0.0.811859101471.issue4886@psf.upfronthosting.co.za>


Changes by Michael Yang <yangofzeal at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4886>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:22:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 21:22:36 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1231449756.39.0.0907447426411.issue3383@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, I did mean /usr/sbin at the time, but I don't remember why I said
that. However, I had access to Solaris and AIX machines back then, and
my comment may be related to finding out where objdump was on those
machines.

(sorry, I have a bad memory)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:24:52 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 08 Jan 2009 21:24:52 +0000
Subject: [issue3551] multiprocessing.Pipe terminates with
	ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
In-Reply-To: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>
Message-ID: <1231449892.17.0.332798207929.issue3551@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3551>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:25:28 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 08 Jan 2009 21:25:28 +0000
Subject: [issue3325] use of cPickle in multiprocessing
In-Reply-To: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za>
Message-ID: <1231449928.13.0.828083761402.issue3325@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3325>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:26:17 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 08 Jan 2009 21:26:17 +0000
Subject: [issue4065] _multiprocessing doesn't build on macosx 10.3
In-Reply-To: <1223376772.75.0.564119782301.issue4065@psf.upfronthosting.co.za>
Message-ID: <1231449977.33.0.205839533895.issue4065@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4065>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:30:23 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 08 Jan 2009 21:30:23 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1231450223.02.0.127242073531.issue4106@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:37:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jan 2009 21:37:05 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1231450625.79.0.7131362736.issue4705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If `PyObject_SetAttrString(raw, "_name", text)` fails, a reference to
raw is leaked.
Other than that, the patch looks good.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Thu Jan  8 22:52:12 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 08 Jan 2009 21:52:12 +0000
Subject: [issue4074] Building a list of tuples has non-linear performance
In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za>
Message-ID: <1231451532.85.0.0357943083828.issue4074@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Looking at gctrigger5.patch, my only thought is that it would be 
helpful for posterity to include more verbose comments about why this 
new behaviour was chosen; chunks of Martin's proposal from the 
referenced python-dev thread could be included verbatim.

Otherwise, LGTM.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4074>
_______________________________________

From report at bugs.python.org  Thu Jan  8 23:04:16 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Thu, 08 Jan 2009 22:04:16 +0000
Subject: [issue4751] Patch for better thread support in hashlib
In-Reply-To: <1230298756.92.0.632482701363.issue4751@psf.upfronthosting.co.za>
Message-ID: <1231452256.75.0.0803254460687.issue4751@psf.upfronthosting.co.za>


Lukas Lueg <knabberknusperhaus at yahoo.de> added the comment:

I'll do a patch for 2.7

----------
versions: +Python 2.7 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4751>
_______________________________________

From report at bugs.python.org  Thu Jan  8 23:06:31 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 08 Jan 2009 22:06:31 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231447081.62.0.822569717399.issue4868@psf.upfronthosting.co.za>
Message-ID: <496678E5.3090607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Marc-Andre, this patch should address your comments.
> 
> Added file: http://bugs.python.org/file12656/decode6.patch

Thanks. Much better !

BTW: I'd also change the variable name "word" to something
different, e.g. bitmap or just data. It looks too much like
a reserved word (which it isn't) ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Thu Jan  8 23:08:07 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 08 Jan 2009 22:08:07 +0000
Subject: [issue4887] environment inspection and manipulation API is buggy,
	inconsistent with "Python philosophy" for wrapping native APIs
In-Reply-To: <1231452487.08.0.408278867366.issue4887@psf.upfronthosting.co.za>
Message-ID: <1231452487.08.0.408278867366.issue4887@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

According to a recent thread on python-dev, Python APIs with the same
name as native APIs can be trusted to just pass through to the platform
API call
(<http://mail.python.org/pipermail/python-dev/2009-January/084899.html>). 
This isn't the case for the environment APIs in the os module.  For
example, os.getenv doesn't always return the actual value of a key in
the environment.  Instead, it looks in the os.environ pseudo-dict to get
the answer.  This can be wrong because os.environ is a *copy* of the
environment which any non-Python API will use, and as a copy it can get
out of sync with the real environment.  One way it can get out of sync
is via os.environ.pop (at least on POSIX - os.environ has different
implementations on different platforms, I find the way an implementation
is selected to be rather confusing and I have not tracked down the
precise behavior for all platforms):

>>> import os
>>> os.environ.pop('PATH')
'/home/exarkun/.local/sbin:/home/exarkun/.local/bin:/home/exarkun/Projects/combinator_paths/bincache:/home/exarkun/.local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games'
>>> os.getenv('PATH')
>>> os.system("echo $PATH")
/home/exarkun/.local/sbin:/home/exarkun/.local/bin:/home/exarkun/Projects/combinator_paths/bincache:/home/exarkun/.local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
0
>>> 

Another way is via calls to the platform environment manipulation APIs
(setenv, unsetenv or putenv).  These might be invoked by a third-party
library which is exposed to Python or via ctypes.

`environ? itself is a C API, though it's a char**, whereas os.environ is
a Python dict.  It's probably convenient for os.environ to remain as a
dict, since that's so much simpler to manipulate and inspect than the C
data structure used.  However, it'd be good if were always in sync with
the real process environment.  A good way to do this would probably be
to stop maintaining a copy of the environment and always pass through to
one of the platform APIs to satisfy a method call onto it.

----------
components: Library (Lib)
messages: 79448
nosy: exarkun
severity: normal
status: open
title: environment inspection and manipulation API is buggy, inconsistent with "Python philosophy" for wrapping native APIs
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4887>
_______________________________________

From report at bugs.python.org  Fri Jan  9 00:18:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Jan 2009 23:18:10 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1231456690.94.0.256174701586.issue4705@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch: clear raw on error
+	if (!Py_UnbufferedStdioFlag)
+		Py_XDECREF(raw);

Question: Should we use line_buffering in unbuffered mode?

Added file: http://bugs.python.org/file12657/unbufferedstdout-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Fri Jan  9 01:20:08 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Jan 2009 00:20:08 +0000
Subject: [issue4394] make the storage of the password optional in .pypirc
	(using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1231460408.35.0.269780108471.issue4394@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r68415

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________

From report at bugs.python.org  Fri Jan  9 03:01:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Jan 2009 02:01:26 +0000
Subject: [issue4876] Incorrect detection of module as local
In-Reply-To: <1231381613.0.0.23916695518.issue4876@psf.upfronthosting.co.za>
Message-ID: <1231466486.04.0.458485714328.issue4876@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r68422.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4876>
_______________________________________

From report at bugs.python.org  Fri Jan  9 03:24:36 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Jan 2009 02:24:36 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231467876.15.0.609653608957.issue4881@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Pablo,
As Martin says, Python does support DST changes. But it might not have
enough information about your timezone. If that's the case, take a look
at these links to see how adding (up-to-date) support for your tz can be
achieved:

Building a tzinfo class ->
http://svn.python.org/view/python/trunk/Doc/includes/tzinfo-examples.py?rev=62214&view=auto

Using the TZ environment variable ->
http://docs.python.org/dev/library/time.html#time.tzset

HTH, Daniel

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Fri Jan  9 05:52:14 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 09 Jan 2009 04:52:14 +0000
Subject: [issue4888] misplaced (or misleading) assert in ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

There is what I believe is a misplaced - or at least misleading - assert
in the while loop following the fast_block_end label.  If why != WHY_YIELD
before the loop starts I don't see how that relationship could change
within the loop.  Proposed patch against py3k branch attached.

(Yes, I realize this is trivial and that the assert is compiled away in
non-debug builds.)

----------
files: assert.diff
keywords: patch
messages: 79453
nosy: skip.montanaro
severity: normal
status: open
title: misplaced (or misleading) assert in ceval.c
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12658/assert.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4888>
_______________________________________

From report at bugs.python.org  Fri Jan  9 06:17:34 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 09 Jan 2009 05:17:34 +0000
Subject: [issue4888] misplaced (or misleading) assert in ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1231478254.38.0.14809785929.issue4888@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Sounds like a fine change to me.

----------
nosy: +jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4888>
_______________________________________

From report at bugs.python.org  Fri Jan  9 06:49:40 2009
From: report at bugs.python.org (Pratik Potnis)
Date: Fri, 09 Jan 2009 05:49:40 +0000
Subject: [issue4889] difflib
In-Reply-To: <1231480179.7.0.0322918194746.issue4889@psf.upfronthosting.co.za>
Message-ID: <1231480179.7.0.0322918194746.issue4889@psf.upfronthosting.co.za>


New submission from Pratik Potnis <pratik.potnis at gmail.com>:

While using function HtmlDiff() from Library difflib, if there is
difference in caps of two strings it does not provide proper diff results.
Two strings in two different files in this context that I used are:
hostname vaijain123 and (this string is in small caps)
hostname CAVANC1001CR1 (This one is in large caps)

Expected behavior after diffing : It should show hostname changed (and
highlight it with Yellow color)

instead of this it is showing Added in one file and deleted in another
file. (Highlighting them with green and red color respectively)

When tried with same caps (either small or large) it shows expected
behavior(highlighting the strings in yellow color). Also with numbers it
works well.

I think its an issue with the CAPS of letters. difflib is not able to
differentiate between the caps of letters.

----------
components: Library (Lib)
files: c1.ios
messages: 79455
nosy: pratik.potnis
severity: normal
status: open
title: difflib
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12659/c1.ios

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4889>
_______________________________________

From report at bugs.python.org  Fri Jan  9 08:23:43 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 07:23:43 +0000
Subject: [issue4888] misplaced (or misleading) assert in ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1231485823.32.0.52202355415.issue4888@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

IIRC, I think I put this here a long while ago when replacing or
removing a corresponding if-test that had always been compiled-in.  The
assertion was a way of validating that the refactoring and elimination
of tests had not broken anything.  If that was the case, I prefer to
leave this in, perhaps with some comment.  The control flow and known
conditions at each step are a bit hairy in this part of the code.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4888>
_______________________________________

From report at bugs.python.org  Fri Jan  9 09:40:03 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 09 Jan 2009 08:40:03 +0000
Subject: =?utf-8?q?[issue4863]_deprecate/delete=09distutils.mwerkscompiler...?=
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <1231490403.96.0.848978497172.issue4863@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4863>
_______________________________________

From report at bugs.python.org  Fri Jan  9 09:47:43 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 09 Jan 2009 08:47:43 +0000
Subject: [issue4889] difflib
In-Reply-To: <1231480179.7.0.0322918194746.issue4889@psf.upfronthosting.co.za>
Message-ID: <1231490863.79.0.783914835587.issue4889@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you be more precise?
I tried to reproduce your problem, but I only get added/deleted chunks,
nothing in yellow.

Please include a script that shows what you did, and the result you
expected.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4889>
_______________________________________

From report at bugs.python.org  Fri Jan  9 10:21:17 2009
From: report at bugs.python.org (Juha Rantanen)
Date: Fri, 09 Jan 2009 09:21:17 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1231492877.07.0.444456863425.issue4566@psf.upfronthosting.co.za>


Juha Rantanen <juha.rantanen at iki.fi> added the comment:

We encountered a problem that Windows installer created with 2.5.2 could
not be installed with 2.6.1 as executing the post-installer script
fails. More details about the reason can be found from
http://code.google.com/p/robotframework/issues/detail?id=196. Is the
problem related to this issue or should I create new issue about that. I
can also provide simple project that could be used to test this out.

----------
nosy: +rantanen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  9 11:23:49 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Fri, 09 Jan 2009 10:23:49 +0000
Subject: [issue4890] handling empty text search pattern in tkinter
In-Reply-To: <1231496629.01.0.458062958908.issue4890@psf.upfronthosting.co.za>
Message-ID: <1231496629.01.0.458062958908.issue4890@psf.upfronthosting.co.za>


New submission from Matthias Kievernagel <mkiever at web.de>:

Split this from issue 1581476 as suggested
 by Guilherme Polo (gpolo).

>Matthias: your issue about the pattern should be placed in a 
>different
>issue.

Quote of my original report:
(This is about the search function of the Text class in Tkinter.
 An IndexError is raised when pattern == '')
...
>In addition I get an IndexError, if I delete the
>last character of the search string.
>Does Tk allow calling search with an empty pattern?

>Tkinter could handle this (with a correct result)
>with the following change in Tkinter.py / Text.search():

>if pattern[0] == '-': args.append('--')
>->
>if pattern and pattern[0] == '-': args.append('--')

A further remark from Guilherme Polo (gpolo):

>For the suggestion about fixing the search method regarding the 
>pattern:
>the fix is almost fine, but we need to disallow None as a pattern.

I do not understand that remark. Is it to avoid the TclError?
Or because the exception changes (IndexError -> TclError)?
What do you want to do when pattern == None? Raise ValueError
or IndexError (as before)?

Appended slightly simplified demo program from issue 1581476
and a patch against trunk r68445.

Cheers,
Matthias Kievernagel
mkiever/at/web/dot/de

----------
components: Tkinter
files: text_search_pattern.py
messages: 79459
nosy: mkiever
severity: normal
status: open
title: handling empty text search pattern in tkinter
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12660/text_search_pattern.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4890>
_______________________________________

From report at bugs.python.org  Fri Jan  9 11:24:41 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Fri, 09 Jan 2009 10:24:41 +0000
Subject: [issue4890] handling empty text search pattern in tkinter
In-Reply-To: <1231496629.01.0.458062958908.issue4890@psf.upfronthosting.co.za>
Message-ID: <1231496681.11.0.746574239962.issue4890@psf.upfronthosting.co.za>


Changes by Matthias Kievernagel <mkiever at web.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12661/text_search_pattern.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4890>
_______________________________________

From report at bugs.python.org  Fri Jan  9 11:27:55 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Fri, 09 Jan 2009 10:27:55 +0000
Subject: [issue1581476] Text search gives bad count if called from variable
	trace
Message-ID: <1231496875.64.0.880177396443.issue1581476@psf.upfronthosting.co.za>


Matthias Kievernagel <mkiever at web.de> added the comment:

>Matthias: your issue about the pattern should be placed in a 
>different
>issue.

Done as Issue4890.
Appended a simplified copy of the demo program
and a patch there. I do not understand your remark
about None though (see new issue).

Cheers,
Matthias Kievernagel
mkiever/at/web/dot/de

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581476>
_______________________________________

From report at bugs.python.org  Fri Jan  9 12:04:39 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 11:04:39 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231499079.32.0.729203571142.issue1696199@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching an updated patch for Py2.7.

* Kept OP's simple constructor call but renamed it from counts() to
Counter():
     item_counts = Counter('acabbacba')
* Followed Guido's advice and avoided subclassing from defaultdict(). 
Instead, subclassed from dict, keeping its familiar API.
* Avoided KeyError issue by defining __missing__().
* Added most_common() method to address a principal use case --
patterned after Smalltalk's sortedByCount() method.
* Added elements() method requested by Alex Martelli -- patterned after
C++, Smalltalk, and Knuth's examples.
* Made necessary subclass overrides to dict methods: __repr__, update,
fromkeys, and copy.
* Wrote docstrings, doctests, and motivating examples.
* Verified that instances are copyable, deepcopyable, and picklable.

Working on docs and unittests.

Nice example (most common words in a text file):

>>> import re
>>> words = re.findall('\w+', open('hamlet.txt').read().lower())
>>> Counter(words).most_common(10)
[('the', 1143), ('and', 966), ('to', 762), ('of', 669), ('i', 631),
('you', 554), ('a', 546), ('my', 514), ('hamlet', 471), ('in', 451)]

----------
keywords: +patch
stage:  -> test needed
type:  -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.6
Added file: http://bugs.python.org/file12662/counter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Fri Jan  9 12:09:01 2009
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 09 Jan 2009 11:09:01 +0000
Subject: [issue4891] formatwarning function signature change breaks code
In-Reply-To: <1231499341.14.0.968854878286.issue4891@psf.upfronthosting.co.za>
Message-ID: <1231499341.14.0.968854878286.issue4891@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

External code that temporarily replaces warnings.formatwarning, a
technique used in IDLE and worked around (see issue 4043), is broken by
the addition of the optional parameter lineno to the formatwarning function.

While normal calls to functions can be "compatibly" extended with
additional optional parameters, that is not the case when the function
is substituted for, by matching its signature... if the signature is
extended, the code breaks on a Python upgrade, because the substituted
function doesn't know about the new parameter, and has fewer than are
being supplied by calls to the function.

Whether this is good, bad, documented, or appropriate, I don't know, but
it broke CherryPy 3.1.1 when running on Python 2.6, because of the new,
optional, lineno=None parameter to warnings.formatwarning



Not sure I have type and components right.  I'm a newbie.

This problem probably also applies to 3.0, but I don't have the
environment to test it there at present.

I first described this problem on python-dev and the suggestion was made
to put it here (remainder of this comment is a quote):

This formatwarning compatibility problem between 2.5 and 2.6 is a bug.
Please file a new issue for this.

-- Amaury Forgeot d'Arc

----------
components: Interpreter Core
messages: 79462
nosy: v+python
severity: normal
status: open
title: formatwarning function signature change breaks code
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4891>
_______________________________________

From report at bugs.python.org  Fri Jan  9 12:13:59 2009
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 09 Jan 2009 11:13:59 +0000
Subject: [issue4891] formatwarning function signature change breaks code
In-Reply-To: <1231499341.14.0.968854878286.issue4891@psf.upfronthosting.co.za>
Message-ID: <1231499639.45.0.380786580655.issue4891@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

For reference, the issue on the CherryPy tracker is #891 (amazing
numerical coincidence 891 there and 4891 here).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4891>
_______________________________________

From report at bugs.python.org  Fri Jan  9 12:46:07 2009
From: report at bugs.python.org (Henrik Gustafsson)
Date: Fri, 09 Jan 2009 11:46:07 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>


New submission from Henrik Gustafsson <henrik.gustafsson at purplescout.se>:

It seems the old pyprocessing (http://pyprocessing.berlios.de/) can do 
some things that the new multiprocessing package can not; 
sending/receiving connection objects for one.

This is a quite handy functionality, so it would be nice if it were 
reintroduced.

Also, the error message isn't very helpful.

Failing test below.


$ python2.6 pipetest2.py 
asdf
Traceback (most recent call last):
  File "a.py", line 10, in <module>
    print c1.recv()
TypeError: Required argument 'handle' (pos 1) not found

$ PYTHONPATH=processing-0.52-py2.5-macosx-10.5-i386.egg python2.5 
pipetest2.py 
asdf
Connection(handle=5)

$ PYTHONPATH=multiprocessing-2.6.0.2-py2.5-macosx-10.5-i386.egg 
python2.5 pipetest2.py 
asdf
Traceback (most recent call last):
  File "pipetest2.py", line 10, in <module>
    print c1.recv()
TypeError: function takes at least 1 argument (0 given)

$ uname -a
Darwin midori.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 
17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386

----------
components: Library (Lib), Macintosh
messages: 79464
nosy: gsson
severity: normal
status: open
title: Sending Connection-objects over multiprocessing connections fails
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Fri Jan  9 12:47:53 2009
From: report at bugs.python.org (Henrik Gustafsson)
Date: Fri, 09 Jan 2009 11:47:53 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1231501673.26.0.621070272444.issue4892@psf.upfronthosting.co.za>


Henrik Gustafsson <henrik.gustafsson at purplescout.se> added the comment:

$ cat pipetest2.py 
try:
	from multiprocessing import Pipe
except ImportError:
	from processing import Pipe

c1, c2 = Pipe(duplex=False)
c2.send('asdf')
print c1.recv()
c2.send(c1)
print c1.recv()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Fri Jan  9 13:01:37 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 09 Jan 2009 12:01:37 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

There is a separate file thread_wince.h for use with CE, but that is
firstly not used due to a missing macro definition and secondly it
doesn't compile as it is. The attached patch defines WINCE_THREADS for
CE and makes the file at least compile.

Note that this doesn't touch any working code, because the CE port is
currently broken anyway. Further, the changes compile, but since there
are various other bits and pieces still missing, it is impossible to
test it yet.

----------
components: Interpreter Core
files: python-2.7-wince-threads.0.patch
keywords: patch
messages: 79466
nosy: eckhardt
severity: normal
status: open
title: Use separate thread support code under MS Windows CE
versions: Python 2.7
Added file: http://bugs.python.org/file12663/python-2.7-wince-threads.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Fri Jan  9 13:14:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 12:14:15 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231503255.44.0.192720472853.issue1696199@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Added a few more in-module tests.

Added file: http://bugs.python.org/file12664/counter2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Fri Jan  9 13:14:26 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 12:14:26 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231503266.26.0.782095243053.issue1696199@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12662/counter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Fri Jan  9 14:01:35 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 13:01:35 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231506095.98.0.496225013178.issue1696199@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file12665/counter3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Fri Jan  9 14:02:42 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 13:02:42 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231506162.97.0.486673728634.issue1696199@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12664/counter2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Fri Jan  9 14:58:36 2009
From: report at bugs.python.org (mroman)
Date: Fri, 09 Jan 2009 13:58:36 +0000
Subject: [issue4894] documentaion doesn't include parameter in
	urllib.request.HTTPRedirectHandler.redirect_request
In-Reply-To: <1231509516.06.0.732679259028.issue4894@psf.upfronthosting.co.za>
Message-ID: <1231509516.06.0.732679259028.issue4894@psf.upfronthosting.co.za>


New submission from mroman <mroman at eduapple.pl>:

documentaion doesn't include parameter in 
urllib.request.HTTPRedirectHandler.redirect_request

http://docs.python.org/3.0/library/urllib.request.html#urllib.request.HT
TPRedirectHandler.redirect_request

says:
HTTPRedirectHandler.redirect_request(req, fp, code, msg, hdrs)

while code says:
    def redirect_request(self, req, fp, code, msg, headers, newurl):

----------
assignee: georg.brandl
components: Documentation
messages: 79468
nosy: georg.brandl, mroman, quiver
severity: normal
status: open
title: documentaion doesn't include parameter in urllib.request.HTTPRedirectHandler.redirect_request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4894>
_______________________________________

From report at bugs.python.org  Fri Jan  9 15:15:04 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 09 Jan 2009 14:15:04 +0000
Subject: [issue4895] Missing strdup() under MS Windows CE
In-Reply-To: <1231510504.25.0.240511707312.issue4895@psf.upfronthosting.co.za>
Message-ID: <1231510504.25.0.240511707312.issue4895@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

CE6 doesn't provide strdup() but provides an equivalent _strdup() in
stdlib.h. The attached patch simply #defines strdup _strdup after
including said header file.

----------
components: Interpreter Core
files: python-2.7-wince-strdup.0.patch
keywords: patch
messages: 79469
nosy: eckhardt
severity: normal
status: open
title: Missing strdup() under MS Windows CE
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file12666/python-2.7-wince-strdup.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4895>
_______________________________________

From report at bugs.python.org  Fri Jan  9 15:31:53 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 09 Jan 2009 14:31:53 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <18791.24525.745699.580609@montanaro.dyndns.org>


New submission from Skip Montanaro <skip at pobox.com>:

The why_code enum in ceval.c has values which form a bit set.  Comparison of
the why variable against multiple values is going to be faster using bitwise
operations instead of logical ones.  For example, instead of

    why == WHY_RETURN || why == WHY_CONTINUE

the equivalent bitwise expression is

    why & (WHY_RETURN | WHY_CONTINUE)

which has fewer operations (one vs three treating the rhs of & as a
constant).  This is already done in one place.  The attached patch converts
all other expressions of the first form.

Also, there are some further manipulations of why in the loop after the
fast_block_end.  The loop can only be entered if why != WHY_NOT.  In the
loop when it is set to WHY_NOT, the loop breaks.  There is thus no reason to
test its value in the while expression.  Further, instead of just breaking
from the loop and then checking the why != WHY_NOT again, just jump past
that check by adding a why_not_here label.

The attached patch implements these changes (against the py3k branch).  All
tests pass on my Mac except test_cmd_line (which has been failing for
awhile).

Skip

----------
files: unnamed
messages: 79470
nosy: skip.montanaro
severity: normal
status: open
title: Faster why variable manipulation in ceval.c
Added file: http://bugs.python.org/file12667/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: application/octet-stream
Size: 2431 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090109/72c62241/attachment.obj>

From report at bugs.python.org  Fri Jan  9 15:36:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 14:36:55 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231511815.54.0.635134931704.issue1696199@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some comments:
- Counter sounds like a really strange name for a container. Why not
call it "Bag" or "Multiset" (or "CountingSet"?)
- why are the unittests inline rather than in Lib/test? inline tests
don't get executed by the buildbots, nor by people running the test
suite at home

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Fri Jan  9 15:52:16 2009
From: report at bugs.python.org (garcia)
Date: Fri, 09 Jan 2009 14:52:16 +0000
Subject: [issue4897] PyIter_Next documentation inconsistent with implementation
In-Reply-To: <1231512736.18.0.593919226046.issue4897@psf.upfronthosting.co.za>
Message-ID: <1231512736.18.0.593919226046.issue4897@psf.upfronthosting.co.za>


New submission from garcia <ronald.garcia at rice.edu>:

The documentation for PyIter_Next says it will raise TypeError if the 
object passed to it is not an iterator.  However, the implementation in 
abstract.c performs an assert rather than raising TypeError.  I would 
prefer if the implementation were adjusted to match the documentation 
rather than vice-versa.

----------
components: None
messages: 79472
nosy: garcia
severity: normal
status: open
title: PyIter_Next documentation inconsistent with implementation
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4897>
_______________________________________

From report at bugs.python.org  Fri Jan  9 16:38:13 2009
From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=)
Date: Fri, 09 Jan 2009 15:38:13 +0000
Subject: [issue4898] {context,
	unified}_diff add spurious trailing whitespace if
	fromfiledate/tofiledate are emptyk
In-Reply-To: <1231515492.91.0.948855864536.issue4898@psf.upfronthosting.co.za>
Message-ID: <1231515492.91.0.948855864536.issue4898@psf.upfronthosting.co.za>


New submission from Adeodato Sim? <dato at net.com.org.es>:

Hello.

I recently noticed that Bazaar's unified_diff() was emiting ---/+++ 
lines with a trailing whitespace if fromfiledate/tofiledate were the 
empty string. (Which was bad because a program to detect spurious 
trailing whitespace in diffs would flag them as errors.)

A patch [1] was committed recently in their tree. During the 
discussion, it was pointed out that the affected function was a copy 
of Python's own unified_diff() in difflib, which suffered the same 
problem.

  [1]: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3923

I'm now attaching a patch to fix this issue in Python. It'd be great 
if you'd consider applying it. (It seems that the correct character to 
separate dates is a tab and not a space; if you feel changing this is 
breaking backwards compatibility, feel free to s/\t/ / in my patch.)

Thanks.

----------
components: Library (Lib)
files: python_difflib_fix.diff
keywords: patch
messages: 79473
nosy: dato, jameinel
severity: normal
status: open
title: {context,unified}_diff add spurious trailing whitespace if fromfiledate/tofiledate are emptyk
type: behavior
Added file: http://bugs.python.org/file12668/python_difflib_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4898>
_______________________________________

From report at bugs.python.org  Fri Jan  9 16:45:00 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 09 Jan 2009 15:45:00 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1231515900.9.0.480846921183.issue4892@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Fri Jan  9 16:45:33 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 09 Jan 2009 15:45:33 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1231515933.2.0.44756670938.issue4892@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

thanks for filing this. I'll need to compare the two code bases and figure 
out why it's either regressed, or Richard removed it prior to the 
integration.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Fri Jan  9 16:51:55 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 09 Jan 2009 15:51:55 +0000
Subject: [issue4888] misplaced (or misleading) assert in ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1231516315.92.0.943587292639.issue4888@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't see why the refactoring has to maintain the same logic bug as
the original.  I'm with Skip & Jeffrey.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4888>
_______________________________________

From report at bugs.python.org  Fri Jan  9 17:14:50 2009
From: report at bugs.python.org (Pablo Castagnino)
Date: Fri, 09 Jan 2009 16:14:50 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231517690.07.0.341472921956.issue4881@psf.upfronthosting.co.za>


Pablo Castagnino <pablo.castagnino at gmail.com> added the comment:

Ok, first of all I want to say I'm no Python programmer/developer.
However, I recently posted a 'bug' for a Linux/Windows program I'm using
very much which is based in Python. The program is called Anki and it's
designed to help you remember facts (such as words and phrases in a
foreign language) as easily, quickly and efficiently as possible.

Here, http://code.google.com/p/anki/issues/detail?id=613, you'll find my
explanation of the 'bug'.

Briefly, I live in Argentina and the current administration has changed
current time because of 'daylight saving'. However, when syncing my
decks (which store all my cards) with Anki's server, it tells me my
current time is wrong and that I need to change it. In fact, it's not MY
clock which is wrong, but Anki's. So, I posted this bug and the
developer, as you can see, told me that: it's not really anki's job - a
setting to shift the clock would need changes all throughout the code.
probably something in python's timezone handling needs to be updated.
could you post about the daylight savings issue on the python mailing
list and see what they say? So, this is what I'm doing. 

Right now I will notify the developer of this program that, actually,
Python already handles 'time saving'.

Thanks for your help. Any other comments/ideas would be greatly appreciated.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Fri Jan  9 17:19:00 2009
From: report at bugs.python.org (Giovanni)
Date: Fri, 09 Jan 2009 16:19:00 +0000
Subject: [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>


New submission from Giovanni <dalloliogm at gmail.com>:

The doctest module should have support for fixtures (e.g. setUp and
tearDown methods).

It is very silly to be forced to always re-import all the modules needed
in every function tested with doctest.
For example, when you have to document functions that open files, you
have to import StringIO or TempFile, and then create a file, while this
could be done easily with a fixture.

----------
components: Tests
messages: 79477
nosy: dalloliogm
severity: normal
status: open
title: doctest should support fixtures
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4899>
_______________________________________

From report at bugs.python.org  Fri Jan  9 18:05:16 2009
From: report at bugs.python.org (mark pennock)
Date: Fri, 09 Jan 2009 17:05:16 +0000
Subject: [issue4900] Can't Locate File with No Capital in Name
Message-ID: <1231520716.63.0.978266493814.issue4900@psf.upfronthosting.co.za>


Changes by mark pennock <markpennock at motorola.com>:


----------
components: None
nosy: markpennock
severity: normal
status: open
title: Can't Locate File with No Capital in Name
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4900>
_______________________________________

From report at bugs.python.org  Fri Jan  9 18:09:27 2009
From: report at bugs.python.org (mark pennock)
Date: Fri, 09 Jan 2009 17:09:27 +0000
Subject: [issue4900] Can't Locate File with No Capital in Name
In-Reply-To: <1231520967.76.0.559191938843.issue4900@psf.upfronthosting.co.za>
Message-ID: <1231520967.76.0.559191938843.issue4900@psf.upfronthosting.co.za>


New submission from mark pennock <markpennock at motorola.com>:

error reading files in python 2.5

reports files don't exist under certain conditions

*Doesn't Work Code*
f = open("D:\test.html", "r").read()

*Does Work Code*
(Change file name and retry)

f = open("D:\Test.html", "r").read()

*Comments*
i tried different file types and names all of which made no difference.
When I copied the file (Windows XP) of the file it automatically adds
"Copy of" to the name. I then narrowed it down to the Capital letter in
the name.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4900>
_______________________________________

From report at bugs.python.org  Fri Jan  9 18:12:48 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 09 Jan 2009 17:12:48 +0000
Subject: [issue4900] Can't Locate File with No Capital in Name
In-Reply-To: <1231520967.76.0.559191938843.issue4900@psf.upfronthosting.co.za>
Message-ID: <1231521168.34.0.665991332469.issue4900@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

"\t" is a tab while "\T" is (I think) just an ugly equivalent to "T". 
Use either of

  r"D:\test.html" 
  "D:\\test.html"

Please check if that is the reason for your failure.

----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4900>
_______________________________________

From report at bugs.python.org  Fri Jan  9 18:16:18 2009
From: report at bugs.python.org (mark pennock)
Date: Fri, 09 Jan 2009 17:16:18 +0000
Subject: [issue4900] Can't Locate File with No Capital in Name
In-Reply-To: <1231521168.34.0.665991332469.issue4900@psf.upfronthosting.co.za>
Message-ID: <E0943CC819E4BE4690E03EFAEDBD7DEF1232956B14@ct11exm84.ds.mot.com>


mark pennock <markpennock at motorola.com> added the comment:

Your right! Thanks a lot, I am obviously a newbie.....

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4900>
_______________________________________

From report at bugs.python.org  Fri Jan  9 18:38:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Jan 2009 17:38:09 +0000
Subject: [issue4897] PyIter_Next documentation inconsistent with implementation
In-Reply-To: <1231512736.18.0.593919226046.issue4897@psf.upfronthosting.co.za>
Message-ID: <1231522689.86.0.976057432881.issue4897@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Closing a duplicate of #3720.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed
superseder:  -> segfault in for loop with evil iterator

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4897>
_______________________________________

From report at bugs.python.org  Fri Jan  9 18:40:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Jan 2009 17:40:06 +0000
Subject: [issue4900] Can't Locate File with No Capital in Name
In-Reply-To: <1231520967.76.0.559191938843.issue4900@psf.upfronthosting.co.za>
Message-ID: <1231522806.82.0.523588360651.issue4900@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4900>
_______________________________________

From report at bugs.python.org  Fri Jan  9 18:53:26 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Jan 2009 17:53:26 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1231523606.78.0.699474083289.issue4896@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Neat, gives a 10% speedup on a Celeron M with gcc 4.2.

----------
nosy: +ajaksu2
versions: +Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12669/gcc_4.2.4_linux_ia32_bench.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Fri Jan  9 19:31:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 18:31:22 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1231525882.18.0.949914448889.issue4896@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I get a 3% speedup on x86-64 with gcc 4.3.2.
The label "why_not_here" should be renamed to something more meaningful
IMO. Or you could just kill the label and use "continue" instead.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Fri Jan  9 19:40:11 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 09 Jan 2009 18:40:11 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <1231525882.18.0.949914448889.issue4896@psf.upfronthosting.co.za>
Message-ID: <18791.39431.870761.751787@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> The label "why_not_here" should be renamed to something more
    Antoine> meaningful IMO. Or you could just kill the label and use
    Antoine> "continue" instead.

I thought "why_not_here" was meaningful.  "Here" is where you go when why ==
WHY_NOT.  I don't think continue will work.  The goto is coming out of an
inner loop.  If you continue from there you just continue the inner loop.  I
replaced a break with a goto.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Fri Jan  9 19:45:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 18:45:07 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1231526707.86.0.952935467471.issue4705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> accepted
stage: patch review -> commit review
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Fri Jan  9 19:51:17 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 09 Jan 2009 18:51:17 +0000
Subject: [issue4884] Work around gethostbyaddr_r bug
In-Reply-To: <1231441695.4.0.529827841073.issue4884@psf.upfronthosting.co.za>
Message-ID: <1231527077.62.0.263034840788.issue4884@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Committed as r68450.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4884>
_______________________________________

From report at bugs.python.org  Fri Jan  9 19:55:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 18:55:58 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.39431.870761.751787@montanaro.dyndns.org>
Message-ID: <1231527372.13806.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I thought "why_not_here" was meaningful.

I don't know, when I see "goto why_not_here" it looks like a joke to
me :)

> I don't think continue will work.  The goto is coming out of an
> inner loop.  If you continue from there you just continue the inner loop.

Oops, sorry for misguided advice.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Fri Jan  9 19:56:17 2009
From: report at bugs.python.org (garcia)
Date: Fri, 09 Jan 2009 18:56:17 +0000
Subject: [issue4901] inconsistent API docs for tp_iter
In-Reply-To: <1231527377.73.0.506480870476.issue4901@psf.upfronthosting.co.za>
Message-ID: <1231527377.73.0.506480870476.issue4901@psf.upfronthosting.co.za>


New submission from garcia <ronald.garcia at rice.edu>:

Page 107 of api.pdf says that Py_TPFLAGS_HAVE_ITER is set if the type 
object has the tp_iter and tp_iternext fields, but on page 109, preceding 
the documentation of tp_iter and tp_iternext, it says "the next two fields 
only exist if the Py_TPFLAGS_HAVE_CLASS flag bit is set".

Should the latter refer to Py_TPFLAGS_HAVE_ITER?

----------
assignee: georg.brandl
components: Documentation
messages: 79487
nosy: garcia, georg.brandl
severity: normal
status: open
title: inconsistent API docs for tp_iter
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4901>
_______________________________________

From report at bugs.python.org  Fri Jan  9 19:59:39 2009
From: report at bugs.python.org (garcia)
Date: Fri, 09 Jan 2009 18:59:39 +0000
Subject: [issue4897] PyIter_Next documentation inconsistent with implementation
In-Reply-To: <1231512736.18.0.593919226046.issue4897@psf.upfronthosting.co.za>
Message-ID: <1231527579.96.0.0516931520218.issue4897@psf.upfronthosting.co.za>


garcia <ronald.garcia at rice.edu> added the comment:

Thanks for the quick response.  I see that the discussion in 3720 
implicitly involves the implementation of PyIter_Next, but the 
documentation for PyIter_Next (and its conflict with the implementation) 
is not mentioned.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4897>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:00:58 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Jan 2009 19:00:58 +0000
Subject: [issue4897] PyIter_Next documentation inconsistent with implementation
In-Reply-To: <1231512736.18.0.593919226046.issue4897@psf.upfronthosting.co.za>
Message-ID: <1231527658.11.0.0279142738362.issue4897@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The reason I linked to that issue is that the proposed patch brings the
implementation inline with the documentation as you wished. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4897>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:15:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 19:15:24 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1231528524.94.0.403889374498.issue4705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r68451. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:34:39 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 19:34:39 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1231492877.07.0.444456863425.issue4566@psf.upfronthosting.co.za>
Message-ID: <4967A6CD.8020300@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is the problem related to this issue or should I create new issue about that. 

You should assume that it is not related.

> I can also provide simple project that could be used to test this out.

That would be necessary.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:40:59 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 19:40:59 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231530059.83.0.0710759422169.issue4893@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So perhaps it is better to use thread_nt.h now on WinCE?

Mark?

----------
nosy: +loewis, mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:48:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 19:48:05 +0000
Subject: [issue4898] {context,
	unified}_diff add spurious trailing whitespace if
	fromfiledate/tofiledate are emptyk
In-Reply-To: <1231515492.91.0.948855864536.issue4898@psf.upfronthosting.co.za>
Message-ID: <1231530485.66.0.508304955523.issue4898@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Who is the author of this patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4898>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:51:51 2009
From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=)
Date: Fri, 09 Jan 2009 19:51:51 +0000
Subject: [issue4898] {context,
	unified}_diff add spurious trailing whitespace if
	fromfiledate/tofiledate are emptyk
In-Reply-To: <1231530485.66.0.508304955523.issue4898@psf.upfronthosting.co.za>
Message-ID: <20090109195148.GA21546@chistera.yi.org>


Adeodato Sim? <dato at net.com.org.es> added the comment:

> Who is the author of this patch?

I am the author of the patch attached to this bug report.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4898>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:52:59 2009
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 09 Jan 2009 19:52:59 +0000
Subject: [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231530779.73.0.818206141585.issue4899@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

I disagree.  Purpose of __doc__ is to explain functionality all at once.
This command idiom is useful:

$ python -c 'from a_module import thing; help(thing)'

The doctest module is a lightweight nicety that helps verify that which
is suitable.  The sufficiently simple algorithms of my code have doc
strings that are the complete test and explanation.  For others I
provide both docstring and unit tests.  But with many I explain the
arguments and output, possibly the algorithm in a doc string.  Tests and
use case examples reside in the module's unit test.

I'm among the "Choose correct tool for the job.  python comes with full
tool bag." group.

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4899>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:55:08 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 19:55:08 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231530908.51.0.159515162006.issue4881@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For Windows (what version are you using?), you need to install
Microsoft's time zone patches, e.g. the one described in

http://support.microsoft.com/kb/951072

Depending on the exact version of Windows that you use, and depending on
whether or not you run Windows update regularly, your system may or may
not have that patch installed.

Same for Linux, except that I can't point to a single update. What
precise Linux distribution are you using? Have you installed their time
zone updates?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:56:01 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 19:56:01 +0000
Subject: [issue4888] misplaced (or misleading) assert in ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1231530961.06.0.530990485926.issue4888@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I wasn't opposing the patch.  Just wanted to look back at why the
assertion was put there in the first place.  If you want it in, go ahead.

----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4888>
_______________________________________

From report at bugs.python.org  Fri Jan  9 20:59:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 19:59:10 +0000
Subject: [issue4604] close() seems to have limited effect
In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za>
Message-ID: <1231531150.95.0.760892447108.issue4604@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Expanded the test a bit and committed the patch in r68454. Thanks!

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4604>
_______________________________________

From report at bugs.python.org  Fri Jan  9 21:04:09 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 09 Jan 2009 20:04:09 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231531449.54.0.953775565505.issue3582@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed this as revision: 68455

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Fri Jan  9 21:08:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 20:08:25 +0000
Subject: [issue4604] close() seems to have limited effect
In-Reply-To: <1228781481.66.0.10678075439.issue4604@psf.upfronthosting.co.za>
Message-ID: <1231531705.41.0.0337575795145.issue4604@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: accepted -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4604>
_______________________________________

From report at bugs.python.org  Fri Jan  9 21:11:30 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 09 Jan 2009 20:11:30 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1231531890.14.0.422052259712.issue3677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Checked in as revision: 68457

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Fri Jan  9 21:24:47 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 09 Jan 2009 20:24:47 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <1231527372.13806.1.camel@localhost>
Message-ID: <18791.45707.388507.96085@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

>> I thought "why_not_here" was meaningful.

    Antoine> I don't know, when I see "goto why_not_here" it looks like a
    Antoine> joke to me :)

Well, I think the enum name WHY_NOT is kind of a joke itself, but it's been
that way for so long I see no reason to change it.  I'll add a comment to
the label which describes the intent in plain(er) English.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Fri Jan  9 21:27:41 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 09 Jan 2009 20:27:41 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1231532861.21.0.201234428466.issue4336@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Checked in revision: 68458 and  
revision: 68459

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Fri Jan  9 21:29:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 20:29:21 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231532961.78.0.364990946665.issue3582@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Windows NT (3.1, and a number of later versions) only support 64 TLS
keys. Starting with Windows 2000, they added another page per thread for
TLS, giving an addition 1024 TLS slots, for a total of 1088 TLS slots.
FWIW, Win 9.x supported 80 TLS slots. See

http://www.nynaeve.net/?p=181
http://msdn.microsoft.com/en-us/library/ms686749.aspx
http://bugs.python.org/file11141/thread_nt.patch

TLS slots are typically considered a scarce resource, so that
programming language implementations typically don't allow applications
direct allocation of TLS slots. Instead, most runtimes I know of will
allocate a single TLS slot for themselves, which then is filled with an
array or a dictionary.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Fri Jan  9 21:31:52 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 09 Jan 2009 20:31:52 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231533112.42.0.0541434767761.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Checked in as revision: 68460

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:02:20 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 09 Jan 2009 21:02:20 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231534940.02.0.716608614717.issue4753@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Paolo,
Applying your patches makes no difference with gcc 4.2 and gives a
barely noticeable (~2%) slowdown with icc. These results are from a
Celeron M 410 (Core Solo Yonah-based), so it's a rather old platform to
run benchmarks on.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:08:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 21:08:26 +0000
Subject: [issue4074] Building a list of tuples has non-linear performance
In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za>
Message-ID: <1231535306.45.0.568960701194.issue4074@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch with updated comments.

Added file: http://bugs.python.org/file12670/gctrigger6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4074>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:12:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 21:12:20 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1231533112.42.0.0541434767761.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231535554.13806.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
> 
> Checked in as revision: 68460

Looks like you forgot the unit tests!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:15:13 2009
From: report at bugs.python.org (Aki)
Date: Fri, 09 Jan 2009 21:15:13 +0000
Subject: [issue4902] failed to build ctypes in Python2.6.1 (even with gcc)
In-Reply-To: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>
Message-ID: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>


New submission from Aki <akineko at users.sourceforge.net>:

I'm trying to build Python 2.6.1 on Solaris/x86 machine but it puked.

gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/home/neko/gnu/Python-2.6.1/./Include
-Ibuild/temp.solaris-2.10-i86pc-2.6/libffi/include
-Ibuild/temp.solaris-2.10-i86pc-2.6/libffi
-I/home/neko/gnu/Python-2.6.1/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/home/neko/gnu/Python-2.6.1/Include
-I/home/neko/gnu/Python-2.6.1 -c
/home/neko/gnu/Python-2.6.1/Modules/_ctypes/libffi/src/x86/sysv.S -o
build/temp.solaris-2.10-i86pc-2.6/home/neko/gnu/Python-2.6.1/Modules/_ctypes/libffi/src/x86/sysv.o
Assembler:
    "/usr/tmp/ccF9sUxS.s", line 215 : Syntax error
    Near line: " movl ((10 + 3) & ~3)(%eax), %esi"
    "/usr/tmp/ccF9sUxS.s", line 215 : Illegal character: <7e>
    "/usr/tmp/ccF9sUxS.s", line 216 : Syntax error
    Near line: " movl ((((10 + 3) & ~3) + 4) + 4)(%eax), %edx"
    "/usr/tmp/ccF9sUxS.s", line 216 : Illegal character: <7e>
    "/usr/tmp/ccF9sUxS.s", line 223 : Syntax error
    Near line: " call *(((10 + 3) & ~3) + 4)(%eax)"
    "/usr/tmp/ccF9sUxS.s", line 223 : Illegal character: <7e>

Failed to build these modules:
_ctypes            _curses            _curses_panel

//

I'm using gcc 3.4.6 and Solaris 10/x86.

I try to identify the problem but I couldn't figure out what went wrong.
I'm using Python 2.6.1 on Solaris/SPARC and I didn't see any problem.

----------
messages: 79508
nosy: akineko
severity: normal
status: open
title: failed to build ctypes in Python2.6.1 (even with gcc)
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4902>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:18:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 21:18:53 +0000
Subject: [issue4902] failed to build ctypes in Python2.6.1 (even with gcc)
In-Reply-To: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>
Message-ID: <1231535933.46.0.831975934314.issue4902@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Run the gcc command line with --save-temps (-fsave-temps if the former
doesn't work), and inspect the assembler file around the line where the
assembler complains. Is this inline assembler code possibly?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4902>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:26:58 2009
From: report at bugs.python.org (Collin Winter)
Date: Fri, 09 Jan 2009 21:26:58 +0000
Subject: [issue4074] Building a list of tuples has non-linear performance
In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za>
Message-ID: <1231536418.98.0.996875618224.issue4074@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

LGTM. Go ahead and commit this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4074>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:36:23 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 09 Jan 2009 21:36:23 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231536983.75.0.926112606086.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I indeed forgot the unittests and docs.
They are now in, in revision: 68461

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:36:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 21:36:45 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231537005.8.0.813817689101.issue1696199@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The counts/counter moniker emerged from the python-dev discussion and
I'm basically happy with it since the typical usage is c=Counter(myseq)
with no other non-dict accesses (mostly just c[elem]+=1 and print
c[elem]).  It's a simple counter with a dict interface so the name
shouldn't suggest anything more complicated than that.

To me, MultiSet or CountingSet is too offputtingly computer-sciency and
misleadingly suggests a set-like API instead of a dict interface. I know
several programmers who don't know the terms, bag or multiset, but they
intuitively understand what a counter does.  Am open to calling it a Bag
but I rather like the self-descriptiveness and simplicity of Counter.  

As noted previously, standalone unittests are forthcoming (and a doc
patch).  Wanted to get the API and sample use cases worked-out first.

Thanks for looking at the initial patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:40:28 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 21:40:28 +0000
Subject: [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231537228.35.0.219542054435.issue4899@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with David.  This is not in the spirit of the doc test module.
 We already have the heavy-weight unittest module as an alternative when
more firepower is needed.  Also, adding more infra-structure to the this
already lengthy module will make it harder to learn, use, and remember.

Tim, I recommend rejecting this request.

----------
assignee:  -> tim_one
nosy: +rhettinger, tim_one
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4899>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:41:46 2009
From: report at bugs.python.org (Aki)
Date: Fri, 09 Jan 2009 21:41:46 +0000
Subject: [issue4902] failed to build ctypes in Python2.6.1 (even with gcc)
In-Reply-To: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>
Message-ID: <1231537306.28.0.945462757103.issue4902@psf.upfronthosting.co.za>


Aki <akineko at users.sourceforge.net> added the comment:

Hello Martin,

Thank you for your prompt response.
I recompiled the source with --save-temps.
I examined the assembler source and found that it was complaining about '~'!

movl ((((10 + 3) & ~3) + 4) + 4)(%eax), %edx
                   ^ this one

The source was compiled and assembled through 'gcc'.
But I don't see gas in my machine so that I assumed it was assembled by
as (Sun's assembler) and as seems not supporting '~'.

I will try several things, such as installing gas to my machine.
I will update when I have something to report.

Thank you!
Aki-

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4902>
_______________________________________

From report at bugs.python.org  Fri Jan  9 22:55:39 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Jan 2009 21:55:39 +0000
Subject: [issue4857] syntax: no unpacking in augassign
In-Reply-To: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>
Message-ID: <1231538139.08.0.229980756913.issue4857@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The grammar in the doc is not the one used to generate the
parser/compiler.  The former is meant to be easier for humans to read,
the latter easier for the parser generator.  Neither completely embody
Python's syntax rules.  Additional restrictions may be applied later in
the chain.  From:
http://svn.python.org/view/python/trunk/Grammar/Grammar?rev=65872&view=auto

expr_stmt: testlist (augassign (yield_expr|testlist) |
                     ('=' (yield_expr|testlist))*)

augassign: ('+=' | '-=' | '*=' | '/=' | '%=' | '&=' | '|=' | '^=' |
            '<<=' | '>>=' | '**=' | '//=')
# For normal assignments, additional restrictions enforced by the
interpreter

Perhaps that should say "For augmented assignments....

Except maybe for the comment above, I think this issue can be closed.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4857>
_______________________________________

From report at bugs.python.org  Fri Jan  9 23:00:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 22:00:07 +0000
Subject: [issue4902] failed to build ctypes in Python2.6.1 (even with gcc)
In-Reply-To: <1231537306.28.0.945462757103.issue4902@psf.upfronthosting.co.za>
Message-ID: <4967C8E4.5050504@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> movl ((((10 + 3) & ~3) + 4) + 4)(%eax), %edx

I'm really puzzled; gcc would normally not generate assembler code
like this. Instead, with the expression being constant, gcc should
normally compute its result, and fill that into the assembler code.

To study this further, one would need to compare preprocessor output
and assembler output, to correlate them.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4902>
_______________________________________

From report at bugs.python.org  Fri Jan  9 23:14:37 2009
From: report at bugs.python.org (Aki)
Date: Fri, 09 Jan 2009 22:14:37 +0000
Subject: [issue4902] failed to build ctypes in Python2.6.1 (even with gcc)
In-Reply-To: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>
Message-ID: <1231539277.8.0.493499400949.issue4902@psf.upfronthosting.co.za>


Aki <akineko at users.sourceforge.net> added the comment:

I have installed GNU binutil package to my machine to use GNU as.
I re-run configure but configure somehow always found Sun as rather than
GNU as even I saw GNU as first from my csh environment.

I temporalily renamed Sun as so that configure was forced to use GNU as.
With such brute force trick, I finally managed to build Python 2.6.1 on
Solaris/x86.

It would be nice if ctypes module and configure handle this elegantly
and amicably, instaed of arguing that Sun as is too old-fashined. 

But I don't have any good idea to deal with this so I need to leave this
to Python developers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4902>
_______________________________________

From report at bugs.python.org  Fri Jan  9 23:20:13 2009
From: report at bugs.python.org (Aki)
Date: Fri, 09 Jan 2009 22:20:13 +0000
Subject: [issue4902] failed to build ctypes in Python2.6.1 (even with gcc)
In-Reply-To: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>
Message-ID: <1231539613.36.0.648292085514.issue4902@psf.upfronthosting.co.za>


Aki <akineko at users.sourceforge.net> added the comment:

> I'm really puzzled; gcc would normally not generate assembler code
like this.

This is because an assembler source (sysv.S) was given.

Python-2.6.1/Modules/_ctypes/libffi/src/x86/sysv.S

It was created by Red Hat.
A macro, RAW_CLOSURE_CIF_OFFSET, contains '~'.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4902>
_______________________________________

From report at bugs.python.org  Fri Jan  9 23:21:44 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 09 Jan 2009 22:21:44 +0000
Subject: [issue4890] handling empty text search pattern in tkinter
In-Reply-To: <1231496629.01.0.458062958908.issue4890@psf.upfronthosting.co.za>
Message-ID: <1231539704.83.0.958714372948.issue4890@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I don't know what I was thinking when I said that, the check you are
doing in the patch is fine. And just to answer your next question: it
would raise ValueError.

Also, it would be good to add the other missing search switches.

----------
nosy: +gpolo
versions: +Python 3.0, Python 3.1 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4890>
_______________________________________

From report at bugs.python.org  Fri Jan  9 23:28:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jan 2009 22:28:31 +0000
Subject: [issue4074] Building a list of tuples has non-linear performance
In-Reply-To: <1223438452.4.0.926419942993.issue4074@psf.upfronthosting.co.za>
Message-ID: <1231540111.78.0.992257258208.issue4074@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, committed in trunk and py3k. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4074>
_______________________________________

From report at bugs.python.org  Fri Jan  9 23:36:53 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 09 Jan 2009 22:36:53 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231540613.09.0.547945702901.issue4893@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Early windows CE devices were very crippled, and IIRC, only the Unicode
version of the API existed, and (also IIRC) this was well before Python
had builtin unicode.  I agree with Martin; it is probably worth
investigating how much effort it is to get thread_nt.h working on CE
these days...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Sat Jan 10 00:04:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 23:04:24 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231542264.18.0.647416878723.issue1696199@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file12671/counter4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Sat Jan 10 00:04:38 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Jan 2009 23:04:38 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231542278.51.0.380673390063.issue1696199@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12665/counter3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Sat Jan 10 00:08:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 23:08:06 +0000
Subject: [issue4902] failed to build ctypes in Python2.6.1 (even with gcc)
In-Reply-To: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>
Message-ID: <1231542486.52.0.190380718073.issue4902@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah, ok. ctypes can indeed only build with GNU tools. This is a known
issue, and nobody has volunteered to fix it yet. Closing it as such, then.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4902>
_______________________________________

From report at bugs.python.org  Sat Jan 10 00:10:37 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 09 Jan 2009 23:10:37 +0000
Subject: [issue4074] Building a list of tuples has non-linear performance
In-Reply-To: <1231540111.78.0.992257258208.issue4074@psf.upfronthosting.co.za>
Message-ID: <4967D96B.8040107@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Ok, committed in trunk and py3k. Thanks!

Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4074>
_______________________________________

From report at bugs.python.org  Sat Jan 10 03:57:58 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 10 Jan 2009 02:57:58 +0000
Subject: [issue4903] binascii.crc32()
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The result of binascii.crc32() is different on the same input in Python 
2.6/3.0.  For example:

Python 2.6:

>>> binascii.crc32('Hello')
-137262718

Python 3.0:

>>> binascii.crc32(b'Hello')
4157704578

----------
components: Library (Lib)
messages: 79524
nosy: beazley
severity: normal
status: open
title: binascii.crc32()
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4903>
_______________________________________

From report at bugs.python.org  Sat Jan 10 04:02:05 2009
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 10 Jan 2009 03:02:05 +0000
Subject: [issue4882] Behavior of backreferences to named groups in regular
	expressions unclear
In-Reply-To: <1231428946.66.0.0747408022841.issue4882@psf.upfronthosting.co.za>
Message-ID: <1231556525.88.0.0720798516511.issue4882@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

That sounds like a good idea, particularly since it is a bit different 
from Perl.  Please do write up the a clarification.

Typically, I have either attached a file with the suggested wording, or 
included it in a comment from which a commiter could cut-and-paste.

(If Georg has different preferences on how to submit the patch, they 
should probably go into a FAQ anyhow.)

----------
nosy: +jimjjewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4882>
_______________________________________

From report at bugs.python.org  Sat Jan 10 04:07:00 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 10 Jan 2009 03:07:00 +0000
Subject: [issue4903] binascii.crc32()
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231556820.05.0.440456737261.issue4903@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

When treated as an unsigned 32bit value those are identical.

Guido prefers to keep Python 2.x always having signed values for the 
scattered crc functions.  We changed it for 3.0 because it makes more 
sense given that python these days no real fixed-bits numeric type.

See also

http://bugs.python.org/issue1202

I posted a workaround in there.  Always & the crc32() or adler32() 
return value with 0xFFFFFFFF.

----------
dependencies: +zlib.crc32() and adler32() return value
nosy: +gregory.p.smith
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4903>
_______________________________________

From report at bugs.python.org  Sat Jan 10 04:09:18 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 10 Jan 2009 03:09:18 +0000
Subject: [issue1202] zlib.crc32() and adler32() return value
In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za>
Message-ID: <1231556958.14.0.0183176615033.issue1202@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

seems there are bugs with it not staying signed as it should on some 
64bit platforms.  i'll be looking into this shortly.  its a good 
candidate bug for 2.6.x and 3.0.x releases.

----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1202>
_______________________________________

From report at bugs.python.org  Sat Jan 10 04:10:01 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 10 Jan 2009 03:10:01 +0000
Subject: [issue1202] zlib.crc32() and adler32() return value
In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za>
Message-ID: <1231557001.73.0.275146111165.issue1202@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

err not 3.0.x, 3.0 is always unsigned like anyone sane would want. :)

----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1202>
_______________________________________

From report at bugs.python.org  Sat Jan 10 04:16:22 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 10 Jan 2009 03:16:22 +0000
Subject: [issue4903] binascii.crc32()
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231557382.78.0.641784245275.issue4903@psf.upfronthosting.co.za>


David M. Beazley <beazley at users.sourceforge.net> added the comment:

Can someone PLEASE make sure this gets documented someplace.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4903>
_______________________________________

From report at bugs.python.org  Sat Jan 10 05:12:55 2009
From: report at bugs.python.org (Craig Holmquist)
Date: Sat, 10 Jan 2009 04:12:55 +0000
Subject: [issue4631] urlopen returns extra, spurious bytes
In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za>
Message-ID: <1231560775.38.0.708449495639.issue4631@psf.upfronthosting.co.za>


Changes by Craig Holmquist <craigholm at gmail.com>:


----------
nosy: +craigh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4631>
_______________________________________

From report at bugs.python.org  Sat Jan 10 05:52:54 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sat, 10 Jan 2009 04:52:54 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231563174.76.0.123045258294.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

@ ajaksu2
> Applying your patches makes no difference with gcc 4.2 and gives a
> barely noticeable (~2%) slowdown with icc.
"Your patches" is something quite unclear :-)
Which are the patch sets you are comparing?
And on 32 or 64 bits? But does Yonah supports 64bits? IIRC no, but I'm
not sure.
I would be surprised from slowdowns for restore-old-oparg-load.diff,
really surprised.
And I would be just surprised by slowdowns on
reenable-static-prediction.diff.
Also, about ICC output, we still need to ensure that it's properly
compiled (see above the instructions for counting "jmp *" or similar).
In the measurements above, ICC did miscompile the patch with the switch.
By "properly compiled" I mean that separate indirect branches are
generated, instead of just one.

> These results are from a
> Celeron M 410 (Core Solo Yonah-based), so it's a rather old platform to
> run benchmarks on.

Not really - at the very least we should listen to results on Pentium 4,
Core (i.e. Yonah) and Core 2, and I would also add Pentium3/Pentium M to
represent the P6 family.
Anyway, I have to do my benchmarks on this, I hope this weekend I'll
have time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 10 07:33:43 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 10 Jan 2009 06:33:43 +0000
Subject: [issue4904] Typo for PickingError in pickle.py
In-Reply-To: <1231569223.03.0.0748221773659.issue4904@psf.upfronthosting.co.za>
Message-ID: <1231569223.03.0.0748221773659.issue4904@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

Noticed that in the release version of python 3.0 and the latest svn that 
on line 835 the exception UnpickingError is raised instead of UnpicklingError.

----------
components: Library (Lib)
messages: 79531
nosy: erickt
severity: normal
status: open
title: Typo for PickingError in pickle.py
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4904>
_______________________________________

From report at bugs.python.org  Sat Jan 10 09:52:31 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sat, 10 Jan 2009 08:52:31 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231577551.9.0.477655297426.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

The standing question is still: can we get ICC to produce the expected 
output? It looks like we still didn't manage, and since ICC is the best 
compiler out there, this matters.
Some problems with SunCC, even if it doesn't do jump sharing, it seems 
that one doesn't get the speedups - I guess that on most platforms we 
should select the most common alternative for interpreters (i.e. no 
switch, one jump table, given by threadedceval5.patch + 
abstract-switch-reduced.diff).

On core platforms we can spend time on fine-tuning - and the definition 
of "core platforms" is given by "do developers want to test for that?".

When that's fixed, I think that we just have to choose the simpler form 
and merge that.

@alexandre:
[about removing the switch]
> There is no speed difference on pybench on x86; on x86-64, the code 
is slower due to the opcode fetching change.

Actually, on my machine it looks like the difference is caused by the 
different layout caused by switch removal, or something like that, 
because fixing the opcode fetching doesn't make a difference here (see 
below).

Indeed, I did my benchmarking duties. Results are that 
abstract-switch-reduced.diff (the one removing the switch) gives a 1-3% 
slowdown, and that all the others don't make a significant difference. 
The differences in the assembly output seem to be due to a different 
code layout for some branches, I didn't have a closer look.

However, experimenting with -falign-labels=16 can give a small speedup, 
I'm trying to improve the results (what I actually want is to align 
just the opcode handlers, I'll probably do that by hand).

reenable-static-prediction can give either a slowdown or a speedup by 
around 1%, i.e. around the statistical noise.

Note that on my machine, I get only a 10% speedup with the base patch, 
and that is more reasonable here. In the original thread on PyPy-dev, I 
got a 20% one with the Python interpreter I built for my student 
project, since that one is faster* (by a 2-3x factor, like PyVM), so 
the dispatch cost is more significant, and reducing it has a bigger 
impact. In fact, I couldn't believe that Python got the same speedup.

This is a Core 2 Duo T7200 (Merom) in 64bit mode with 4MB of L2 cache, 
and since it's a laptop I expect it to have slower RAM than a desktop.

@alexandre:
> The patch make a huge difference on 64-bit Linux. I get a 20% 
speed-up and the lowest run time so far. That is quite impressive!
Which processor is that?

@pitrou:
> The machine I got the 15% speedup on is in 64-bit mode with gcc
4.3.2.

Which is the processor? I guess the bigger speedups should be on 
Pentium4, since it has the bigger mispredict penalties.

====
*DISCLAIMER: the interpreter of our group (me and Sigurd Meldgaard) is 
not complete, has some bugs, and the source code has not yet been 
published, so discussion about why it is faster shall not happen here - 
I want to avoid any flame.
I believe it's not because of skipped runtime checks or such stuff, but 
because we used garbage collection instead of refcounting, indirect  
threading and tagged integers, but I don't have time to discuss that 
yet.
The original thread on pypy-dev has some insights if you are interested 
on this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 10 10:07:26 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sat, 10 Jan 2009 09:07:26 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231578446.7.0.768936823866.issue4893@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

The thread code is unaffected by the Unicode/ANSI issues, but CE 
doesn't have _beginthread[ex], which are mandatory for the desktop 
variants. I have checkin 68455 and I will try to compile the new NT 
code under CE to estimate how large the changes are.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Sat Jan 10 10:24:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 10 Jan 2009 09:24:28 +0000
Subject: [issue4903] binascii.crc32()
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231579468.22.0.0183557779484.issue4903@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What is "this" that you want to get documented? Can you propose a
specific wording?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4903>
_______________________________________

From report at bugs.python.org  Sat Jan 10 10:41:55 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sat, 10 Jan 2009 09:41:55 +0000
Subject: [issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers
In-Reply-To: <1231580515.2.0.210154432041.issue4905@psf.upfronthosting.co.za>
Message-ID: <1231580515.2.0.210154432041.issue4905@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

GetFileAttributes[W|A] returns a DWORD with this value when it 
couldn't determine the file's attributes. In the Python codebase, 
there are basically three values this is compared with, the above 
macro, 0xffffffff and (DWORD)-1, it should only be the macro.

However, this macro isn't defined in some SDKs (I don't remember if 
those were early MSVC versions or some MS Windows CE SDKs), so we also 
need to work around that.

I'm currently preparing a patch that resolves those including the 
workaround when the macro isn't defined.

----------
components: Interpreter Core
messages: 79535
nosy: eckhardt
severity: normal
status: open
title: Use INVALID_FILE_ATTRIBUTES instead of magic numbers
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4905>
_______________________________________

From report at bugs.python.org  Sat Jan 10 10:44:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 09:44:40 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1231577551.9.0.477655297426.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231580692.7676.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> @pitrou:
> > The machine I got the 15% speedup on is in 64-bit mode with gcc
> 4.3.2.
> 
> Which is the processor? I guess the bigger speedups should be on 
> Pentium4, since it has the bigger mispredict penalties.

Athlon X2 3600+.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 10 10:55:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 09:55:00 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1231577551.9.0.477655297426.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231581315.7676.14.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It looks like we still didn't manage, and since ICC is the best 
> compiler out there, this matters.

Well, from the perspective of Python, what matters mostly is the
commonly used compilers (that is, gcc and MSVC). I doubt many people
compile Python with icc, honestly.

Same for CPU-specific tuning: I don't think we want to ship Python with
compiler flags which depend on the particular CPU being used.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 10 12:11:51 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 10 Jan 2009 11:11:51 +0000
Subject: [issue4906] os.listdir fails on debug build (windows)
In-Reply-To: <1231585911.12.0.413619049778.issue4906@psf.upfronthosting.co.za>
Message-ID: <1231585911.12.0.413619049778.issue4906@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Due to r68455, os.listdir fails on debug build (windows).

//////////////////////////////////

Python 2.7a0 (trunk, Jan 10 2009, 18:36:15) [MSC v.1200 32 bit (Intel)] 
on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import os
[33639 refs]
>>> os.listdir(".")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 0] ???????????????: './*.*'
[33678 refs]

//////////////////////////////////

Probably a following XP Buildbot error comes from same reason.

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%
20trunk/builds/1759/step-compile/0

This error is raised near Modules/posixmodule.c (2205)

	Py_BEGIN_ALLOW_THREADS
	result = FindNextFile(hFindFile, &FileData);
	Py_END_ALLOW_THREADS
	/* FindNextFile sets error to ERROR_NO_MORE_FILES if
	   it got to the end of the directory. */
	if (!result && GetLastError() != ERROR_NO_MORE_FILES) {

GetLastError() is sometimes 0 when should be ERROR_NO_MORE_FILES.
This happens because, on debug build, Py_END_ALLOW_THREADS finally
reaches PyThread_get_key_value in Python/thread_nt.h, and TlsGetValue
in it calls SetValueError(0) when function succeeds. See
http://msdn.microsoft.com/en-us/library/ms686812.aspx

I've attached the patch to fix this. I believe LastError set by
TlsGetValue on its failure is not used anywhere.

----------
components: Interpreter Core
files: fix_thread_nt.patch
keywords: needs review, patch
messages: 79538
nosy: ocean-city
priority: critical
severity: normal
status: open
title: os.listdir fails on debug build (windows)
versions: Python 2.7
Added file: http://bugs.python.org/file12672/fix_thread_nt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4906>
_______________________________________

From report at bugs.python.org  Sat Jan 10 12:29:51 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 10 Jan 2009 11:29:51 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1231581315.7676.14.camel@localhost>
Message-ID: <49688699.5050804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-10 10:55, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> It looks like we still didn't manage, and since ICC is the best 
>> compiler out there, this matters.
> 
> Well, from the perspective of Python, what matters mostly is the
> commonly used compilers (that is, gcc and MSVC). I doubt many people
> compile Python with icc, honestly.

Agreed. Our main targets should be GCC for Linux and MSVC for Windows.

On other platforms such as Solaris and AIX, the native vendor compilers
are commonly used for compiling Python.

That said, with a configure option to turn the optimization on and
off, there shouldn't be any problem with slowdowns.

> Same for CPU-specific tuning: I don't think we want to ship Python with
> compiler flags which depend on the particular CPU being used.

Certainly not in the binaries we release on python.org.

Of course, people are still free to setup OPT to have the compiler
generate CPU specific code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 10 13:08:13 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 10 Jan 2009 12:08:13 +0000
Subject: [issue4906] os.listdir fails on debug build (windows)
In-Reply-To: <1231585911.12.0.413619049778.issue4906@psf.upfronthosting.co.za>
Message-ID: <1231589293.48.0.55489593934.issue4906@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I see, so it was I that caused this :)
I will owe up to it and submit a fix.

----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4906>
_______________________________________

From report at bugs.python.org  Sat Jan 10 13:08:55 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sat, 10 Jan 2009 12:08:55 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231589335.04.0.524089759982.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

> Same for CPU-specific tuning: I don't think we want to ship Python
with compiler flags which depend on the particular CPU being used.

I wasn't suggesting this - but since different CPUs have different
optimization rules, something like "oh, 20% performance slowdown on
PowerPC" or "on P4" is important to know (and yeah, configure options
are a good solution).

Which is the barrier for platform-specific tricks, as long as the code
is still portable? I'd like to experiment with __builtin_expect and with
manual alignment (through 'asm volatile(".p2align 4")' on x86/x86_64
with GAS - PPC might need a different alignment probably).

All hidden through macros to make it disappear on unsupported platforms,
without any configure option for them (there shouldn't be the need for
that).

> I doubt many people compile Python with icc, honestly.

Yep :-(. <rant>Why don't distributors do it?</rant> (First culprit might
be license/compatibility problems I guess, but the speedup would be
worth the time to fix the troubles IMHO).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 10 13:12:03 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 10 Jan 2009 12:12:03 +0000
Subject: [issue4903] binascii.crc32()
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231589523.12.0.0809247258625.issue4903@psf.upfronthosting.co.za>


David M. Beazley <beazley at users.sourceforge.net> added the comment:

Placing a note in the standard library documentation would be a start.   
Just say in Python 3.0 it always returns the result as an unsigned 
integer whereas in Python 2.6 a 32-bit signed integer is returned. 
Although the numerical value may differ between versions, the underlying 
bits are the same.  Use crc32() & 0xffffffff to get a consistent value 
(already noted).

Note: Not everyone uses checksums in only a packed-binary format.  
Having the integer value just change across Python  versions like that 
is a real subtle compatibility problem to point out.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4903>
_______________________________________

From report at bugs.python.org  Sat Jan 10 13:14:50 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 10 Jan 2009 12:14:50 +0000
Subject: [issue4906] os.listdir fails on debug build (windows)
In-Reply-To: <1231585911.12.0.413619049778.issue4906@psf.upfronthosting.co.za>
Message-ID: <1231589690.79.0.250120290979.issue4906@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Checked in:
Completed: At revision: 68476

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4906>
_______________________________________

From report at bugs.python.org  Sat Jan 10 15:54:37 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sat, 10 Jan 2009 14:54:37 +0000
Subject: [issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers
In-Reply-To: <1231580515.2.0.210154432041.issue4905@psf.upfronthosting.co.za>
Message-ID: <1231599277.33.0.0340389978073.issue4905@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

The patch replaces remaining magic numbers with INVALID_FILE_ATTRIBUTES.

----------
keywords: +patch
Added file: http://bugs.python.org/file12673/python-2.7-fileattrib-magic.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4905>
_______________________________________

From report at bugs.python.org  Sat Jan 10 16:03:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 15:03:24 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1231589335.04.0.524089759982.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231599819.6069.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> (First culprit might
> be license/compatibility problems I guess, but the speedup would be
> worth the time to fix the troubles IMHO).

That would be the obvious reason IMO. And Intel is the only one who can
"fix the troubles".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 10 16:31:57 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 10 Jan 2009 15:31:57 +0000
Subject: [issue4884] Work around gethostbyaddr_r bug
In-Reply-To: <1231441695.4.0.529827841073.issue4884@psf.upfronthosting.co.za>
Message-ID: <1231601517.47.0.986793759083.issue4884@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

What about socket_gethostbyname_ex() ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4884>
_______________________________________

From report at bugs.python.org  Sat Jan 10 16:40:13 2009
From: report at bugs.python.org (williambr)
Date: Sat, 10 Jan 2009 15:40:13 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1231602013.14.0.591060214439.issue1767370@psf.upfronthosting.co.za>


williambr <william88 at gmail.com> added the comment:

Hi.

I am very intereasted about this patch... specially about the keep-alive
part...
I have a proposition... wouldn't be fair enough to have a separated
Transport just for keep-alive connections?

I could wirte one if no one is against it...

----------
nosy: +williambr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_______________________________________

From report at bugs.python.org  Sat Jan 10 16:45:02 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 10 Jan 2009 15:45:02 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

ast.literal_eval does not properly handle complex numbers:

>>> ast.literal_eval("1j")
1j
>>> ast.literal_eval("2+1j")
Traceback (most recent call last):
  ...
ValueError: malformed string
>>> ast.literal_eval("(2+1j)")
Traceback (most recent call last):
  ...
ValueError: malformed string

Expected result:

>>> ast.literal_eval("1j")
1j
>>> ast.literal_eval("2+1j")
(2+1j)
>>> ast.literal_eval("(2+1j)")
(2+1j)

I attached a patch that fixes this problem.

----------
components: Library (Lib)
files: literal-eval.patch
keywords: needs review, patch, patch
messages: 79548
nosy: aronacher
priority: normal
severity: normal
stage: patch review
status: open
title: ast.literal_eval does not properly handled complex numbers
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12674/literal-eval.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Sat Jan 10 16:46:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 15:46:28 +0000
Subject: [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231602388.69.0.587368590133.issue4868@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I committed the patch with the last suggested change (word -> data) in
py3k (r68483). I don't intend to backport it to trunk, but I suppose it
wouldn't be too much work to do.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4868>
_______________________________________

From report at bugs.python.org  Sat Jan 10 16:47:06 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 10 Jan 2009 15:47:06 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231602426.49.0.853465625707.issue4907@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

fixed patch :)

Added file: http://bugs.python.org/file12675/literal-eval.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Sat Jan 10 17:23:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 16:23:28 +0000
Subject: [issue3860] GzipFile and BZ2File should support context manager
	protocol
In-Reply-To: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za>
Message-ID: <1231604608.24.0.41073987276.issue3860@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in trunk and py3k. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3860>
_______________________________________

From report at bugs.python.org  Sat Jan 10 17:27:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 16:27:46 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1231604866.72.0.671600164596.issue4879@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why not name the parameter buffering=False rather than nobuffer=True?
Sounds more "natural" to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Sat Jan 10 17:33:51 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 10 Jan 2009 16:33:51 +0000
Subject: [issue4472] Is shared lib building broken on trunk for Mac OS X?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <1231605231.89.0.498944795074.issue4472@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Works for me.  Thanks Ronald.  Closing...

----------
assignee:  -> ronaldoussoren
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________

From report at bugs.python.org  Sat Jan 10 17:57:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Jan 2009 16:57:37 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231606657.96.0.751721496643.issue4907@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Looks good to me assuming you add a test.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:05:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Jan 2009 17:05:59 +0000
Subject: [issue4904] Typo for PickingError in pickle.py
In-Reply-To: <1231569223.03.0.0748221773659.issue4904@psf.upfronthosting.co.za>
Message-ID: <1231607159.51.0.225451376986.issue4904@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the report! Fixed in r68488.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4904>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:20:40 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 10 Jan 2009 17:20:40 +0000
Subject: [issue4861] fix problems with ctypes.util.find_library
In-Reply-To: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>
Message-ID: <1231608040.61.0.770185068693.issue4861@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

now fixed in 2.6, 2.7, 3.0 and 3.1.

objdump is never installed in /sbin. I don't think we should assume a
specific path for objdump. we don't do this for gcc either.

----------
assignee: theller -> doko
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4861>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:23:11 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 10 Jan 2009 17:23:11 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1231608191.42.0.703681334153.issue3383@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

I keep this open for now, I don't have access to AIX. Yes, if objdump is
found in some /sbin PATH, then maybe we should search there explicitely.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:37:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Jan 2009 17:37:06 +0000
Subject: [issue4901] inconsistent API docs for tp_iter
In-Reply-To: <1231527377.73.0.506480870476.issue4901@psf.upfronthosting.co.za>
Message-ID: <1231609026.55.0.076072688695.issue4901@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the report! Fixed in r68495.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4901>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:38:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 17:38:19 +0000
Subject: [issue2396] Backport memoryview object to Python 2.7
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1231609099.4.0.360352057221.issue2396@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. Some remarks:
- I had to disable a few tests in test_memoryview.py, mainly because
array.array does not support the new buffer API in 2.x
- I kept the PyBytes_* aliases in memoryobject.c rather than using the
PyString_* equivalents. Is it ok?
- I didn't update the Windows build files, I suppose someone else can do
it (I'm unable to do it myself)
- I'm not sure about the tp_flags juggling in typeobject.c, my additions
may be redundant (although very lightweight)

----------
assignee:  -> pitrou
keywords: +patch
stage:  -> patch review
title: Backport memoryview object to Python 2.6 -> Backport memoryview object to Python 2.7
Added file: http://bugs.python.org/file12676/memview-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:42:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Jan 2009 17:42:48 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231609368.88.0.384621045482.issue2486@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

(Adding Raymond to the nosy list.)

In r68494, I've checked in some work towards rewriting Decimal (or parts 
of Decimal) in C.  I reused Facundo's old /decimal directory in the 
sandbox, so the URL is:

http://svn.python.org/view/sandbox/trunk/decimal/decimal_in_c/

What's there is a fully functional hybrid Python and C implementation of 
decimal.  All the existing decimal tests pass, at least on my machine.  
There's very little performance increase to boast of at the moment, but 
that may change.  To try it, check out the directory and follow the
README instructions.  This probably doesn't work on Windows;  help
fixing that would be appreciated.

The code is for py3k only;  I started out maintaining versions
for both 2.x and 3.x, but that was just too painful.  I'd rather
get the py3k version working, then backport.

The main files are:
  deccoeff.c:  contains classes Deccoeff and _Decimal.  Deccoeff
    implements base 10 nonnegative integer arithmetic:  its instances
    can be treated as integers, but also sliced as though they were
    strings, which makes rounding and shifting operations simple.
    _Decimal is a minimal base class for Decimal;  the idea is
    to move functions from Decimal to _Decimal over time.
  decimal.py: version of Lib/decimal.py, fixed to use Deccoeff
    instead of string for the coefficient.

As I see it, there are two goals for this work:

(1) Speed decimal up.
(2) Bring proposals to add a decimal literal to C closer to realizability.

By the way, presumably it's not a prerequisite for (2) that *all* of the 
decimal.py functionality be recoded in C?  I could imagine a situation 
where the decimal literals are present in the core, but an 'import 
decimal' was necessary to get complete functionality.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:43:36 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Sat, 10 Jan 2009 17:43:36 +0000
Subject: [issue1777] ElementTree/cElementTree findtext inconsistency
In-Reply-To: <1199905088.24.0.426478607654.issue1777@psf.upfronthosting.co.za>
Message-ID: <1231609416.52.0.820192895908.issue1777@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

Forgot to mention that this is fixed in the cElementTree trunk (public
as of today's 1.0.6 preview release).  Will merge with Python trunk when
I find the time...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:45:06 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 10 Jan 2009 17:45:06 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Let's add a "get_metadata" API in Distutils that would return
in a dictionary the content of the .egg-info file introduced into Python
2.5.


  >>> from distutils import get_metadata
  >>> get_metadata('ThePackage')
  {..}

(Working on a prototype)

----------
assignee: tarek
components: Distutils
messages: 79562
nosy: tarek
severity: normal
status: open
title: adding a get_metadata in distutils
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:45:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 17:45:10 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231609510.42.0.475917480479.issue2486@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:46:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Jan 2009 17:46:42 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231609602.92.0.629407542298.issue2486@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Changing title and assignee.  (But all help is appreciated:  if anyone 
wants to commit changes to the sandbox directory, please go ahead!)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:47:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Jan 2009 17:47:07 +0000
Subject: [issue2486] Recode (parts of) decimal module in C
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231609627.19.0.441848270341.issue2486@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: facundobatista -> marketdickinson
title: Decimal slowdown in 3.0 due to str/unicode changes -> Recode (parts of) decimal module in C

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Sat Jan 10 18:51:24 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 10 Jan 2009 17:51:24 +0000
Subject: [issue4884] Work around gethostbyaddr_r bug
In-Reply-To: <1231441695.4.0.529827841073.issue4884@psf.upfronthosting.co.za>
Message-ID: <1231609884.49.0.355675283169.issue4884@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

socket_gethostbyname_ex() calls gethostbyname_r() rather than
gethostbyaddr_r(), and that appears not to have the bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4884>
_______________________________________

From report at bugs.python.org  Sat Jan 10 19:10:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Jan 2009 18:10:50 +0000
Subject: [issue2486] Recode (parts of) decimal module in C
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231611050.75.0.166721298652.issue2486@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> (2) Bring proposals to add a decimal literal to C ...

That should be "to Python", not "to C", of course.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Sat Jan 10 19:14:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 18:14:52 +0000
Subject: [issue2486] Recode (parts of) decimal module in C
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231611292.83.0.13957773808.issue2486@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> By the way, presumably it's not a prerequisite for (2) that *all* of the 
> decimal.py functionality be recoded in C?  I could imagine a situation 
> where the decimal literals are present in the core, but an 'import 
> decimal' was necessary to get complete functionality.

We already have this situation with builtin open() and "import io", so I
guess that wouldn't be out of question.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Sat Jan 10 19:17:37 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 10 Jan 2009 18:17:37 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1231611457.66.0.78801277316.issue2233@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Jason, did you test what is result is DESTDIR default to "/".

This variable(macro) is used with specific syntax by example (from
Makefile):
  $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$b; \
where $$b is absolute path.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Sat Jan 10 19:41:04 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 10 Jan 2009 18:41:04 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1231612864.54.0.497841711478.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file12677/python-trunk.patch-CROSS-20090110

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sat Jan 10 19:41:55 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 10 Jan 2009 18:41:55 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1231612915.24.0.608398068997.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file12678/python-trunk.patch-MINGW-20090110

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Jan 10 20:32:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 10 Jan 2009 19:32:33 +0000
Subject: [issue4909] incorrect renaming in imports
In-Reply-To: <1231615953.75.0.823644333839.issue4909@psf.upfronthosting.co.za>
Message-ID: <1231615953.75.0.823644333839.issue4909@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The fragment

try:
    import cStringIO as StringIO
except ImportError:
    import StringIO
s=StringIO.StringIO()

gets rewritten to

try:
    import io as StringIO
except ImportError:
    import io
s=io.StringIO()

Unfortunately, that code fails to work: the first import succeeds,
actually binding StringIO; the name io is unbound and gives NameError.

Apparently, the fixer choses to replace all occurrences of StringIO with
io; it should extend this replacement to "as" clauses.

My work-around is to import as _StringIO in both cases, and then refer
to the module as _StringIO.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 79568
nosy: loewis
severity: normal
status: open
title: incorrect renaming in imports

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4909>
_______________________________________

From report at bugs.python.org  Sat Jan 10 20:38:31 2009
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 10 Jan 2009 19:38:31 +0000
Subject: [issue2396] Backport memoryview object to Python 2.7
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1231616311.15.0.890870994226.issue2396@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
_______________________________________

From report at bugs.python.org  Sat Jan 10 20:41:49 2009
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 10 Jan 2009 19:41:49 +0000
Subject: [issue1251] ssl module doesn't support non-blocking handshakes
In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>
Message-ID: <1231616509.69.0.977282418497.issue1251@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Bill, should this issue be closed?

Or Senthil found a bug in the actual code and you're waiting for him to
point out where is the problem or a way to reproduce it?

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1251>
_______________________________________

From report at bugs.python.org  Sat Jan 10 20:52:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 19:52:18 +0000
Subject: [issue2396] Backport memoryview object to Python 2.7
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1231617138.1.0.494812510234.issue2396@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This new patch includes documentation update and fixes as well.

Added file: http://bugs.python.org/file12679/memview-trunk2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
_______________________________________

From report at bugs.python.org  Sat Jan 10 21:32:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Jan 2009 20:32:22 +0000
Subject: [issue4910] help(int.__long__) refers to nonexistent long function
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In Python 3.x:

>>> int.__long__.__doc__
'x.__long__() <==> long(x)'

But the long builtin no longer exists.

I'm actually not sure why the nb_long slot still exists in 3.x at all.  
Can anyone enlighten me?

----------
messages: 79571
nosy: marketdickinson
severity: normal
status: open
title: help(int.__long__) refers to nonexistent long function
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Sat Jan 10 21:41:08 2009
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 10 Jan 2009 20:41:08 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1231620068.08.0.914916910282.issue1424152@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Everything looks ok, with one detail, the new set_tunnel() function.

Should this function be public? If yes, new documentation should be
added. If not, it should start with "_". 

I think that it should be public, because we're using it from somewhere
else. So, please provide new patchs for documentation (don't bother to
modify actual code patches).

Thank you!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sat Jan 10 21:55:12 2009
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 10 Jan 2009 20:55:12 +0000
Subject: [issue4607] uuid behavior with multiple threads
In-Reply-To: <1228817613.61.0.835491086026.issue4607@psf.upfronthosting.co.za>
Message-ID: <1231620912.48.0.894022590252.issue4607@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Yes, _buffer is not longer global.

Thanks for the report!

----------
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4607>
_______________________________________

From report at bugs.python.org  Sat Jan 10 22:00:06 2009
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 10 Jan 2009 21:00:06 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1231621206.25.0.678912424138.issue4608@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Senthil, do you think you could provide a test case for this?

Thank you!

----------
assignee:  -> facundobatista
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Sat Jan 10 22:03:17 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Jan 2009 21:03:17 +0000
Subject: [issue4909] incorrect renaming in imports
In-Reply-To: <1231615953.75.0.823644333839.issue4909@psf.upfronthosting.co.za>
Message-ID: <1231621397.33.0.960067818236.issue4909@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Tricky. I only solution I can think of is replacing cStringIO with
_stringio or just refusing to replace StringIO usage once cStringIO has
been seen. The latter seems like the best solutions.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4909>
_______________________________________

From report at bugs.python.org  Sat Jan 10 22:07:59 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 10 Jan 2009 21:07:59 +0000
Subject: [issue4909] incorrect renaming in imports
In-Reply-To: <1231615953.75.0.823644333839.issue4909@psf.upfronthosting.co.za>
Message-ID: <1231621679.62.0.833475791282.issue4909@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If there is no straight-forward solution, we should close it as "won't
fix", and encourage users to work around.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4909>
_______________________________________

From report at bugs.python.org  Sat Jan 10 22:12:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Jan 2009 21:12:25 +0000
Subject: [issue4909] incorrect renaming in imports
In-Reply-To: <1231615953.75.0.823644333839.issue4909@psf.upfronthosting.co.za>
Message-ID: <1231621945.93.0.456651596172.issue4909@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Ok. I will close this for now. This is a very common construct; if we
get more bug reports, we can reconsider. (I'm attaching the patch I used
to "fix" this for future reference.)

----------
keywords: +patch
resolution:  -> wont fix
status: open -> closed
Added file: http://bugs.python.org/file12681/cStringIO_hack.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4909>
_______________________________________

From report at bugs.python.org  Sat Jan 10 22:36:50 2009
From: report at bugs.python.org (Ray)
Date: Sat, 10 Jan 2009 21:36:50 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231623410.48.0.0929259846425.issue4908@psf.upfronthosting.co.za>


Changes by Ray <rayjohnterrill at gmail.com>:


----------
nosy: +rayterrill

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Sat Jan 10 22:43:11 2009
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 10 Jan 2009 21:43:11 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1231623791.77.0.0575493527582.issue4796@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Raymond, Mark, thanks for this work!

I'd include the following in the PEP (under the "from float"
discussion), what do you think?

"""
Update: The .from_float() method was added to Python 2.7 and 3.1
versions, providing lossless and exact conversion from float to Decimal 
(see issue 4796 [7]_ for further information).


It has the following syntax::

    Decimal.from_float(floatNumber)

where ``floatNumber`` is the float number origin of the construction.  
Example::

    >>> Decimal.from_float(1.1)
    Decimal('1.100000000000000088817841970012523233890533447265625')
"""

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sat Jan 10 23:00:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Jan 2009 22:00:36 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1231624836.73.0.242691726541.issue4796@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree the PEP should be updated.  Your proposed update looks good to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sat Jan 10 23:16:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Jan 2009 22:16:16 +0000
Subject: [issue4910] Should both nb_long and nb_int still exist in 3.x?
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1231625776.83.0.462802899091.issue4910@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

long(x) replaced by int(x) in r68508.

I'm still wondering about the nb_long slot, though.

----------
title: help(int.__long__) refers to nonexistent long function -> Should both nb_long and nb_int still exist in 3.x?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Sat Jan 10 23:34:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 22:34:45 +0000
Subject: [issue4912] Invalid syntax in ctypes/util.py
In-Reply-To: <1231626885.19.0.766373314699.issue4912@psf.upfronthosting.co.za>
Message-ID: <1231626885.19.0.766373314699.issue4912@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

ctypes/util.py contains invalid py3k syntax at lines 106-107:

        if rv == 10:
            raise OSError, 'gcc or cc command not found'

----------
assignee: theller
components: ctypes
messages: 79582
nosy: pitrou, theller
severity: normal
status: open
title: Invalid syntax in ctypes/util.py
type: crash
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4912>
_______________________________________

From report at bugs.python.org  Sat Jan 10 23:37:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 10 Jan 2009 22:37:49 +0000
Subject: [issue4912] Invalid syntax in ctypes/util.py
In-Reply-To: <1231626885.19.0.766373314699.issue4912@psf.upfronthosting.co.za>
Message-ID: <1231627069.12.0.0911491637763.issue4912@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r68511.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4912>
_______________________________________

From report at bugs.python.org  Sat Jan 10 23:53:40 2009
From: report at bugs.python.org (Mark Sapiro)
Date: Sat, 10 Jan 2009 22:53:40 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1231628020.41.0.542996708458.issue4279@psf.upfronthosting.co.za>


Mark Sapiro <mark at msapiro.net> added the comment:

This problem also occurs when building the 2.6.1 parser module on Cygwin
1.5.25. It did not occur with Python 2.6 or 2.5.x.

The error from 'make' is

building 'parser' extension
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.25-i686-2.6/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.o
-L/usr/local/lib -L. -lpython2.6 -o
build/lib.cygwin-1.5.25-i686-2.6/parser.dll
build/temp.cygwin-1.5.25-i686-2.6/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.o:
In function `parser_expr':
/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.c:552:
undefined reference to `__PyParser_Grammar'
build/temp.cygwin-1.5.25-i686-2.6/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.o:
In function `parser_suite':
/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.c:552:
undefined reference to `__PyParser_Grammar'
collect2: ld returned 1 exit status

I was able to work around the error and build a parser module that
passed unit test by manually running

gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.25-i686-2.6/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.o
Python/graminit.o -L/usr/local/lib -L. -lpython2.6 -o
build/lib.cygwin-1.5.25-i686-2.6/parser.dll

i.e. by including Python/graminit.o in the explicit object files to load.

I have also confirmed that applying the parser-grammar.patch from #4288
will allow make to successfully build a parser module that passes unit
tests.

----------
nosy: +msapiro
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Sun Jan 11 00:00:35 2009
From: report at bugs.python.org (Mark Sapiro)
Date: Sat, 10 Jan 2009 23:00:35 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1231628435.96.0.203432581824.issue4288@psf.upfronthosting.co.za>


Changes by Mark Sapiro <mark at msapiro.net>:


----------
nosy: +msapiro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Jan 11 02:22:56 2009
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Sun, 11 Jan 2009 01:22:56 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1231636976.38.0.862804909947.issue4279@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

Here's the patch I used for the Cygwin Ports 2.6 and 3.0 packages.  It's
the simplest working solution that I could find.

Added file: http://bugs.python.org/file12682/2.6.1-parsermodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Sun Jan 11 03:16:43 2009
From: report at bugs.python.org (Alex Robinson)
Date: Sun, 11 Jan 2009 02:16:43 +0000
Subject: [issue4913] wave.py writes 16 bit sample files of half the correct
	duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>


New submission from Alex Robinson <alex_python_org at tranzoa.com>:

Corrected code in writeframesraw():

            self._datawritten = self._datawritten + len(data) *
self._sampwidth
        else:
            self._file.write(data)
            self._datawritten = self._datawritten + len(data) *
self._sampwidth


Note that the default (not byte swapped) assignment to _datawritten must
also be multiplied by _sampwidth. If not, audio programs will ignore the
second half of a 16-bit-sample file.

As a side note, the calls to _patchheader() do not need to be protected
by this "if" statement:

        if self._datalength != self._datawritten:

_patchheader does the same test to optimize its operation.

----------
components: Library (Lib)
messages: 79586
nosy: alex_python_org
severity: normal
status: open
title: wave.py writes 16 bit sample files of half the correct duration
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Sun Jan 11 03:53:57 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 11 Jan 2009 02:53:57 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231642437.86.0.643187368802.issue4753@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan 11 05:57:57 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Jan 2009 04:57:57 +0000
Subject: [issue2486] Recode (parts of) decimal module in C
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231649877.5.0.294443447747.issue2486@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I'm currently seeking project sponsorship to work on this.  To do
it right, a substantial portion of the module should be coded in C and
needs to function independently of Python, with accessors provided to
for Python to wrap around.

Once, there is a fast C version, a discussion of a decimal literal can
become a reasonable possibility.  It will be an uphill battle though. 
Many decimal apps have few internal constants -- most of the data comes
into the program from and external source and gets written back.  A
literal itself doesn't have much utility except for playing around at
the command line.  Also, there would need to be a PEP talking about how
decimals should interact with binary floats and the rest of the language
(which pretty much ignores decimals).

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Sun Jan 11 06:03:50 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Jan 2009 05:03:50 +0000
Subject: [issue4796] Decimal to receive from_float method
In-Reply-To: <1230764359.55.0.955763939043.issue4796@psf.upfronthosting.co.za>
Message-ID: <1231650230.27.0.977428592917.issue4796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Go ahead with the update, but it isn't really necessary.  The PEPs are
for getting something into the language in the first place and for
centralizing a major discussion.  They typically get out of date quickly
after they've been implemented.  In this case, we've got the tracker
discussion to document the minor discussions than led to this minor
change in the API.  So, it's okay to update the PEP or not.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4796>
_______________________________________

From report at bugs.python.org  Sun Jan 11 06:19:57 2009
From: report at bugs.python.org (Mark Sapiro)
Date: Sun, 11 Jan 2009 05:19:57 +0000
Subject: [issue4789] Documentation changes break existing URIs
In-Reply-To: <1230683867.44.0.219209732128.issue4789@psf.upfronthosting.co.za>
Message-ID: <1231651197.46.0.0616570309615.issue4789@psf.upfronthosting.co.za>


Mark Sapiro <mark at msapiro.net> added the comment:

Thank you for adding the redirects, and for getting them right in spite
of my garbling some of them in the original report.

I have updated the links for the next Mailman release.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4789>
_______________________________________

From report at bugs.python.org  Sun Jan 11 06:37:18 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 11 Jan 2009 05:37:18 +0000
Subject: [issue4914] trunc(x) erroneously documented as built-in
In-Reply-To: <1231652236.88.0.715538324364.issue4914@psf.upfronthosting.co.za>
Message-ID: <1231652236.88.0.715538324364.issue4914@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In the Numeric Types documentation for 2.6, 3.0, and 3.1 trunc is 
documented as a built-in, like round, but while there is a trunc in math 
there is no built-in trunc. Read some of the debate on trunc from a year 
ago convinced me that this discrepancy is a documentation problem not a 
problem with the built-in functions.  Sorry if I'm completely off target 
here, but since I noticed I figured it was worth an issue.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 79590
nosy: MLModel, georg.brandl
severity: normal
status: open
title: trunc(x) erroneously documented as built-in
versions: Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4914>
_______________________________________

From report at bugs.python.org  Sun Jan 11 08:22:49 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 11 Jan 2009 07:22:49 +0000
Subject: [issue4903] binascii.crc32() - document signed vs unsigned results
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231658569.72.0.82217927041.issue4903@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Agreed, we failed to mention the behavior change in the docs.  I'll take 
care of that.  (if its mentioned at all, its mentioned in a note buried 
in the Misc/NEWS file somewhere)

2to3 could presumably be made to notice crc32 and adler32 calls and warn 
about this problem.  I wouldn't have 2to3 add code to re-sign the return 
value by default as not everything needs that but it is worthy of a 
warning.

----------
assignee:  -> gregory.p.smith
components: +Documentation
priority:  -> normal
resolution: duplicate -> 
status: closed -> open
title: binascii.crc32() -> binascii.crc32() - document signed vs unsigned results

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4903>
_______________________________________

From report at bugs.python.org  Sun Jan 11 10:33:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 09:33:53 +0000
Subject: [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1231666433.82.0.313465192714.issue4279@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now committed 2.6.1-parsermodule.patch as r68523, r68524, r68525,
and r68526. Thanks for the patch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________

From report at bugs.python.org  Sun Jan 11 10:35:19 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 09:35:19 +0000
Subject: [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1231666519.86.0.860195543361.issue4288@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed with the resolution to issue 4279.

----------
resolution:  -> fixed
status: open -> closed
superseder:  -> Module 'parser' fails to build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________

From report at bugs.python.org  Sun Jan 11 10:45:49 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 09:45:49 +0000
Subject: [issue4895] Missing strdup() under MS Windows CE
In-Reply-To: <1231510504.25.0.240511707312.issue4895@psf.upfronthosting.co.za>
Message-ID: <1231667149.04.0.573548321527.issue4895@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r68527, r68528.

----------
nosy: +loewis
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4895>
_______________________________________

From report at bugs.python.org  Sun Jan 11 12:03:30 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 11:03:30 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231671810.83.0.453764157989.issue4893@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

Okay, the changes necessary to the NT thread code are rather minimal,
see attached patch. The file thread_wince.c could then be removed, too.

I also removed a comment which was left over from the version before but
doesn't apply any more.

Added file: http://bugs.python.org/file12683/python-2.7-wince-threads.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Sun Jan 11 13:25:14 2009
From: report at bugs.python.org (Dwayne Bailey)
Date: Sun, 11 Jan 2009 12:25:14 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1231676714.01.0.742631006027.issue2504@psf.upfronthosting.co.za>


Changes by Dwayne Bailey <dwayne+pythonbugs at translate.org.za>:


----------
nosy: +dwayne

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sun Jan 11 14:32:09 2009
From: report at bugs.python.org (Andrew Bennetts)
Date: Sun, 11 Jan 2009 13:32:09 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231680729.88.0.771624642555.issue4753@psf.upfronthosting.co.za>


Changes by Andrew Bennetts <spiv at users.sourceforge.net>:


----------
nosy: +spiv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan 11 14:45:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Jan 2009 13:45:04 +0000
Subject: [issue4220] Builtins treated as free variables?
In-Reply-To: <1225210788.32.0.89272753959.issue4220@psf.upfronthosting.co.za>
Message-ID: <1231681504.2.0.0238376121534.issue4220@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

There is no way for the interpreter to distinguish between builtins and
"other" types of free variables.

If you need unqualified exec to work in an innner function, use function
parameters with defaults, like this:

def a():
    def b(long=long):
        x = long(3)
        exec ""

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4220>
_______________________________________

From report at bugs.python.org  Sun Jan 11 15:48:22 2009
From: report at bugs.python.org (Luciano Ramalho)
Date: Sun, 11 Jan 2009 14:48:22 +0000
Subject: [issue1293741] doctest runner cannot handle non-ascii characters
Message-ID: <1231685302.85.0.59840919709.issue1293741@psf.upfronthosting.co.za>


Luciano Ramalho <luciano at ramalho.org> added the comment:

I have confirmed everything that akaihola reports in Python 2.4, 2.5 and
2.6, but the problem is not limited to non-matching test output. It also
happens with doctests with zero failures when the module is run with the
-v command-line switch, or testmod is called with verbose=True.

The attached file shows a work-around: handle the UnicodeEncodeError
thrown by testmod, and display the "object" attribute of the exception
to see exactly where the problem is.

----------
nosy: +luciano
title: doctest runner cannot handle non-ascii characters  -> doctest runner cannot handle non-ascii characters
versions: +Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12684/issue1293741.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1293741>
_______________________________________

From report at bugs.python.org  Sun Jan 11 17:00:13 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 11 Jan 2009 16:00:13 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1231689613.65.0.530372462166.issue4896@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Pystone results:

apply why patch

py3k% rm $TMPDIR/*.[coi] ; make python.exe && rm -f /tmp/trash ; 
./python.exe Lib/test/pystone.py
rm: /tmp/*.[coi]: No such file or directory
make: `python.exe' is up to date.
Pystone(1.1) time for 50000 passes = 1.08154
This machine benchmarks at 46230.2 pystones/second
py3k% rm $TMPDIR/*.[coi] ; make python.exe && rm -f /tmp/trash ; 
./python.exe Lib/test/pystone.py
rm: /tmp/*.[coi]: No such file or directory
make: `python.exe' is up to date.
Pystone(1.1) time for 50000 passes = 1.08365
This machine benchmarks at 46140.4 pystones/second
py3k% rm $TMPDIR/*.[coi] ; make python.exe && rm -f /tmp/trash ; 
./python.exe Lib/test/pystone.py
rm: /tmp/*.[coi]: No such file or directory
make: `python.exe' is up to date.
Pystone(1.1) time for 50000 passes = 1.08598
This machine benchmarks at 46041.4 pystones/second

remove patch

py3k% rm $TMPDIR/*.[coi] ; make python.exe && rm -f /tmp/trash ; 
./python.exe Lib/test/pystone.py
rm: /tmp/*.[coi]: No such file or directory
make: `python.exe' is up to date.
Pystone(1.1) time for 50000 passes = 1.10093
This machine benchmarks at 45416.3 pystones/second
py3k% rm $TMPDIR/*.[coi] ; make python.exe && rm -f /tmp/trash ; 
./python.exe Lib/test/pystone.py
rm: /tmp/*.[coi]: No such file or directory
make: `python.exe' is up to date.
Pystone(1.1) time for 50000 passes = 1.10458
This machine benchmarks at 45266.1 pystones/second
py3k% rm $TMPDIR/*.[coi] ; make python.exe && rm -f /tmp/trash ; 
./python.exe Lib/test/pystone.py
rm: /tmp/*.[coi]: No such file or directory
make: `python.exe' is up to date.
Pystone(1.1) time for 50000 passes = 1.10333
This machine benchmarks at 45317.5 pystones/second

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Sun Jan 11 17:05:31 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 11 Jan 2009 16:05:31 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1231689931.88.0.903214792759.issue4896@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

pybench comparison...

% ./python.exe Tools/pybench/pybench.py -s stock.out -c why.out -----------------
--------------------------------------------------------------
PYBENCH 2.0
-------------------------------------------------------------------------------
* using CPython 3.1a0 (py3k:68444M, Jan 11 2009, 10:02:04) [GCC 4.0.1 (Apple Inc. 
build 5490)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

-------------------------------------------------------------------------------
Benchmark: stock.out
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    Darwin-9.6.0-i386-32bit
       Processor:      i386
    
    Python:
       Implementation: CPython
       Executable:     /Users/skip/src/python/py3k/python.exe
       Version:        3.1.0
       Compiler:       GCC 4.0.1 (Apple Inc. build 5490)
       Bits:           32bit
       Build:          Jan 11 2009 09:57:51 (#py3k:68444)
       Unicode:        UCS2


-------------------------------------------------------------------------------
Comparing with: why.out
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    Darwin-9.6.0-i386-32bit
       Processor:      i386
    
    Python:
       Implementation: CPython
       Executable:     /Users/skip/src/python/py3k/python.exe
       Version:        3.1.0
       Compiler:       GCC 4.0.1 (Apple Inc. build 5490)
       Bits:           32bit
       Build:          Jan 11 2009 10:02:04 (#py3k:68444M)
       Unicode:        UCS2


Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other   diff
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:   110ms   106ms   +4.1%   111ms   107ms   +3.7%
           BuiltinMethodLookup:    78ms    79ms   -0.7%    80ms    80ms   -0.4%
                 CompareFloats:   105ms   113ms   -7.3%   106ms   114ms   -6.8%
         CompareFloatsIntegers:   161ms   146ms  +10.8%   163ms   151ms   +7.7%
               CompareIntegers:   145ms   151ms   -3.8%   147ms   152ms   -3.1%
        CompareInternedStrings:   109ms   134ms  -18.9%   110ms   135ms  -18.9%
                  CompareLongs:    86ms    90ms   -4.5%    86ms    91ms   -4.8%
                CompareStrings:    89ms    88ms   +0.4%    91ms    89ms   +2.3%
    ComplexPythonFunctionCalls:   146ms   141ms   +3.1%   151ms   143ms   +5.9%
                 ConcatStrings:   124ms   123ms   +0.8%   126ms   129ms   -2.0%
               CreateInstances:   146ms   144ms   +1.9%   148ms   146ms   +1.2%
            CreateNewInstances:   110ms   109ms   +1.2%   111ms   110ms   +0.6%
       CreateStringsWithConcat:   171ms   158ms   +8.4%   175ms   165ms   +5.8%
                  DictCreation:    85ms    80ms   +6.5%    86ms    81ms   +6.8%
             DictWithFloatKeys:    98ms    99ms   -1.0%    99ms   100ms   -1.0%
           DictWithIntegerKeys:    94ms    97ms   -3.4%    94ms   103ms   -8.6%
            DictWithStringKeys:    84ms    88ms   -5.0%    84ms    92ms   -8.3%
                      ForLoops:    85ms    82ms   +3.0%    85ms    83ms   +3.1%
                    IfThenElse:   116ms   132ms  -12.1%   117ms   133ms  -12.5%
                   ListSlicing:   119ms   118ms   +0.1%   124ms   124ms   -0.1%
                NestedForLoops:   141ms   129ms   +9.1%   142ms   132ms   +7.8%
      NestedListComprehensions:   164ms   159ms   +3.4%   166ms   160ms   +3.8%
          NormalClassAttribute:   215ms   218ms   -1.2%   217ms   220ms   -1.2%
       NormalInstanceAttribute:   111ms   115ms   -3.0%   113ms   117ms   -3.7%
           PythonFunctionCalls:   104ms   123ms  -15.5%   104ms   124ms  -15.6%
             PythonMethodCalls:   144ms   144ms   -0.3%   148ms   149ms   -0.6%
                     Recursion:   180ms   195ms   -7.8%   191ms   198ms   -3.7%
                  SecondImport:   106ms   107ms   -1.1%   107ms   108ms   -1.1%
           SecondPackageImport:   118ms   117ms   +1.3%   119ms   118ms   +1.1%
         SecondSubmoduleImport:   154ms   156ms   -1.2%   156ms   157ms   -0.6%
       SimpleComplexArithmetic:    87ms    89ms   -1.9%    88ms    95ms   -7.4%
        SimpleDictManipulation:   180ms   176ms   +2.5%   183ms   178ms   +2.6%
         SimpleFloatArithmetic:    92ms    99ms   -7.3%    93ms   102ms   -9.0%
      SimpleIntFloatArithmetic:   127ms   127ms   -0.4%   128ms   129ms   -0.8%
       SimpleIntegerArithmetic:   127ms   136ms   -6.7%   128ms   138ms   -7.6%
      SimpleListComprehensions:   128ms   129ms   -0.4%   131ms   130ms   +0.2%
        SimpleListManipulation:    95ms   108ms  -12.5%    97ms   110ms  -11.6%
          SimpleLongArithmetic:    85ms    86ms   -2.0%    85ms    89ms   -4.4%
                    SmallLists:   154ms   153ms   +0.8%   157ms   156ms   +0.8%
                   SmallTuples:   159ms   157ms   +1.3%   161ms   159ms   +1.1%
         SpecialClassAttribute:   357ms   341ms   +4.8%   360ms   345ms   +4.3%
      SpecialInstanceAttribute:   110ms   113ms   -2.5%   111ms   115ms   -3.4%
                StringMappings:   293ms   312ms   -6.3%   298ms   315ms   -5.3%
              StringPredicates:   122ms   126ms   -2.6%   125ms   127ms   -1.9%
                 StringSlicing:   216ms   215ms   +0.5%   222ms   221ms   +0.8%
                     TryExcept:    76ms    71ms   +7.0%    77ms    71ms   +7.5%
                    TryFinally:    84ms    86ms   -1.2%    85ms    86ms   -1.4%
                TryRaiseExcept:    58ms    60ms   -3.4%    59ms    61ms   -3.6%
                  TupleSlicing:   174ms   158ms  +10.3%   181ms   162ms  +11.4%
                   WithFinally:   133ms   142ms   -6.2%   138ms   143ms   -3.8%
               WithRaiseExcept:   153ms   149ms   +2.6%   154ms   151ms   +2.0%
-------------------------------------------------------------------------------
Totals:                          6708ms  6772ms   -0.9%  6820ms  6897ms   -1.1%

(this=stock.out, other=why.out)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Sun Jan 11 17:10:05 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 16:10:05 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>
Message-ID: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

The attached patch is for sysmodule.c, it contains two changes:

1. The check whether stdin is a directory is rewritten without using
fstat(), which doesn't exist under CE.

2. Replacing sys.argv[0] with the full path is skipped, CE doesn't have
a current working dir or paths relative to it, so it must already be an
absolute path.

----------
components: Interpreter Core
files: python-2.7-wince-sysmodule.0.patch
keywords: patch
messages: 79600
nosy: eckhardt
severity: normal
status: open
title: Port sysmodule.c to MS Windows CE
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file12685/python-2.7-wince-sysmodule.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Sun Jan 11 17:19:53 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 11 Jan 2009 16:19:53 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1231690793.31.0.459117089503.issue4879@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes, if you think so.  But my intention was to indicate that 
the "nobuffering" is a special feature the user can turn off to resort 
to what could be considered normal, buffered, behaviour.

But either way is fine, and I'll be happy to change it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Sun Jan 11 17:24:58 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 11 Jan 2009 16:24:58 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1231691098.0.0.403864597772.issue4879@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Checked in as revision: 68532

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Sun Jan 11 17:36:36 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 16:36:36 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231691796.58.0.891270457894.issue4893@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

Okay, hopefully this patch is final. The last one was using 'errno' in
debug mode, but under CE using CreateThread() it should use
GetLastError(). I also took the liberty of saving that error information
for both variants directly after creating the thread fails, so
intermediate calls don't clobber that value.

Added file: http://bugs.python.org/file12686/python-2.7-wince-threads.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Sun Jan 11 17:44:07 2009
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 11 Jan 2009 16:44:07 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1231692247.85.0.29288708571.issue2320@psf.upfronthosting.co.za>


Changes by Martina Oefelein <Martina at oefelein.de>:


----------
nosy: +oefe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
_______________________________________

From report at bugs.python.org  Sun Jan 11 17:45:03 2009
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 11 Jan 2009 16:45:03 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1231692303.96.0.216137643415.issue1731717@psf.upfronthosting.co.za>


Changes by Martina Oefelein <Martina at oefelein.de>:


----------
nosy: +oefe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Sun Jan 11 18:33:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Jan 2009 17:33:55 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231695235.49.0.880998736303.issue4907@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not sure that this is desirable behaviour.  There's no such thing as a 
complex literal---only imaginary literals.  Why allow evaluation of 2+1j
but not of 2 + 1, or 2*1j.

In any case, I'm not sure that the patch behaves as intended.  For 
example,

>>> ast.literal_eval('2 + (3 + 4j)')
(5+4j)

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Sun Jan 11 18:37:23 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 11 Jan 2009 17:37:23 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231695443.96.0.128523294829.issue4753@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Here's a port of threadedceval5.patch to trunk. It passes the tests. I
haven't benchmarked this exact patch, but on one Intel Core2, a similar
patch got an 11%-14% speedup (on 2to3 and pybench).

I've also cleaned up Jakob Sievers' vmgen patch (representing
forth-style dispatch) a bit so that it passes all the tests, and on the
same machine it got a 13%-17% speedup. The vmgen patch is not quite at
feature parity (it throws out support for LLTRACE and a couple other
#defines), and there are fairly good arguments against committing it to
python at all (it requires installing and modifying vmgen to build), but
I'll post it after I've ported it to trunk.

Re skip and paolo: JITting and machine-specific assembly will probably
be important to speeding up Python in the long run, but they'll also
take a long while to get right, so we shouldn't let them distract us
from committing the dispatch optimization.

Added file: http://bugs.python.org/file12687/pitrou_dispatch_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan 11 19:00:22 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 11 Jan 2009 18:00:22 +0000
Subject: [issue4903] binascii.crc32() - document signed vs unsigned results
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231696822.56.0.19456486286.issue4903@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

binascii and zlib documentation updated in trunk r68535.  I'll close the 
issue after I've merged it into release26-maint, release30-maint and 
py3k.

Any objections to the wording?

http://svn.python.org/view/python/trunk/Doc/library/binascii.rst?
rev=68535&view=diff&r1=68535&r2=68534&p1=python/trunk/Doc/library/binasc
ii.rst&p2=/python/trunk/Doc/library/binascii.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4903>
_______________________________________

From report at bugs.python.org  Sun Jan 11 19:44:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 18:44:40 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231699480.28.0.220270538481.issue4893@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The introduction of "int e" is redundant now, right?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Sun Jan 11 19:49:55 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 18:49:55 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>
Message-ID: <1231699795.17.0.801413710014.issue4915@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The S_ISDIR test is to prevent the case

  python < /etc

Is it really possible to invoke Python in such a way on CE? If not, it
would be better if the entire test wasn't performed on CE. If it does
get performed, I think it would be better if the code kept a matching
number of parentheses (i.e. don't incorporate the opening curly bracket
into the conditional).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Sun Jan 11 19:57:46 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Jan 2009 18:57:46 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1231700266.23.0.630889548343.issue2504@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't see any change in Modules/_localemodule.c: you reimplemented 
pgettext() in pure Python. Why no reusing existing pgettext() function 
(at least when it's present)?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:00:36 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 19:00:36 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1231700436.91.0.55961970783.issue2504@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The gettext module is intentionally written in pure Python; it should
stay that way. Whether or not the _locale module should also grow
support for pgettext is a different issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:07:09 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Jan 2009 19:07:09 +0000
Subject: [issue4911] Windows installer Quad processor issues
Message-ID: <1231700829.24.0.978656105102.issue4911@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Could it be related to http://support.microsoft.com/kb/839547?

----------
nosy: +haypo
title: Quad processor issues -> Windows installer Quad processor issues

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4911>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:07:48 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 11 Jan 2009 19:07:48 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231700868.62.0.54853195601.issue4908@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

It looks like the best way to do this is to:

- make distutils.dist.DistributionMetadata also read existing egg-info files

- add get_metadata in pkgutil instead of distutils, and make it use 
  distutils.dist.DistributionMetadata

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:08:41 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Jan 2009 19:08:41 +0000
Subject: [issue4911] Windows installer Quad processor issues
Message-ID: <1231700921.88.0.983662681455.issue4911@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a duplicate of the issue #4735.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4911>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:09:11 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Jan 2009 19:09:11 +0000
Subject: [issue4735] An error occurred during the installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1231700951.99.0.7778110745.issue4735@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue 4911 is a duplicate of this issue.

Could the issue be related to http://support.microsoft.com/kb/839547?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4735>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:11:56 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Jan 2009 19:11:56 +0000
Subject: [issue4735] An error occurred during the installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1231701116.28.0.949607485447.issue4735@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also 
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=121817

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4735>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:15:00 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 11 Jan 2009 19:15:00 +0000
Subject: [issue4913] wave.py writes 16 bit sample files of half the correct
	duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231701300.57.0.801312744202.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Wave_read.initfp also needs fixing on counting the frame number, correct
me if its wrong.

Patch added.

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file12688/issue_4913.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:17:28 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 11 Jan 2009 19:17:28 +0000
Subject: [issue4913] wave.py writes 16 bit sample files of half the correct
	duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231701448.65.0.44649532782.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Oops, _framesize already takes sampwidth into account. So there is a
problem somewhere else, since reading the wave file is returning the
number of frames multiplied by the sampwidth.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:17:34 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 11 Jan 2009 19:17:34 +0000
Subject: [issue4913] wave.py writes 16 bit sample files of half the correct
	duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231701454.62.0.457732404563.issue4913@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file12688/issue_4913.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:39:30 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 11 Jan 2009 19:39:30 +0000
Subject: [issue4913] wave.py writes 16 bit sample files of half the correct
	duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231702770.39.0.620326119019.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Given the name of the function related to the problem: "writeframesraw",
it seems to be more correct to remove the sampwidth multiplication from
the other case (not add it in the other one), since you must already
pass the data multiplied by it.

Does that make sense to you Alex ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:47:59 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 11 Jan 2009 19:47:59 +0000
Subject: [issue4913] wave.py writes 16 bit sample files of half the correct
	duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231703279.37.0.198008196241.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Ah, yes :) But in the other case (the one where it is currently
multiplied) the multiplication happens because data is formatted to
either bytes, shorts or longs, so without the multiplication data length
would end up being divided by 1, 2 or 4.

So, besides the extras "if" statements all is good.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Sun Jan 11 20:57:13 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 19:57:13 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231703833.23.0.150691866393.issue4893@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

Actually, I made the distinction between the 'int e' and the 'unsigned 
e' consciously. When using 'errno', using an 'int' is correct. When 
using GetLastError(), I would have used a win32 DWORD if there was a 
format sequence that correctly and portably formats it, so I 
chose 'unsigned' as one that IMHO most likely matches it. That is also 
the reason for the two different error messages, otherwise I don't 
think it makes a big difference.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Sun Jan 11 21:05:24 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 20:05:24 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>
Message-ID: <1231704324.93.0.216806586561.issue4915@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

I don't really know what happens when you try to read()/fread() from 
stdin that is a directory, but I guess it will fail quickly even 
without an explicit check by Python. A directory can be opened under 
win32 just like a file, so I guess that you could also set one as 
stdin for a process. All in all, I don't care whether the check is 
made or not, but it doesn't hurt to be there either.

I'll submit a changed patch that has the opening curly brackets 
outside the conditional code. Thanks for the review, Martin, I 
appreciate your support on this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Sun Jan 11 21:15:17 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 20:15:17 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>
Message-ID: <1231704917.56.0.671075971143.issue4915@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

Changed patch with curly brackets outside the conditional code.

Added file: http://bugs.python.org/file12689/python-2.7-wince-sysmodule.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Sun Jan 11 21:17:29 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 20:17:29 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1231705049.49.0.82651393121.issue4449@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think Amaury's patch (mp_array_2.patch) is correct. If there is no
objection to its acceptance within the next two days, I think it should
be applied.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Sun Jan 11 21:22:01 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 20:22:01 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231703833.23.0.150691866393.issue4893@psf.upfronthosting.co.za>
Message-ID: <496A54E6.9090705@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Actually, I made the distinction between the 'int e' and the 'unsigned 
> e' consciously. When using 'errno', using an 'int' is correct. When
> using GetLastError(), I would have used a win32 DWORD if there was a 
> format sequence that correctly and portably formats it, so I 
> chose 'unsigned' as one that IMHO most likely matches it. 

That's all fine, but why do you need a variable named "e" in the first
place? Can't you leave the code as it was before?

> That is also 
> the reason for the two different error messages, otherwise I don't 
> think it makes a big difference.

Introducing an unnecessary variable should be avoided; this is just
cruft that accumulates. Please remove both variables.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Sun Jan 11 21:35:15 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 20:35:15 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231704324.93.0.216806586561.issue4915@psf.upfronthosting.co.za>
Message-ID: <496A57FE.9040906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't really know what happens when you try to read()/fread() from 
> stdin that is a directory, but I guess it will fail quickly even 
> without an explicit check by Python.

Without the explicit check, the interpreter crashed; this was the
reason to add the check in the first place. See issue 887946.

> A directory can be opened under 
> win32 just like a file, so I guess that you could also set one as 
> stdin for a process. 

I just tried to run

python.exe < c:\python25

on W2k3, and get "Access denied" (instead of getting the error
message of the Python interpreter). Indeed, it is apparently
*not* possible to open a directory just like a file under win32.
As

http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx

explains: you must pass FILE_FLAG_BACKUP_SEMANTICS, which
you normally don't pass.

Not sure whether this all applies to CE, though.

> All in all, I don't care whether the check is 
> made or not, but it doesn't hurt to be there either.

It does hurt. It clutters the code. So if it could be determined
that you can't open a directory at all with CreateFile on
Windows CE, then it would be better if the block was removed,
than fixed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Sun Jan 11 21:43:35 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 20:43:35 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231706615.56.0.124096260237.issue4893@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

> That's all fine, but why do you need a variable named "e" in
> the first place? Can't you leave the code as it was before?"

There is an intermediate call to a function that retrieves the 
thread's ID. That function may or may not change the output of 
GetLastError(). It probably won't change errno, since it is just 
implemented as a call to the win32 API GetCurrentThreadId(). Still, 
when I have a function that fails and provides additional info through 
errno or GetLastError(), I personally prefer to save that value ASAP 
instead of relying on the fact that some call in between doesn't touch 
it.

I don't really care too much about this piece of code, since it's just 
debug output, but in other cases (like #4906) making such distinction 
is crucial. Since people might read and copy the code, I prefer to 
give them a good example. If you feel differently, just drop me a note 
and I'll change it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Sun Jan 11 21:46:18 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 11 Jan 2009 20:46:18 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231706778.24.0.868863770223.issue4753@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Benchmarking pitrou_dispatch_2.7.patch applied to trunk r68522 on a 32-
bit Efficeon (x86) using gcc 4.2.4-1ubuntu3 yields a 10% pybench 
speedup.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan 11 22:25:48 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 21:25:48 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>
Message-ID: <1231709148.62.0.966755411595.issue4915@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

The CE documentation mentions directories, too, but is silent on the 
FILE_FLAG_BACKUP_SEMANTICS use for them. Also, even using that flag, I 
can't open a directory under CE. It seems that this check is 
superfluous there.

I can also confirm that you get an error if you try to redirect stdin 
via the commandline to a dir even before the executable is even 
launched. The only way to still have a dir as stdin could be to use 
CreateProcess(), but I'm neither sure nor do I care about such abuses.

Do you want to remove the whole check for MS Windows then? Are you 
otherwise comfortable with the second part of the patch, the one about 
resolving argv[0]?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Sun Jan 11 22:29:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 11 Jan 2009 21:29:10 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231709148.62.0.966755411595.issue4915@psf.upfronthosting.co.za>
Message-ID: <496A64A3.7070607@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Do you want to remove the whole check for MS Windows then?

Yes, please. A comment that you can't really redirect from a dir
on Win32 might be useful.

> Are you 
> otherwise comfortable with the second part of the patch, the one about 
> resolving argv[0]?

That's fine - I trust you that the code is not needed on CE.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Sun Jan 11 22:53:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 Jan 2009 21:53:46 +0000
Subject: [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

======================================================================
FAIL: testEncodedWrites (test.test_io.TextIOWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_io.py", line 1082, in
testEncodedWrites
    self.assertEquals(f.read(), data * 2)
AssertionError:
'\U00310000\U00320000\U00330000\U00340000\U00350000\U00360000\U00370000\U00380000\U00390000\U00300000\U00310000\U00320000\U00330000\U00340000\U00350000\U00360000\U00370000\U0038000090'
!= '12345678901234567890'

======================================================================
FAIL: testNewlines (test.test_io.TextIOWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_io.py", line 874, in testNewlines
    self.assertEquals(got_line, exp_line)
AssertionError: '\U00750000\U006e0000\U00690000\U00780000\n' != 'unix\n'

======================================================================
FAIL: test_newline_decoder (test.test_io.TextIOWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_io.py", line 1275, in
test_newline_decoder
    self.check_newline_decoder(decoder, enc)
  File "/temp/python/py3k/Lib/test/test_io.py", line 1263, in
check_newline_decoder
    self.assertEquals(decoder.decode("abc".encode(encoding)), "abc")
AssertionError: '\U00610000\U00620000c' != 'abc'

----------------------------------------------------------------------

----------
components: Interpreter Core
messages: 79630
nosy: benjamin.peterson
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_io is broken on UCS4
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4916>
_______________________________________

From report at bugs.python.org  Sun Jan 11 22:55:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 Jan 2009 21:55:20 +0000
Subject: [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231710920.13.0.421043872633.issue4916@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4916>
_______________________________________

From report at bugs.python.org  Sun Jan 11 23:10:37 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 22:10:37 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>
Message-ID: <1231711837.23.0.672353870816.issue4915@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

Next attempt, exclude all win variants from check.

Added file: http://bugs.python.org/file12690/python-2.7-wince-sysmodule.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Sun Jan 11 23:54:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Jan 2009 22:54:04 +0000
Subject: [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231714444.88.0.359200809272.issue4916@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ouch. What platform is this on?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4916>
_______________________________________

From report at bugs.python.org  Sun Jan 11 23:55:08 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 Jan 2009 22:55:08 +0000
Subject: [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231714508.15.0.0909551451052.issue4916@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

MacOS 10.4 PPC

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4916>
_______________________________________

From report at bugs.python.org  Sun Jan 11 23:59:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Jan 2009 22:59:04 +0000
Subject: [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231714744.71.0.206753069195.issue4916@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is because of the new utf16 decoding code. I'll post a patch soon.

----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4916>
_______________________________________

From report at bugs.python.org  Mon Jan 12 00:03:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Jan 2009 23:03:56 +0000
Subject: [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231715036.25.0.161973816048.issue4916@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you try with this one?

PS: do we have a buildbot with such a configuration?

----------
keywords: +patch
Added file: http://bugs.python.org/file12691/issue4916.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4916>
_______________________________________

From report at bugs.python.org  Mon Jan 12 00:52:48 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 11 Jan 2009 23:52:48 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231717968.5.0.71096708858.issue4908@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

heres a first simple draft, that works on .egg-info files,

(the Description extractor needs to rework, but this patch is enough to
discuss the feature)

----------
keywords: +patch
Added file: http://bugs.python.org/file12692/get_metadata.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Mon Jan 12 00:58:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Jan 2009 23:58:16 +0000
Subject: [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231718296.04.0.126609123483.issue4916@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Benjamin confirmed to me that the patch is ok, committing.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4916>
_______________________________________

From report at bugs.python.org  Mon Jan 12 01:13:55 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Jan 2009 00:13:55 +0000
Subject: [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231719235.53.0.015799358833.issue4916@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

In r68537.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4916>
_______________________________________

From report at bugs.python.org  Mon Jan 12 01:21:44 2009
From: report at bugs.python.org (O. Morvant)
Date: Mon, 12 Jan 2009 00:21:44 +0000
Subject: [issue4917] PyBytes_Format documented but doesn't exist in C/API
In-Reply-To: <1231719704.09.0.309980656756.issue4917@psf.upfronthosting.co.za>
Message-ID: <1231719704.09.0.309980656756.issue4917@psf.upfronthosting.co.za>


New submission from O. Morvant <olivier.morvant at neuf.fr>:

The C/API function PyBytes_Format(PyObject*, PyObject*) is documentated
in python 3.0 API (http://docs.python.org/3.0/c-api/bytes.html) at the
end of the Bytes Object description page. 

Examining the Python 3.0 source code, it can't be found in bytesobject.h
file or in any others files.

----------
assignee: theller
components: ctypes
messages: 79639
nosy: omorvant, theller
severity: normal
status: open
title: PyBytes_Format documented but doesn't exist in C/API
type: resource usage
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4917>
_______________________________________

From report at bugs.python.org  Mon Jan 12 01:23:01 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Jan 2009 00:23:01 +0000
Subject: [issue4917] PyBytes_Format documented but doesn't exist in C/API
In-Reply-To: <1231719704.09.0.309980656756.issue4917@psf.upfronthosting.co.za>
Message-ID: <1231719781.48.0.720727102751.issue4917@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: theller -> 
components: +Interpreter Core -ctypes
nosy:  -theller
type: resource usage -> feature request
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4917>
_______________________________________

From report at bugs.python.org  Mon Jan 12 01:28:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Jan 2009 00:28:51 +0000
Subject: [issue4917] PyBytes_Format documented but doesn't exist in C/API
In-Reply-To: <1231719704.09.0.309980656756.issue4917@psf.upfronthosting.co.za>
Message-ID: <1231720131.03.0.402644495528.issue4917@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

PyBytes_Format is not supported, so I removed the documentation in r68538.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4917>
_______________________________________

From report at bugs.python.org  Mon Jan 12 02:20:40 2009
From: report at bugs.python.org (Brian Thorne)
Date: Mon, 12 Jan 2009 01:20:40 +0000
Subject: [issue4508] distutils compiler not handling spaces in path to
	output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1231723240.44.0.0316121999448.issue4508@psf.upfronthosting.co.za>


Brian Thorne <hardbyte at gmail.com> added the comment:

Ok - this bug has nothing to do with weave itself. I think any extension
written in C or C++ that has a space in the filename will raise the
error in both windows and gnu/linux.
Here is a simple c extension with and without spaces. The one with
spaces in the filename fails to build on standard python. Whereas the
one without should build fine. Did for me on windows 2000 on both python
2.5 and 2.6 with and without spaces in their paths.

Added file: http://bugs.python.org/file12693/python_extension_bug.rar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4508>
_______________________________________

From report at bugs.python.org  Mon Jan 12 02:26:01 2009
From: report at bugs.python.org (Pablo Castagnino)
Date: Mon, 12 Jan 2009 01:26:01 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231723561.54.0.0483181622176.issue4881@psf.upfronthosting.co.za>


Pablo Castagnino <pablo.castagnino at gmail.com> added the comment:

the last post on that link is the point - python supports daylight
savings, but if
your city recently started using daylight savings, and didn't before,
then either
python or linux needs to be updated to know that.

I'm using Ubuntu Intrepid Ibex.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Mon Jan 12 05:07:20 2009
From: report at bugs.python.org (Alex Robinson)
Date: Mon, 12 Jan 2009 04:07:20 +0000
Subject: [issue4913] wave.py writes 16 bit sample files of half the correct
	duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231733240.59.0.817430451811.issue4913@psf.upfronthosting.co.za>


Alex Robinson <alex_python_org at tranzoa.com> added the comment:

Oh golly. I was confused. For some reason I was thinking
"writesamples()" when using "writeframes()".

So the current code reads ok. Which makes this "bug" a request for
writesamples() and readsamples() to be added to wave.py. They would
shield sleep deprived saps from the .wav file data frame format. :)


Here are python2.4-ish versions written for outside wave.py. Combos of 8
and 16 bit samples, mone and stereo, are tested. I did not test the
32-bit sample logic.

Sample values are expected to be +-32767 or +-128 ints (or +-2.x gig if
32-bit).


def readsamples(wf, nframes) :
    """ Read an array of number-of-channels normalized int sample
arrays. """

    wav = wf.readframes(nframes)

    if    wf.getsampwidth() == 4 :
        wav = struct.unpack("<%ul" % (len(wav) / 4), wav)
    elif  wf.getsampwidth() == 2 :
        wav = struct.unpack("<%uh" % (len(wav) / 2), wav)
    else :
        wav = struct.unpack("%uB"  %  len(wav),      wav)
        wav = [ s - 128 for s in wav ]

    nc  = wf.getnchannels()
    if  nc > 1  :
        wavs    = []
        for i in xrange(nc) :
            wavs.append([ wav[si] for si in xrange(0, len(wav), nc) ])
        pass
    else :
        wavs    = [ wav ]

    return(wavs)



def writesamples(wf, wavs) :
    """
        Write samples to the wave file.
        'wavs' looks like this:
               [ left_channel_samples,  right_channel_samples ]
            or [ left_channel_samples                         ]
            or   mono_samples
        This routine calls setnchannels() from information about 'wavs'
length.
    """

    if  wavs :
        if  len(wavs) not in [ 1, 2, 4 ] :
            wavs    = [ wavs, wv ]

        wf.setnchannels(len(wavs))

        if  len(wavs)   > 1 :
            wav         = []
            for w in zip(*wavs):
                wav    += w
            pass
        else :
            wav         = wavs[0]

        if    wf.getsampwidth() == 4 :
            ws  = array.array('l', [ s       for s in wav ])
        elif  wf.getsampwidth() == 2 :
            ws  = array.array('h', [ s       for s in wav ])
        else :
            ws  = array.array('B', [ s + 128 for s in wav ])

        ws  = ws.tostring()

        wf.writeframes(ws)

    pass

# end of code to edit and insert in wave.py

----------
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 05:36:42 2009
From: report at bugs.python.org (Alex Robinson)
Date: Mon, 12 Jan 2009 04:36:42 +0000
Subject: [issue4913] wave.py writes 16 bit sample files of half the correct
	duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231735002.67.0.780194538335.issue4913@psf.upfronthosting.co.za>


Alex Robinson <alex_python_org at tranzoa.com> added the comment:

Oh gob. I left a debug artifact in that code.

            wavs    = [ wavs, wv ]

needs to be without the 'wv'.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 05:51:37 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 12 Jan 2009 04:51:37 +0000
Subject: [issue3826] Problem with SocketIO for closing the socket
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1231735897.53.0.697666069457.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Committed all of our tests and the actual code to fix the problem from 
socket_real_close-5.patch in py3k r68539.

This still needs back porting to release30-maint assuming no other 
issues are found with it.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Mon Jan 12 06:09:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 12 Jan 2009 05:09:43 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231736983.1.0.475959968111.issue4881@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For Ubuntu Intrepid, you need the package tzdata 2008h-2ubuntu1
installed; it contains a correction for the Argentinian DST definition.
Intrepid itself only shipped with 2008h-2.

Closing this as third-party.

----------
resolution:  -> works for me
status: open -> closed
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Mon Jan 12 06:28:31 2009
From: report at bugs.python.org (Juha Rantanen)
Date: Mon, 12 Jan 2009 05:28:31 +0000
Subject: [issue4918] Windows installer created with Python 2.5 does not work
	with Python 2.6.1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>


New submission from Juha Rantanen <juha.rantanen at iki.fi>:

1. Create Windows installer with Python 2.5 from attached project.
2. Install it with Python 2.6.1.
3. The post-installer will fail with error message: 
*** run_installscript: internal error 0xFFFFFFFF ***

The code causing this is:

import socket

and the actual error is:

ImportError
DLL load failed: The specified module could not be found.
  File "<string>", line 6, in windows_binary_install
  File "c:\apps\python26\lib\socket.py", line 46, in <module>
    import _socket

If the installer is created with Python 2.6.1, it works fine. 

The problem was noticed in the Robot Framework project and the issue can
be found from http://code.google.com/p/robotframework/issues/detail?id=196.

This problem was first asked as part of issue
http://bugs.python.org/issue4566, but Martin v. L?wis recommended to
open new issue for this.

----------
components: Distutils
files: simple.zip
messages: 79647
nosy: rantanen
severity: normal
status: open
title: Windows installer created with Python 2.5  does not work with Python 2.6.1
versions: Python 2.6
Added file: http://bugs.python.org/file12694/simple.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4918>
_______________________________________

From report at bugs.python.org  Mon Jan 12 06:46:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 12 Jan 2009 05:46:12 +0000
Subject: [issue4918] Windows installer created with Python 2.5 does not work
	with Python 2.6.1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1231739172.71.0.407162473282.issue4918@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Was the 2.6 installation "for all users", or "just for me"? What Windows
version are you using?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4918>
_______________________________________

From report at bugs.python.org  Mon Jan 12 08:55:53 2009
From: report at bugs.python.org (Juha Rantanen)
Date: Mon, 12 Jan 2009 07:55:53 +0000
Subject: [issue4918] Windows installer created with Python 2.5 does not work
	with Python 2.6.1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1231746953.98.0.664841088711.issue4918@psf.upfronthosting.co.za>


Juha Rantanen <juha.rantanen at iki.fi> added the comment:

Python 2.6.1 was installed with option all users. I have admin rights
and the Windows version is:
XP Professional
Version 2002
Service Pack 3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4918>
_______________________________________

From report at bugs.python.org  Mon Jan 12 09:01:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Jan 2009 08:01:17 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231747277.17.0.967767439778.issue1696199@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Georg, could you give this a once over before I commit?  Thanks.

----------
assignee: rhettinger -> georg.brandl
nosy: +georg.brandl
Added file: http://bugs.python.org/file12695/counter5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 09:04:13 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 12 Jan 2009 08:04:13 +0000
Subject: [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>
Message-ID: <1231747453.61.0.959117714888.issue4915@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r68540, r68541.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4915>
_______________________________________

From report at bugs.python.org  Mon Jan 12 09:22:37 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 12 Jan 2009 08:22:37 +0000
Subject: [issue4893] Use separate thread support code under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231748557.33.0.532159711649.issue4893@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see. Whether the call to PyThread_get_thread_ident comes before the
access to errno (in the original version) depends on the compiler, of
course. Also, this function should be trusted to not affect the last
error, since it can't fail.

I've added a comment to explain what the variables are good for, and
committed the patch as r68542, r68543.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4893>
_______________________________________

From report at bugs.python.org  Mon Jan 12 09:25:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 12 Jan 2009 08:25:27 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231748727.46.0.908795770635.issue3582@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please add a Misc/NEWS entry for this change.

----------
assignee:  -> krisvale
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Mon Jan 12 10:14:51 2009
From: report at bugs.python.org (scott wedel)
Date: Mon, 12 Jan 2009 09:14:51 +0000
Subject: [issue4919] 2.6.1 build issues on solaris with SunStudio 12
In-Reply-To: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>
Message-ID: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>


New submission from scott wedel <taverngeek at gmail.com>:

The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm
instead of just -lm

Sun Studio 12 compiler also seems to choke on the PyByteArray_GET_SIZE
and _AS_STRING because those macros use the ',' operator to stuff an
assert before the pointer lookup.  When I remove the assert portion of
those macros then they compile fine.

The assertions in those macros appear a bit silly because some places
they are used already have prior assertions and I don't see the point of
the macro which appears to be to crash due to an assertion one statement
prior to the null pointer reference causing a crash.

The configure process also appeared to make a few mistakes such as not
finding uid_t because that is in <sys/types.h> and not in the presumed
header file.  If configure were to include the standard header files AND
the file that it expects to find the definition then it would be better
at finding what is defined.  I don't know why Sun does that.

----------
components: Build
messages: 79654
nosy: taverngeek
severity: normal
status: open
title: 2.6.1 build issues on solaris with SunStudio 12
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4919>
_______________________________________

From report at bugs.python.org  Mon Jan 12 10:15:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Jan 2009 09:15:28 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1231751728.93.0.64653478502.issue4910@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch against the py3k branch that gets rid of the two existing 
uses of nb_long in the core:

 - in PyNumber_Long, conversion was attempted first using nb_int and
   then using nb_long.  The patch simply removes the nb_long code, so
   int(x) no longer attempts to use the __long__ method for conversion.

 - in Modules/_struct.c, there's a call to nb_long in a function that's
   attempting to turn an arbitrary PyObject into a PyLongObject;  the
   patch replaces this with nb_int (and updates an error message).

 - In Lib/test/test_long.py, __long__ has been replaced with __int__
   in a test that __int__/__long__ takes precedence over __trunc__
   for conversion to int.

With this patch, all tests pass on my (OS X 10.5/Intel) machine.
(Except test_socket, but I'm 97.2% certain that's unrelated.)

If someone can review this quickly I'll move on to the next patch towards 
removing nb_long.  (My issue #1717 experience suggests that it ought to be 
easier to effect the removal via a series of 3 or 4 short, easy-to-review 
patches with clear intent than via one bigger, more confused patch.)

I think it would be good if nb_long could be altered before 3.0.1.

Benjamin, do you have time to take a look?

----------
assignee:  -> benjamin.peterson
keywords: +patch
nosy: +benjamin.peterson
priority:  -> critical
title: Should both nb_long and nb_int still exist in 3.x? -> Remove uses of nb_long slot, and rename to nb_reserved.
type:  -> behavior
Added file: http://bugs.python.org/file12696/issue4910_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Mon Jan 12 10:19:59 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 12 Jan 2009 09:19:59 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231751999.66.0.751252828318.issue3582@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Note, see defect 4906 for fallout caused by this checkin.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Mon Jan 12 10:21:02 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 12 Jan 2009 09:21:02 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231752062.37.0.852123859247.issue3582@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Misc/NEWS updated in revision: 68544

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Mon Jan 12 10:24:34 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 12 Jan 2009 09:24:34 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1231752274.27.0.822786618407.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Added MISC/News entry in revision: 68545

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Mon Jan 12 11:14:59 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Jan 2009 10:14:59 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1231755299.55.0.34630183833.issue4910@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That was a pretty poor patch.  Here's a better one:

 - added Misc/NEWS entry
 - added tests to check that __long__ is never called
 - removed Modules/_struct.c change, in the interests of
   keeping the patch focused.

Added file: http://bugs.python.org/file12697/issue4910_1a.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Mon Jan 12 11:36:06 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 Jan 2009 10:36:06 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231756566.23.0.684848810107.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Documentation, tests and patch against trunk are needed to get this into
Python, but to me the request is fine.

----------
title: wave.py writes 16 bit sample files of half the correct duration -> wave.py: add writesamples() and readsamples()
versions:  -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 11:40:30 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 12 Jan 2009 10:40:30 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231756830.32.0.73271721832.issue1696199@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, I'll have a look this evening.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 11:42:55 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 Jan 2009 10:42:55 +0000
Subject: [issue1483545] Wave.py support for ulaw and alaw audio
Message-ID: <1231756975.2.0.559141962955.issue1483545@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
type:  -> feature request
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483545>
_______________________________________

From report at bugs.python.org  Mon Jan 12 11:43:30 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 Jan 2009 10:43:30 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231757010.99.0.631733737277.issue4913@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:10:09 2009
From: report at bugs.python.org (Jaroslaw Rosiek)
Date: Mon, 12 Jan 2009 11:10:09 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>


New submission from Jaroslaw Rosiek <jaroslaw.rosiek at interia.pl>:

1. collections.MutableSet refers to __next__() slot instead of next()
buildin. 

2. collection.Iterator is not compatible with 2.6's iterators which
should have next() slot. Proposed solution: add a next() method to
collections.Iterator that falls back to __next__().

Attaching:
  1. Example code for problem 1
  2. Example code for problem 2
  3. A patch

When are you planning next bugfix release for 2.6 (I am particularly
interested in these issues :))?

----------
components: Library (Lib)
files: example1.py
messages: 79662
nosy: jrosiek
severity: normal
status: open
title: Inconsistent usage of next/__next__ in ABC collections; collections.Iterator is not compatible with Python 2.6 iterators.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12698/example1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:10:38 2009
From: report at bugs.python.org (Jaroslaw Rosiek)
Date: Mon, 12 Jan 2009 11:10:38 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1231758638.85.0.663688429707.issue4920@psf.upfronthosting.co.za>


Changes by Jaroslaw Rosiek <jaroslaw.rosiek at interia.pl>:


Added file: http://bugs.python.org/file12699/example2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:10:47 2009
From: report at bugs.python.org (Jaroslaw Rosiek)
Date: Mon, 12 Jan 2009 11:10:47 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1231758647.72.0.875869449531.issue4920@psf.upfronthosting.co.za>


Changes by Jaroslaw Rosiek <jaroslaw.rosiek at interia.pl>:


Removed file: http://bugs.python.org/file12699/example2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:11:03 2009
From: report at bugs.python.org (Jaroslaw Rosiek)
Date: Mon, 12 Jan 2009 11:11:03 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1231758663.75.0.213695145674.issue4920@psf.upfronthosting.co.za>


Changes by Jaroslaw Rosiek <jaroslaw.rosiek at interia.pl>:


Added file: http://bugs.python.org/file12700/example2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:13:18 2009
From: report at bugs.python.org (Jaroslaw Rosiek)
Date: Mon, 12 Jan 2009 11:13:18 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1231758798.66.0.178723122244.issue4920@psf.upfronthosting.co.za>


Changes by Jaroslaw Rosiek <jaroslaw.rosiek at interia.pl>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12701/_abcoll.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:16:21 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Jan 2009 11:16:21 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231758981.47.0.86276746301.issue1696199@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching an update with improved docs.  Thanks for looking at this.

Added file: http://bugs.python.org/file12702/counter6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:16:34 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Jan 2009 11:16:34 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231758994.33.0.610334905866.issue1696199@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12671/counter4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:16:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Jan 2009 11:16:40 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231759000.17.0.854276700762.issue1696199@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file12695/counter5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:19:17 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 12 Jan 2009 11:19:17 +0000
Subject: [issue4921] Object lifetime and inner recursive function
In-Reply-To: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>
Message-ID: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Hello. Sorry if this is noise. I expected

__del__
out of function
__del__
out of function
__del__
out of function

on following code, but actually I got

out of function
out of function
out of function
__del__
__del__
__del__

Is this expected behavoir? (I believed `a' would be
freed after returned from f(), so I was suprised)

If I remove the comment of gc.collect(), the code works as expected.

///////////////////////////////

import gc

class A:
    def __del__(self):
        print("__del__")

def f():
    a = A()
    def g():
        a
        g()

def main():
    for _ in range(3):
        f()
#       gc.collect()
        print("out of function")

if __name__ == '__main__':
    main()

----------
components: Interpreter Core
messages: 79664
nosy: ocean-city
severity: normal
status: open
title: Object lifetime and inner recursive function
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4921>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:24:00 2009
From: report at bugs.python.org (Jaroslaw Rosiek)
Date: Mon, 12 Jan 2009 11:24:00 +0000
Subject: [issue4922] set.add and set.discard are not conformant to
	collections.MutableSet interface
In-Reply-To: <1231759440.37.0.125734005136.issue4922@psf.upfronthosting.co.za>
Message-ID: <1231759440.37.0.125734005136.issue4922@psf.upfronthosting.co.za>


New submission from Jaroslaw Rosiek <jaroslaw.rosiek at interia.pl>:

Methods set.add and set.discard should return boolean values according
to collections.MutableSet but they are not.

>>> print set().add(5)
None
>>> print set().discard(5)
None

----------
components: Library (Lib)
messages: 79665
nosy: jrosiek
severity: normal
status: open
title: set.add and set.discard are not conformant to collections.MutableSet interface
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4922>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:31:13 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Jan 2009 11:31:13 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1231759873.78.0.89271247195.issue4920@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Good catch!

----------
nosy: +rhettinger
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:31:21 2009
From: report at bugs.python.org (Riccardo Attilio Galli)
Date: Mon, 12 Jan 2009 11:31:21 +0000
Subject: [issue4923] time.strftime documentation needs update
In-Reply-To: <1231759881.41.0.312941806858.issue4923@psf.upfronthosting.co.za>
Message-ID: <1231759881.41.0.312941806858.issue4923@psf.upfronthosting.co.za>


New submission from Riccardo Attilio Galli <riquito at gmail.com>:

there are discrepancies in the online documentation of
  strftime
in time.strftime http://docs.python.org/library/time.html
and datetime.strftime (http://docs.python.org/library/datetime.html)

In particular, seems like datetime.strftime is the one up to date,
having format codes %f and %z documented, and possibly others

----------
assignee: georg.brandl
components: Documentation
messages: 79667
nosy: georg.brandl, riquito
severity: normal
status: open
title: time.strftime documentation needs update
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4923>
_______________________________________

From report at bugs.python.org  Mon Jan 12 12:32:55 2009
From: report at bugs.python.org (Alex Robinson)
Date: Mon, 12 Jan 2009 11:32:55 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231759975.87.0.699040221453.issue4913@psf.upfronthosting.co.za>


Alex Robinson <alex_python_org at tranzoa.com> added the comment:

I might be able to do doc/test/patch in a month or two, but know
zero.zero about the process so would expect it to take far more than a
few hours when I do have time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 13:02:16 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 Jan 2009 12:02:16 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231761736.02.0.961464477836.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I could do it, but I'm in disagreement with big part of your patch.

Can you add some kind of test you used for it ? Raw data, sample file,
or something like this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 13:21:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Jan 2009 12:21:42 +0000
Subject: [issue4921] Object lifetime and inner recursive function
In-Reply-To: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>
Message-ID: <1231762902.14.0.443502484483.issue4921@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Since g calls "itself" in its own scope, it is stored as one of its own
cell vars, which creates a reference cycle. a is also part of its
reference cycle for the same reason, so it must wait for garbage
collection to be reclaimed.

If g didn't keep a reference to its cell vars, closures wouldn't be
possible, because the cell vars wouldn't survive the end of f's scope.

(g doesn't have to be recursive, it's enough that it makes a reference
to itself in its own scope:

def f():
    a = A()
    def g():
        a
        g

or even:

def f():
    a = A()
    def g():
        a
        h
    h = g

)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4921>
_______________________________________

From report at bugs.python.org  Mon Jan 12 13:57:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Jan 2009 12:57:46 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1231765066.74.0.906094185794.issue812369@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looking at the patch, is there any reason it doesn't get rid of the
current _PyModule_Clear() implementation to replace it by a call to
PyDict_Clear() followed by PyGC_Collect()?
(the call to PyGC_Collect could be disabled while finalizing, because
there's no use calling it as many times as there are modules to be
disbanded)

The major annoyance with the current scheme is that, at interpreter
shutdown, some globals you want to rely on in your destructors suddenly
become None.

About what to do of gc.garbage at shutdown, there was another proposal
in #477863.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Mon Jan 12 13:58:17 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 12 Jan 2009 12:58:17 +0000
Subject: [issue4921] Object lifetime and inner recursive function
In-Reply-To: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>
Message-ID: <1231765097.03.0.601557837636.issue4921@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for explanation. The combination of inner function + method 
variable was very handy for me, but maybe I should refrain from using 
it lightly. :-(

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4921>
_______________________________________

From report at bugs.python.org  Mon Jan 12 14:03:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Jan 2009 13:03:34 +0000
Subject: [issue4924] gc.collect() won't always collect as expected
In-Reply-To: <1231765413.97.0.063026202194.issue4924@psf.upfronthosting.co.za>
Message-ID: <1231765413.97.0.063026202194.issue4924@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I haven't verified this through any test (actually I'm wondering how to
deterministically reproduce it), but logically there are cases where
gc.collect() (and, similarly, PyGC_Collect()) won't work as advertised.

Specifically, when the GC is asked to collect a given generation but a
younger generation is already being collected, collect() will simply
notice this and return 0. However, only the younger generation will have
been collected, not the generation asked by the user.

It wouldn't take too much effort to make gc.collect() and PyGC_Collect()
truely deterministic.

----------
messages: 79673
nosy: pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: gc.collect() won't always collect as expected
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4924>
_______________________________________

From report at bugs.python.org  Mon Jan 12 14:22:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 12 Jan 2009 13:22:34 +0000
Subject: [issue4924] gc.collect() won't always collect as expected
In-Reply-To: <1231765413.97.0.063026202194.issue4924@psf.upfronthosting.co.za>
Message-ID: <1231766554.88.0.577972764197.issue4924@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It should be possible to trigger this by invoking gc.collect in an
__del__ implementation of an object that is attached to a cycle.

However, I don't think this is an important issue; +0 for resolving this
by documenting the status quo (instead of making the implementation
match the documentation).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4924>
_______________________________________

From report at bugs.python.org  Mon Jan 12 14:31:01 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Jan 2009 13:31:01 +0000
Subject: [issue881261] Overflow in Python Profiler
Message-ID: <1231767061.71.0.417610439849.issue881261@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

on POSIX, clock() indeed wraps around after some time.
This was corrected with issue645894, and is available since python 2.5.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> better timer resolution for profile.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue881261>
_______________________________________

From report at bugs.python.org  Mon Jan 12 15:28:58 2009
From: report at bugs.python.org (Ray)
Date: Mon, 12 Jan 2009 14:28:58 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231770538.22.0.0275652051626.issue4908@psf.upfronthosting.co.za>


Ray <rayjohnterrill at gmail.com> added the comment:

The patch didn't install correctly using 'patch', but I manually merged
the changes into my environment (Ubuntu 8.10 running 2.5.2) - I'll
upload the diff rejections if they'll be helpful.

After installing, I attempted to use the new code to determine the
version number, and am receiving 'None' as my result.  After looking
through the code, I believe its looking for a '.egg-info' file, but my
custom package doesn't have one (it was installed using 'easy_install' -
easy_install -z <package_name>), so it looks like that info is instead
stored in EGG_INFO/PKG-INFO within the egg itself.

Here's a dir dump of my installed egg:
my_package-1.0-py2.5.egg/
|-- EGG-INFO
|   |-- PKG-INFO
|   |-- SOURCES.txt
|   |-- dependency_links.txt
|   |-- top_level.txt
|   `-- zip-safe
|-- my_package.py
`-- my_package.pyc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Mon Jan 12 15:34:42 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Jan 2009 14:34:42 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231770882.7.0.469426814052.issue4908@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

yes the patch doesn't treat the eggs installed with easy_install yet,
just plain distutils

I'll let you know when EGG_INFO/PKG-INFO is ready (should be in the
coming days)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Mon Jan 12 15:37:35 2009
From: report at bugs.python.org (Alex Robinson)
Date: Mon, 12 Jan 2009 14:37:35 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231771055.2.0.328768975947.issue4913@psf.upfronthosting.co.za>


Alex Robinson <alex_python_org at tranzoa.com> added the comment:

Polo: "I could do it, but I'm in disagreement with big part of your patch."

Why surely you can't mean the bug. :) (The test program has it fixed.)

What is the disagreement?

Apparently this bug system allows file attachments, so I will upload a
test program and wave file.

The program is hard coded to read the wave file and write a bunch of
wave files, the names of which describe what they sound like.

Added file: http://bugs.python.org/file12703/wave_futz.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 15:53:56 2009
From: report at bugs.python.org (Ray)
Date: Mon, 12 Jan 2009 14:53:56 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231772036.84.0.987020047144.issue4908@psf.upfronthosting.co.za>


Ray <rayjohnterrill at gmail.com> added the comment:

I've tested it out using the straight distutils installation, and it
works great!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Mon Jan 12 16:08:25 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 12 Jan 2009 15:08:25 +0000
Subject: [issue4921] Object lifetime and inner recursive function
In-Reply-To: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>
Message-ID: <1231772905.18.0.390990818537.issue4921@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

A little followup. Attached script q112.py (some puzzle program) ate up 
my RAM (80MB) and never ran GC while solving. Current python GC looks 
at the number of GC objects, but GC object like set object can contain 
many non GC object, so... I feel it would be nice if there is better GC 
triger/timing.

Added file: http://bugs.python.org/file12704/q112.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4921>
_______________________________________

From report at bugs.python.org  Mon Jan 12 16:34:31 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 Jan 2009 15:34:31 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231774471.95.0.552352281523.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Aren't 8 bit samples stored as unsigned bytes ? If yes, they don't range
between -128 and 127 (first disagreement). So this line: wav = [ s - 128
for s in wav ] and the respective one (that adds +128 in writesamples)
should go.

Why is this check: "if len(wavs) not in [ 1, 2, 4 ]" needed ?

Calling setnchannels inside writesamples looks very wrong to me, weren't
you going to writesamples ? Then why is it modified the number of
channels ? The caller should be responsible for calling setnchannels,
besides, what is the use of calling setnchannels here ?

I see writesamples is expecting "wavs" to be a list of lists containing
integers, is that the best format to expect ? writeframes works with
strings (which are actually byte strings).

The code layout didn't help me to get in agreement with it either.

The above paragraphs are the things I disagree with the patch, hopefully
you can help on those questions. Also, it would be better to hand write
the wave file for testing so we can be sure about its content without
needing much analysis.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 16:39:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Jan 2009 15:39:24 +0000
Subject: [issue1403068] cannot import extension module with Purify
Message-ID: <1231774764.21.0.286003275996.issue1403068@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Newer versions of Purify seem to convert the file name to uppercase
letters (PYTHON27__D$Purify...), so the error is does not occur anymore.
The current code is fragile though...

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1403068>
_______________________________________

From report at bugs.python.org  Mon Jan 12 17:03:19 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 12 Jan 2009 16:03:19 +0000
Subject: [issue4760] cmp gone documentations
In-Reply-To: <1230436607.02.0.835606741355.issue4760@psf.upfronthosting.co.za>
Message-ID: <1231776199.67.0.197281008447.issue4760@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

http://docs.python.org/dev/3.1/library/unittest.html#module-unittest

Search for "cmp".  There are two references.  I apologize if I
misunderstand issue 1717,

----------
title: cmp gone---What's new in 3.1 -> cmp gone documentations

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4760>
_______________________________________

From report at bugs.python.org  Mon Jan 12 17:26:57 2009
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 12 Jan 2009 16:26:57 +0000
Subject: [issue4925] Improve error message of subprocess
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

I think the following error output unsatisfactory as it does not give me
any hint what file was not found:

$ fetch_quals.py blah.txt 
Traceback (most recent call last):
  File "/home/mmokrejs/bin/fetch_quals.py", line 15, in <module>
    _p1 = subprocess.Popen(['query_tracedb', 'retrieve', 'quality',
_id], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
  File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
    errread, errwrite)
  File "/usr/lib/python2.5/subprocess.py", line 1091, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
$

I know now that I had to specify full path tot he binary or include
shell=True argument but anyway, please improve the error message.

----------
components: Extension Modules
messages: 79684
nosy: mmokrejs
severity: normal
status: open
title: Improve error message of subprocess
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Mon Jan 12 18:17:13 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 12 Jan 2009 17:17:13 +0000
Subject: [issue4925] Improve error message of subprocess
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1231780633.49.0.635295840262.issue4925@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

Related, but outside python realm, this error likewise confuses:

$ cat <<EOF > s.sh
#! invalid path
echo hi
EOF
$ ./s.sh 
zsh: no such file or directory: ./s.sh

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Mon Jan 12 18:18:48 2009
From: report at bugs.python.org (Alex Robinson)
Date: Mon, 12 Jan 2009 17:18:48 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231780728.69.0.979790939194.issue4913@psf.upfronthosting.co.za>


Alex Robinson <alex_python_org at tranzoa.com> added the comment:

"8 bit samples stored as unsigned bytes"?
8 bit samples are 0..255 in the file. But to work with them, you'll want
them -128..127. The code assumes DC==0 sample values for simplicity.

"if len(wavs) not in [ 1, 2, 4 ]" ?
That way if you're working with mono, you can simply pass your samples
down to writesamples() without having to remember to "[ samples ]" them.
If you forget, no big deal. It's too bad that readsamples() can't know
that you want only mono samples. That would make mono work simpler.
Anyway, I don't argue very strongly for this spiff. In some ways it's
worse to be there. After all, the caller may be writing 1 frame at a
time, though I don't think that such logic would work. And would be
pretty slow, too, probably.

"Calling setnchannels"?
Since the number of channels *must* be the number of sample arrays
passed to writesamples(), either writesamples() must rely on the caller
already having gratuitously set the number of channels (correctly), or
writesamples() can simply force the issue. If the caller set the number
of channels wrongly, then the output file will be corrupt or
writesamples() would need to raise an exception. Both just make work for
the caller. get/set_nchannels() are not particularly useful if you are
using the read/write_sample API. If there were no ..frame() API,
getnchannels() might still be handy to use to find out how many channels
a wave file being read has before any samples have been read. But that's
about it.

"integers, is that the best format"?
Far bettern than the byte stream form which is useless, confusing, error
prone, and exposes the internal wave file format to the caller who could
generally care less how a wave file stores the samples. But, you bring
up a very good point, I think. I forgot to int(s) the samples when they
are put in to the arrays. The reason for an int() call on all the
samples is so that the caller can deal with samples as floats. (Which is
how he will want to deal with them if he's doing anything interesting.)
So, this:
            ws  = array.array('l', [ int(s)       for s in wav ])
            ws  = array.array('h', [ int(s)       for s in wav ])
            ws  = array.array('B', [ int(s + 128) for s in wav ])
And, for testing, in normalize_samples():
        samps   = [ s * mxm for s in samps ]
So normalize_samples() always sends floats to writesamples().


"The code layout"?
:) Well. Whatever. I know that the "official" python thing is to push
colons left. I don't like that. I've experimented in the last few years
with doing a lot of vertical alignment. Over time, I've found that it is
a great way to do things. It's pretty amazing how much easier it is to
scan and read code that has, as a start, the "="'s vertically aligned.
And, over the last few years, I've put more and more blank lines in.
Vertically compressed code tends to look like assembler language. I edit
with 200+ character wide screen so, since I stopped forcing everything
to fit on TTY, text mode CGA, or punch cards, I've lost a taste for
narrow code. In fact, I personally have a real hard time reading
line-broken code. That said, multi-lining "if" statements in ways that
allow delete/insert of lines, 1 for each "operator ()" expression, can
be very nice. Calls to routines with a gob of parameters, each on a
separate line, can sure be a good way to deal with a bad thing (routines
that take a lot of params are bad, that is). Etc. Anyway, I assumed that
the code would be reformatted by whomever maintains wave.py. No biggy.

"hand write the wave file for testing"?
Good point! Allows a test to do things like odd numbers of frames, 1
frame, max'ed out sample values, long runs of silence, DC offsets, etc.
Do you know whether there are already test files for wave.py? They'd
have those sorts of things in them. Hmmm. It's odd that wave.py doesn't
run from the command line and dump the header or something, at least.
Maybe do some simple conversions (8/16, mono/stereo switches, reverses
... that sort of thing). Would be handy.


This code is not tested on a big-endian machine. I ran it under XP
(py2.4) and Ubuntu64 (py2.5) and all the output files CRC the same on
both PCs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 18:55:15 2009
From: report at bugs.python.org (Fernando Gomes)
Date: Mon, 12 Jan 2009 17:55:15 +0000
Subject: [issue1168055] Add current dir when running try_run test program
Message-ID: <1231782915.89.0.598515155558.issue1168055@psf.upfronthosting.co.za>


Fernando Gomes <fgsj74 at gmail.com> added the comment:

Dear Community,
I'd fronted problems to install Statistics module on my Ubuntu.
There are errors that are hard to solve without an expert help, such as
the one received from Michiel (Thank you again!!!).
Errors are listed below:

# XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
oot at fgsj-IMA:/usr/lib/python2.5/statistics-0.19# python setup.py config
running config
 ============= begin statistics configuration ================
unable to execute _configtest: No such file or directory
libm does not contain erf; skipping this feature
unable to execute _configtest: No such file or directory
libm does not contain erfc; skipping this feature
 ============= end statistics configuration ==================
wrote config file (src/config.h)
root at fgsj-IMA:/usr/lib/python2.5/statistics-0.19# python setup.py build
running build
running build_ext
building 'statistics' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -Isrc
-I/usr/lib/python2.5/site-packages/numpy/core/include
-I/usr/include/python2.5
-c src/statisticsmodule.c -o
build/temp.linux-i686-2.5/src/statisticsmodule.o
src/statisticsmodule.c:1:20: error: Python.h: No such file or directory
In file included from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
                from src/statisticsmodule.c:2:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:100:2:
error: #error Must use Python with unicode enabled.
In file included from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
                from src/statisticsmodule.c:2:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:920:
error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:921:
error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?npy_uintp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1013:
error:
expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?*? token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1014:
error:
expected ?)? before ?*? token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1016:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1016:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1017:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1027:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1027:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1029:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1029:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1030:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1032:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1037:
error:
expected ?)? before ?*? token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1042:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1044:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1045:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1045:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1047:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1051:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1053:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1054:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1055:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1056:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1056:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1057:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1057:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1061:
error:
expected specifier-qualifier-list before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1074:
error:
expected specifier-qualifier-list before ?PyArray_GetItemFunc?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1175:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1207:
error:
expected specifier-qualifier-list before ?PyObject?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1217:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1242:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1250:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1257:
error:
expected declaration specifiers or ?...? before ?PyObject?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1399:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1546:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1600:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1813:
error:
expected specifier-qualifier-list before ?npy_intp?
In file included from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1828,
                from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
                from src/statisticsmodule.c:2:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:403:
error: ?NULL? undeclared here (not in a function)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:
In function ?_import_array?:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
error: ?PyObject? undeclared (first use in this function)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
error: (Each undeclared identifier is reported only once
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
error: for each function it appears in.)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
error: ?numpy? undeclared (first use in this function)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
warning: implicit declaration of function ?PyImport_ImportModule?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:961:
error: ?c_api? undeclared (first use in this function)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:963:
warning: implicit declaration of function ?PyObject_GetAttrString?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:964:
warning: implicit declaration of function ?Py_DECREF?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:965:
warning: implicit declaration of function ?PyCObject_Check?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:966:
warning: implicit declaration of function ?PyCObject_AsVoidPtr?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:973:
warning: implicit declaration of function ?PyErr_Format?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:973:
error: ?PyExc_RuntimeError? undeclared (first use in this function)
src/statisticsmodule.c: At top level:
src/statisticsmodule.c:14: error: expected ?)? before ?*? token
src/statisticsmodule.c:71: error: expected ?)? before ?*? token
src/statisticsmodule.c: In function ?find_mnemonic?:
src/statisticsmodule.c:117: warning: implicit declaration of function
?strlen?
src/statisticsmodule.c:117: warning: incompatible implicit declaration of
built-in function ?strlen?
src/statisticsmodule.c:119: warning: implicit declaration of function
?malloc?
src/statisticsmodule.c:119: warning: incompatible implicit declaration of
built-in function ?malloc?
src/statisticsmodule.c:120: warning: implicit declaration of function
?strcpy?
src/statisticsmodule.c:120: warning: incompatible implicit declaration of
built-in function ?strcpy?
src/statisticsmodule.c:121: warning: implicit declaration of function
?tolower?
src/statisticsmodule.c:123: warning: implicit declaration of function
?strcmp?
src/statisticsmodule.c:134: warning: implicit declaration of function ?free?
src/statisticsmodule.c:134: warning: incompatible implicit declaration of
built-in function ?free?
src/statisticsmodule.c: At top level:
src/statisticsmodule.c:152: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?parse_integer?
src/statisticsmodule.c:227: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:445: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:646: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:840: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:985: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1046: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1115: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1195: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1292: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1490: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1650: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1821: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:2013: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:2057: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:2181: error: array type has incomplete element type
src/statisticsmodule.c:2182: error: ?PyCFunction? undeclared here (not in a
function)
src/statisticsmodule.c:2182: error: expected ?}? before ?py_mean?
src/statisticsmodule.c:2183: error: expected ?}? before ?py_median?
src/statisticsmodule.c:2184: error: expected ?}? before ?py_variance?
src/statisticsmodule.c:2185: error: expected ?}? before ?py_covariance?
src/statisticsmodule.c:2186: error: expected ?}? before ?py_correlation?
src/statisticsmodule.c:2187: error: expected ?}? before ?py_regression?
src/statisticsmodule.c:2188: error: expected ?}? before ?py_bandwidth?
src/statisticsmodule.c:2189: error: expected ?}? before ?py_pdf?
src/statisticsmodule.c:2190: error: expected ?}? before ?py_cpdf?
src/statisticsmodule.c:2191: error: expected ?}? before ?py_cpdfc?
src/statisticsmodule.c: In function ?initstatistics?:
src/statisticsmodule.c:2202: warning: implicit declaration of function
?PyErr_Print?
src/statisticsmodule.c:2202: warning: implicit declaration of function
?PyErr_SetString?
src/statisticsmodule.c:2202: error: ?PyExc_ImportError? undeclared
(first use
in this function)
src/statisticsmodule.c:2203: warning: implicit declaration of function
?Py_InitModule3?
src/statisticsmodule.c:2204: warning: implicit declaration of function
?PyErr_Occurred?
src/statisticsmodule.c:2204: warning: implicit declaration of function
?Py_FatalError?
error: command 'gcc' failed with exit status 1
root at fgsj-IMA:/usr/lib/python2.5/statistics-0.19# python setup.py install
running install
running build
running build_ext
building 'statistics' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -Isrc
-I/usr/lib/python2.5/site-packages/numpy/core/include
-I/usr/include/python2.5
-c src/statisticsmodule.c -o
build/temp.linux-i686-2.5/src/statisticsmodule.o
src/statisticsmodule.c:1:20: error: Python.h: No such file or directory
In file included from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
                from src/statisticsmodule.c:2:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:100:2:
error: #error Must use Python with unicode enabled.
In file included from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
                from src/statisticsmodule.c:2:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:920:
error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:921:
error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?npy_uintp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1013:
error:
expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?*? token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1014:
error:
expected ?)? before ?*? token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1016:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1016:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1017:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1027:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1027:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1029:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1029:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1030:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1032:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1037:
error:
expected ?)? before ?*? token
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1042:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1044:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1045:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1045:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1047:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1051:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1053:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1054:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1055:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1056:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1056:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1057:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1057:
error:
expected declaration specifiers or ?...? before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1061:
error:
expected specifier-qualifier-list before ?npy_intp?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1074:
error:
expected specifier-qualifier-list before ?PyArray_GetItemFunc?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1175:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1207:
error:
expected specifier-qualifier-list before ?PyObject?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1217:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1242:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1250:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1257:
error:
expected declaration specifiers or ?...? before ?PyObject?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1399:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1546:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1600:
error:
expected specifier-qualifier-list before ?PyObject_HEAD?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1813:
error:
expected specifier-qualifier-list before ?npy_intp?
In file included from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1828,
                from
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
                from src/statisticsmodule.c:2:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:403:
error: ?NULL? undeclared here (not in a function)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:
In function ?_import_array?:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
error: ?PyObject? undeclared (first use in this function)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
error: (Each undeclared identifier is reported only once
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
error: for each function it appears in.)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
error: ?numpy? undeclared (first use in this function)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:960:
warning: implicit declaration of function ?PyImport_ImportModule?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:961:
error: ?c_api? undeclared (first use in this function)
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:963:
warning: implicit declaration of function ?PyObject_GetAttrString?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:964:
warning: implicit declaration of function ?Py_DECREF?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:965:
warning: implicit declaration of function ?PyCObject_Check?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:966:
warning: implicit declaration of function ?PyCObject_AsVoidPtr?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:973:
warning: implicit declaration of function ?PyErr_Format?
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:973:
error: ?PyExc_RuntimeError? undeclared (first use in this function)
src/statisticsmodule.c: At top level:
src/statisticsmodule.c:14: error: expected ?)? before ?*? token
src/statisticsmodule.c:71: error: expected ?)? before ?*? token
src/statisticsmodule.c: In function ?find_mnemonic?:
src/statisticsmodule.c:117: warning: implicit declaration of function
?strlen?
src/statisticsmodule.c:117: warning: incompatible implicit declaration of
built-in function ?strlen?
src/statisticsmodule.c:119: warning: implicit declaration of function
?malloc?
src/statisticsmodule.c:119: warning: incompatible implicit declaration of
built-in function ?malloc?
src/statisticsmodule.c:120: warning: implicit declaration of function
?strcpy?
src/statisticsmodule.c:120: warning: incompatible implicit declaration of
built-in function ?strcpy?
src/statisticsmodule.c:121: warning: implicit declaration of function
?tolower?
src/statisticsmodule.c:123: warning: implicit declaration of function
?strcmp?
src/statisticsmodule.c:134: warning: implicit declaration of function ?free?
src/statisticsmodule.c:134: warning: incompatible implicit declaration of
built-in function ?free?
src/statisticsmodule.c: At top level:
src/statisticsmodule.c:152: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?parse_integer?
src/statisticsmodule.c:227: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:445: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:646: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:840: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:985: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1046: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1115: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1195: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1292: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1490: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1650: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:1821: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:2013: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:2057: error: expected ?=?, ?,?, ?;?, ?asm? or
?__attribute__? before ?*? token
src/statisticsmodule.c:2181: error: array type has incomplete element type
src/statisticsmodule.c:2182: error: ?PyCFunction? undeclared here (not in a
function)
src/statisticsmodule.c:2182: error: expected ?}? before ?py_mean?
src/statisticsmodule.c:2183: error: expected ?}? before ?py_median?
src/statisticsmodule.c:2184: error: expected ?}? before ?py_variance?
src/statisticsmodule.c:2185: error: expected ?}? before ?py_covariance?
src/statisticsmodule.c:2186: error: expected ?}? before ?py_correlation?
src/statisticsmodule.c:2187: error: expected ?}? before ?py_regression?
src/statisticsmodule.c:2188: error: expected ?}? before ?py_bandwidth?
src/statisticsmodule.c:2189: error: expected ?}? before ?py_pdf?
src/statisticsmodule.c:2190: error: expected ?}? before ?py_cpdf?
src/statisticsmodule.c:2191: error: expected ?}? before ?py_cpdfc?
src/statisticsmodule.c: In function ?initstatistics?:
src/statisticsmodule.c:2202: warning: implicit declaration of function
?PyErr_Print?
src/statisticsmodule.c:2202: warning: implicit declaration of function
?PyErr_SetString?
src/statisticsmodule.c:2202: error: ?PyExc_ImportError? undeclared
(first use
in this function)
src/statisticsmodule.c:2203: warning: implicit declaration of function
?Py_InitModule3?
src/statisticsmodule.c:2204: warning: implicit declaration of function
?PyErr_Occurred?
src/statisticsmodule.c:2204: warning: implicit declaration of function
?Py_FatalError?
error: command 'gcc' failed with exit status 1
# XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

----------
nosy: +fernando_gomes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1168055>
_______________________________________

From report at bugs.python.org  Mon Jan 12 18:59:09 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 12 Jan 2009 17:59:09 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231783149.08.0.363724623791.issue4753@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Here's the vmgen-based patch for comparison. Again, it passes all the
tests, but isn't complete outside of that and (unless consensus develops
that a couple percent is worth requiring vmgen) shouldn't distract from
reviewing Antoine's patch. I'll look over threadedceval5.patch in detail
next.

Added file: http://bugs.python.org/file12705/vmgen_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Mon Jan 12 19:00:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Jan 2009 18:00:54 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1231783254.69.0.94500858505.issue4910@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The first installment looks good!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Mon Jan 12 19:20:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Jan 2009 18:20:58 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231784458.07.0.761257685691.issue1696199@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> the typical usage is c=Counter(myseq) with no other non-dict accesses
> (mostly just c[elem]+=1 and print c[elem])

Isn't collections.defaultdict(lambda:0) enough for this purpose?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 19:28:17 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 Jan 2009 18:28:17 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231784897.89.0.136929327156.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

1) wave.py doesn't do assumptions about what the user wants, so I don't
think it is the place to put the DC (0 hz) assumption.

3) writesamples would raise an exception in the case of the current
number of channels set being wrong.

4) Well, lets fix a format then. I said list of lists of integers, or it
could use generators, and you didn't disagree here so it seems to be
fine. The problem in the current code is that you are making mono
channels special by being the one where a list of lists of integers is
not returned, but instead a single is returned. This is troublesome for
the caller to set the number of channels then, it is also a different
format then when something with 2 channels or other configuration is
used. With that in mind I have simplified some of your code as this:


def readsamples(self, nframes) :
    """Return a list of lists of integers.

    The number of these inner lists is given by the number of channels in
    the wave file. Each list contains the channel samples formatted as
    integers.
    """
    wav = self.readframes(nframes)

    sampwidth = self.getsampwidth()
    wav = struct.unpack(
            '<%d%s' % (len(wav) / sampwidth, wave._array_fmts[sampwidth]),
            wav)

    nc = self.getnchannels()
    if nc > 1:
        wavs = []
        for c in xrange(nc):
            wavs.append([wav[si] for si in xrange(c, len(wav), nc)])
    else:
        wavs = [[wav]]

    return wavs

def writesamples(self, *wavs) :
    """Write samples to the wave file.

    wavs must follow the structure returned by readsamples.
    """
    if self.getnchannels() != len(wavs):
        raise wave.Error("# of channels != # of samples")

    wav = []
    for w in zip(*wavs):
        wav.extend(w)

    ws = array.array(wave._array_fmts[self.getsampwidth()], wav)
    ws = ws.tostring()

    # we want all the samples in writeframes() format so that _convert
    # can be called on them
    self.writeframes(ws)


You can monkey patch wave then by doing:

wave.Wave_write.writesamples = writesamples
wave.Wave_read.readsamples = readsamples

And then change some other parts of your code.

5) There is a very small test for wave in Python's source,
Lib/test/test_wave.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 19:39:23 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 Jan 2009 18:39:23 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231785563.3.0.0783491101932.issue4913@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I was going to reply about your "code layout" answer but forgot. Well,
each one has their preferences so I'm not going to question yours.

The only problem is that there is no maintainer for wave.py, so, the
more you follow the rules for Python code (or at least code that gets
included in Python) the greater are the chances for them getting included.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Mon Jan 12 19:46:23 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Jan 2009 18:46:23 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1231785983.8.0.235330554264.issue3720@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think PyObject_NextNotImplemented should be renamed to
_PyObject_NextNotImplemented. Aside from that, I think the patch is
ready for committing.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Mon Jan 12 19:55:10 2009
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 12 Jan 2009 18:55:10 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231786510.88.0.83764793202.issue1696199@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The whole point was to have a function (or class) that accumulates a
sequence and counts it. collections.defaultdict(lambda: 0) doesn't
achieve this on its own because it only knows how to handle sequences of
(key, value):

>>> d = collections.defaultdict(lambda: 0)
>>> d.update('aaabbac')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: dictionary update sequence element #0 has length 1; 2 is
required

The feature request here was mainly a request to provide an abbreviation
of a very common 4-line function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 20:03:15 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Mon, 12 Jan 2009 19:03:15 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231786995.7.0.133049493347.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

A couple percent maybe is not worth vmgen-ing. But even if I'm not a
vmgen expert, I read many papers from Ertl about superinstructions and
replication, so the expected speedup from vmgen'ing is much bigger.
Is there some more advanced feature we are not using and could use?
Have the previous static predictions be converted to superinstructions?
Have other common sequences be treated like that?
Is there an existing discussion on this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Mon Jan 12 20:25:09 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Jan 2009 19:25:09 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231788309.99.0.725176017649.issue1696199@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

In counter6.diff line 56

"Assigning a count of zero or reducing the count to the zero leaves the"

suggest s/the zero/zero/

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 20:39:09 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 12 Jan 2009 19:39:09 +0000
Subject: [issue4925] Improve error message of subprocess
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1231789149.95.0.709243504522.issue4925@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

(Actual command stream includes chmod +x ./s.sh)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Mon Jan 12 20:40:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 12 Jan 2009 19:40:25 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231789225.85.0.745591073308.issue1696199@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Attaching new patch with small changes:

* Don't describe a class with "Returns ..." as if it was a function.
* Indent interposed paragraphs so that the method descriptions still
belong to the .. class directive.
* Fixed Ned's typo.
* Note that elements() and most_common() order elements arbitrarily.
* Reorder the seealso's a bit; the first line is bold.

Questions:

* Steven's counter.update('abcdee') wouldn't work -- I guess one is
supposed to use counter.update(Counter('abcdee')). Should that be noted
in the docs?
* Is it needed to sort the items for the __repr__?

Added file: http://bugs.python.org/file12706/counter7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 20:56:35 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 12 Jan 2009 19:56:35 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231790195.63.0.568424334084.issue1696199@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Mon Jan 12 21:19:14 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 12 Jan 2009 20:19:14 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231791554.92.0.926310792792.issue4753@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

I've left some line-by-line comments at
http://codereview.appspot.com/11905. Sorry if there was already a
Rietveld thread; I didn't see one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Mon Jan 12 21:34:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Jan 2009 20:34:55 +0000
Subject: [issue2486] Recode (parts of) decimal module in C
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231792495.44.0.509554044859.issue2486@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Guess that makes this a bit of a wasted effort on my part, then.  Darn.

> a substantial portion of the module should be coded in C and
> needs to function independently of Python, with accessors provided to
> for Python to wrap around.

I'm curious what sort of memory model you have in mind for this:  would
you implement separate memory management code that could easily be
swapped in or out for the standard Python object allocator?  Or does the 
functioning independently of Python bit not go as far as memory 
management?

In any case, let me know if there's anything I can do to help out, 
whether it's coding, or review, or whatever.  For what it's worth, I'm 
hoping to check in a significantly simpler (and I hope faster!) version 
of the log, log10 and exp functions to decimal.py in the near future, 
which should make rewriting that portion a little easier.  The pow stuff 
could use some work, too.

----------
assignee: marketdickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Mon Jan 12 21:42:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Jan 2009 20:42:40 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231792960.03.0.0735939653248.issue4907@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, both those "I'm not sure"s should be taken literally:  I'm not a user 
of the ast module, I don't know who the typical users are, and I don't 
know what the typical uses for the literal_eval function are.  The patch 
just struck me as odd, so I thought I'd comment.

IOW, take my comments with a large pinch of salt.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Mon Jan 12 21:44:47 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Jan 2009 20:44:47 +0000
Subject: [issue2486] Recode (parts of) decimal module in C
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1231793087.33.0.00188239992474.issue2486@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

FWIW, I actually prefer Mark's graduated approach to the Python->C
migration since we have a continuously working module that will get
incrementally faster over time. As profiling finds performance
bottlenecks in the Python code, those parts can be migrated to C (e.g.
as has been done initially with the manipulation of the coefficient,
which has been one of the main time sinks in the decimal module since
the days when it was still stored as a tuple instead of a string).

Having most of the module in C should be the endpoint, not where we
attempt to start (as I recall, attempts to rewrite the whole module in C
in one go have already been made, and they failed miserably).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Mon Jan 12 22:24:02 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 12 Jan 2009 21:24:02 +0000
Subject: [issue3038] Return results from Python callbacks to Tcl as Tcl
	objects, please backport it.
In-Reply-To: <1212629912.92.0.209823350261.issue3038@psf.upfronthosting.co.za>
Message-ID: <1231795441.94.0.228787841909.issue3038@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Not going to happen, python 2.5.4 is already out there.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3038>
_______________________________________

From report at bugs.python.org  Mon Jan 12 22:47:16 2009
From: report at bugs.python.org (Jason Tishler)
Date: Mon, 12 Jan 2009 21:47:16 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1231796836.98.0.11773400337.issue2233@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

Obviously not... :,(

It seems like we might have to go with your "/./" workaround, but let 
me see if I can come up with another approach.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Mon Jan 12 23:06:41 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 12 Jan 2009 22:06:41 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1231798001.6.0.773779319696.issue3582@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Mon Jan 12 23:15:06 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 12 Jan 2009 22:15:06 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231798506.74.0.858037117966.issue4907@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Here a patch with unittests to correctly handle complex numbers.  This
does not allow the user of arbitrary add/sub expressions on complex numbers.

Added file: http://bugs.python.org/file12707/literal-eval.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Mon Jan 12 23:28:49 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 12 Jan 2009 22:28:49 +0000
Subject: [issue1479611] speed up function calls
Message-ID: <1231799329.14.0.397137854858.issue1479611@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter, jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1479611>
_______________________________________

From report at bugs.python.org  Mon Jan 12 23:51:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Jan 2009 22:51:36 +0000
Subject: [issue4921] Object lifetime and inner recursive function
In-Reply-To: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>
Message-ID: <1231800696.48.0.0695842703574.issue4921@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, tracking memory consumption of each container would be better than
simpling couting them, but it's much more complicated as well (not to
mention that memory consumption can vary, so you must recalculate it
periodically...).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4921>
_______________________________________

From report at bugs.python.org  Tue Jan 13 00:05:14 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Jan 2009 23:05:14 +0000
Subject: [issue1696199] Add collections.counts()
Message-ID: <1231801514.41.0.408854585899.issue1696199@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the review comments.  Incorporated all suggested changes and
did some other minor tidying-up.  Extended the update example to include
c.update(Counter('abcdee')).  Committed as r68559 .

Decided to leave __repr__() with a sort.  Though it's not strictly
necessary, it's a nice convenience saving a user from doing the same
thing mentally.  Also, it helps with doctests by giving a reliable
ordering when element counts are non-equal.  For datasets small enough
that someone would want to display their repr, the time spent sorting is
negligible.

----------
assignee: georg.brandl -> rhettinger
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696199>
_______________________________________

From report at bugs.python.org  Tue Jan 13 00:30:37 2009
From: report at bugs.python.org (David Watson)
Date: Mon, 12 Jan 2009 23:30:37 +0000
Subject: [issue4926] putenv() accepts names containing '=',
	return value of unsetenv() not checked
In-Reply-To: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>
Message-ID: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

One of these problems interacts with the other, and can cause
os.unsetenv() to free memory that's still in use.  Firstly,
calling os.putenv("FOO=BAR", "value") causes putenv(3) to be
called with the string "FOO=BAR=value", which sets a variable
called FOO, not FOO=BAR; hence, os.putenv() should not accept a
name with an "=" character in it.

The way this interacts with os.unsetenv() is that the string
(FOO=BAR=value) is stored in the internal dictionary object
posix_putenv_garbage under the key "FOO=BAR".  The reference in
this dict is supposed to prevent the bytes object (str in 3.x on
Windows) that contains the string from being garbage collected
and freed until unsetenv() is called, since putenv(3) makes the
char **environ array point to the actual string, not a copy.

The problem with os.unsetenv() is that it does not check the
return value from unsetenv(3) at all and will unconditionally
remove the corresponding string from posix_putenv_garbage.
Following the example above, when os.unsetenv("FOO=BAR") is
called, unsetenv(3) will fail because the name contains an "="
character, but the object containing the string will be garbage
collected even though char **environ still has a pointer to it.

This is a bit tricky to give a visible demonstration of, but the
attached visibility.diff adds posix_putenv_garbage to the module
namespace and prints the return value from unsetenv() so you can
see what's going on.

The other two attached diffs fix the problems (for 2.x and 3.x
separately) by making os.unsetenv() raise OSError on failure in
the usual way, and os.putenv() raise ValueError when its first
argument contains "=".  They also add test cases and docs.  In
the patch for 3.x, some of the relevant code differs between Unix
and Windows; I changed both but I've only tested the Unix
version.

----------
components: Extension Modules
files: visibility.diff
keywords: patch
messages: 79708
nosy: baikie
severity: normal
status: open
title: putenv() accepts names containing '=', return value of unsetenv() not checked
type: behavior
Added file: http://bugs.python.org/file12708/visibility.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4926>
_______________________________________

From report at bugs.python.org  Tue Jan 13 00:31:27 2009
From: report at bugs.python.org (David Watson)
Date: Mon, 12 Jan 2009 23:31:27 +0000
Subject: [issue4926] putenv() accepts names containing '=',
	return value of unsetenv() not checked
In-Reply-To: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>
Message-ID: <1231803088.0.0.53713239987.issue4926@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file12709/2.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4926>
_______________________________________

From report at bugs.python.org  Tue Jan 13 00:31:49 2009
From: report at bugs.python.org (David Watson)
Date: Mon, 12 Jan 2009 23:31:49 +0000
Subject: [issue4926] putenv() accepts names containing '=',
	return value of unsetenv() not checked
In-Reply-To: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>
Message-ID: <1231803109.84.0.49001847607.issue4926@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


Added file: http://bugs.python.org/file12710/3.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4926>
_______________________________________

From report at bugs.python.org  Tue Jan 13 01:00:25 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 13 Jan 2009 00:00:25 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1231804825.98.0.475573740842.issue3720@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Any crash is a potential security problem.

This needs to be fixed in 2.6.x without breaking 2.6.0 extension 
compatibility.  (requiring extensions to be recompiled to fix the 
problem for an extension is fine, but they still need to load and work 
normally even if they have not been)

As trunk r68560 can't be backported?  what will?  Is there an 
appropriate pre-existing hackish substitute for PyObj_NextNotImplemented 
or will it require adding a test anytime the tp_nextiter slot is used?

----------
components: +Interpreter Core
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Tue Jan 13 01:03:35 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Jan 2009 00:03:35 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1231805015.23.0.677553722973.issue3720@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r68560 (trunk) and r68561 (py3k).

Difficult to backport: extensions compiled with 2.6.x would not run on 
2.6.0.

----------
keywords:  -needs review
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Tue Jan 13 01:47:53 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Jan 2009 00:47:53 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1231807672.89.0.242331234379.issue3720@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, a hack: What about setting tp_iternext to PyObject_GetIter? they happen 
to have the same signature.
Yes, calling next() will call iter() instead; but an iterator is often its 
own iterator, and more importantly, PyIter_Check() is also called.

And the error message is surprisingly almost correct:
  "TypeError: iter() returned non-iterator of type 'BadIterator'"
It's not completely correct since the error occurred while calling the 
__next__() method of the iterator.

See attached patch for 2.6.

I can see one cause of incompatibility: if someone designed an extension 
type in C where tp_iternext is already PyObject_GetIter. It's is insane but 
valid, and the patch would break it. It's not worth the trouble I suppose...

----------
keywords: +needs review
status: pending -> open
Added file: http://bugs.python.org/file12711/next-nevernull-26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Tue Jan 13 02:50:24 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 13 Jan 2009 01:50:24 +0000
Subject: [issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers
In-Reply-To: <1231580515.2.0.210154432041.issue4905@psf.upfronthosting.co.za>
Message-ID: <1231811424.89.0.745540699276.issue4905@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

The patch looks fine to me

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4905>
_______________________________________

From report at bugs.python.org  Tue Jan 13 02:55:03 2009
From: report at bugs.python.org (Pablo Castagnino)
Date: Tue, 13 Jan 2009 01:55:03 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231811703.71.0.438059740743.issue4881@psf.upfronthosting.co.za>


Pablo Castagnino <pablo.castagnino at gmail.com> added the comment:

Ok, everything seems to be working now in Ubuntu. However, I can't get
it work in WIN XP (at work). :(

Thanks for all your help!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Tue Jan 13 03:20:27 2009
From: report at bugs.python.org (Alex Robinson)
Date: Tue, 13 Jan 2009 02:20:27 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231813227.64.0.0644400252103.issue4913@psf.upfronthosting.co.za>


Alex Robinson <alex_python_org at tranzoa.com> added the comment:

"DC (0 hz) assumption"?
wave.py makes the assumption that what the user wants is whatever
happens to be in the file, however arbitrary. (That 8 bit samples are
unsigned bytes is probably an artifact of early ADC logic. Typically you
got an absolute, n-bit value from an old ADC. Newer chips often return
signed values.) It's very unlikely that anything but a copy program
would try to work with unsigned char samples. Too many things to go
wrong. Too much confusion. Zero means zero in most of the world, in and
out of audio processing. :)  That said, not having to offset the 8 bit
samples sparsifies the read/write_sample code. But, I'm thinking that
that's at the expense of every program that uses it. When in doubt, I
figure, do what is more useful. Don't force the caller to write a
wrapper if he'll need to do it 99% of the time. But this is not a
religious thing with me. A wrapper can be written. And, in fact, I'd
sure think it would be nice to include wrappers like auto-scaling and
auto-zeroing in wave.py. But maybe not, as these ops probably belong in
some array.py type module. Anyway, a non-audio guy who just wants to
read a wave file, diddle with it, and write it out. Or who just wants to
generate some sound and write it out. Or who just wants to read a wave
file and graph it or something. All of these guys will be stunned when
they find out to their hours-of-work chagrin that wave files' 8 bit
samples are not signed chars. And, if I were one of them, I'd be plenty
peeved after having to spend all that time learning about some
historical artifact just to read an danged audio file, for gosh sakes.
But not putting the 8-bit offset in the read/write_samples logic does
eliminate 2 lines of code in each routine.

"writesamples would raise an exception"
Yep, taste. I'm inclined to find this irritating and I don't like being
irritated by packages I use. Makes for a poor out-of-box experience.
But, taste. :)

"4) Well, lets fix a format then. else: wavs = [[wav]]" ?
That's an extra [] I think. [[samples]] would be an array of array of an
array of samples. s = [1,2]; print [ [ a ] ];    [[[1,2]]]
On reflection, I'd say I agree with you more than I do with me on the
ability of writesamples() to take a simple array of mono samples. Not a
good thing to do.

"wavs.extend(wav)" ?
I had to look up extend() and try it in the Python shell! :) To each his
own. But when I found out that one could do list+=added_list in Python I
never looked back. Intuitive. I special-cased mono for speed purposes.
No reason to do the +=/extend for mono samples. But, maybe the
interpretor handles all that. Don't know. Didn't measure it.

"monkey patch"?'
Wonderful! This makes your rewrite of the code *so* much cleaner. Thanks
for the tip!

"code layout"?
Har, har. Yep, no one in software has ever spent any time "discussing"
code layout before. Let's do it for the first time in history.

"test_wave.py"?
Oooo. Bit minimal, that. Yeah, I think a couple of things could be
fleshed out there.

Gotta run now. But will try to update the code in wave_futz later. Other
things on plate, though.

Guilherme, I really appreciate your handling this and your guidance. Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Tue Jan 13 03:21:27 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 13 Jan 2009 02:21:27 +0000
Subject: [issue4903] binascii.crc32() - document signed vs unsigned results
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231813287.95.0.119206932423.issue4903@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Just a small note on the wording: "will have" and "will always be" look 
too strong to me. I'd just use is, are. Present tense seems to be --in 
general-- the preferred style in the documentation.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4903>
_______________________________________

From report at bugs.python.org  Tue Jan 13 04:02:52 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 13 Jan 2009 03:02:52 +0000
Subject: [issue4913] wave.py: add writesamples() and readsamples()
In-Reply-To: <1231813227.64.0.0644400252103.issue4913@psf.upfronthosting.co.za>
Message-ID: <ac2200130901121902k2d380310n7bb92080c61245a@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> "DC (0 hz) assumption"?
> wave.py makes the assumption that what the user wants is whatever
> happens to be in the file, however arbitrary. (That 8 bit samples are
> unsigned bytes is probably an artifact of early ADC logic. Typically you
> got an absolute, n-bit value from an old ADC. Newer chips often return
> signed values.) It's very unlikely that anything but a copy program
> would try to work with unsigned char samples. Too many things to go
> wrong. Too much confusion. Zero means zero in most of the world, in and
> out of audio processing. :)

Every document/text I've found so far talks about 8 bit samples being
unsigned, it is not like I'm trying to enforce it just because I want,
just following the specification.
But, SDL for example, accepts wav files with unsigned 8 bits, signed 8
bits, unsigned 16 bits, signed 16 bits, and with different byte
orders, so apparently different libraries write different wave files.
I wonder which of these would be good to get included in wave.py, but
for this current issue I would prefer to not even touch this another
problem and stick with what is the documented for the wave format.

> .
> .
> But not putting the 8-bit offset in the read/write_samples logic does
> eliminate 2 lines of code in each routine.

It is good that it is just two lines, it means they could be added
back (and adapted) when we start supporting different output/input
formats for wave.

> "4) Well, lets fix a format then. else: wavs = [[wav]]" ?
> That's an extra [] I think.

Right.

> "wavs.extend(wav)" ?
> I had to look up extend() and try it in the Python shell! :) To each his
> own. But when I found out that one could do list+=added_list in Python I
> never looked back. Intuitive. I special-cased mono for speed purposes.
> No reason to do the +=/extend for mono samples. But, maybe the
> interpretor handles all that.

It won't just do this optimization, keeping the special case for mono is fine.

> "test_wave.py"?
> Oooo. Bit minimal, that. Yeah, I think a couple of things could be
> fleshed out there.

I'm waiting for the new hand written tests now :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4913>
_______________________________________

From report at bugs.python.org  Tue Jan 13 04:49:50 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 13 Jan 2009 03:49:50 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1231818590.11.0.349846622765.issue3720@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

nice hack! :)

I'm going to guess that existing code in the wild setting tp_iternext = 
&PyObject_GetIter is rare.  I certainly can not rule it entirely out but 
I don't see anything in the open source world using 
http://www.google.com/codesearch

I'd be okay with this hack.  Let the release manager and/or BDFL make 
this call.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Tue Jan 13 05:36:49 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 13 Jan 2009 04:36:49 +0000
Subject: [issue4926] putenv() accepts names containing '=',
	return value of unsetenv() not checked
In-Reply-To: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>
Message-ID: <1231821409.09.0.222085640341.issue4926@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4926>
_______________________________________

From report at bugs.python.org  Tue Jan 13 06:15:17 2009
From: report at bugs.python.org (Andi Albrecht)
Date: Tue, 13 Jan 2009 05:15:17 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231823717.44.0.271927120779.issue4908@psf.upfronthosting.co.za>


Andi Albrecht <albrecht.andi at gmail.com> added the comment:

Is it intended that when reading PKG-INFO files the PEP 314 attributes
(provides, requires, obsoletes) are only set if version is exactly "1.1"? 

I'd expected that those attributes are available regardless of the
metadata version of the parsed file (with None as default for PKG-INFO
files < 1.1).

----------
nosy: +aalbrecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Tue Jan 13 06:34:43 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 13 Jan 2009 05:34:43 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231824883.86.0.647712818456.issue4871@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Lukas Lueg> The default encoding is UTF8

What do you mean? Not inside a zip file. The default encoding is CP437 
(the original IBM PC US character set).

A zipfile password is a sequence of bytes, not characters, as defined 
in the specification. Probably this issue has to wait until it is 
decided what to do in the general case; anyway, encoding the password 
to bytes at the application level seems to be safer.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Tue Jan 13 06:49:04 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Tue, 13 Jan 2009 05:49:04 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1231825744.14.0.0234159944222.issue4896@psf.upfronthosting.co.za>


Changes by Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com>:


----------
nosy: +blaisorblade

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Tue Jan 13 06:56:43 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 13 Jan 2009 05:56:43 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231826203.72.0.40943999099.issue4753@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

@Paolo: I'm going to be looking into converting more common sequences
into superinstructions. We only have LOAD_CONST+XXX so far. The others
are difficult because vmgen doesn't provide easy ways to deal with error
handling, but Jakob and I have come up with a couple ideas to get around
that.

Replication would be trickier since we want the bytecode generation to
be deterministic, but it's probably doable too. I'll post any
significant results I get.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Tue Jan 13 07:38:07 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 13 Jan 2009 06:38:07 +0000
Subject: [issue4889] difflib
In-Reply-To: <1231480179.7.0.0322918194746.issue4889@psf.upfronthosting.co.za>
Message-ID: <1231828687.13.0.319172613104.issue4889@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

You (as a human) most likely parse these lines:

hostname vaijain123
hostname CAVANC1001CR1

as "two words, the first one is the same, the second word changed".
But difflib sees them more or less as: "21 letters, 8 of them are the 
same, 13 are different". There are many more differences than matches, 
so it makes sense to show the changes as a complete replacement:

>>> d = difflib.ndiff(["hostname vaijain123\n"], ["hostname 
CAVANC1001CR1\n"])
>>> print ''.join(d)
- hostname vaijain123
+ hostname CAVANC1001CR1

It has nothing to do with upper or lower case letters ("A" and "a" are 
completely different things for difflib). If the names were shorter, it 
might consider a match:

>>> d = difflib.ndiff(["hostname vai\n"], ["hostname CAV\n"])
>>> print ''.join(d)
- hostname vai
?          ^^^
+ hostname CAV
?          ^^^

Note how the ratio changes:

>>> difflib.SequenceMatcher(None, "hostname vaijain123", "hostname 
CAVANC1001CR1").ratio()
0.48780487804878048
>>> difflib.SequenceMatcher(None, "hostname vai", "hostname CAV").ratio
()
0.75

The ratio must be 0.75 or higher for a differ to consider two lines 
"close enough" to show intra-line differences.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4889>
_______________________________________

From report at bugs.python.org  Tue Jan 13 07:45:38 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Tue, 13 Jan 2009 06:45:38 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231829138.54.0.853518537147.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

Ok, then vmgen adds almost just direct threading instead of indirect
threading.

Since the purpose of superinstructions is to eliminate dispatch
overhead, and that's more important when little actual work is done,
what about all ones which unconditionally end with FAST_DISPATCH and are
common? DUP_TOP, POP_TOP, DUP_TOPX(2,3) and other stack handling staff
which can't fail? To have any of them + XXX without error handling
problems? Removing handling of DUP_TOPX{4,5} is implied, you shouldn't
check functionality of the compiler during interpretation - indeed, even
the idea using a parameter for that is a waste. Have DUP_TOPX2 and
DUP_TOPX3, like JVM, is just simpler.

> Replication would be trickier since we want the bytecode generation to
be deterministic, but it's probably doable too.

Bytecode conversion during I/O is perfectly fine, to convert from the
actual bytecode to one of the chosen replicas. Conversion in a rescan
pass can be also OK (less cache friendly though, so if it's easy to
avoid, please do).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Tue Jan 13 09:12:55 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 13 Jan 2009 08:12:55 +0000
Subject: [issue4922] set.add and set.discard are not conformant to
	collections.MutableSet interface
In-Reply-To: <1231759440.37.0.125734005136.issue4922@psf.upfronthosting.co.za>
Message-ID: <1231834375.11.0.492496120149.issue4922@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4922>
_______________________________________

From report at bugs.python.org  Tue Jan 13 09:14:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 13 Jan 2009 08:14:12 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231834452.02.0.665718301164.issue4907@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Nit: the "except" should only catch ValueError.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 09:40:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Jan 2009 08:40:50 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231836050.54.0.099422209009.issue4871@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

in Lib/zipfile.py, the filename is already allowed to be unicode if the
"flag_bits" for the file entry contains 0x800. This indicates that the
encoding is utf-8.

We could do the same for the password. Attached is a tentative patch
along this idea (for py3k replace 'unicode' with 'str' of course)

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file12712/zipfile-pwd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Tue Jan 13 10:09:52 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Jan 2009 09:09:52 +0000
Subject: [issue4922] set.add and set.discard are not conformant to
	collections.MutableSet interface
In-Reply-To: <1231759440.37.0.125734005136.issue4922@psf.upfronthosting.co.za>
Message-ID: <1231837792.61.0.00281236765598.issue4922@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The comments were incorrect.
Mutating methods always return None.
Fixed in r68570.
Needs to be ported to 2.6, 3.0, and 3.1.

----------
assignee: rhettinger -> georg.brandl
keywords: +26backport
nosy: +georg.brandl
resolution:  -> fixed
versions: +Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4922>
_______________________________________

From report at bugs.python.org  Tue Jan 13 10:21:37 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 09:21:37 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The repr for fileobjects is inconsistent.  On windows:
f = file("tmp\\foo", "wb")
f
<open file 'tmp\foo', mode 'wb' at ...>
f = file(u"tmp\\foo", "wb")
f
<open file u'tmp\\foo', mode 'wb' at ...>

For unicode, the filename is a proper "repr", but for a string it is 
just the plain string, enclosed in single quotes.  Note that I consider 
the string case in error.  Like the repr of a list or tuple, it should 
be a string containin the repr of its components.

This leads to problems in the testsuite on vista.

I propose to change this with the patch provided, which always displays 
the repr of the filename.  It may have side effects in the testsuite, I 
will add a separate file for that.

----------
components: Interpreter Core
files: fileobject.patch
keywords: needs review, patch, patch
messages: 79726
nosy: krisvale
severity: normal
stage: patch review
status: open
title: Inconsistent unicode repr for fileobject
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12713/fileobject.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Tue Jan 13 10:22:46 2009
From: report at bugs.python.org (Richard Philips)
Date: Tue, 13 Jan 2009 09:22:46 +0000
Subject: [issue4928] Problem with tempfile.NamedTemporaryFile on Solaris 10
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>


New submission from Richard Philips <rphilips at users.sourceforge.net>:

On Solaris 10 (Solaris 10 5/08 s10x_u5wos_10 X86),
with python 2.5 (Python 2.5.2 (r252:60911, Sep  8 2008, 16:53:36) [C] on
sunos5),

tempfile.NamedTemporaryFile creates - as advertised - a temporary file.

After closing this file object (e.g. by exiting the python process), the
temporary file is indeed removed.

But if you just kill the python process, the temporary file is not
destroyed.

This behavior is different on Red Hat Linux and MS Vista, on these OSes
the temporary file is removed.

A snapshot to illustrate the behavior:

[moto /]# python
Python 2.5.2 (r252:60911, Sep  8 2008, 16:53:36) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, tempfile
>>> f = tempfile.NamedTemporaryFile()
>>> f.name
'/tmp/tmpfHraUd'
>>> os.getpid()
4403
>>> x = "With root priveleges, I execute: 'kill 4403'"
>>>
>>> Terminated
[moto /]#

----------
components: Library (Lib)
messages: 79727
nosy: rphilips
severity: normal
status: open
title: Problem with tempfile.NamedTemporaryFile on Solaris 10
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4928>
_______________________________________

From report at bugs.python.org  Tue Jan 13 10:26:34 2009
From: report at bugs.python.org (Richard Philips)
Date: Tue, 13 Jan 2009 09:26:34 +0000
Subject: [issue4928] Problem with tempfile.NamedTemporaryFile on Solaris 10
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1231838794.62.0.686790898282.issue4928@psf.upfronthosting.co.za>


Richard Philips <rphilips at users.sourceforge.net> added the comment:

[Replaces msg 79727]


On Solaris 10 (Solaris 10 5/08 s10x_u5wos_10 X86),
with python 2.5 (Python 2.5.2 (r252:60911, Sep  8 2008, 16:53:36) [C] on
sunos5),

tempfile.NamedTemporaryFile creates - as advertised - a temporary file.

After closing this file object (e.g. by exiting the python process), the
temporary file is indeed removed.

But if you just kill the python process, the temporary file is not
destroyed.

This behavior is different on Red Hat Linux and MS Vista, on these OSes
the temporary file is removed.

A snapshot to illustrate the behavior:

[moto /]# python
Python 2.5.2 (r252:60911, Sep  8 2008, 16:53:36) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, tempfile
>>> f = tempfile.NamedTemporaryFile()
>>> f.name
'/tmp/tmpfHraUd'
>>> os.getpid()
4403
>>> x = "With root priveleges, I execute: 'kill 4403'"
>>>
>>> Terminated
[moto /]# ls /tmp/tmpfHraUd
/tmp/tmpfHraUd
[moto /]#

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4928>
_______________________________________

From report at bugs.python.org  Tue Jan 13 11:02:04 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 10:02:04 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1231840924.46.0.937071956561.issue4927@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Adding patch for test_file

Added file: http://bugs.python.org/file12714/test_file.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Tue Jan 13 11:47:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Jan 2009 10:47:05 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231843625.94.0.123915977162.issue4907@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nice fix!

Exactly which complex strings should be accepted here?
The patched version of literal-eval still accepts some
things that would be rejected as inputs to complex():

>>> ast.literal_eval('-1+-3j')
(-1-3j)
>>> complex('-1+-3j')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: complex() arg is a malformed string

and it produces different results from the complex
constructor in some other cases:

>>> complex('-0.0+0.0j').real
-0.0
>>> ast.literal_eval('-0.0+0.0j').real
0.0

But since I don't really know what ast_literal
is used for, I don't know whether this matters.

It still seems odd to me to be doing just one
special case of expression evaluation in
ast_literal, but maybe that's just me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 11:54:20 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 10:54:20 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1231844060.17.0.741078007709.issue4804@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I submit to you a patch to the trunk which narrows down the problem.  In  
stead of throwing the switch for the whole process, we selectively 
disable the hard error checking for those two cases that require it:  
The file open mode string (unless we want to reimplement the crt mode 
string parser) and the posix file descriptor methods.  The remaining 
case, strftime, we fix with a proper argument checking function.

Yesterday I put in some tests in to the testsuite to excercise this 
functionality (revision 68547)

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file12715/crterror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Tue Jan 13 12:31:17 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 11:31:17 +0000
Subject: [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

the SMPT.getreply() method doesn't check for socket.error when doing its 
readline() call.  We now check for connection reset and others that can 
occur here and properly close.  This is to comply with the documentation 
that doesn't specify socket.error as part of the exceptions raised.

----------
components: Library (Lib)
files: smtplib.patch
keywords: needs review, patch, patch
messages: 79732
nosy: krisvale
severity: normal
stage: patch review
status: open
title: smptlib.py can raise socket.error
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12716/smtplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4929>
_______________________________________

From report at bugs.python.org  Tue Jan 13 12:34:53 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Tue, 13 Jan 2009 11:34:53 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231846493.91.0.109539323588.issue4907@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

literal_eval has eval() semantics and not complex() constructor
semantics.  It accepts what eval() accepts just without arithmetic and
unsafe features.

For exmaple "(2 + 4j)" is perfectly fine even though the complex call
only supports "2+4j" (no parentheses and whitespace).

I commit the fix with the ValueError except Georg suggested.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 12:37:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 11:37:24 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231846644.07.0.154442787193.issue4753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As for superinstructions, you can find an example here: #4715.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Tue Jan 13 12:40:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Jan 2009 11:40:46 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231846846.37.0.229228972522.issue4907@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So why accept (4+2j) but not (2j+4)?

(BTW, I'm fairly sure that the complex constructor does
accept parentheses;  you're right about the whitespace, though.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 12:45:18 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Tue, 13 Jan 2009 11:45:18 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231847118.51.0.605950819995.issue4907@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Indeed, it accepts parentheses in 2.6 now, but not in 2.5 or earlier.

Why not the other way round?  Somewhere there has to be a limit.  And if
you write down complex numbers you usually have the imaginary part after
the real part.

But let's try no to make this a bikeshed discussion.  If you say that
literal_eval can safely evaluate the repr() of builtins (with the
notable exception of reprs that eval can't evaluate either [like nan,
inf etc.]) and probably a bit more it should be fine :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 12:52:57 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Tue, 13 Jan 2009 11:52:57 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231847577.19.0.482243373071.issue4907@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Fixed in rev68571.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 13:30:44 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 13 Jan 2009 12:30:44 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231849844.05.0.737146863022.issue4907@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Why didn't you use assertRaises in place of that try/except for a test ?

I was somewhat following this issue and just saw it being commited, but
the change was being discussed. Aren't you supposed to commit these kind
of changes only after entering in agreement with others ?

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 13:38:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Jan 2009 12:38:47 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231850327.07.0.532082705018.issue4907@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> If you say that
> literal_eval can safely evaluate the repr() of builtins

Sorry, yes, that makes perfect sense.  (And now I see that that's what
distinguishes 4+2j from 2j+4---finally the light dawns.) Apologies for
being obtuse.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 14:03:03 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Tue, 13 Jan 2009 13:03:03 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231851783.55.0.327741140988.issue4907@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

> Why didn't you use assertRaises in place of that try/except for a test ?
Could be changed.

> I was somewhat following this issue and just saw it being commited,
> but the change was being discussed. Aren't you supposed to commit
> these kind of changes only after entering in agreement with others ?
The "needs review" keyowrd was removed, I was under the impression I can
commit now :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Tue Jan 13 14:14:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 13:14:20 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1231852460.88.0.224524166872.issue4874@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is probably fine, but it would be nice to add some unit tests
for the new behaviour.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Tue Jan 13 14:48:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Jan 2009 13:48:47 +0000
Subject: [issue4930] Small optimization in type construction
In-Reply-To: <1231854527.51.0.654505109034.issue4930@psf.upfronthosting.co.za>
Message-ID: <1231854527.51.0.654505109034.issue4930@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Replace a strcmp call by a direct slot address comparison.

This follows Neil's remark in 
http://mail.python.org/pipermail/python-checkins/2009-January/077156.html

----------
assignee: amaury.forgeotdarc
files: slotcomparison.patch
keywords: patch
messages: 79742
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: Small optimization in type construction
Added file: http://bugs.python.org/file12717/slotcomparison.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4930>
_______________________________________

From report at bugs.python.org  Tue Jan 13 15:03:43 2009
From: report at bugs.python.org (Giovanni)
Date: Tue, 13 Jan 2009 14:03:43 +0000
Subject: [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231855423.14.0.029103803335.issue4899@psf.upfronthosting.co.za>


Giovanni <dalloliogm at gmail.com> added the comment:

I was proposing to adopt doctest in the biopython project (modules for
bioinformatics in python, http://biopython.org/).

Doctest is very useful to document modules that will be used by many
other people: for example, there are many different file formats in
bioinformatics, and it is very useful to add an example of the file to
be parsed in the documentation of a file parser.
Look at my code here: 
-
http://github.com/dalloliogm/biopython---popgen/blob/980419dbc0666e2578c2486dab1fef23ccfbb72c/src/PopGen/Gio/TpedIO.py


However, it is very uncomfortable to have to create a file-like object
in every docstring, especially when you want to document the methods of
a class.
It would be useful if at least the doctests of the methods of a class
share the objects created in the main doctest of the class.

Let's say I have a class called FastaIO (fasta is a file format for
sequence).
This module would have many methods: format, to_dict (returns a
dictionary of the sequences included in the file), and many others.
The main docstring of the class will have an example of a fasta file,
and shows how to create an instance of FastaIO.
It is silly to have to repeat this example (creating an instance of
FastaIO) in every submethod. Moreover, it is more difficult to maintain
and more error prone (imagine you have a class with one hundred methods).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4899>
_______________________________________

From report at bugs.python.org  Tue Jan 13 15:31:45 2009
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 13 Jan 2009 14:31:45 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1231857105.62.0.536884954847.issue4242@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Here is a summarizing implementation that accepts this interface:

    if check_impl_detail():               # only on CPython (default)
    if check_impl_detail(jython=True):    # only on Jython
    if check_impl_detail(cpython=False):  # everywhere except on CPython

and similarly with the decorator:

    @impl_detail()                # only on CPython (default)
    @impl_detail("reason...")     # the same, with an explicit message
    @impl_detail(jython=True)     # only on Jython
    @impl_detail(cpython=False)   # everywhere except on CPython

I think this is a nice interface, although it takes some largish number
of lines to implement.

Added file: http://bugs.python.org/file12718/test-impl-details-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 13 16:35:22 2009
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 13 Jan 2009 15:35:22 +0000
Subject: [issue1251] ssl module doesn't support non-blocking handshakes
In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>
Message-ID: <1231860922.8.0.199635933802.issue1251@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Well, maybe he found something -- never reported back.  But it was a few
months ago...  I'm in no hurry to close it, though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1251>
_______________________________________

From report at bugs.python.org  Tue Jan 13 16:46:31 2009
From: report at bugs.python.org (Pablo Castagnino)
Date: Tue, 13 Jan 2009 15:46:31 +0000
Subject: [issue4881] Python's timezon handling: daylight saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231861591.93.0.364651177172.issue4881@psf.upfronthosting.co.za>


Pablo Castagnino <pablo.castagnino at gmail.com> added the comment:

Ok. I installed the WIN XP patch loewis talked about...and now
everything works smoothly in Windows too. Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4881>
_______________________________________

From report at bugs.python.org  Tue Jan 13 16:46:55 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 13 Jan 2009 15:46:55 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231861615.4.0.978367575404.issue4715@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Those look nice, although I need to look at the patches in more detail.
What speedup do they give you?

----------
nosy: +collinwinter, jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Tue Jan 13 17:11:26 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Jan 2009 16:11:26 +0000
Subject: [issue4807] wrong wsprintf usage
In-Reply-To: <1230901683.42.0.873273528074.issue4807@psf.upfronthosting.co.za>
Message-ID: <1231863086.6.0.126845643394.issue4807@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch seems good.
This only applies to trunk: py3k already uses PyUnicode_FromFormat.

----------
nosy: +amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4807>
_______________________________________

From report at bugs.python.org  Tue Jan 13 18:19:09 2009
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 13 Jan 2009 17:19:09 +0000
Subject: [issue4888] misplaced (or misleading) assert in ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1231867149.1.0.0312891211179.issue4888@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

I agree with Raymond.  A comment *might* be sufficient, but ... in some 
sense, that is the purpose of an assert.

The loop is reasonably long; it already includes macros which could 
(but currently don't) change the value, and function calls which might 
plausibly (but don't) reset a "why" variable.  The why variable is 
techically local, but the scope is still pretty large, so that isn't 
clear at first.

It took me some work to verify the assertion, and I'm not at all 
confident that a later change wouldn't violate it.  Nor am I confident 
that the symptoms would make for straightforward debugging.  (Would it 
look like stack corruption?  Would it take several more opcodes before 
a problem was visible?)

----------
nosy: +jimjjewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4888>
_______________________________________

From report at bugs.python.org  Tue Jan 13 18:27:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 17:27:19 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231867639.01.0.795150403011.issue4715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

pybench runtimes (attached) are almost the same. The big win is on list
comprehensions with an "if" clause.

Added file: http://bugs.python.org/file12719/pybench.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Tue Jan 13 18:31:05 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 13 Jan 2009 17:31:05 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

Today I was trying to compile a module using an extension in C and
noticed there are differences between compiling it on Python 2.5 and 2.6.
I was trying to compile psutil (svn checkout
http://psutil.googlecode.com/svn/trunk/ psutil) but I think that the
problem may occur with any other package using C extensions.

Python 2.5:

D:\pyftpdlib\svn\psutil\trunk>C:\python25\python.exe setup.py install
running install
running build
running build_ext
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible
binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin
installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.



Python 2.6:

D:\pyftpdlib\svn\psutil\trunk>C:\python26\python.exe setup.py install
running install
running build
running build_ext
building 'psutil/_psutil_mswindows' extension
error: None

----------
components: Distutils
messages: 79751
nosy: giampaolo.rodola
severity: normal
status: open
title: distutils does not show any error msg when can't build C module extensions due to a missing C compiler
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Tue Jan 13 18:32:35 2009
From: report at bugs.python.org (Andres Moreira)
Date: Tue, 13 Jan 2009 17:32:35 +0000
Subject: [issue4932] Little improvement on urlparse module, urlparse function.
In-Reply-To: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>
Message-ID: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>


New submission from Andres Moreira <elkpichico at gmail.com>:

Hi, 
 I make a little change in the urlsplit function of urlparse module. And
the performance when I'm parsing a lot of urls was improved a bit.
In the best case was improved around a 20% percent.

Python version:
2.5.2 (r252:60911, Oct  5 2008, 19:29:17) 
[GCC 4.3.2]

Here are the benchmarks:
#:~/tests$ python profile_urlparse.py 
timing urlparse.urlparse():
    [0.28006601333618164, 0.27513313293457031, 0.20408511161804199]
timing myurlparse.urlparse():
    [0.11000704765319824, 0.10729002952575684, 0.10677695274353027]
#:~/tests$ python profile_urlparse2.py 
timing urlparse.urlparse():
    [0.28334403038024902, 0.27912592887878418, 0.15959692001342773]
timing myurlparse.urlparse():
    [0.11277103424072266, 0.11163187026977539, 0.11175107955932617]
#:~/tests$ python profile_urlparse2.py 
timing urlparse.urlparse():
    [0.28750920295715332, 0.2779538631439209, 0.27816200256347656]
timing myurlparse.urlparse():
    [0.25010085105895996, 0.11236691474914551, 0.11198592185974121]


#-- Paste here the profiling code -----------
#-- Please rename the file as : profile_urlparse.py

urls = [
   
"http://www.notonthehighstreet.com/boxwood/product/dotty_picture_frames",
    "http://www.fancylighting.com/acatalog/Petrushka_Bronze.html",
   
"http://cgi.ebay.co.uk/3-LITRE-SUNNEX-STAINLESS-STEEL-TEAPOT-COFFEE-POT_W0QQitemZ160230173283QQcategoryZ122942QQcmdZViewItem",
   
"http://retail.ictc.co.uk/acatalog/Online_Catalogue__Homegrown_184.html",
   
"http://www.amazon.co.uk/Big-Mog-Tape-Judith-Kerr/dp/0001025252?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=0001025252",
   
"http://www.dinerstore.co.uk/acatalog/copy_of_Bedford_Oak_Table_and_Six.html",
   
"http://www.panik-design.co.uk/acatalog/Iittala_-_A_Citterio_-_Citterio_98_Cutlery_24pcs_.html",
    "http://www.johnlewis.com/230544027/Product.aspx",
   
"http://cgi.ebay.co.uk/Damask-Black-Pink-Cream-Large-Modern-Rugs-120x170cm_W0QQitemZ400021540458QQcategoryZ57237QQcmdZViewItem",
   
"http://www.amazon.co.uk/Nikon-50Mm-F1-2-Nikkor-Lens/dp/B00009R95Y?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B00009R95Y",
   
"http://www.amazon.co.uk/Storeys-Guide-Raising-Llamas-Birutta/dp/1580173284?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=1580173284",
    "http://www.24electric.com/detail.php?ProdID=46519663",
   
"http://cgi.ebay.co.uk/Antique-Pine-Midi-Sleeper-Childrens-Bed-VGC_W0QQitemZ280285887713QQcategoryZ122763QQcmdZViewItem",
    "http://www.johnlewis.com/230421907/Product.aspx",
   
"http://cgi.ebay.co.uk/WICKER-PLACE-DINNER-MATS-X6-IN-A-WICKER-BASKET-WITH-LID_W0QQitemZ350141392941QQcategoryZ20660QQcmdZViewItem",
   
"http://www.trueshopping.co.uk/product/Draper_1_4_Square_Drive_Reversible_Ratchet/3495/43235.html",
   
"http://www.amazon.co.uk/Transcend-TS128MIB6986-128MB-Module/dp/B000HCO61K?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B000HCO61K",
   
"http://www.unitedinteriors.co.uk/regency-pine-hi-fi-cabinet-4741-p.asp",
   
"http://www.amazon.co.uk/BATTERY-CAMCORDER-DCR-DVD602-DCR-DVD602E-DCRDVD602/dp/B0017UM1OU?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B0017UM1OU",
    "http://www.tooled-up.com/Product.asp?PID=145138",
   
"http://www.dinerstore.co.uk/acatalog/copy_of_Bedford_Oak_Table_and_Six.html",
   
"http://www.panik-design.co.uk/acatalog/Iittala_-_A_Citterio_-_Citterio_98_Cutlery_24pcs_.html",
    "http://www.johnlewis.com/230544027/Product.aspx",
   
"http://cgi.ebay.co.uk/Damask-Black-Pink-Cream-Large-Modern-Rugs-120x170cm_W0QQitemZ400021540458QQcategoryZ57237QQcmdZViewItem",
   
"http://www.amazon.co.uk/Nikon-50Mm-F1-2-Nikkor-Lens/dp/B00009R95Y?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B00009R95Y",
   
"http://www.amazon.co.uk/Storeys-Guide-Raising-Llamas-Birutta/dp/1580173284?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=1580173284",
    "http://www.24electric.com/detail.php?ProdID=46519663",
   
"http://cgi.ebay.co.uk/Antique-Pine-Midi-Sleeper-Childrens-Bed-VGC_W0QQitemZ280285887713QQcategoryZ122763QQcmdZViewItem",
    "http://www.johnlewis.com/230421907/Product.aspx",
   
"http://cgi.ebay.co.uk/WICKER-PLACE-DINNER-MATS-X6-IN-A-WICKER-BASKET-WITH-LID_W0QQitemZ350141392941QQcategoryZ20660QQcmdZViewItem",
   
"http://www.trueshopping.co.uk/product/Draper_1_4_Square_Drive_Reversible_Ratchet/3495/43235.html",
]

if __name__ == '__main__':
    import sys
    import timeit

    if len(sys.argv) > 1:
        times = int(sys.argv[1])
    else:
        times = 1000

    t = timeit.Timer("[urlparse.urlparse(u) for u in urls]", 
                     "from profile_urlparse import urls; import urlparse")
    print "timing urlparse.urlparse():"
    print "   ", t.repeat(3, times)


    t = timeit.Timer("[myurlparse.urlparse(u) for u in urls]", 
                     "from profile_urlparse import urls; import myurlparse")
    print "timing myurlparse.urlparse():"
    print "   ", t.repeat(3, times)

#--- End of profile code ----------------------------------------

----------
components: Library (Lib)
files: urlparse.py
messages: 79752
nosy: andrix
severity: normal
status: open
title: Little improvement on urlparse module, urlparse function.
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file12720/urlparse.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4932>
_______________________________________

From report at bugs.python.org  Tue Jan 13 18:34:37 2009
From: report at bugs.python.org (Scott McCreary)
Date: Tue, 13 Jan 2009 17:34:37 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>
Message-ID: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>


New submission from Scott McCreary <scottmc2 at gmail.com>:

This patch adds preliminary support for Haiku.  We still have to hand
tweak a few other files to get things to build.  We have further patches
to get python-2.5.4 to build, but it's failing some of the regression
tests so we're leaving those parts out of this submitted patch.
For more details on the progress of the Haiku port check here:
http://ports.haiku-files.org/wiki/dev-lang/python/2.5.4

----------
components: Build
files: python-2.5.4-haiku-2.diff
keywords: patch
messages: 79753
nosy: scottmc
severity: normal
status: open
title: Patch to add preliminary support for Haiku
versions: Python 2.5
Added file: http://bugs.python.org/file12721/python-2.5.4-haiku-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Tue Jan 13 18:44:48 2009
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 13 Jan 2009 17:44:48 +0000
Subject: [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231868688.21.0.408124646821.issue4899@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

My goodness, that's the starting base sequence to gene 38c, chromosome 4
of the Columbian caldera cricket!  But seriously...

1) The relevant part of the doc string is this, and this is how it
should read (your argument being "if doctests provided setUp framework
my doc string would look like this!"):

def TpedIterator(handle):

    '''
        Iterates on an TPed file handler.
        Returns Marker objects.

            Tped_stream = open('cricket.sequence','r')
            ti = TpedIterator(Tped_stream)
            for marker in ti:
                use(marker)
    '''


2) (With the caveat that I am unfamilar with your project.)  You should
choose terminology appropriate for your project.  A computer scientist
would expect "file handle" to be an integer.  What you call "handle" is
clearly a "stream" object and therefore of uncommon name.  Since the
file objects are more likely to be from the computer sciences rather
than the biological realm you should stick with "stream".

3) We agree, "Don't Repeat Yourself".  The last two chunks of your file
enable doctest.  I'll guess that similar lines may be found repeated
throughout your sources.  Instead of internal support, write a single
test script that provides external support.  It would process named
files with unittest, doctest.[, and customtests.]
    $ python -c 'import test' glob
There may be a python library for this.  I can't guide you easily
because I built and use my own framework.  Nor have I bothered to figure
out how python runs its own installation tests.

4) Yes, unittest are quite appropriate for your project.  When you move
your docstring tests to unittests try to isolate the tests.  For
instance, the test you've shown couples the TpedIterator with the string
representation of a Marker object.

5) Is your system really so simple that it's useful to run
interactively?  I may be out of touch but I script most of my codes and
tests because I make so many errors and module changes.  In other words,
is your interactive docstring example a reasonable use case?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4899>
_______________________________________

From report at bugs.python.org  Tue Jan 13 18:54:45 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 13 Jan 2009 17:54:45 +0000
Subject: [issue4934] tp_del and tp_version_tag undocumented
In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>
Message-ID: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The PyTypeObject field "tp_version_tag" (new in 2.6) isn't documented.

"tp_del" isn't documented either.  I'm not sure when it was added.

----------
assignee: georg.brandl
components: Documentation
messages: 79755
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: tp_del and tp_version_tag undocumented
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4934>
_______________________________________

From report at bugs.python.org  Tue Jan 13 18:58:47 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 13 Jan 2009 17:58:47 +0000
Subject: [issue4888] misplaced (or misleading) assert in ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1231869527.24.0.354004803603.issue4888@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

The assert seems confusing to me because it's overly specific. It causes
me to ask, "what's special about WHY_YIELD that why might be set to it?"
If I understand the loop correctly, we could rewrite the top as:

assert(why != WHY_YIELD);  /* These two values aren't handled in the
loop. */
assert(why != WHY_RERAISE);
orig_why = why;
while (why != WHY_NOT && f->f_iblock > 0) {
    /* The code does not change 'why' without breaking out of the loop. */
    assert(why == orig_why);
    ...
}

which would tell the reader more about the state of the world without
focusing their attention on anything that isn't somehow special.

Of course, nothing prevents the code from changing orig_why (*pines for
const and late declarations*), but such a change would be more obviously
wrong.

Was there another reason to assert(why!=WHY_YIELD) than that the if's
don't handle it? Is 'why' more likely to become WHY_YIELD than WHY_RERAISE?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4888>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:04:00 2009
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 13 Jan 2009 18:04:00 +0000
Subject: [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231869840.32.0.721674195544.issue4899@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

For unittests I recommend two things instead of need for doctest change.
A decoupled strict test to prove that the iterator works, and this class
to publish,

class Tped_use_cases(...):

    def test_Marker_iteration(self):

        '''
            Illustrative code adapted from what is now your doctest
        '''

    ...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4899>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:27:12 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 18:27:12 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>
Message-ID: <1231871232.05.0.297150915638.issue4933@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 2.5 branch is now frozen: only security fixes are accepted. You 
should work on 2.6 or better on Python trunk for faster integration of 
your patches ;-) Your patch looks good.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:30:28 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 13 Jan 2009 18:30:28 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1231871428.03.0.276884655308.issue4449@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I agree with Martin - if no one else gets to this before me, I should be 
able to submit it within the next day.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:36:26 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 13 Jan 2009 18:36:26 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1231871786.21.0.132149018166.issue4242@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

At the language summit I actually plan on proposing separating out the
Python the language and standard library from CPython. That would make
this patch mostly unneeded as the CPython-specific tests and code would
simply be kept separate from the language code that PyPy and other VMs
would use.

Because of this I am not going to do any code review right now in hopes
that my more radical proposal goes through.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:38:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 13 Jan 2009 18:38:28 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <496CDFA2.6070607@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This leads to problems in the testsuite on vista.

To which problem specifically?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:42:57 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 13 Jan 2009 18:42:57 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1231844060.17.0.741078007709.issue4804@psf.upfronthosting.co.za>
Message-ID: <496CE0AE.7000908@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I submit to you a patch to the trunk which narrows down the problem.  In  
> stead of throwing the switch for the whole process, we selectively 
> disable the hard error checking for those two cases that require it:  

-1. Setting the CRT report mode is not thread-safe, so this code may
randomly affect concurrent threads.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:44:07 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 18:44:07 +0000
Subject: [issue4932] Little improvement on urlparse module, urlparse function.
In-Reply-To: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>
Message-ID: <1231872247.66.0.319479548304.issue4932@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like most of your changes are already part of urlparse module 
of Python 2.6. Can you port your patch to Python 2.6 and retry your 
benchmark on Python 2.6?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4932>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:47:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 18:47:25 +0000
Subject: [issue4807] wrong wsprintf usage
In-Reply-To: <1230901683.42.0.873273528074.issue4807@psf.upfronthosting.co.za>
Message-ID: <1231872445.4.0.78778442925.issue4807@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

fprintf() is much better than wsprintf() + fputs() with a fixed size 
buffer (with no size/error check!). Same remark for 
PyString_FromFormat() instead of wsprintf()+PyString_FromString().

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4807>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:49:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 18:49:23 +0000
Subject: [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1231872563.81.0.647252807948.issue4929@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Your patch looks fine but it would be much better with a test in 
Lib/test/test_smtp.py ;-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4929>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:50:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 18:50:39 +0000
Subject: [issue4935] Segmentation fault in bytearray tests
In-Reply-To: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>
Message-ID: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This happens on a 32-bit build on a 64-bit system, which happens to have
some interesting properties: for example, malloc() will happily allocate
memory larger than Py_SSIZE_T_MAX.

The crash is exactly triggered by the following snippet:

        if sys.maxsize < (1 << 32) and struct.calcsize('P') == 4:
            self.assertRaises(OverflowError,
                              self.marshal(b'\ta\n\tb').expandtabs,
sys.maxsize)

----------
components: Interpreter Core
messages: 79766
nosy: pitrou
priority: critical
severity: normal
status: open
title: Segmentation fault in bytearray tests
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4935>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:52:01 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 13 Jan 2009 18:52:01 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1231872721.25.0.880707806351.issue4931@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What is the specific error you are reporting?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:55:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 13 Jan 2009 18:55:32 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>
Message-ID: <1231872932.35.0.730099957547.issue4933@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What is the purpose of this patch? I.e. why are you submitting it to
this bug tracker?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:57:53 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 13 Jan 2009 18:57:53 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1231873073.49.0.467917849945.issue4931@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Currently I haven't any C compiler installed on my system so I expect
distutils to report that every time I try to compile a C module extension.
Python 2.5 did that while Python 2.6 does not.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Tue Jan 13 19:59:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 18:59:25 +0000
Subject: [issue4936] bytearrayobject.o does not depend on stringlib files
In-Reply-To: <1231873165.21.0.228432008628.issue4936@psf.upfronthosting.co.za>
Message-ID: <1231873165.21.0.228432008628.issue4936@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Modifying one of the stringlib files does not trigger recompiling of
Objects/bytearray.c, although the latter includes the former.

----------
components: Build
messages: 79770
nosy: pitrou
priority: normal
severity: normal
status: open
title: bytearrayobject.o does not depend on stringlib files
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4936>
_______________________________________

From report at bugs.python.org  Tue Jan 13 20:25:05 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 19:25:05 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231874705.21.0.627892901703.issue4871@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created small archive with a password using zip 2.32 (Ubuntu Gutsy). 
The unicode flag is not set and so ASCII charset is used to encode the 
password. But my password was an unicode password using non-ASCII 
characters and so I get an UnicodeEncodeError ('ascii' codec can't 
encode character u'\xe9' ...). The user (me) doesn't expect such error 
here :-/

If I encode the unicode password to bytes using 
password.encode('utf-8'), it works as expected. So I would prefer to 
just reject unicode for the password. Attached patch implements that.

Added file: http://bugs.python.org/file12722/zipfile_no_unicode_pasword.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Tue Jan 13 20:29:20 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 19:29:20 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231874960.57.0.761608080753.issue4871@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12722/zipfile_no_unicode_pasword.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Tue Jan 13 20:29:34 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 19:29:34 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231874974.91.0.26118776592.issue4871@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file12723/zipfile_no_unicode_pasword.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Tue Jan 13 20:59:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 19:59:23 +0000
Subject: [issue4935] Segmentation fault in bytearray tests
In-Reply-To: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>
Message-ID: <1231876763.04.0.950867144377.issue4935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. The idea is to use unsigned arithmetic instead of
signed, and to check for overflows by comparing with PY_SSIZE_T_MAX.

(the exact reason of the crash is unknown, it looks like either a
compiler bug or a mis-optimization as (i < 0) returns 0 while i is
-0x7FFFFFFF)

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file12724/issue4935.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4935>
_______________________________________

From report at bugs.python.org  Tue Jan 13 21:08:39 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Jan 2009 20:08:39 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1231877319.19.0.105930333149.issue4242@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Physically splitting the code base? Ick... I'd prefer just to flag the
parts of the test suite that are optional and let the developers of
other implementations pick and choose as to how much of the pure Python
code they want to adopt to pass the non-optional parts of the test-suite...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 13 22:02:31 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Tue, 13 Jan 2009 21:02:31 +0000
Subject: [issue4937] Mac DMG install missing version.plist required by
	bundlebuilder.py
In-Reply-To: <1231880551.46.0.128485851272.issue4937@psf.upfronthosting.co.za>
Message-ID: <1231880551.46.0.128485851272.issue4937@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

I installed mac python 2.6.1 on Mac OS X 10.5.6

I then ran my pysvn workbench kitting script that uses
bundlebuilder.py. It fails because version.plist is not installed.

Traceback (most recent call last):
  File "make_wb_bundle.py", line 91, in <module>
    myapp.build()
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/bundlebuilder.py",
line 163, in build
    self._copyFiles()
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/bundlebuilder.py",
line 218, in _copyFiles
    copy(src, dst, mkdirs=1)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/bundlebuilder.py",
line 758, in copy
    shutil.copy2(src, dst)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/shutil.py",
line 99, in copy2
    copyfile(src, dst)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/shutil.py",
line 52, in copyfile
    fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory:
'/Library/Frameworks/Python.framework/Versions/2.6/Resources/version.plist'

----------
components: Installation
messages: 79774
nosy: barry-scott
severity: normal
status: open
title: Mac DMG install missing version.plist required by bundlebuilder.py
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4937>
_______________________________________

From report at bugs.python.org  Tue Jan 13 22:11:36 2009
From: report at bugs.python.org (Scott McCreary)
Date: Tue, 13 Jan 2009 21:11:36 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231871232.05.0.297150915638.issue4933@psf.upfronthosting.co.za>
Message-ID: <b2c273ce0901131306r66a7a439ka29f0d4bc7758a27@mail.gmail.com>


Scott McCreary <scottmc2 at gmail.com> added the comment:

On Tue, Jan 13, 2009 at 10:27 AM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Python 2.5 branch is now frozen: only security fixes are accepted. You
> should work on 2.6 or better on Python trunk for faster integration of
> your patches ;-) Your patch looks good.
>
> ----------
> nosy: +haypo
>
> _______________

2.6.x is next on my list, then we'll focus on 3.x.x.  Probably have a
patch cleaned and ready to post within a few days here.

Martin v. L?wis <martin at v.loewis.de> added the comment:

What is the purpose of this patch? I.e. why are you submitting it to
this bug tracker?

"This patch adds preliminary support for Haiku." In case you were
wondering what Haiku was, it is the open source replacement for BeOS,
see haiku-os.org for more background.
As for part two of your question, is there somewhere else I should be
posting patches?  If so direct me and I'll post them there.

-scottmc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Tue Jan 13 22:50:29 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 13 Jan 2009 21:50:29 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <b2c273ce0901131306r66a7a439ka29f0d4bc7758a27@mail.gmail.com>
Message-ID: <496D0BE5.2060106@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What is the purpose of this patch? I.e. why are you submitting it to
> this bug tracker?
> 
> "This patch adds preliminary support for Haiku." In case you were
> wondering what Haiku was, it is the open source replacement for BeOS,
> see haiku-os.org for more background.
> As for part two of your question, is there somewhere else I should be
> posting patches?  If so direct me and I'll post them there.

No, my question is whether you really want to see this patch considered
for inclusion into Python. If so, I guess I need to reject it, as we
decided some time ago to not accept patches for such minority platforms
anymore.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Tue Jan 13 22:54:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 13 Jan 2009 21:54:51 +0000
Subject: [issue4936] bytearrayobject.o does not depend on stringlib files
In-Reply-To: <1231873165.21.0.228432008628.issue4936@psf.upfronthosting.co.za>
Message-ID: <1231883691.51.0.719858164246.issue4936@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r68579 (trunk) and r68581 (py3k).

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4936>
_______________________________________

From report at bugs.python.org  Tue Jan 13 22:56:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Jan 2009 21:56:37 +0000
Subject: [issue4935] Segmentation fault in bytearray tests
In-Reply-To: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>
Message-ID: <1231883797.56.0.848554709303.issue4935@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What's the purpose of old_i?  It looks like it's never used for anything.

Other than than, the patch looks good to me.

I'd guess that the "if (i < 0)" was simply optimized away.  This isn't 
necessarily a compiler bug: if I understand correctly, a strict reading of 
the C standards says it's legitimate for a compiler to assume that code is 
written in such a way that signed-arithmetic overflow never happens, and 
gcc (for one) is known to take advantage of this.

Also, it would be nice to cleanup the whitespace in this function while 
you're fixing it;  at the moment it's showing me a mixture of tabs and 
spaces.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4935>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:09:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Jan 2009 22:09:25 +0000
Subject: [issue4935] Segmentation fault in bytearray tests
In-Reply-To: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>
Message-ID: <1231884565.66.0.764914657747.issue4935@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Actually, what's the purpose of old_j?  It looks like that's not needed 
any more, either!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4935>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:12:52 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 13 Jan 2009 22:12:52 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1231884772.96.0.515630372363.issue2233@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file12725/py-issue-2233.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:30:56 2009
From: report at bugs.python.org (John Levon)
Date: Tue, 13 Jan 2009 22:30:56 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1231885856.79.0.465462815396.issue1975@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

This issue also affects Solaris (and in particular xend is broken). Is
there a reason bamby's fix isn't yet applied?

----------
nosy: +movement
title: signals in thread problem -> signals not always delivered to main thread, since other threads have the signal unmasked

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:33:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 22:33:07 +0000
Subject: [issue4935] Segmentation fault in bytearray tests
In-Reply-To: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>
Message-ID: <1231885987.46.0.86037691652.issue4935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You are right, old_i and old_j are unused, they were part of another
approach I tried and which failed.
Attaching new patch with these 2 variables removed, and the function
cleanly reindented (of course the patch is messier because of this).

Added file: http://bugs.python.org/file12726/issue4935-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4935>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:34:42 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 13 Jan 2009 22:34:42 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1231886082.67.0.307386418124.issue4804@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Martin,
  Would you be happier if this functionality was exposed via _msvcrt and
disabled in the test suite (either globally or selectively)?  Obviously
this is still not thread-safe, but it is closer towards putting this
behaviour in the control of the app itself.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:38:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 22:38:52 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1231886332.34.0.575848494853.issue1975@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is there any reason not to simply catch KeyboardInterrupt in the user
thread, and then notify the main thread?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:46:01 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 13 Jan 2009 22:46:01 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231886761.18.0.738071588059.issue4871@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Yes, the unicode flag is irrelevant to the password. To successfuly 
decrypt a file, one must know the password *and* the encoding in use 
when it was written, so the only sensible thing to do is to accept 
bytes only.

Your patch looks good to me with a few comments:

- I'd only check the password in setpassword() and open(); the other 
methods eventually call open().

- The issue version says "3.0"; but it should be applied to 2.6 2.7 
and 3.1 too.

- For 3.0 the check is wrong, should say "bytes" instead of "str". 
Even in 2.6 should use "bytes" to make clear the intent.

- The usual wording for such TypeError is more like "pwd: 
expected 'bytes', got '%s'"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:48:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Jan 2009 22:48:01 +0000
Subject: [issue4935] Segmentation fault in bytearray tests
In-Reply-To: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>
Message-ID: <1231886881.01.0.180953492821.issue4935@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks fine;  I think this should be applied.

It seems as though your reindentation left trailing whitespace on
the blank lines in the function:  the svn commit hook might
complain about this...

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4935>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:49:38 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 13 Jan 2009 22:49:38 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1231886082.67.0.307386418124.issue4804@psf.upfronthosting.co.za>
Message-ID: <496D1A80.2010803@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>   Would you be happier if this functionality was exposed via _msvcrt and
> disabled in the test suite (either globally or selectively)?  Obviously
> this is still not thread-safe, but it is closer towards putting this
> behaviour in the control of the app itself.

Adding stuff into _msvcrt is fine with me. I guess the debate then might
be what the default should be. I personally don't care at all, as I
rarely ever use the debug build on Windows in the first place.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:55:44 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Jan 2009 22:55:44 +0000
Subject: [issue4938] Pdb cannot access doctest source in postmortem
In-Reply-To: <1231887344.64.0.130142534031.issue4938@psf.upfronthosting.co.za>
Message-ID: <1231887344.64.0.130142534031.issue4938@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With attached x.py:

$ cat x.py
"""
>>> foo()
"""
def foo():
    1/0

if __name__ == '__main__':
    import doctest, pdb
    try:
        doctest.testmod(raise_on_error=True)
    except doctest.UnexpectedException, e:
        pdb.post_mortem(e.exc_info[2])

$ ./python.exe x.py
> /Users/sasha/Work/python-svn/trunk/x.py(5)foo()
-> 1/0
(Pdb) up
> <doctest __main__[0]>(1)<module>()
(Pdb) l
[EOF]


Apparently the problem is that the default getlines gets restored in the  
"finally:" section in DocTestRunner.run() before post_mortem is invoked.

The only solution that comes to mind is to patch pdb.post_mortem 
similarly to the way pdb.set_trace is patched but not restore it until 
the end of testmod().

Am I missing a simpler solution?

----------
files: x.py
messages: 79787
nosy: belopolsky
severity: normal
status: open
title: Pdb cannot access doctest source in postmortem
Added file: http://bugs.python.org/file12727/x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4938>
_______________________________________

From report at bugs.python.org  Tue Jan 13 23:57:48 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Jan 2009 22:57:48 +0000
Subject: [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231887468.71.0.431819716594.issue4899@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4899>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:19:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Jan 2009 23:19:45 +0000
Subject: [issue4807] wrong wsprintf usage
In-Reply-To: <1230901683.42.0.873273528074.issue4807@psf.upfronthosting.co.za>
Message-ID: <1231888785.2.0.273785351179.issue4807@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r68592.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4807>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:20:13 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 13 Jan 2009 23:20:13 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231888813.58.0.227500613556.issue4715@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I've backported condbranches-plus.patch to trunk, and I'm getting these 
results:

PyBench: 1.84-2.21% faster
2to3: 3.83% faster
Spitfire: 6.13-6.23% faster

PyBench was run with -w=1; 2to3 is translating its entire source 
directory five times; Spitfire is measured by the "Spitfire -O4" line 
from tests/perf/bigtable.py, run 15 times. This is on a Core 2 system. 
My AMD system (otherwise identical) shows somewhat less improvement, 
but still an improvement.

I've haven't tested condbranches.patch vs condbranches-plus.patch; what 
difference are you seeing, Antoine?

I like these changes. Folding POP into JUMP_IF_{TRUE,FALSE} should have 
been done years ago (I think I proposed it and Raymond shot me down). 
I'm also in favor of making POP_JUMP_IF_* absolute jumps.

This patch mostly looks good, though you still need to change Doc/
library/dis.rst and the pure-Python compiler package. I'd get someone 
else to look over the patch, too, though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:22:21 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 23:22:21 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231888941.28.0.944096147465.issue4871@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

gagenellina: Oops, yes, I wrote my patch for Python trunk. New patch 
only uses two checks for the password type (since extract() calls 
open()). I also changed the error message.

----------
versions: +Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12728/zipfile_no_unicode_pasword-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:22:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 23:22:37 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is witnessed on trunk, at home as well as on the buildbots:

======================================================================
ERROR: test_dotted_attribute (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
492, in test_dotted_attribute
    self.test_simple1()
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
376, in test_simple1
    self.assertEqual(p.pow(6,8), 6**8)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_introspection1 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
398, in test_introspection1
    meth = p.system.listMethods()
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_introspection2 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
413, in test_introspection2
    divhelp = p.system.methodHelp('div')
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_introspection3 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
425, in test_introspection3
    myfunction = p.system.methodHelp('my_function')
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_introspection4 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
438, in test_introspection4
    divsig = p.system.methodSignature('div')
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_multicall (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
453, in test_multicall
    add_result, pow_result, div_result = multicall()
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1042, in
__call__
    return
MultiCallIterator(self.__server.system.multicall(marshalled_list))
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_non_existing_multicall (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
468, in test_non_existing_multicall
    result = multicall()
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1042, in
__call__
    return
MultiCallIterator(self.__server.system.multicall(marshalled_list))
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_simple1 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
376, in test_simple1
    self.assertEqual(p.pow(6,8), 6**8)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_basic (test.test_xmlrpc.FailingServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
534, in test_basic
    self.assertEqual(p.pow(6,8), 6**8)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

----------------------------------------------------------------------

----------
components: Library (Lib)
messages: 79792
nosy: pitrou
priority: critical
severity: normal
status: open
title: Failures in test_xmlrpc
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:23:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 23:23:27 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231889007.25.0.651275407797.issue4871@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch for py3k: str=>bytes, remove "u" string prefix and 
rename "bytes" variable to "data" to avoid conflict with the bytes 
type.

Added file: http://bugs.python.org/file12729/zipfile_no_unicode_pasword-2-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:25:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 23:25:27 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1231888813.58.0.227500613556.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231889146.7109.6.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

> I've backported condbranches-plus.patch to trunk, and I'm getting these 
> results:

Thanks!

> PyBench: 1.84-2.21% faster
> 2to3: 3.83% faster
> Spitfire: 6.13-6.23% faster

What is Spitfire?

> I've haven't tested condbranches.patch vs condbranches-plus.patch; what 
> difference are you seeing, Antoine?

condbranches.patch is the earlier version (without POP_OR_JUMP and
JUMP_OR_POP), it can be ignored.

> This patch mostly looks good, though you still need to change Doc/
> library/dis.rst and the pure-Python compiler package.

Well, the pure-Python compiler package doesn't exist in py3k, for which
I've initially made the patch.
(and its state in 2.x is very sorry...)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:26:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 23:26:46 +0000
Subject: [issue4935] Segmentation fault in bytearray tests
In-Reply-To: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>
Message-ID: <1231889206.68.0.997485618298.issue4935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in trunk, py3k, 2.6 and 3.0. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4935>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:29:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 23:29:09 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231889349.58.0.407577264326.issue4939@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:29:09 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 13 Jan 2009 23:29:09 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1231889146.7109.6.camel@localhost>
Message-ID: <43aa6ff70901131529n34730cbbk74cc48455fbde86c@mail.gmail.com>


Collin Winter <collinw at gmail.com> added the comment:

On Tue, Jan 13, 2009 at 3:25 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Hello,
>
>> I've backported condbranches-plus.patch to trunk, and I'm getting these
>> results:
>
> Thanks!
>
>> PyBench: 1.84-2.21% faster
>> 2to3: 3.83% faster
>> Spitfire: 6.13-6.23% faster
>
> What is Spitfire?

http://code.google.com/p/spitfire/. It's a template system designed
for performance that I have some experience with.

>> I've haven't tested condbranches.patch vs condbranches-plus.patch; what
>> difference are you seeing, Antoine?
>
> condbranches.patch is the earlier version (without POP_OR_JUMP and
> JUMP_OR_POP), it can be ignored.

I was mostly curious whether the POP_OR_JUMP and JUMP_OR_POP opcodes
had a noticeable performance impact, ie, do they make things fast
enough to warrant their inclusion over the old JUMP_IF_FALSE
implementations.

>> This patch mostly looks good, though you still need to change Doc/
>> library/dis.rst and the pure-Python compiler package.
>
> Well, the pure-Python compiler package doesn't exist in py3k, for which
> I've initially made the patch.
> (and its state in 2.x is very sorry...)

I'll update the compiler package in 2.x and post my patch once I have
it working. There are also some test failures in 2.x that I'll take
care of.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:30:08 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 23:30:08 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1231889408.49.0.19128708207.issue4927@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Turns out it wasn't vista related at all, but related to TESTFN being 
tmp\@test
When this happens, test_file.py fails when testing the repr for a 
unicode file, because the repr contains u'tmp\\@test' whereas for a 
string filename it will contain 'tmp\@test'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:30:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 23:30:36 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231889436.41.0.231499595094.issue4715@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12419/condbranches.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:32:23 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 23:32:23 +0000
Subject: [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1231889543.25.0.987741877441.issue4929@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

If you can offer a suggestion as to how to reliably trigger a 
WSAECONNRESET error on windows (or its equivalent on unix) I'll be 
happy to do that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4929>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:35:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 23:35:26 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231889726.29.0.612677308754.issue4715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, hadn't seen your message before removing the file. Here it is again.

Added file: http://bugs.python.org/file12730/condbranches.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:36:28 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 23:36:28 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231889788.05.0.529272054693.issue4939@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Regression introduced by r68532. Replace self._parse_response() by 
self.parse_response() fixes the tests.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:37:57 2009
From: report at bugs.python.org (John Levon)
Date: Tue, 13 Jan 2009 23:37:57 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1231889877.52.0.328368784371.issue1975@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

Yes, Python guarantees the behaviour under discussion:

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:38:56 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 23:38:56 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231889936.89.0.514330542411.issue4939@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r68532 was a fix for the issue #4879 and removed an old compatibility 
interface (_parse_response).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:39:00 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 23:39:00 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1231889940.76.0.814920155845.issue4804@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

It is not an issue with debug builds only.  The crt error handler is 
currently also reset globally for all builds which is very evil.

The current way we do thing is also not thread safe WRT other 
application threads.  On second thought though it is better to at least 
keep this modification within the bounds of the GIL.  I'll change the 
patch for that.

IMHO, the issue for the posix fd functions isn't that great, since 
hardly anyone would want to use them on windows.  The main issue is 
still the open() call.  This one is possible to avoid too without 
invoking changin the crt behaviour, by simply ramping up the 
_sanitize_mode function.

I'll put in some more effort then, because I think it is really 
important for Python to leave the crt settings alone, and still be sure 
that random input can't have unforeseen consequences.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:39:38 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Jan 2009 23:39:38 +0000
Subject: [issue1162154] inspect.getmembers() breaks sometimes
Message-ID: <1231889978.01.0.839748545331.issue1162154@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r68596.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1162154>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:42:41 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 23:42:41 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1231890161.15.0.154186797721.issue2736@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12013/datetime_totimestamp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:42:46 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 23:42:46 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1231890166.87.0.0348237471953.issue2736@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12014/datetime_totimestamp-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:42:58 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Jan 2009 23:42:58 +0000
Subject: [issue2736] datetime needs and "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1231890178.98.0.677993582061.issue2736@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12123/timestamp.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:45:35 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 23:45:35 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231890335.83.0.34143038399.issue4939@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Oh dear, this is because it skips those tests on windows.  I'll check 
in a fix to xmlrpclib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:15:54 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Jan 2009 23:15:54 +0000
Subject: [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231888554.76.0.393132884489.issue4899@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The OP's problem, i.e. the need to reimport modules in every docstring 
can  easily be addressed by injecting the necessary names using 
extraglobs argument to doctest.testmod().

I like the following trick:

def getextraglobs():
   import StringIO, tempfile, ...
   return locals()
doctest.testmod(extraglobs=getextraglobs())

This however does not solve a problem of cleanup after examples and some 
way to specify a tearDown fixture would be helpful, particularly because  
cleanup code in examples will rarely improve documentation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4899>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:46:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 23:46:53 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <43aa6ff70901131529n34730cbbk74cc48455fbde86c@mail.gmail.com>
Message-ID: <1231890431.7109.15.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> http://code.google.com/p/spitfire/. It's a template system designed
> for performance that I have some experience with.

6% faster on a template system simply by optimizing conditional jumps is
quite neat.
(the spitfire homepage itself is rather intriguing, they claim to be
faster than plain string joining...)

> I was mostly curious whether the POP_OR_JUMP and JUMP_OR_POP opcodes
> had a noticeable performance impact, ie, do they make things fast
> enough to warrant their inclusion over the old JUMP_IF_FALSE
> implementations.

Well, I don't remember really, although this is only a few weeks old.
POP_OR_JUMP / JUMP_OR_POP will be used when the "and" and "or" keywords
are involved. That's basically the only situation where you don't want
to pop the top of stack after a conditional jump.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:48:55 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 13 Jan 2009 23:48:55 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231890535.73.0.673717929034.issue4939@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r68597.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:52:41 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 23:52:41 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231890761.92.0.894634001999.issue4939@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, you beat me to it.
So, is there any good reason to keep those xmlrpc tests defunct on 
win32 still?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 00:55:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 13 Jan 2009 23:55:22 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231890761.92.0.894634001999.issue4939@psf.upfronthosting.co.za>
Message-ID: <1afaf6160901131555n74bfdfb9y9aa07fb87d32e059@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Tue, Jan 13, 2009 at 5:52 PM, Kristj?n Valur J?nsson
<report at bugs.python.org> wrote:
>
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
>
> Ok, you beat me to it.

Sorry, I just seem to have bad timing today. :)

> So, is there any good reason to keep those xmlrpc tests defunct on
> win32 still?

I'm not sure. Have you tried enabling them?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 01:01:50 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Jan 2009 00:01:50 +0000
Subject: [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>
Message-ID: <1231891310.47.0.250168149881.issue2723@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Initial proposition (len.diff) was rejected. If you want to change 
len() behaviour, reopen this issue or open another one.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2723>
_______________________________________

From report at bugs.python.org  Wed Jan 14 01:11:42 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 14 Jan 2009 00:11:42 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231891902.06.0.236417606217.issue4939@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes and they work, but do take some 10 seconds to run.  If it is 
similar on unix, I'll do so.  What's your numbers?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 01:12:48 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Jan 2009 00:12:48 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231891902.06.0.236417606217.issue4939@psf.upfronthosting.co.za>
Message-ID: <1afaf6160901131612u26c12a50hea1388b1305281eb@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Tue, Jan 13, 2009 at 6:11 PM, Kristj?n Valur J?nsson
<report at bugs.python.org> wrote:
>
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:
>
> Yes and they work, but do take some 10 seconds to run.  If it is
> similar on unix, I'll do so.  What's your numbers?

It takes about a second to run them here.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 01:14:12 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 14 Jan 2009 00:14:12 +0000
Subject: [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231892052.75.0.226922740639.issue4939@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, I'll keep them disabled until I figure out why they take so long.  
Maybe there is some performance enhancements yet to be made :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4939>
_______________________________________

From report at bugs.python.org  Wed Jan 14 01:29:57 2009
From: report at bugs.python.org (rech)
Date: Wed, 14 Jan 2009 00:29:57 +0000
Subject: [issue4940] decimal.Decimal.__init__ should raise an instance of
	ValueError
In-Reply-To: <1231892997.26.0.818737849163.issue4940@psf.upfronthosting.co.za>
Message-ID: <1231892997.26.0.818737849163.issue4940@psf.upfronthosting.co.za>


New submission from rech <r.rechkemmer at web.de>:

A common pattern is to check numeric input like this:

a = input()
try:
   int(a) # or float(a)
except ValueError:
   print("Bad input")

One would expect this to work with decimal.Decimal(a), too. But, as
Decimal.__init__ raises decimal.InvalidOperation instead of a
ValueError, it fails.

Making Decimal.__init__ raise a ValueError in this context would be an
incompatible change. Also, making decimal.InvalidOperation a subclass of
ValueError might not be correct.
It would be best to create a new an more specific exception for this
case, a subclass of both decimal.InvalidOperation and ValueError. This
would keep all functionality and enable this kind of intuitive use.

----------
components: Library (Lib)
messages: 79814
nosy: lemburg, rech
severity: normal
status: open
title: decimal.Decimal.__init__ should raise an instance of ValueError
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4940>
_______________________________________

From report at bugs.python.org  Wed Jan 14 01:35:03 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Jan 2009 00:35:03 +0000
Subject: [issue1565525] gc allowing tracebacks to eat up memory
Message-ID: <1231893303.58.0.433889168889.issue1565525@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I wrote a patch to support <traceback object>.tb_frame=None. It works 
but the traceback becomes useless because you have unable to display 
the traceback. The frame is used by tb_printinternal() to get the 
filename (co_filename) and the code name (co_name).

I also tried:
    while tbi:
        frame = tbi.tb_frame
        tbi = tbi.tb_next
        frame.f_locals.clear()
        frame.f_globals.clear()

... and it doesn't work because the tbi variable is also removed!

A traceback object have to contain the full frame, but the frame 
contains "big" objects eating your memory. A solution to your initial 
problem (store exceptions) is to not store the traceback object or at 
least to store it as a (list of) string. Solution already proposed by 
loewis (msg29999).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Wed Jan 14 01:35:55 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Jan 2009 00:35:55 +0000
Subject: [issue4940] decimal.Decimal.__init__ should raise an instance of
	ValueError
In-Reply-To: <1231892997.26.0.818737849163.issue4940@psf.upfronthosting.co.za>
Message-ID: <1231893355.25.0.965278011016.issue4940@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, the decimal world has it's own little world of precisely defined
and spec-mandated exceptions.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4940>
_______________________________________

From report at bugs.python.org  Wed Jan 14 01:40:57 2009
From: report at bugs.python.org (Greg Hazel)
Date: Wed, 14 Jan 2009 00:40:57 +0000
Subject: [issue1565525] gc allowing tracebacks to eat up memory
Message-ID: <1231893657.92.0.481572649422.issue1565525@psf.upfronthosting.co.za>


Greg Hazel <ghazel at users.sourceforge.net> added the comment:

But a list of strings is not re-raisable. The co_filename, co_name, and 
such used to print a traceback are not dependent on the locals or 
globals.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Wed Jan 14 02:09:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Jan 2009 01:09:23 +0000
Subject: [issue1565525] gc allowing tracebacks to eat up memory
Message-ID: <1231895363.78.0.128452246045.issue1565525@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried to remove the frame from the traceback type (to keep only the 
filename and code name), but many functions rely on the frame object. 
Some examples:

Lib/unittest.py:
   class TestResult(object):
      def _is_relevant_tb_level(self, tb):
         return '__unittest' in tb.tb_frame.f_globals

Lib/traceback.py:
   print_tb() uses tb.tb_frame.f_globals for linecache.getline()

Doc/tools/jinga/debugger.py:
   translate_exception() checks if __jinja_template__ variable is 
present in b.tb_frame.f_globals

Lib/idlelib/StackViewer.py:
   StackTreeItem.get_stack() stores each tb.tb_frame in a list
   FrameTreeItem.GetText() reads frame.f_globals["__name__"] and gets 
the filename and code name using frame.f_code

Lib/logging/__init__.py:
   currentframe() reads sys.exc_traceback.tb_frame.f_back

Lib/types.py:
   Use tb.tb_frame to create the FrameType

(...)

co_name/co_filename can be stored directly in the traceback. But what 
about tb.tb_frame.f_back and tb.tb_frame.f_globals? I'm not motivated 
enough to change traceback API.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Wed Jan 14 02:12:50 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Jan 2009 01:12:50 +0000
Subject: [issue1565525] gc allowing tracebacks to eat up memory
In-Reply-To: <1231893657.92.0.481572649422.issue1565525@psf.upfronthosting.co.za>
Message-ID: <200901140212.41667.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Greg Hazel> But a list of strings is not re-raisable

Do you need the original traceback? Why not only raising the exception? Eg.
----
import sys
try:
    raise Exception("hm!")
except:
    t, v, tb = sys.exc_info()
    raise v
----

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Wed Jan 14 02:19:15 2009
From: report at bugs.python.org (Greg Hazel)
Date: Wed, 14 Jan 2009 01:19:15 +0000
Subject: [issue1565525] gc allowing tracebacks to eat up memory
Message-ID: <1231895955.37.0.356782997554.issue1565525@psf.upfronthosting.co.za>


Greg Hazel <ghazel at users.sourceforge.net> added the comment:

STINNER Victor> Do you need the original traceback? Why not only raising 
the exception?

If the exception was captured in one stack, and is being re-raised in 
another. It would be more useful to see the two stacks appended instead 
of just the place where it was re-raised (or the place where it was 
raised initially, which is what a string would get you - not to mention 
the inability to catch it).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Wed Jan 14 03:10:30 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 14 Jan 2009 02:10:30 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

As suggested by Paolo Giarrusso, add a "likely()" to Py_DECREF, telling
GCC it doesn't call the destructor in the common path.

This optimization seems to interact well with #4896 and to be slower on
top of #4753 on my system. Patching ceval.c instead of object.h seems to
give the same result, FWIW. Benchmarks most welcome :)

Paolo Giarrusso wrote:
"Anyway, yesterday I was looking at the assembly and I realized that
GCC optimizes the case where Py_DECREF calls the destructor! Since I
don't have time for this, can you hint GCC for the better by adding
unlikely() to Py_DECREF, at least (or maybe only) for ceval.c, or
maybe even only for the main interpreter?"

pybench:
    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    Linux-2.6.24-23-generic-i686-with-debian-lenny-sid
       Processor:      Intel Celeron M 410

    Python:
       Implementation: CPython
       Executable:     /home/ajaksu/py3k/python
       Version:        3.1.0
       Compiler:       GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
       Bits:           32bit
       Build:          Jan 13 2009 23:40:05 (#py3k:68571M)
       Unicode:        UCS2


Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other 
 diff
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:   147ms   163ms   -9.7%   148ms   164ms
 -10.0%
           BuiltinMethodLookup:   138ms   154ms  -10.3%   139ms   155ms
 -10.6%
                 CompareFloats:   185ms   191ms   -3.4%   185ms   192ms
  -3.4%
         CompareFloatsIntegers:   304ms   294ms   +3.1%   304ms   296ms
  +2.7%
               CompareIntegers:   287ms   281ms   +2.0%   288ms   281ms
  +2.3%
        CompareInternedStrings:   189ms   217ms  -12.7%   192ms   217ms
 -11.7%
                  CompareLongs:   167ms   162ms   +3.3%   168ms   162ms
  +3.3%
                CompareStrings:   152ms   178ms  -14.2%   156ms   179ms
 -12.7%
    ComplexPythonFunctionCalls:   192ms   202ms   -5.1%   193ms   206ms
  -6.2%
                 ConcatStrings:   325ms   327ms   -0.7%   326ms   330ms
  -1.1%
               CreateInstances:   200ms   209ms   -4.4%   204ms   210ms
  -2.9%
            CreateNewInstances:   149ms   156ms   -4.4%   151ms   161ms
  -5.8%
       CreateStringsWithConcat:   255ms   272ms   -6.1%   258ms   275ms
  -6.3%
                  DictCreation:   145ms   151ms   -4.0%   146ms   154ms
  -5.3%
             DictWithFloatKeys:   209ms   224ms   -6.8%   209ms   224ms
  -6.7%
           DictWithIntegerKeys:   170ms   185ms   -8.0%   171ms   187ms
  -8.3%
            DictWithStringKeys:   155ms   172ms  -10.1%   156ms   173ms
 -10.2%
                      ForLoops:   162ms   183ms  -11.7%   162ms   183ms
 -11.4%
                    IfThenElse:   189ms   217ms  -12.7%   190ms   219ms
 -13.1%
                   ListSlicing:   156ms   156ms   -0.3%   156ms   158ms
  -1.0%
                NestedForLoops:   199ms   219ms   -9.1%   201ms   220ms
  -8.6%
      NestedListComprehensions:   222ms   245ms   -9.5%   228ms   251ms
  -9.2%
          NormalClassAttribute:   352ms   376ms   -6.2%   353ms   378ms
  -6.6%
       NormalInstanceAttribute:   188ms   212ms  -11.1%   191ms   215ms
 -11.3%
           PythonFunctionCalls:   173ms   192ms   -9.6%   174ms   193ms
  -9.7%
             PythonMethodCalls:   213ms   226ms   -5.6%   214ms   227ms
  -5.8%
                     Recursion:   275ms   295ms   -7.0%   276ms   296ms
  -7.0%
                  SecondImport:   158ms   158ms   +0.2%   160ms   160ms
  +0.1%
           SecondPackageImport:   164ms   168ms   -2.2%   166ms   170ms
  -2.8%
         SecondSubmoduleImport:   221ms   226ms   -2.4%   223ms   229ms
  -2.9%
       SimpleComplexArithmetic:   143ms   166ms  -13.5%   144ms   166ms
 -13.4%
        SimpleDictManipulation:   269ms   296ms   -9.2%   270ms   297ms
  -9.0%
         SimpleFloatArithmetic:   150ms   177ms  -15.3%   151ms   196ms
 -23.2%
      SimpleIntFloatArithmetic:   200ms   226ms  -11.4%   203ms   232ms
 -12.4%
       SimpleIntegerArithmetic:   200ms   226ms  -11.4%   202ms   235ms
 -13.9%
      SimpleListComprehensions:   186ms   211ms  -12.0%   193ms   218ms
 -11.5%
        SimpleListManipulation:   161ms   180ms  -10.6%   161ms   181ms
 -10.9%
          SimpleLongArithmetic:   137ms   159ms  -14.0%   137ms   162ms
 -15.2%
                    SmallLists:   197ms   209ms   -5.6%   201ms   210ms
  -4.2%
                   SmallTuples:   215ms   234ms   -8.2%   216ms   236ms
  -8.2%
         SpecialClassAttribute:   544ms   566ms   -4.0%   549ms   571ms
  -3.7%
      SpecialInstanceAttribute:   188ms   211ms  -11.0%   190ms   214ms
 -11.0%
                StringMappings:   432ms   439ms   -1.6%   433ms   441ms
  -1.9%
              StringPredicates:   183ms   198ms   -7.8%   183ms   199ms
  -7.9%
                 StringSlicing:   304ms   317ms   -4.2%   310ms   321ms
  -3.3%
                     TryExcept:   138ms   154ms  -10.5%   139ms   155ms
 -10.4%
                    TryFinally:   149ms   156ms   -4.8%   151ms   159ms
  -5.1%
                TryRaiseExcept:    76ms    78ms   -2.3%    77ms    82ms
  -6.3%
                  TupleSlicing:   254ms   254ms   -0.2%   254ms   257ms
  -1.0%
                   WithFinally:   204ms   207ms   -1.1%   206ms   209ms
  -1.1%
               WithRaiseExcept:   187ms   190ms   -2.0%   188ms   192ms
  -2.2%
-------------------------------------------------------------------------------
Totals:                         10557ms 11266ms   -6.3% 10647ms 11397ms
  -6.6%

(this=likely_object.pybench, other=classic_opcode.pybench)

----------
components: Interpreter Core
files: likely_decref.diff
keywords: patch
messages: 79821
nosy: ajaksu2, blaisorblade, pitrou
severity: normal
status: open
title: Tell GCC Py_DECREF is unlikely to call the destructor
type: performance
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12731/likely_decref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Wed Jan 14 03:42:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Jan 2009 02:42:31 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1231900951.51.0.401297962235.issue4941@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I get a slowdown here (results attached). Many objects are shortlived in
Python, so I'm not sure the approach is valid anyway.

Added file: http://bugs.python.org/file12732/pybench.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Wed Jan 14 03:48:38 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 14 Jan 2009 02:48:38 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231901318.17.0.42716995759.issue4715@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Looking through the patch...

I don't really like the names for JUMP_OR_POP and POP_OR_JUMP. (They
don't really indicate to me that the choice depends on the truth of the
top of the stack.) How about JUMP_IF_FALSE_OR_POP and
JUMP_IF_TRUE_OR_POP (or s/OR/ELSE/)? 

If the old opcodes weren't called JUMP_IF_XXX, I'd suggest the
always-popping variants just use those names. Many other opcodes
implicitly consume their arguments so these could too. But since this
would be confusing with both the old meanings and the other new pair,
your names are probably better.

The comments in opcode.h and opcode.py are inconsistent.

I now get a warning that PRED_POP_TOP is defined but not used, so you
should remove the PREDICTED macro for it.

I wonder if BINARY_AND and BINARY_OR should get predictions ... not for
this patch.

I would probably put the POP_JUMP_IF_XXX definitions next to the
JUMP_OR_POP definitions to emphasize their similarity.

You missed a comment referring to JUMP_IF_FALSE before
compiler_try_except().

POP_JUMP_IF_TRUE is only used in one place: assertions. I wonder if
anyone would cry if we compiled assertions to UNARY_NOT;
POP_JUMP_IF_FALSE instead... Anyway, also not for this patch.

In compiler_comprehension_generator, "compiler_use_next_block(c, skip);"
is now always followed by "compiler_use_next_block(c, if_cleanup);".
Should you remove the use(skip) call?

In peephole.c, s/JUMP_SIGN/JUMPS_ON_TRUE/ ?

test_peepholer fails for me, which makes sense because it still refers
to JUMP_IF_XXX.

Whoo, the peephole.c changes are complex. I'll do those in a second round.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 03:55:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Jan 2009 02:55:37 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231901737.83.0.976109459074.issue4715@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, the goal is to replace the opcode peephole optimizer with a more
powerful equivalent working on the AST just prior to code generation.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 04:48:26 2009
From: report at bugs.python.org (Hamish Moffatt)
Date: Wed, 14 Jan 2009 03:48:26 +0000
Subject: [issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3
In-Reply-To: <1231904905.99.0.375318145536.issue4942@psf.upfronthosting.co.za>
Message-ID: <1231904905.99.0.375318145536.issue4942@psf.upfronthosting.co.za>


New submission from Hamish Moffatt <hamish at cloud.net.au>:

As of 2.5.3, calling accept() on an AF_UNIX socket fails on arm. The
following exception occurs:

SystemError: Negative size passed to PyString_FromStringAndSize

I have attached a test program that creates a socket and connects to it.
It works on x86-64 but fails on armeb (gcc 4.1.2).

This failure has been noted a few times by the arm buildbot too:
http://archives.free.net.ph/message/20081012.121034.89069ea2.en.html

It's already fixed in 2.6.x in rev 60214. I applied the same change to
2.5.4 and the problem was resolved.

----------
components: Extension Modules
files: accept_test.py
messages: 79825
nosy: hmoffatt
severity: normal
status: open
title: accept() on AF_UNIX sockets broken on arm as of 2.5.3
versions: Python 2.5
Added file: http://bugs.python.org/file12733/accept_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4942>
_______________________________________

From report at bugs.python.org  Wed Jan 14 05:16:07 2009
From: report at bugs.python.org (Matt McClure)
Date: Wed, 14 Jan 2009 04:16:07 +0000
Subject: [issue4943] trace.CoverageResults.write_results can't write results
	file for modules loaded by __path__ manipulation
In-Reply-To: <1231906566.94.0.987113502153.issue4943@psf.upfronthosting.co.za>
Message-ID: <1231906566.94.0.987113502153.issue4943@psf.upfronthosting.co.za>


New submission from Matt McClure <mlm at aya.yale.edu>:

The function trace.CoverageResults.write_results() can't write coverage
results on Windows for modules loaded by using the __path__ feature of
PEP 302.

For example, Bazaar uses the __path__ feature to load plugins from
directories specified by the BZR_PLUGIN_PATH environment variable.

The attached zip file contains a test case.  If it is unpacked so that
tracebug.py is in C:\, it will fail to produce a coverage results file
for C:\tracebug\dir2\hello.py.  Instead it will produce an empty file
named C:\tracebug\out\C .

The bug appears to be that trace.fullmodname() returns
C:.tracebug.dir2.hello .  Since the result contains a colon (:), it
can't be used as the filename of the output file produced by
trace.CoverageResults.write_results().

----------
components: Library (Lib)
files: tracebug.zip
messages: 79826
nosy: matthewlmcclure
severity: normal
status: open
title: trace.CoverageResults.write_results can't write results file for modules loaded by __path__ manipulation
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12734/tracebug.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4943>
_______________________________________

From report at bugs.python.org  Wed Jan 14 05:16:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Jan 2009 04:16:59 +0000
Subject: [issue4940] decimal.Decimal.__init__ should raise an instance of
	ValueError
In-Reply-To: <1231892997.26.0.818737849163.issue4940@psf.upfronthosting.co.za>
Message-ID: <1231906619.43.0.274753320655.issue4940@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4940>
_______________________________________

From report at bugs.python.org  Wed Jan 14 05:19:03 2009
From: report at bugs.python.org (Matt McClure)
Date: Wed, 14 Jan 2009 04:19:03 +0000
Subject: [issue4943] trace.CoverageResults.write_results can't write results
	file for modules loaded by __path__ manipulation
In-Reply-To: <1231906566.94.0.987113502153.issue4943@psf.upfronthosting.co.za>
Message-ID: <1231906743.61.0.911582879602.issue4943@psf.upfronthosting.co.za>


Matt McClure <mlm at aya.yale.edu> added the comment:

The attached patch replaces the offending colon with a period.

----------
keywords: +patch
Added file: http://bugs.python.org/file12735/tracebug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4943>
_______________________________________

From report at bugs.python.org  Wed Jan 14 05:19:32 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 14 Jan 2009 04:19:32 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>
Message-ID: <1231906772.62.0.640745268531.issue4933@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> we decided some time ago to not accept patches for such minority 
> platforms anymore.

I don't have any particular interest in BeOS variants, but this comes as 
a surprise given that http://python.org/about/ proclaims that "Python 
runs everywhere."

Maybe Haiku could become a supported platform instead of more or less 
defunct BeOS?  As far as I can tell there is no current BeOS port 
maintainer, but there is some crud left over from the better times.  If 
Haiku community can step in and clean up BeOS crud by either removing it 
or making sure it works on modern BeOS variants, this can only be a good 
thing.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Wed Jan 14 05:43:00 2009
From: report at bugs.python.org (Javen Wang)
Date: Wed, 14 Jan 2009 04:43:00 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>


New submission from Javen Wang <javen72 at gmail.com>:

I encountered a very strange issue in file flush operation in Windows.
Here's the scenario of my application:

    1. The main thread of my application will create makefiles sequentially.
    2. Once a makefile is generated, launch a separate process calling
nmake.exe to run it in parallell. The main thread then create another
makefile until no more makefiles to create.
    3. The number of new processes is limited by command line options.

My application has been running for almost a year without any problem.
But, after I made some changes recently to the content of makefile
generated, "nmake.exe" in separate process sometimes complains that
the makefile was not found. But when I went into the directory, the
makefile was there.

Because I didn't change any thing related to file creation and the new
makefiles are a little bit less than before, I guessed that the
makefile just created hasn't been flushed to disk because of size
change so the new process could not see it in a short time.

So I decided add code to force flush file buffer after writing the
file content (I didn't flush the file explicitly before). I did it
like below:

    Fd = open(File, "w")
    Fd.write(Content)
    Fd.flush()
    os.fsync(Fd.fileno())
    Fd.close()

The strangest thing happened. The "makefile" missing happened more
frequently than no flush operation. I searched the web but no answer
there.

Finally I tried to use Windows file API to create the file via pywin32
extension. The problem's gone.

        import win32file
        Fd = win32file.CreateFile(
                        File,
                        win32file.GENERIC_WRITE,
                        0,
                        None,
                        win32file.CREATE_ALWAYS,
                        win32file.FILE_ATTRIBUTE_NORMAL,
                        None
                        )
        win32file.WriteFile(Fd, str(Content), None)
        win32file.FlushFileBuffers(Fd)
        win32file.CloseHandle(Fd)

I tried writing small python extension in C to make use Windows API to
create file like above. It also works well, even I removed the
FlushFileBuffers() calling.

I think that there's a bug in Python file buffer mechanism.

----------
components: Windows
messages: 79829
nosy: javen72
severity: normal
status: open
title: os.fsync() doesn't work as expect in Windows
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 06:21:41 2009
From: report at bugs.python.org (Gerard)
Date: Wed, 14 Jan 2009 05:21:41 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1231910501.07.0.798845509403.issue1519638@psf.upfronthosting.co.za>


Gerard <gjp at gp-net.nl> added the comment:

Dear Bobby,

I don't see what would be the part that generates the empty string?

Regards,

Gerard.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Wed Jan 14 06:23:02 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 14 Jan 2009 05:23:02 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1231910582.19.0.885397677047.issue4941@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

If speedup on other machines are confirmed, a slowdown of less than 2%
should be acceptable (it's also similar to the statistic noise I have on
my machine - it's a pity pybench does not calculate the standard
deviation of the execution time).

It is true that many objects are short lived, and that makes
generational GC work, but the patch is about another point. Do most
refcount decrements lead to garbage collection? That's a completely
different question. And I don't think that popping a function call
argument usually leads to a destructor invocation, for instance, unless
the argument is a temporary. The same reasoning holds for most other
opcodes.

The simplest way to check this is to look at the compilation output with
Profile-Guided Optimization active and verify which branch is optimized.

Having said that, the slowdown you get (on your Athlon X2 3600+) might
be due to a higher cost in case of failed static prediction, since that
leads to 2 jumps.

This code leads to 0 or 1 jump:

if (likely(cond)) {
  destructor
}

while with unlikely, one runs through either 0 or 2 jumps. The second
jump is unconditional, so it has a much smaller delay (the decode unit
has to tell the fetch unit to fetch another instruction). However, in
that case one has to invoke anyway the destructor through a virtual
call, which is much more expensive.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Wed Jan 14 06:31:39 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 14 Jan 2009 05:31:39 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

json compares arguments against True/False by identity, not by boolean 
value; by example:

    if (skipkeys is False and ensure_ascii is True and
        check_circular is True and allow_nan is True ...

Using `ensure_ascii=1` won't work as intended. I don't see the reason 
to check those values by identity - they *are* boolean flags, and 
should be checked by value, as the usual practice.

The attached patch fixes the code and documentation (and a bug encoding 
True/False as keys, including unit tests)

----------
components: Library (Lib)
messages: 79832
nosy: gagenellina
severity: normal
status: open
title: json checks True/False by identity, not boolean value
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Wed Jan 14 06:48:06 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 14 Jan 2009 05:48:06 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1231912086.44.0.600433254101.issue4945@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12736/json.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Wed Jan 14 06:50:19 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 14 Jan 2009 05:50:19 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231912219.2.0.741538103865.issue4715@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

In peephole.c:

_optimize isn't a great label name, but I don't have a great
replacement. Maybe reoptimize_current_index?

Your change to the "LOAD_CONST trueconst JUMP_IF_FALSE xx POP_TOP"
optimization doesn't preserve the optimization to:
  def f():
    return 1 and a
I suspect we don't care since "0 or a" wasn't optimized.

I wonder what the "POP_TOP JUMP_FORWARD 1 POP_TOP" was ever for. Why did
compiler_comprehension_generator() emit it in the first place?

After "if (JUMP_SIGN(j) == JUMP_SIGN(opcode)) {", it might be nice to
have a comment like, "/* The second jump will always be taken if the
first was. */" and similarly for the else branch with an explanation why
the POP should become unconditional.

Otherwise looks good.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 07:08:06 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Wed, 14 Jan 2009 06:08:06 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231913286.63.0.447041211106.issue4944@psf.upfronthosting.co.za>


Changes by Ulrich Eckhardt <eckhardt at satorlaser.com>:


----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 07:28:56 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 14 Jan 2009 06:28:56 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1231914536.92.0.225696601395.issue4941@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I dislike about this patch that there are two different else cases
(giving the trivial macro definition); there should only be one such case.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Wed Jan 14 07:31:22 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 14 Jan 2009 06:31:22 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1231914682.02.0.730301420017.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

#4715 is interesting, but is not really about superinstructions.
Superinstructions are not created because they make sense; any common
sequence of opcodes can become a superinstruction, just for the point of
saving dispatches. And the creation can even be dynamic!

However, when I'll have substantial time for coding, I'd like to spend
it experimenting with subroutine threading. vmgen author despises it,
but nowadays it probably became even faster, as discussed by the article
"Context threading: A flexible and efficient dispatch technique for
virtual machine interpreters".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan 14 07:33:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 14 Jan 2009 06:33:58 +0000
Subject: [issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3
In-Reply-To: <1231904905.99.0.375318145536.issue4942@psf.upfronthosting.co.za>
Message-ID: <1231914838.45.0.618717070036.issue4942@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No further bug fixes are accepted for Python 2.5. Closing this as "won't
fix".

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4942>
_______________________________________

From report at bugs.python.org  Wed Jan 14 07:38:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 14 Jan 2009 06:38:58 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231906772.62.0.640745268531.issue4933@psf.upfronthosting.co.za>
Message-ID: <496D887E.6060101@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't have any particular interest in BeOS variants, but this comes as 
> a surprise given that http://python.org/about/ proclaims that "Python 
> runs everywhere."
> 
> Maybe Haiku could become a supported platform instead of more or less 
> defunct BeOS?

Maybe this can be discussed on python-dev, but there is a standing BDFL
pronouncement on this matter. It used to be the policy to accept patches
for any operating system, but this policy is reverted now.

> As far as I can tell there is no current BeOS port 
> maintainer, but there is some crud left over from the better times.  If 
> Haiku community can step in and clean up BeOS crud by either removing it 
> or making sure it works on modern BeOS variants, this can only be a good 
> thing.

No. The cost is too high, and there are more important issues to
resolve. Of course, the Haiku community can provide there fork of Python
if they want to (and they also get official blessing for forking if they
want to).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Wed Jan 14 07:41:30 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 14 Jan 2009 06:41:30 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231915290.47.0.930527061527.issue4944@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I tried to reproduce the issue, interpreting your description, but 
failed. It worked fine in my setup. Perhaps you can add more elements 
until it fails.

----------
nosy: +gagenellina
Added file: http://bugs.python.org/file12737/test_file_flush.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 07:42:37 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 14 Jan 2009 06:42:37 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231915357.33.0.684186519589.issue4944@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Added file: http://bugs.python.org/file12738/checkfile.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 07:52:12 2009
From: report at bugs.python.org (Hamish Moffatt)
Date: Wed, 14 Jan 2009 06:52:12 +0000
Subject: [issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3
In-Reply-To: <1231904905.99.0.375318145536.issue4942@psf.upfronthosting.co.za>
Message-ID: <1231915932.89.0.0807638594105.issue4942@psf.upfronthosting.co.za>


Hamish Moffatt <hamish at cloud.net.au> added the comment:

Thanks for your feedback, but I'm a bit confused by the note on the web
site:

"This is the last bugfix release of Python 2.5. Python 2.5 is now in
bugfix-only mode; no new features are being added."

This implies further bug fixes are possible (and further fixes were just
made to 2.4 despite the above comment about 2.4.5). 

Also it's a regression from 2.5.2, which must be of some concern?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4942>
_______________________________________

From report at bugs.python.org  Wed Jan 14 08:25:16 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 14 Jan 2009 07:25:16 +0000
Subject: [issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3
In-Reply-To: <1231915932.89.0.0807638594105.issue4942@psf.upfronthosting.co.za>
Message-ID: <496D9356.2080406@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> "This is the last bugfix release of Python 2.5. Python 2.5 is now in
> bugfix-only mode; no new features are being added."

Thanks for pointing that out; I have fixed the page now.

> Also it's a regression from 2.5.2, which must be of some concern?

It is; and it is unfortunate that this wasn't fixed before the release.
However, support for AF_UNIX sockets on ARM is not important enough
to warrant another bug fix release.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4942>
_______________________________________

From report at bugs.python.org  Wed Jan 14 08:48:05 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Jan 2009 07:48:05 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231919285.93.0.0467389044208.issue4944@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

python2.5 uses the functions of the fopen() family: fwrite(), fclose(). 
Does the problem reproduce if you use these functions in your extension 
module?

Are your files located on the local hard drive, or on a network storage?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 08:55:10 2009
From: report at bugs.python.org (Hamish Moffatt)
Date: Wed, 14 Jan 2009 07:55:10 +0000
Subject: [issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3
In-Reply-To: <1231904905.99.0.375318145536.issue4942@psf.upfronthosting.co.za>
Message-ID: <1231919710.91.0.160826127479.issue4942@psf.upfronthosting.co.za>


Hamish Moffatt <hamish at cloud.net.au> added the comment:

Understood.

Would it be appropriate to list this issue on the known bugs page?
http://www.python.org/download/releases/2.5.4/bugs/

I can't reproduce it on x86, but it's probably not ARM specific. It
might even be a compiler bug. I tried the same version on x86 and x86-64
and didn't have a problem.

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4942>
_______________________________________

From report at bugs.python.org  Wed Jan 14 09:40:05 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 14 Jan 2009 08:40:05 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231852460.88.0.224524166872.issue4874@psf.upfronthosting.co.za>
Message-ID: <496DA483.7040203@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-13 14:14, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> The patch is probably fine, but it would be nice to add some unit tests
> for the new behaviour.

+1 from my side.

Thanks for the patch, Viktor.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Wed Jan 14 09:41:51 2009
From: report at bugs.python.org (Aaron Brady)
Date: Wed, 14 Jan 2009 08:41:51 +0000
Subject: [issue4708] os.pipe should return inheritable descriptors (Windows)
In-Reply-To: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za>
Message-ID: <1231922511.54.0.921337513981.issue4708@psf.upfronthosting.co.za>


Aaron Brady <castironpi at gmail.com> added the comment:

This is currently accomplished in 'multiprocessing.forking' with a
'duplicate' function.

Use (line #213):
    rfd, wfd = os.pipe()
    
    # get handle for read end of the pipe and make it inheritable
    rhandle = duplicate(msvcrt.get_osfhandle(rfd), inheritable=True)

Definition (line #192).

Should it be included in the public interface and documented, or perhaps
a public entry point to it made?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4708>
_______________________________________

From report at bugs.python.org  Wed Jan 14 11:25:25 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Jan 2009 10:25:25 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1231928725.7.0.546233134317.issue4931@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem has two causes:
- IOError is raised when no compiler is found. DistutilsPlatformError
should be used instead, this was fixed by #4702.

- the distutils.util.grok_environment_error function transforms a
IOError("Unable to find vcvarsall.bat") into "error: None".

This function should not be used IMO. Its docstring claims that it
"Handles Python 1.5.1 and 1.5.2 styles", but str() does a better job...

Patch attached.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file12739/distutils_ioerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Wed Jan 14 11:54:27 2009
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Wed, 14 Jan 2009 10:54:27 +0000
Subject: [issue4946] Lib/test/test__locale uses is to compare strings
In-Reply-To: <1231930466.83.0.500418142072.issue4946@psf.upfronthosting.co.za>
Message-ID: <1231930466.83.0.500418142072.issue4946@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

this is at least a bad practice. It also might break silently at any point.

----------
components: Library (Lib), Tests
files: out.diff
keywords: patch
messages: 79846
nosy: fijal
severity: normal
status: open
title: Lib/test/test__locale uses is to compare strings
versions: Python 2.7
Added file: http://bugs.python.org/file12740/out.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4946>
_______________________________________

From report at bugs.python.org  Wed Jan 14 12:07:53 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Jan 2009 11:07:53 +0000
Subject: [issue4781] The function, Threading.Timer.run(), may be Inappropriate
In-Reply-To: <1230651841.99.0.415726342941.issue4781@psf.upfronthosting.co.za>
Message-ID: <1231931273.13.0.510580311037.issue4781@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed, Timer is designed to run the function once.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4781>
_______________________________________

From report at bugs.python.org  Wed Jan 14 12:10:55 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Jan 2009 11:10:55 +0000
Subject: [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1231931455.18.0.07188867749.issue4929@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4929>
_______________________________________

From report at bugs.python.org  Wed Jan 14 12:17:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Jan 2009 11:17:45 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1231912219.2.0.741538103865.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231931883.6605.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Your change to the "LOAD_CONST trueconst JUMP_IF_FALSE xx POP_TOP"
> optimization doesn't preserve the optimization to:
>   def f():
>     return 1 and a
> I suspect we don't care since "0 or a" wasn't optimized.

Yes, this optimization seems meant for "while 1" and "while True" mainly
(which my patch preserves, but I might add a comment).

> I wonder what the "POP_TOP JUMP_FORWARD 1 POP_TOP" was ever for. Why did
> compiler_comprehension_generator() emit it in the first place?

I'm as clueless as you...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 12:18:48 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 14 Jan 2009 11:18:48 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

Documentation for files states that when writing to a file, unicode 
strings are converted to byte strings using the encoding specified by 
file.encoding.
http://docs.python.org/library/stdtypes.html#file.encoding

sys.stdout is a file, but it does not behave as stated above:

>>> type(sys.stdout)
<type 'file'>
>>> sys.stdout.encoding
'UTF-8'
>>> u = u"\u554a"
>>> print u
?
>>> sys.stdout.write(u)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u554a' in 
position 0: ordinal not in range(128)
>>> sys.stdout.write(u.encode('utf-8'))
?

----------
messages: 79849
nosy: stevenjd
severity: normal
status: open
title: sys.stdout fails to use default encoding as advertised
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Wed Jan 14 12:25:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Jan 2009 11:25:40 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1231901318.17.0.42716995759.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231932356.6605.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 14 janvier 2009 ? 02:48 +0000, Jeffrey Yasskin a ?crit :
> Looking through the patch...
> 
> I don't really like the names for JUMP_OR_POP and POP_OR_JUMP.

I don't like them either, they're the only relatively short ones I could
come up with. I'll change them to your proposal
(JUMP_IF_{TRUE,FALSE}_OR_POP).

> I wonder if BINARY_AND and BINARY_OR should get predictions ... not for
> this patch.

With the patch, I don't think they need predictions anymore.

> POP_JUMP_IF_TRUE is only used in one place: assertions. I wonder if
> anyone would cry if we compiled assertions to UNARY_NOT;
> POP_JUMP_IF_FALSE instead...

No, POP_JUMP_IF_TRUE is also used when optimizing the sequence
"UNARY_NOT; POP_JUMP_IF_FALSE" (think "if not x: ...").

> In compiler_comprehension_generator, "compiler_use_next_block(c, skip);"
> is now always followed by "compiler_use_next_block(c, if_cleanup);".
> Should you remove the use(skip) call?

I'll look at this.

> In peephole.c, s/JUMP_SIGN/JUMPS_ON_TRUE/ ?

Great, another stupid name disappears :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 12:33:00 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 14 Jan 2009 11:33:00 +0000
Subject: [issue4715] optimize bytecode for conditional branches
In-Reply-To: <1229900285.73.0.345956521758.issue4715@psf.upfronthosting.co.za>
Message-ID: <1231932780.82.0.128432302344.issue4715@psf.upfronthosting.co.za>


Changes by Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com>:


----------
nosy: +blaisorblade

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4715>
_______________________________________

From report at bugs.python.org  Wed Jan 14 12:45:13 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Wed, 14 Jan 2009 11:45:13 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1231933513.01.0.0718897529628.issue4941@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

Also, GCC 2.95 does not support the construct, GCC 2.96 is required.
So, I'd suggest defining likely/unlikely unconditionally and using this,
which leads to less code overall:

#  if (__GNUC__ < 2) || ((__GNUC__ == 2) && (__GNUC_MINOR__ <= 95))
#  define __builtin_expect(exp, prediction)  (exp)
#  endif

This is the simplest way to code this, assuming that ICC defines
__GNUC__, and my reference guide tells "yes, it defines __GNUC__ and
__INTEL_COMPILER".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Wed Jan 14 15:32:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Jan 2009 14:32:00 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1231943520.98.0.933429277745.issue4947@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It probably uses sys.getdefaultencoding() instead.

----------
components: +Interpreter Core
nosy: +pitrou
priority:  -> high
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Wed Jan 14 15:34:03 2009
From: report at bugs.python.org (Bobby Xiao)
Date: Wed, 14 Jan 2009 14:34:03 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1231943643.23.0.579673348714.issue1519638@psf.upfronthosting.co.za>


Bobby Xiao <nneonneo at gmail.com> added the comment:

Well, in this example the group (ar) is unmatched, so sre throws the
error, and because of the alternation, the workaround you mentioned
doesn't seem to directly apply.

A better example is probably
re.sub("foo(?:b(ar)|foo)","\\1","foofoo")
because this can't be simply repaired by refactoring the regex.

The correct behaviour, as I have observed in other regex
implementations, is to replace the group by the empty string; for
example, in Javascript:
>>> 'foobar'.replace(/foo(?:b(ar)|baz)/,'$1')
"ar"
>>> 'foobaz'.replace(/foo(?:b(ar)|baz)/,'$1')
""

----------
versions: +Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Wed Jan 14 16:31:02 2009
From: report at bugs.python.org (Javen Wang)
Date: Wed, 14 Jan 2009 15:31:02 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231947062.98.0.53816511256.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

gagenellina,

My application is a little bit different from your test code. It won't
wait for the exit of new process and there're file writing operations
during makefile running. I changed the test code to be real
multi-process and tried many file sizes. But I cannot reproduce it.
Maybe my application is more complicated situation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 16:42:17 2009
From: report at bugs.python.org (Jason Tishler)
Date: Wed, 14 Jan 2009 15:42:17 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1231947737.55.0.516049566281.issue2233@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

Your latest patch is on the right track, but see my latest one, 
Makefile.pre.in.v2.diff, for an optimization.  I tested make install 
with and without DESTDIR defined on the command line and both cases 
behaved as expected.

Added file: http://bugs.python.org/file12741/Makefile.pre.in.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Wed Jan 14 16:57:13 2009
From: report at bugs.python.org (Javen Wang)
Date: Wed, 14 Jan 2009 15:57:13 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231948633.83.0.498766688742.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

The created files are on local drive. I saw the problem on the laptop
(XP-SP2), desktop(XP-SP3) and server (Win2003). But there's no such
problem on the Linux and Mac boxes.

I tried to use fopen/fwrite in my extension according to your
suggestion. The problem wasn't be reproduced. It seems the bug is more
alike in Python part.

My application is a build system and is also an open source project. Is
it possible for you to download it and try it in your box?

I created temporary user (py123, password: 123py123) for you (just in
case) and here's steps of how to reproduce it.

  1. Checkout the build system source code in, for example, c:\test
     C:\test> svn co --username py123 --password 123py123
https://buildtools.tianocore.org/svn/buildtools/trunk/BaseTools tools

  2. Checkout the source code to be built against in c:\test
     C:\test> svn co --username py123 --password 123py123
https://edk2.tianocore.org/svn/edk2/trunk/edk2 edk2

  3. Change the source code between line 222 and line 229 of
c:\test\tools\Source\Python\Common\Misc.py (SaveFileOnChange function)
like below:

     Fd = open(File, "wb")
     Fd.write(Content)
     Fd.flush()
     os.fsync(Fd.fileno())
     Fd.close()

  4. In c:\test\edk2, run
     C:\test\edk2> edksetup.bat
     C:\test\edk2> set PYTHONPATH=C:\test\tools\Source\Python
     C:\test\edk2> python.exe C:\test\tools\Source\Python\build\build.py
-n 2 -p MdeModulePkg\MdeModulePkg.dsc -a IA32 -s

  5. If the application stops with message like "makefile not found" or
"AutoGen.h not found" message, that means the problem happened.

Visual Studio 2005 is needed to reproduce it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 17:16:05 2009
From: report at bugs.python.org (Javen Wang)
Date: Wed, 14 Jan 2009 16:16:05 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231949765.25.0.619727903602.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

There would be more chances to see the problem by doing this:

C:\test\edk2> python.exe C:\test\tools\Source\Python\build\build.py
-n 2 -p IntelFrameworkModulePkg\IntelFrameworkModulePkg.dsc -a IA32 -s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 17:33:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 14 Jan 2009 16:33:16 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231950796.46.0.543037501376.issue4944@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I really tried, but I can't run your script. first PYTHONPATH must be
set to some value (I tried with tools\Source\Python); Also the tool is
complaining about missing WORKSPACE and EDK_TOOLS_PATH env vars, and a
missing file "Conf\target.txt".
This seems very complicated for a test case... furthermore it comes with
binaries already linked with a specific version of python... what if I
want to use a debug build?

Another question: is there a running anti-virus? if yes, can you try to
temporarily disable it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 14 17:40:28 2009
From: report at bugs.python.org (Benoit Boissinot)
Date: Wed, 14 Jan 2009 16:40:28 +0000
Subject: [issue4948] Make heapq work with all mutable sequences
In-Reply-To: <1231951228.13.0.336987683355.issue4948@psf.upfronthosting.co.za>
Message-ID: <1231951228.13.0.336987683355.issue4948@psf.upfronthosting.co.za>


New submission from Benoit Boissinot <bboissin+pythonbugs at gmail.com>:

Generalize heapq to work with all kind of mutable sequences. It should
be investigated PySequence_SetItem is a lot slower than PyList_SET_ITEM
(same for GET_ITEM and GET_SIZE).

----------
components: Extension Modules
messages: 79859
nosy: bboissin
severity: normal
status: open
title: Make heapq work with all mutable sequences
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4948>
_______________________________________

From report at bugs.python.org  Wed Jan 14 17:54:56 2009
From: report at bugs.python.org (Andres Moreira)
Date: Wed, 14 Jan 2009 16:54:56 +0000
Subject: [issue4932] Little improvement on urlparse module, urlparse function.
In-Reply-To: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>
Message-ID: <1231952096.36.0.023788595647.issue4932@psf.upfronthosting.co.za>


Andres Moreira <elkpichico at gmail.com> added the comment:

Hi haypo,
 Ok I've been testing with python 2.6 and I put the results here:
 optimizedurlparse is the file with my patch

 First test optimizedurlparse, second urlparse:

#:/opt/python2.6/release26-maint$ ./python mio/profile_urlparse.py 
timing optimizedurlparse.urlparse():
    [0.89634895324707031, 0.61937308311462402, 0.62004208564758301]
timing urlparse.urlparse():
    [0.64083003997802734, 0.6862800121307373, 0.67195010185241699]

#:/opt/python2.6/release26-maint$ ./python mio/profile_urlparse.py 2000
timing optimizedurlparse.urlparse():
    [1.5077390670776367, 1.2391939163208008, 1.2390918731689453]
timing urlparse.urlparse():
    [1.2550511360168457, 1.2493829727172852, 1.2445049285888672]

Now I'll change the order of execution, first urlparse , second
optimizedurlparse:

#:/opt/python2.6/release26-maint$ ./python mio/profile_urlparse.py 2000
timing urlparse.urlparse():
    [1.6836080551147461, 1.3892900943756104, 1.3195438385009766]
timing optimizedurlparse.urlparse():
    [1.4834678173065186, 1.4077410697937012, 1.3824198246002197]
[19647 refs]
#:/opt/python2.6/release26-maint$ ./python mio/profile_urlparse.py 2000
timing urlparse.urlparse():
    [1.4398901462554932, 1.3237769603729248, 1.3057329654693604]
timing optimizedurlparse.urlparse():
    [1.3134419918060303, 1.3127460479736328, 1.2928199768066406]
[19647 refs]

Python Version: 
2.6.1+ (release26-maint:68606, Jan 14 2009, 08:48:41)

The small changes optimize the urlparse.urlparse and urlsplit function a
bit :D.

Added file: http://bugs.python.org/file12742/optmizedurlparse.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4932>
_______________________________________

From report at bugs.python.org  Wed Jan 14 18:03:40 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Jan 2009 17:03:40 +0000
Subject: [issue4932] Little improvement on urlparse module, urlparse function.
In-Reply-To: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>
Message-ID: <1231952620.16.0.596903828121.issue4932@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Please, attach patches instead of the full file.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4932>
_______________________________________

From report at bugs.python.org  Wed Jan 14 18:08:41 2009
From: report at bugs.python.org (Andres Moreira)
Date: Wed, 14 Jan 2009 17:08:41 +0000
Subject: [issue4932] Little improvement on urlparse module, urlparse function.
In-Reply-To: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>
Message-ID: <1231952921.35.0.920320833851.issue4932@psf.upfronthosting.co.za>


Andres Moreira <elkpichico at gmail.com> added the comment:

And that is the profile code.

Added file: http://bugs.python.org/file12743/profile_urlparse.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4932>
_______________________________________

From report at bugs.python.org  Wed Jan 14 18:26:06 2009
From: report at bugs.python.org (Andres Moreira)
Date: Wed, 14 Jan 2009 17:26:06 +0000
Subject: [issue4932] Little improvement on urlparse module, urlparse function.
In-Reply-To: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>
Message-ID: <1231953966.09.0.197377513134.issue4932@psf.upfronthosting.co.za>


Andres Moreira <elkpichico at gmail.com> added the comment:

Hi haypo, 
 sorry for submit all the file, it's my first time here and I'm not very
used to this process yet. :)
Now I attach the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file12744/urlparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4932>
_______________________________________

From report at bugs.python.org  Wed Jan 14 18:35:02 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Jan 2009 17:35:02 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1231954502.13.0.130785664637.issue4945@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Wed Jan 14 18:44:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Jan 2009 17:44:38 +0000
Subject: [issue4932] Little improvement on urlparse module, urlparse function.
In-Reply-To: <1231953966.09.0.197377513134.issue4932@psf.upfronthosting.co.za>
Message-ID: <200901141844.31229.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Now I attach the patch.

Your first patch for Python 2.5 was interesting, and looked close to the 
python 2.6 version. But your second patch (for 2.6) contains only 
micro-optimisations:
 - inline the one-line clear_cache() function
 - replace "scheme, url = ..." assignation (used for scheme different 
   than http) by classic assignation (url = ...)

Your benchmark numbers are difficult to read, but I can't see impressive 
results (I guess it's smaller than 10%, maybe 5%).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4932>
_______________________________________

From report at bugs.python.org  Wed Jan 14 18:45:54 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Jan 2009 17:45:54 +0000
Subject: [issue4948] Make heapq work with all mutable sequences
In-Reply-To: <1231951228.13.0.336987683355.issue4948@psf.upfronthosting.co.za>
Message-ID: <1231955154.4.0.745565257812.issue4948@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This was discussed at the outset and the decision was a conscious one.

Do you have any particular use cases in mind (what other mutable
sequences do you reach for when you need a heap)?  Or is this just a
general discussion on generalization?

----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4948>
_______________________________________

From report at bugs.python.org  Wed Jan 14 18:53:02 2009
From: report at bugs.python.org (Benoit Boissinot)
Date: Wed, 14 Jan 2009 17:53:02 +0000
Subject: [issue4948] Make heapq work with all mutable sequences
In-Reply-To: <1231951228.13.0.336987683355.issue4948@psf.upfronthosting.co.za>
Message-ID: <1231955582.23.0.761996847855.issue4948@psf.upfronthosting.co.za>


Benoit Boissinot <bboissin+pythonbugs at gmail.com> added the comment:

I was thinking about array.array. I don't know if it would be faster
than using a list, but it seemed elegant to be able to do a heap on it
anyway.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4948>
_______________________________________

From report at bugs.python.org  Wed Jan 14 18:57:32 2009
From: report at bugs.python.org (Andres Moreira)
Date: Wed, 14 Jan 2009 17:57:32 +0000
Subject: [issue4932] Little improvement on urlparse module, urlparse function.
In-Reply-To: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>
Message-ID: <1231955852.71.0.959547908492.issue4932@psf.upfronthosting.co.za>


Andres Moreira <elkpichico at gmail.com> added the comment:

Yes are micro-optimizations, but when I parsed a lot of url(10.000 or
more) that 10% or 8% or 5% is very well for me :). It was little
contribution to that module, anyway, i think that there are more
optimizatoins to do but I will try to do it then.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4932>
_______________________________________

From report at bugs.python.org  Wed Jan 14 19:04:59 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Wed, 14 Jan 2009 18:04:59 +0000
Subject: [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

The "name" argument to PyErr_NewException() should be changed from "char
*" to "const char *". Since the rest of pyerrors.h is const-correct,
this seems like an omission.

----------
components: Interpreter Core
messages: 79868
nosy: inducer
severity: normal
status: open
title: Constness in PyErr_NewException
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4949>
_______________________________________

From report at bugs.python.org  Wed Jan 14 19:14:39 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Jan 2009 18:14:39 +0000
Subject: [issue4948] Make heapq work with all mutable sequences
In-Reply-To: <1231951228.13.0.336987683355.issue4948@psf.upfronthosting.co.za>
Message-ID: <1231956879.19.0.0905354089212.issue4948@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

array.array is terribly slow.  It is optimized for space, not speed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4948>
_______________________________________

From report at bugs.python.org  Wed Jan 14 19:33:28 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Wed, 14 Jan 2009 18:33:28 +0000
Subject: [issue4950] Redundant declaration in pyerrors.h
In-Reply-To: <1231958008.57.0.172561550702.issue4950@psf.upfronthosting.co.za>
Message-ID: <1231958008.57.0.172561550702.issue4950@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

When compiling with -Wredundant-decls gcc spots a redundant declaration:

flub at laurie:sandbox$ cat test.c 
#include <Python.h>
#include <stdio.h>

int main(void)
{
        printf("hello\n");
        return 0;
}
flub at laurie:sandbox$ gcc -I /usr/local/include/python3.0/
-Wredundant-decls test.c 
In file included from /usr/local/include/python3.0/Python.h:102,
                 from test.c:1:
/usr/local/include/python3.0/pyerrors.h:155: warning: redundant
redeclaration of ?PyExc_BufferError?
/usr/local/include/python3.0/pyerrors.h:147: warning: previous
declaration of ?PyExc_BufferError? was here
flub at laurie:sandbox$

This is annoying since when developing extension modules I usually use
-Werror on top of -Wredundant-decls (among others).

Regards
Floris

----------
components: Extension Modules
messages: 79870
nosy: flub
severity: normal
status: open
title: Redundant declaration in pyerrors.h
type: compile error
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4950>
_______________________________________

From report at bugs.python.org  Wed Jan 14 20:41:55 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Wed, 14 Jan 2009 19:41:55 +0000
Subject: [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1231962115.25.0.935824655218.issue4949@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

It's not just that function, at least not in trunk. There are also 
PyErr_SetFromErrnoWithFilename, PyErr_SetFromErrnoWithUnicodeFilename 
and _PyErr_BadInternalCall which should be made const correct, see 
attached patch for trunk.

This patch also fixes some inconsistencies between the documentation 
and warning support functions.

----------
keywords: +patch
nosy: +eckhardt
Added file: http://bugs.python.org/file12745/python-2.7-const-error.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4949>
_______________________________________

From report at bugs.python.org  Wed Jan 14 21:01:55 2009
From: report at bugs.python.org (Scott McCreary)
Date: Wed, 14 Jan 2009 20:01:55 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <496D887E.6060101@v.loewis.de>
Message-ID: <b2c273ce0901141200k39487230s6ced906a70c46643@mail.gmail.com>


Scott McCreary <scottmc2 at gmail.com> added the comment:

On Tue, Jan 13, 2009 at 10:38 PM, Martin v. L?wis
<report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> I don't have any particular interest in BeOS variants, but this comes as
>> a surprise given that http://python.org/about/ proclaims that "Python
>> runs everywhere."
>>
>> Maybe Haiku could become a supported platform instead of more or less
>> defunct BeOS?
>
> Maybe this can be discussed on python-dev, but there is a standing BDFL
> pronouncement on this matter. It used to be the policy to accept patches
> for any operating system, but this policy is reverted now.
>

I just joined that list, and will move further discussion of this
there, that is once I have a clean patch that can be applied to the
2.6.x branch.  One of Haiku's goals was to improve on POSIX
compliance, so in many ports that we've done (over 100 now) we've
actually had to un-workaround former BeOS workarounds.  So we'd be
fine with removing any BeOS cruft that we come across during a
potential Haiku port/fork.

>> As far as I can tell there is no current BeOS port
>> maintainer, but there is some crud left over from the better times.  If
>> Haiku community can step in and clean up BeOS crud by either removing it
>> or making sure it works on modern BeOS variants, this can only be a good
>> thing.
>
> No. The cost is too high, and there are more important issues to
> resolve. Of course, the Haiku community can provide there fork of Python
> if they want to (and they also get official blessing for forking if they
> want to).
>

I disagree about the cost being too high, as long as our patches are
clean I don't see an issue here, if anything we might find things that
are broken in python that weren't uncovered previously, I think it's a
win-win.  I don't think there's going to be a whole lot that needs to
be patched to get it working on Haiku, we've got a mostly working
2.5.2 binary already, but it's failing a few of the regression tests,
so we are looking into why on those and have left those patches out of
what was submitted, as we wouldn't want to have to undo one of our
previous patches.

-scottmc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Wed Jan 14 21:19:53 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Jan 2009 20:19:53 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1231964393.11.0.665152331416.issue1242657@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reassigning to Raymond (as per the thread at
http://mail.python.org/pipermail/python-dev/2009-January/085030.html)

----------
assignee: georg.brandl -> rhettinger
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Wed Jan 14 21:37:29 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 14 Jan 2009 20:37:29 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1231965449.09.0.400303320225.issue2233@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Hi Jason,
quick review without tests - I expect $${DESTDIR:-/} to work without :
in expression, i.e. just $${DESTDIR-/}.

The ":" in expression is not so portable (some shells fail on this).
Please see "Shell Substitutions" in autoconf manual.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Wed Jan 14 21:55:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 14 Jan 2009 20:55:43 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>
Message-ID: <1231966543.46.0.231661907542.issue4933@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, I'm closing this patch as rejected. If the discussion on python-dev
turns out that Haiku support should be added, then please create a new
issue (with a patch for 2.7 - clearly, for 2.6, no new features can be
added).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Wed Jan 14 22:02:14 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 14 Jan 2009 21:02:14 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231966934.21.0.242808641242.issue4908@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Added file: http://bugs.python.org/file12746/get_metadata.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Wed Jan 14 22:02:28 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 14 Jan 2009 21:02:28 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231966948.8.0.419023508672.issue4908@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file12692/get_metadata.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Wed Jan 14 22:04:10 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 14 Jan 2009 21:04:10 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231967050.57.0.793440246602.issue4908@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I have improved the patch (uploaded here) (some cases are not done yet,
still work in progress)

Ray, it should work with egg generated by setuptools now, (zipped as well)

Andi, right ! -> fixed in the current patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Wed Jan 14 22:58:37 2009
From: report at bugs.python.org (Jason Tishler)
Date: Wed, 14 Jan 2009 21:58:37 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1231970317.07.0.333868771594.issue2233@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

I guess you mean the following:

${var:-value} 
Old BSD shells, including the Ultrix sh, don't accept the colon for 
any shell substitution, and complain and die.

If so, should we just go forward without the colon?  The bash manpage 
indicates the following:

In each of the cases below, ... bash tests for a parameter that is 
unset or null; omitting the colon results in a test only for a 
parameter that is unset.

So, if a user executes "make DESTDIR= install", then the build will 
fail. Or, maybe we shouldn't worry about that corner case.

What do you think?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Wed Jan 14 23:16:04 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Jan 2009 22:16:04 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>
Message-ID: <1231971364.34.0.99068283526.issue4933@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I've launched a discussion on python-dev.  If the OP is willing to
maintain the deltas over a long period of time (and perhaps provide a
buildbot for Haiku), then I fully support his effort.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Wed Jan 14 23:24:34 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 14 Jan 2009 22:24:34 +0000
Subject: [issue4946] Lib/test/test__locale uses is to compare strings
In-Reply-To: <1231930466.83.0.500418142072.issue4946@psf.upfronthosting.co.za>
Message-ID: <1231971874.33.0.546140986134.issue4946@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Yes, checking object identity is wrong in this case. Your patch looks 
fine to me.

I've found several other "is" comparisons that should not be there -- 
working on a patch right now.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4946>
_______________________________________

From report at bugs.python.org  Thu Jan 15 01:10:46 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 15 Jan 2009 00:10:46 +0000
Subject: [issue4933] Patch to add preliminary support for Haiku
In-Reply-To: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>
Message-ID: <1231978246.95.0.298963462555.issue4933@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

[Copy of a post I just made to python-dev]

I'm with Martin. In these days of distributed version control systems, I
would think that the effort for the Haiku folks to maintain a branch of
Python in their own version control would be minimal. It is likely that
for each new Python version that comes out, initially it is broken on
Haiku, and then they have to go in and fix it. Doing that in their own
version control has the advantage that they don't have to worry about
not breaking support for any other minority operating systems, so I
expect that all in all the cost will be less for them than if they have
to submit these patches to core Python; and since that will definitely
be less work for core Python, I would call that a win-win solution.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4933>
_______________________________________

From report at bugs.python.org  Thu Jan 15 01:13:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Jan 2009 00:13:04 +0000
Subject: [issue4951] failure in test_httpservers
In-Reply-To: <1231978384.8.0.984870711272.issue4951@psf.upfronthosting.co.za>
Message-ID: <1231978384.8.0.984870711272.issue4951@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This one seems to pop up rather frequently on the buildbots:


======================================================================
FAIL: test_post (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_httpservers.py",
line 330, in test_post
    self.assertEquals(res.read(), b'1, python, 123456\n')
AssertionError: b'' != b'1, python, 123456\n'

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 79881
nosy: pitrou
priority: high
severity: normal
status: open
title: failure in test_httpservers
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4951>
_______________________________________

From report at bugs.python.org  Thu Jan 15 01:35:38 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 15 Jan 2009 00:35:38 +0000
Subject: [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1231979738.43.0.176292573841.issue4929@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

On Windows, if you exit a process abnormally (using e.g. os._exit() in 
Python) while it still has open connections, the other side receives a 
WSAECONNRESET (error 10054).

So, you could write a test case using a dumb server (running as another 
process) with a very short, predefined sequence of recv/send calls, 
ending abruptly with os._exit().

On Linux I *think* you would get ECONNRESET, and at least some form of 
error on other OS's.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4929>
_______________________________________

From report at bugs.python.org  Thu Jan 15 01:50:35 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 15 Jan 2009 00:50:35 +0000
Subject: [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1231980635.79.0.411668460601.issue4929@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

IMHO I wouldn't test such case.
Behaviors between different platform are unpredictable.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4929>
_______________________________________

From report at bugs.python.org  Thu Jan 15 03:05:09 2009
From: report at bugs.python.org (Javen Wang)
Date: Thu, 15 Jan 2009 02:05:09 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231985109.56.0.644631353672.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

Thank you very much for the trying. You might miss the step 4 in my
previous message. The step is:

  C:\test\edk2> edksetup.bat
  C:\test\edk2> set PYTHONPATH=C:\test\tools\Source\Python
  C:\test\edk2> python.exe C:\test\tools\Source\Python\build\build.py
-n 2 -p IntelFrameworkModulePkg\IntelFrameworkModulePkg.dsc -a IA32 -s

The Visual Studio 2005 must be in the standard installation directory.
Otherwise the C:\test\edk2\Conf\tools_def.txt needs to be changed to
reflect the real path.

And I tried to disabled all antivirus services and the problem is still
there. 

Don't worry about the binary version of build in
edk2\BaseTools\Bin\Win32 (linked against Python 2.5.2). The step I told
you is to execute my application from Python script directly. And I
tried to execute from script source against Python 2.5.4 and the problem
is the same. And no matter running the build from script source or the
freeze-ed binary, the results are the same either.

If it's hard or inconvenient for you to reproduce it, could you please
give me any advice or suggestion on how to debug it (in the interpreter)
and where's most possible place the root cause would be in the Python
interpreter's code? I can try to change something in the Python
interpreter's code, rebuild it and try it on my machine. Although I have
work around for this problem, I'd like to root cause it to avoid further
possible build break of our project.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Thu Jan 15 04:29:24 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 15 Jan 2009 03:29:24 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231990164.42.0.611937971289.issue4944@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I patiently waited for all those 150MB to download, modified Misc.py, 
run the specified commands and got this error:

build.py...
 : error 7000: Failed to start command
        C:\Program Files\Microsoft Visual Studio 8\Vc\bin\nmake.exe /
nologo -s t
build [C:\test\edk2\Build\MdeModule\DEBUG_MYTOOLS\IA32\MdePkg\Library
\BasePrintL
ib\BasePrintLib]

That's right - VS is installed in another place. "C:\Program Files" 
doesn't even exist in my Spanish version of Windows. edksetup.bat 
didn't report any error, and I have nmake.exe in my PATH.

Anyway, trying to hunt a bug in the middle of 150 MB of code is way too 
much. You should try to reduce it to the smallest piece that still 
shows the problem. 

(As a side note, a project so big SHOULD have plenty of unit tests, but 
I see they're almost inexistant. Having to write tests forces people to 
use a more modular design. In this case, probably it would have been 
easier to test this issue, in a more isolated way, without having to 
bring the whole framework in).

Multithreaded programs may be tricky. Looking at the 
_MultiThreadBuildPlatform method (we're talking of it, right?) it isn't 
obvious that there are no race conditions in the code.

For a producer-consumer process like this, I would use a pool of worker 
threads, all waiting for work to do from a Queue, and a main (producer) 
thread that puts tasks to be done into the Queue. The synchronization 
is already done for you, it's almost automatic.

I've modified my previous example to show this usage.

Unless you can bring more evidence that this is a real Python issue and 
not a race condition in your code or something, I'd recommend to close 
this as invalid.

Added file: http://bugs.python.org/file12747/test_file_flush.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Thu Jan 15 05:36:29 2009
From: report at bugs.python.org (Javen Wang)
Date: Thu, 15 Jan 2009 04:36:29 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231994189.62.0.687251030746.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

I agree multithread programming is kind of difficult and tricky. But I
don't think there's a race condition in _MultiThreadBuildPlatform
method, because I do have only one producer. And the consumer consumes
the product only when it's done (i.e. the file is created and closed).
The only race condition, I think, it's in the Python or Windows file
system, in which the file created might not be seen by other process due
to the file buffer mechanism. I think the flush() method of file object
and os.fsync() are to remove the race condition. But it seems that they
are not working as they're supposed to be.

What I know is that os.fsync() calls the _commit() which calls
FlushFileBuffers(). Why no problem if I call the FlushFileBuffers()
directly? That's why I think the most possible race condition is in
Python file buffer operation which is out of the control of my Python code.

I'm sorry that I didn't realize there's 150M code to checkout. Thanks
for your patience. Actually they are not code of my application itself.
They are the code used to test my application because my application is
a build system which needs source code to build. The real code of my
application is in the, for my example, directory of
C:\test\tools\Source\Python with just about 3M source files :-) And I
think I have narrowed down the issue in the file creation in
SaveFileOnChange function in C:\test\tools\Source\Python\Common\Misc.py. 

I know it's very hard to reproduce issue in multi-thread context. And I
cannot say absolutely there's no bug in my code. It's OK for you to
close this tracker. But it would be better to let it open for a few days
so that I can do more investigation then. Anyway, thanks for the trying
again.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Thu Jan 15 05:53:13 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 15 Jan 2009 04:53:13 +0000
Subject: [issue4947] sys.stdout fails to use default encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1231995193.73.0.812382975911.issue4947@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

> It probably uses sys.getdefaultencoding() instead.

That would be wrong too, according to the cited documentation.

file.encoding is a read only attribute; it can be set in C code using 
PyFile_SetEncoding. Apart from its definition in fileobject.c, it is 
*only* used by PyInitialize when sys.stdin/stdout/stderr are created. 
There are no tests, nor any other use of it anywhere. Apparently the 
attribute *is* checked when writing unicode objects, but it does not 
work.

I'm guessing now, but probably the original intent was to make file 
objects behave like the wrapper returned by codecs.open works now -- 
later it was deemed impractical and forgotten. Now, the "declarative" 
meaning of file.encoding survives, but the "behavior" is broken.

I don't know what would be the right thing to do. The encoding used by 
stdin/stdout/stderr is valuable information so the attribute should 
remain. Fixing the behavior is like having a crippled 
StreamReaderWriter and I don't see the point. But StreamReaderWriter 
has an "encoding" attribute too, and it "works", so one cannot rely on 
having such attribute to know whether the stream automatically encodes 
its data or not.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Thu Jan 15 06:29:19 2009
From: report at bugs.python.org (Gil)
Date: Thu, 15 Jan 2009 05:29:19 +0000
Subject: [issue4952] Running Python Script to Run a C++ Code
In-Reply-To: <1231997358.88.0.339846951949.issue4952@psf.upfronthosting.co.za>
Message-ID: <1231997358.88.0.339846951949.issue4952@psf.upfronthosting.co.za>


New submission from Gil <mathnasiumcos at gmail.com>:

Attached you will find my attachment "testdll.zip", my dilemma was how 
to run the attached C++ program using python scripts.  Please advise.

Thanks,
Gil

----------
components: IDLE
files: testdll.zip
messages: 79888
nosy: dominade27
severity: normal
status: open
title: Running Python Script to Run a C++ Code
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file12748/testdll.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4952>
_______________________________________

From report at bugs.python.org  Thu Jan 15 07:03:41 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 15 Jan 2009 06:03:41 +0000
Subject: [issue4952] Running Python Script to Run a C++ Code
In-Reply-To: <1231997358.88.0.339846951949.issue4952@psf.upfronthosting.co.za>
Message-ID: <1231999421.58.0.988833842763.issue4952@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Please post your question to the Python users mailing list: python-
list at python.org -- mirrored as the comp.lang.python newsgroup too.
Also, gmane.org provides a web interfase: http://dir.gmane.org/
gmane.comp.python.general

Back to your question, the easiest way would be to define a C interfase 
(not C++) that you can call directly from Python using the ctypes 
module (available in the standard library since 2.5)
Another good alternative is to use Cython (which evolved from the Pyrex 
project). See http://wiki.python.org/moin/
IntegratingPythonWithOtherLanguages

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4952>
_______________________________________

From report at bugs.python.org  Thu Jan 15 08:25:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 15 Jan 2009 07:25:14 +0000
Subject: [issue4952] Running Python Script to Run a C++ Code
In-Reply-To: <1231997358.88.0.339846951949.issue4952@psf.upfronthosting.co.za>
Message-ID: <1232004314.72.0.133056085602.issue4952@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The bug tracker is not a place to obtain help, but to offer help (e.g.
by proposing patches to Python). As Gabriel explains, there are better
places to get help with Python. Closing the report as invalid.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4952>
_______________________________________

From report at bugs.python.org  Thu Jan 15 08:45:05 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Jan 2009 07:45:05 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1232005505.77.0.359133035395.issue1242657@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Here's a patch that fixes-up length_hint and it's internal callers.

I think there are plenty of other places that also swallow exceptions
but will leave those for someone who wants to look at every instance of
PyErr_Clear() to see if it has been restricted to some small group of
exceptions.

----------
assignee: rhettinger -> 
keywords: +patch
versions: +Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12749/lenhint.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Thu Jan 15 10:02:47 2009
From: report at bugs.python.org (oopos)
Date: Thu, 15 Jan 2009 09:02:47 +0000
Subject: [issue4953] Cannot upload binary file from form ?
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>


New submission from oopos <myoopos at gmail.com>:

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
---------------------------------------------
Hi,I user Python! 
 
 
UnicodeDecodeError	Python 3.0: G:\cgi\python\python.exe
Thu Jan 15 16:46:34 2009

A problem occurred in a Python script. Here is the sequence of function
calls leading up to the error, in the order they occurred.
 G:\webserver\xampp\cgi-bin\testupload.py in ()
  107 
  108 # get form
  109 opsform = cgi.FieldStorage()
  110 
  111 print ("<br>","form-data:","<br>",opsform,"<br>")
opsform undefined, cgi = <module 'cgi' from 'G:\cgi\python\lib\cgi.py'>,
cgi.FieldStorage = <class 'cgi.FieldStorage'>
 G:\cgi\python\lib\cgi.py in __init__(self=FieldStorage(None, None, []),
fp=None, headers={'content-length': '671631', 'content-type':
'multipart/form-data;
boundary=---------------------------9699301019407'}, outerboundary='',
environ=<os._Environ object at 0x00C90C50>, keep_blank_values=0,
strict_parsing=0)
  477             self.read_urlencoded()
  478         elif ctype[:10] == 'multipart/':
  479             self.read_multi(environ, keep_blank_values,
strict_parsing)
  480         else:
  481             self.read_single()
self = FieldStorage(None, None, []), self.read_multi = <bound method
FieldStorage.read_multi of FieldStorage(None, None, [])>, environ =
<os._Environ object at 0x00C90C50>, keep_blank_values = 0,
strict_parsing = 0
 G:\cgi\python\lib\cgi.py in read_multi(self=FieldStorage(None, None,
[]), environ=<os._Environ object at 0x00C90C50>, keep_blank_values=0,
strict_parsing=0)
  597         # Create bogus content-type header for proper multipart
parsing
  598         parser.feed('Content-Type: %s; boundary=%s\r\n\r\n' %
(self.type, ib))
  599         parser.feed(self.fp.read())
  600         full_msg = parser.close()
  601         # Get subparts
parser = <email.feedparser.FeedParser object at 0x00DD5650>, parser.feed
= <bound method FeedParser.feed of <email.feedparser.FeedParser object
at 0x00DD5650>>, self = FieldStorage(None, None, []), self.fp =
<io.TextIOWrapper object at 0x00BE3FB0>, self.fp.read = <bound method
TextIOWrapper.read of <io.TextIOWrapper object at 0x00BE3FB0>>
 G:\cgi\python\lib\io.py in read(self=<io.TextIOWrapper object at
0x00BE3FB0>, n=-1)
 1722             # Read everything.
 1723             result = (self._get_decoded_chars() +
 1724                       decoder.decode(self.buffer.read(), final=True))
 1725             self._set_decoded_chars('')
 1726             self._snapshot = None
decoder = <encodings.gbk.IncrementalDecoder object at 0x00DB7AB0>,
decoder.decode = <built-in method decode of IncrementalDecoder object at
0x00DB7AB0>, self = <io.TextIOWrapper object at 0x00BE3FB0>, self.buffer
= <io.BufferedReader object at 0x00BE3F90>, self.buffer.read = <bound
method BufferedReader.read of <io.BufferedReader object at 0x00BE3F90>>,
final undefined

UnicodeDecodeError: 'gbk' codec can't decode bytes in position 157-158:
illegal multibyte sequence
      args = ('gbk',
b'-----------------------------9699301019407\r\n...-----------------------------9699301019407--\r\n',
157, 159, 'illegal multibyte sequence')
      encoding = 'gbk'
      end = 159
      object =
b'-----------------------------9699301019407\r\n...-----------------------------9699301019407--\r\n'
      reason = 'illegal multibyte sequence'
      start = 157
      with_traceback = <built-in method with_traceback of
UnicodeDecodeError object at 0x00DB7BF0>

l:\tmp_dir\tmpxyeojf.html contains the description of this error. 


-------------------------------------------
Hi,
I am newbie for python under the windows.
I find that the cgi module always work wrong for the binary files to upload.
I find that it cannot auto to discern the files' mode and alway use the
default mode : 'TEXT'.
So I want to change the sys.stdin 's mode to BINARY to support the
binary files.
I got this way:
 import msvcrt,os
 msvcrt.setmode(0,os.O_BINARY) # for stdin 
 msvcrt.setmode(1,os.O_BINARY) # for stdout
but it isn't work,too.
I know use C progam language can use this function:
  freopen("somefilename","mode","stdin or stdout") to redirect the file
flow.
Can every one help me ?

Best Regards
   oopos

I

----------
components: Unicode
files: tmpav1vve.html
messages: 79892
nosy: oopos
severity: normal
status: open
title: Cannot upload binary file from form ?
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file12750/tmpav1vve.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 15 11:59:26 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Jan 2009 10:59:26 +0000
Subject: [issue4953] Cannot upload binary file from form ?
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232017166.25.0.539387131535.issue4953@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Does it work if you change your script like this:
   opsform = cgi.FieldStorage(open(sys.stdin.fileno(), 'rb'))

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 15 12:58:37 2009
From: report at bugs.python.org (oopos)
Date: Thu, 15 Jan 2009 11:58:37 +0000
Subject: [issue4953] Cannot upload binary file from form ?
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232020717.0.0.328974989315.issue4953@psf.upfronthosting.co.za>


oopos <myoopos at gmail.com> added the comment:

To Amaury Forgeot d'Arc :

Thank you.

That error have sloved with your way:
[quote]Does it work if you change your script like this:
   opsform = cgi.FieldStorage(open(sys.stdin.fileno(), 'rb'))[/quote]

Now,The new problem come out:
[code]  97         """Push some new data into this object."""
 
   98         # Handle any previous leftovers
 
   99         data, self._partial = self._partial + data, ''
 
  100         # Crack into lines, but preserve the newlines on the end 
of each
 
  101         parts = NLCRE_crack.split(data)
 
data = b'-----------------------------7d91f41a302f4
\nCo...\x0e\x0f\x0c\x10\x17\x14\x18\x18\x17\x14\x16\x16', self = 
<email.feedparser.BufferedSubFile object at 0x00DD5270>, self._partial 
= '' 

TypeError: Can't convert 'bytes' object to str implicitly 
[/code]

I find that the CGI LIB didn't use bytes flow, it always use string 
flow.

More info in the attch file:

Added file: http://bugs.python.org/file12751/tmpy44zj7.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 15 13:14:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Jan 2009 12:14:24 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232021663.86.0.294979325942.issue4242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks nice to me. (I'm curious why you call gc.collect()
several times in a row, though)

However, since it is an important change in the long run, perhaps the
specifics could be further discussed on python-dev before taking a decision?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Thu Jan 15 13:43:51 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Jan 2009 12:43:51 +0000
Subject: [issue4953] Cannot upload binary file from form ?
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232023431.81.0.996981440833.issue4953@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

OK, another try. Please replace the previous version with these 3 lines:

  encoding = os.environ.get('HTTP_TRANSFER_ENCODING')
  stdin = open(sys.stdin.fileno(), 'r', encoding=encoding)
  opsform = cgi.FieldStorage(stdin)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 15 14:45:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Jan 2009 13:45:42 +0000
Subject: [issue4928] Problem with tempfile.NamedTemporaryFile on Solaris 10
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1232027142.9.0.182762150868.issue4928@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> high
stage:  -> test needed
versions: +Python 2.6, Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4928>
_______________________________________

From report at bugs.python.org  Thu Jan 15 15:01:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 14:01:47 +0000
Subject: [issue4397] test_socket fails occassionaly in teardown:
	AssertionError: [Errno 57] Socket is not connected
In-Reply-To: <1227475750.08.0.401391689781.issue4397@psf.upfronthosting.co.za>
Message-ID: <1232028107.58.0.93770734483.issue4397@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  I take it back:  this *does* appear to be OS X specific.
I've attached a small (17-line) example that fails with
the Errno 57 error on OS X, but passes on the Linux machines I tested.

In this example, it appears that when 'conn.close()' is called by the 
server, the client socket 'cli' is automatically disconnected, hence
the shutdown failure.  On Linux that doesn't happen.

Can anyone shed any light on this, and/or suggest what should be done?

----------
components: +Macintosh
stage: patch review -> 
Added file: http://bugs.python.org/file12752/socket_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4397>
_______________________________________

From report at bugs.python.org  Thu Jan 15 15:34:46 2009
From: report at bugs.python.org (oopos)
Date: Thu, 15 Jan 2009 14:34:46 +0000
Subject: [issue4953] Cannot upload binary file from form ?
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232030086.75.0.617040045233.issue4953@psf.upfronthosting.co.za>


oopos <myoopos at gmail.com> added the comment:

Thank you for time.
Now,I try with you saied.Bu it is taken wrong as before.

See the files:

Added file: http://bugs.python.org/file12753/full_source_and_error.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 15 16:10:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 15:10:05 +0000
Subject: [issue4397] test_socket fails occassionaly in teardown:
	AssertionError: [Errno 57] Socket is not connected
In-Reply-To: <1227475750.08.0.401391689781.issue4397@psf.upfronthosting.co.za>
Message-ID: <1232032205.63.0.322116727251.issue4397@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Found a better (one-line) fix.  Fixed in the trunk in r68611.
Will port to 2.6, 3.0, 3.1.

----------
resolution:  -> fixed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4397>
_______________________________________

From report at bugs.python.org  Thu Jan 15 16:38:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 15:38:43 +0000
Subject: [issue4397] test_socket fails occassionaly in teardown:
	AssertionError: [Errno 57] Socket is not connected
In-Reply-To: <1227475750.08.0.401391689781.issue4397@psf.upfronthosting.co.za>
Message-ID: <1232033923.0.0.595688737189.issue4397@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in 2.6, 3.0, 3.1.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4397>
_______________________________________

From report at bugs.python.org  Thu Jan 15 17:45:25 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Jan 2009 16:45:25 +0000
Subject: [issue4953] Cannot upload binary file from form ?
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232037925.21.0.269096812132.issue4953@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the test case. I reproduced it easily.
There is indeed a real problem in CGI streams.

The first thing to do is to start python with the -u option (add it to
the end of the first #! line), so that stdin yields bytes instead of
unicode chars, and \r\n are not translated on Windows.

Even then, I noticed that in the multipart/form-data section, text
fields are utf-8 encoded, but the file content is raw binary.
(FWIW, I use Firefox and Apache on Windows)
No encoding seems to be specified, neither in the content, nor in the
environment (no HTTP_TRANSFER_ENCODING)

And of course, the email.parser.FeedParser object used to parse it
accepts only unicode, not bytes.
Help needed.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 15 17:48:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 16:48:16 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1232038096.18.0.856118615051.issue4910@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Benjamin!  Checked in in r68553, backported to 3.0 in r68556.

Here's the second patch, which fixes almost all remaining uses of nb_long 
but stops short of actually removing/renaming the nb_long slot.

Notes:

(1) I haven't tested the change to PC/winreg.c

(2) The Modules/_struct.c change does introduce a change in behaviour:
for example, before the patch,

struct.pack('q', decimal.Decimal(1))

raises struct.error.  After the patch, the packing succeeds.  I *think*
the patched behaviour is probably the right behaviour, since it agrees 
with 2.x, but it's not 100% clear to me what the intentions of the struct 
module are with respect to integer packing of non-integer types.  This is 
probably a question for another issue.

Added file: http://bugs.python.org/file12754/issue4910_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Thu Jan 15 18:23:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 17:23:10 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1232040190.08.0.394220368091.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Retargeting, now that 2.5 is in security-fix-only mode.

Bob, can you clarify what *should* be happening in 2.6, 2.7, 3.0 and 3.1 
for things like:

struct.pack('L', 2009.1)
struct.pack('L', Decimal('3.14')) 

?

It also seems that 'L' and 'Q behave differently.  For example, with 2.7:

>>> struct.pack('L', 3.1)
sys:1: DeprecationWarning: integer argument expected, got float
'\x03\x00\x00\x00'
>>> struct.pack('Q', 3.1)
'\x03\x00\x00\x00\x00\x00\x00\x00'

----------
nosy: +marketdickinson
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Thu Jan 15 18:28:14 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Jan 2009 17:28:14 +0000
Subject: [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1232040494.66.0.18127740145.issue4929@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Submitted as r68618

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4929>
_______________________________________

From report at bugs.python.org  Thu Jan 15 18:35:09 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Jan 2009 17:35:09 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1232040909.63.0.490554278889.issue4927@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Just to clarify, 
Ascii files and unicode files will repr() as
<open file 'tmp\foo', mode 'wb' at ...>
<open file u'tmp\\foo', mode 'wb' at ...>
respectively.  In the former, the backslash isn't escaped, but in the 
latter it is.  The single quotes certainly imply repr, and if this were 
a list, it would repr as:
['tmp\\foo']
and so I think that the ascii syntax really ought to be
<open file 'tmp\\foo', mode 'wb' at ...>


The inconsistency shows up in the testsuite for test_file() when the 
TMPFN is tmp\@test (because test_support didn't succeed in creating a 
temp file @test) when it is checking the repr of a file opened with a 
unicode filename with code that corresponds exactly to code used for an 
string filename.

Any thoughts?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Thu Jan 15 18:39:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 17:39:15 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1232041155.31.0.828580312001.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some more strange results:

Python 2.6.1+ (release26-maint:68613, Jan 15 2009, 15:19:54) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import pack
>>> from decimal import Decimal
>>> pack('l', Decimal('3.14'))
'\x03\x00\x00\x00'
>>> pack('L', Decimal('3.14'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for &: 'Decimal' and 'long'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Thu Jan 15 18:57:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Jan 2009 17:57:00 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1232038096.18.0.856118615051.issue4910@psf.upfronthosting.co.za>
Message-ID: <1afaf6160901150956h28d5bc8ehbccd85fefd7d72b2@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Thu, Jan 15, 2009 at 10:48 AM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Thanks, Benjamin!  Checked in in r68553, backported to 3.0 in r68556.
>
> Here's the second patch, which fixes almost all remaining uses of nb_long
> but stops short of actually removing/renaming the nb_long slot.
>
> Notes:
>
> (1) I haven't tested the change to PC/winreg.c

This looks correct. In fact, I don't really see the point of having
PyHKEY_unaryFailureFunc since a TypeError will automatically be raised
if the slot is NULL, but that is certainly another issue.

>
> (2) The Modules/_struct.c change does introduce a change in behaviour:
> for example, before the patch,
>
> struct.pack('q', decimal.Decimal(1))
>
> raises struct.error.  After the patch, the packing succeeds.  I *think*
> the patched behaviour is probably the right behaviour, since it agrees
> with 2.x, but it's not 100% clear to me what the intentions of the struct
> module are with respect to integer packing of non-integer types.  This is
> probably a question for another issue.

Since Decimal implements __int__ and that's what the struct module is
converting with, I think this is fine.

Overall, the patch looks fine. I wonder if we should mark
PyNumber_Long as deprecated in the docs, though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Thu Jan 15 19:04:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 18:04:29 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1232042668.89.0.907426453228.issue4842@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Does anyone have time to review these patches?  I think the first is 
straightforward, and I'm reasonably sure of the correctness of the second 
patch.  I'm less sure that it's the right thing to do.  The question is 
what should happen when pickling an integer using the LONG opcode (pickle 
protocol 0).  The options are:

- append an 'L' on output in 3.x; accept input with and without trailing
  'L'.  This is what the patch does.  The only downside is the
  continuing presence of the 'L' in 3.x, which some might object to.

- don't append an 'L' on output in 3.x; accept input with and without
  trailing 'L'.  This would retain compatilbiity, but would mean that
  we can get different output *for the same opcode* with 2.x and 3.x.
  I don't think there's a precedent for this, but I can't see why it
  would be harmful.  Still, it seems safer not to do it.

- don't append an 'L' on output in 3.x, and reject input with a trailing
  'L' in 3.x.  This would make 3.x and 2.x pickles incompatible with
  each other, and breaks some tests.  Seems like a bad idea all around to
  me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Thu Jan 15 19:12:30 2009
From: report at bugs.python.org (Noufal)
Date: Thu, 15 Jan 2009 18:12:30 +0000
Subject: [issue4860] js_output wrong for cookies with " characters
In-Reply-To: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>
Message-ID: <1232043150.15.0.492960089557.issue4860@psf.upfronthosting.co.za>


Noufal <noufal at nibrahim.net.in> added the comment:

What's wrong with < and >?

I can see the issues with ; though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4860>
_______________________________________

From report at bugs.python.org  Thu Jan 15 19:12:42 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 15 Jan 2009 18:12:42 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1232040909.63.0.490554278889.issue4927@psf.upfronthosting.co.za>
Message-ID: <496F7C97.4070308@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Any thoughts?

I still hadn't time to reproduce the problem, so I still don't
understand it. What specific failure (file and line number) occurs,
and what specific strings get compared? test_file.py has 600 lines,
and I can't guess which test is failing. (also, you say test_file();
if you really refer to a function - where is that function defined?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Thu Jan 15 19:21:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Jan 2009 18:21:15 +0000
Subject: [issue4930] Small optimization in type construction
In-Reply-To: <1231854527.51.0.654505109034.issue4930@psf.upfronthosting.co.za>
Message-ID: <1232043675.61.0.559255491763.issue4930@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Looks good to me.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4930>
_______________________________________

From report at bugs.python.org  Thu Jan 15 19:54:52 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 15 Jan 2009 18:54:52 +0000
Subject: [issue1700288] Armin's method cache optimization updated for Python
	2.6
Message-ID: <1232045692.41.0.333816693838.issue1700288@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Looks like this was re-applied in r59943 and r59944. Thanks for taking
care of this, Amaury.

----------
nosy: +collinwinter, jyasskin
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1700288>
_______________________________________

From report at bugs.python.org  Thu Jan 15 20:21:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 19:21:29 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1232047289.09.0.290533960168.issue4910@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I wonder if we should mark
> PyNumber_Long as deprecated in the docs, though.

It would be nice to standardize on one of (PyNumber_Long, PyNumber_Int) 
and document the other as deprecated.

Maybe it would make more sense to stick with PyNumber_Long and deprecate 
PyNumber_Int, though?  It would make 2.x -> 3.x transitions easier, and 
would be consistent with some of the rest of the API:  we seem to be 
using PyLong_Check in preference to PyInt_Check in current code...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Thu Jan 15 20:31:09 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Jan 2009 19:31:09 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1232047869.93.0.920930235728.issue1242657@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Anyone else want to pick this up from here?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Thu Jan 15 20:53:56 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Jan 2009 19:53:56 +0000
Subject: [issue4860] js_output wrong for cookies with " characters
In-Reply-To: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>
Message-ID: <1232049236.59.0.0738130759742.issue4860@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> What's wrong with < and >?

>>> c=Cookie.Cookie('Customer="</script>";'); print c.js_output()

        <script type="text/javascript">
        <!-- begin hiding
        document.cookie = "Customer="</script>"";
        // end hiding -->
        </script>

It allows HTML/Javascript injection. Well, Python 2.5 already displays 
a warning:

/usr/lib/python2.5/Cookie.py:710: DeprecationWarning: 
Cookie/SmartCookie class is insecure; do not use it

The right fix is maybe to remove deprecated and unsecure function!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4860>
_______________________________________

From report at bugs.python.org  Thu Jan 15 21:53:11 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 15 Jan 2009 20:53:11 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1232052791.81.0.340339067074.issue3871@psf.upfronthosting.co.za>


Changes by Luke Kenneth Casson Leighton <lkcl at lkcl.net>:


----------
nosy: +lkcl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Thu Jan 15 22:21:04 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 15 Jan 2009 21:21:04 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

this patch uses work from #3871 to get a build of python for win32
by running msys under Wine, the windows emulator, on linux.
no proprietary operating system or proprietary software was used.

/bin/sh.exe is so xxxxing unbelievably slow on msys under wine
(each sh.exe takes two seconds to start up, loads 240 fonts
and 40 libraries) that running configure was completely intolerable.

consequently, given that PC/config.h is perfectly useable on nt,
this patch totally bypasses the majority of autoconf tests, and
thus cuts the configure time down from three hours to (only!)
fifteen minutes.

configure must be run as:
   ./configure --prefix/python25 --enable-win32build=yes  \
               --enable=shared=yes

there is an additional bug in msys /bin/sh which stops python.exe
from executing scripts that are handed to it on the command-line.
scripts that are fed as standard-input are absolutely fine
(even the same script).  running the same script from python.exe
from wineconsole cmd prompt is _also_ fine.

as a result, the build process terminates at:
   ./python.exe -E setup.py build

to complete the build, "wineconsole cmd" must be run, cd $(BUILDDIR)
and then run the commands manually:
   ./python.exe -E setup.py build
   ./python.exe -E setup.py install
then, back in the borked /bin/sh.exe, make install can be run.

stunningly, this does actually work: python.exe is build,
libpython2.5.dll and libpython2.5.dll.a are built... amazing.

other necessary workarounds:

* gcc -shared .... --out-implib=libpython2.5.dll.a .... etc fails
  spectacularly to create both the .a implib _and_ the .dll.
  consequently, it was necessary to split these up and use dlltool
  to create the dll, implib and .def file etc. etc.

* ar and ranlib on msys, versions 2.16, 2.17 _and_ 2.19 of binutils
  are borked.  2.16 and 2.17 throw an exception; 2.19 segfaults.
  consequently, building of $LIBRARY had to be terminated with
  prejudice.  --enable-shared=no will fail miserably.

regarding testing: it's all a bit... odd.

* ctypes tests cause segfaults!  the S8H one manages a segfault
  all on its own, but there are other tests that cause corruption
  that only shows up later... euurgh.

* builtin test_open fails due to putting \r\n instead of \n in the file

* test_file.py gets a sharing violation

* test_str gets a great one!

   test_str^M
   fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
   fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
   err:seh:setup_exception_record stack overflow 872 bytes in thread
001e eip 7bc3b1dc esp 00410fc8 stack 0x410000-0x411000-0x610000

   yup.... test_floatformatting.

   ahh, this is gooood :)


overall it's a damn good start - i'm dead impressed with
wine and msys in that they exist at all.

compiling and testing python under wine + msys should help
test and improve both those projects, and both this patch
and #3871 will help get python off of its dependence on
proprietary software.

----------
components: Build
files: f
messages: 79916
nosy: lkcl
severity: normal
status: open
title: native build of python win32 using msys under wine.
versions: Python 2.5
Added file: http://bugs.python.org/file12755/f

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Thu Jan 15 22:24:43 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 15 Jan 2009 21:24:43 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232054683.41.0.217632422377.issue4954@psf.upfronthosting.co.za>


Changes by Luke Kenneth Casson Leighton <lkcl at lkcl.net>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Thu Jan 15 22:35:16 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 15 Jan 2009 21:35:16 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232055316.51.0.200133948062.issue4954@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Are you seriously requesting inclusion of the file f into Python? It
contains many changes that are unsuitable for inclusion, such as the
removal of graminit.c and the removal of configure.

(besides, I personally think that the ability to compile Python with
msys under Wine doesn't belong into core Python, because it is a
minority platform)

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Thu Jan 15 23:26:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Jan 2009 22:26:20 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1232058380.64.0.314220939573.issue4910@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Second patch applied in r68619 (py3k) and r68620 (3.0 maintenance branch).

Here's the third and final patch:  rename the nb_long slot to nb_reserved, 
and change its type to (void *).

Added file: http://bugs.python.org/file12756/issue4910_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Thu Jan 15 23:31:41 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Jan 2009 22:31:41 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1232058701.65.0.971545626481.issue4927@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I thought I'd explained it in detail without having to invoke the 
testsuite.  If TEMPFN is "tmp\\@test" you get the following failure:
FAILED (failures=1)
test test_file failed -- Traceback (most recent call last):
  File "D:\pydev\python\trunk\lib\test\test_file.py", line 175, in 
testUnicodeOpen
    self.assert_(repr(f).startswith("<open file u'" + TESTFN))
AssertionError: None

It fails, because print repr(f) will start with:
<open file u'tmp\\@test


Essentially, when generating a repr of a fileobject with a string 
filename, the string filename is interpolated between the single colons.
But when it generates a repr of a fileobject with a unicode filename, 
the unicode name is  escaped and then interpolated.
This results in unicode filename fileobjects having a repr with escaped 
backslashes, while the string filename fileobjects have a repr where the 
backslashes appear unescaped between the colons.

My patch proposes to 
a) make sure that the repr(f) is a string containing the repr of the 
filename (be it unicode, string or whatever)
b) Fix the testsuite so that both this case and the one testing string 
filenames assumes a repr of the filename.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Thu Jan 15 23:34:32 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 15 Jan 2009 22:34:32 +0000
Subject: [issue4955] inconsistent, perhaps incorrect,
	behavior with respect to entities parsed by xml.sax
In-Reply-To: <1232058872.83.0.627723376398.issue4955@psf.upfronthosting.co.za>
Message-ID: <1232058872.83.0.627723376398.issue4955@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

The attached program demonstrates that the ContentHandler.skippedEntity
callback is not invoked for all skipped entities.  Specifically, it is
not invoked for those in attribute values.  Additionally, it
demonstrates that when parsing a document with no DOCTYPE, skippedEntity
is not called at all; instead the parser raises an exception about an
"undefined entity".

----------
components: Library (Lib)
files: entity-skipped-in-attribute-value.py
messages: 79920
nosy: exarkun
severity: normal
status: open
title: inconsistent, perhaps incorrect, behavior with respect to entities parsed by xml.sax
Added file: http://bugs.python.org/file12757/entity-skipped-in-attribute-value.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4955>
_______________________________________

From report at bugs.python.org  Thu Jan 15 23:46:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 15 Jan 2009 22:46:11 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1232058701.65.0.971545626481.issue4927@psf.upfronthosting.co.za>
Message-ID: <496FBCB0.4090303@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I thought I'd explained it in detail [...]

Well, so far, you didn't say that it was testUnicodeOpen that
failed. Now that I see that, I can understand the problem.

In your original message, I failed to see a problem. Yes, the repr
is inconsistent - but why is that a problem? (and then, why does
it actually cause real problems in the test suite on Vista - as
it turns out, the inconsistency causes no problems in the testsuite
at all)

> My patch proposes to 
> a) make sure that the repr(f) is a string containing the repr of the 
> filename (be it unicode, string or whatever)

I cannot understand how this contributes to solving the problem. -1.

> b) Fix the testsuite so that both this case and the one testing string 
> filenames assumes a repr of the filename.

As it is clearly the test suite that is broken, we should just fix the
test suite. If the two chunks in the test, only the second chunk is
relevant for fixing the problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Thu Jan 15 23:49:05 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 15 Jan 2009 22:49:05 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1232059745.07.0.988431428365.issue1242657@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In _PyObject_LengthHint() code, at the line:
    if (ro == NULL && PyErr_Occurred()) {
It seems that PyErr_Occurred() is not useful and is always true when the 
previous PyObject_CallMethodObjArgs() returned NULL.

Otherwise the patch is fine to me.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Thu Jan 15 23:55:17 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Jan 2009 22:55:17 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1232060117.49.0.131416420232.issue4927@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I think the testsuite just exposed a design fault in python or a bug, if 
you will.  When we by accident had a backslash in the filename, I 
noticed the inconsistency between
'tmp\@test' and u'tmp\\@test'.
One is a valid repr, the other isn't.  It is customary when producing a 
repr() of an object, to have it contain a repr() of the any inner 
object, such as a string.  'tmp\@test' looks like a valid python literal 
but if entered, would produce an incorrect result.

Fixing the testsuite only, will just keep this discrepancy (or incorrect 
string repr maybe) hidden for longer.

It is a different story, maybe, that thee test_file.py hasn't done more 
aggressive testing on filenames with backslashes.  This is far from 
being the only case that fails because of this.  Some is due to 
incorrectly coded tests.  Others are due to surprising python behaviour, 
like this one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 00:00:35 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 15 Jan 2009 23:00:35 +0000
Subject: [issue4956] Py_Initialize needs to be done before file load (on
	msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

this is a _very_ strange case where the file contents cannot be read,
under msys+wine, but under _just_ wine (cmd.exe) everything goes
absolutely fine.

by moving Py_Initialize() to _before_ the file load, it works!

----------
components: Build
files: f
messages: 79924
nosy: lkcl
severity: normal
status: open
title: Py_Initialize needs to be done before file load (on msys+wine)
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file12758/f

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4956>
_______________________________________

From report at bugs.python.org  Fri Jan 16 00:01:02 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Jan 2009 23:01:02 +0000
Subject: [issue4957] os.ftruncate raises IOError instead of OSError
In-Reply-To: <1232060462.22.0.637111039397.issue4957@psf.upfronthosting.co.za>
Message-ID: <1232060462.22.0.637111039397.issue4957@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

I stumbled upon this.  Of all the errors in the posixmodule.c, ftruncate 
alone raises an IOError upon failure.  All the others raise OSError.  
This behaviour is not documented.  However, the os module documentation 
says>

Note
All functions in this module raise OSError in the case of invalid or 
inaccessible file names and paths, or other arguments that have the 
correct type, but are not accepted by the operating system.

This came to light when I added tests to verify that exceptions were 
being raised by invalid file descriptors.

I propose to fix this to comply with the docs.

----------
components: Interpreter Core
files: ftruncate.patch
keywords: patch, patch
messages: 79925
nosy: krisvale
severity: normal
status: open
title: os.ftruncate raises IOError instead of OSError
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12759/ftruncate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4957>
_______________________________________

From report at bugs.python.org  Fri Jan 16 00:03:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 15 Jan 2009 23:03:21 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1232060117.49.0.131416420232.issue4927@psf.upfronthosting.co.za>
Message-ID: <496FC0B7.2050903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I think the testsuite just exposed a design fault in python or a bug, if 
> you will.

I disagree. The feature is intentional as-is, and well-designed.

> It is customary when producing a 
> repr() of an object, to have it contain a repr() of the any inner 
> object, such as a string.

Not at all. It is customary to invoke the nested object's repr, in
the hope that the result of repr will be a string that you can pass
to eval(). This is completely different, because there is no hope
that the result of repr() of a file can be eval()ed.

As the repr is a string, it is natural to just concatenate the pieces
of the repr, including the file name string. For Unicode file names,
this natural approach fails, because one needs to encode the string
first. Mark chose to use an escape representation, because this gives
plain ASCII.

> Fixing the testsuite only, will just keep this discrepancy (or incorrect 
> string repr maybe) hidden for longer.

Right. Changing the repr will break existing code, for no good reason.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 00:33:09 2009
From: report at bugs.python.org (Jan Malakhovski)
Date: Thu, 15 Jan 2009 23:33:09 +0000
Subject: [issue4958] email/header.py ecre regular expression issue
In-Reply-To: <1232062389.84.0.560697403346.issue4958@psf.upfronthosting.co.za>
Message-ID: <1232062389.84.0.560697403346.issue4958@psf.upfronthosting.co.za>


New submission from Jan Malakhovski <jan.malachowski at gmail.com>:

Hello.

I have dedicated mail server at home
and it holds about 1G of mail.
Most of mail is in non UTF-8 codepage, so today
I wrote little script that should recode
all letters to UTF. But I found that
email.header.decode_header parses some headers wrong.

For example, header
Content-Type: application/x-msword; name="2008
=?windows-1251?B?wu7v8O7x+w==?= 2 =?windows-1251?B?4+7kIDgwONUwMC5kb2M=?="
parsed as
[('application/x-msword; name="2008', None),
('\xc2\xee\xef\xf0\xee\xf1\xfb', 'windows-1251'), ('2
=?windows-1251?B?4+7kIDgwONUwMC5kb2M=?="', None)]
that is obviously wrong.

Now I'm playing with email/header.py file in
python 2.5 debian package
(but it's same in 2.6.1 version except that all <> changed to !=).

If it's patched with
==================BEGIN CUT==================
--- oldheader.py	2009-01-16 01:47:32.553130030 +0300
+++ header.py	2009-01-16 01:47:16.783119846 +0300
@@ -39,7 +39,6 @@
   \?                    # literal ?
   (?P<encoded>.*?)      # non-greedy up to the next ?= is the encoded
string
   \?=                   # literal ?=
-  (?=[ \t]|$)           # whitespace or the end of the string
   ''', re.VERBOSE | re.IGNORECASE | re.MULTILINE)
 
 # Field name regexp, including trailing colon, but not separating
whitespace,
==================END CUT==================
it works fine.

So I wonder if this
  (?=[ \t]|$)           # whitespace or the end of the string
really needed, after all if there is only
whitespaces after encoded word, its just
appended to the list by

parts = ecre.split(line)

--
Also, there is related mail list thread:
http://mail.python.org/pipermail/python-dev/2009-January/085088.html

----------
components: Library (Lib)
messages: 79927
nosy: oxij
severity: normal
status: open
title: email/header.py ecre regular expression issue
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4958>
_______________________________________

From report at bugs.python.org  Fri Jan 16 02:57:43 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Jan 2009 01:57:43 +0000
Subject: [issue4957] os.ftruncate raises IOError instead of OSError
In-Reply-To: <1232060462.22.0.637111039397.issue4957@psf.upfronthosting.co.za>
Message-ID: <1232071063.68.0.949198375411.issue4957@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+1 for renaming. Although it looks like it has been this way since the
beginning, the examples of os.ftruncate I found didn't seem to rely on
this behavior. In addition, I think this is a small price to pay for
good consistency. [1]

[1] http://google.com/codesearch?hl=en&sa=N&q=lang:python+os.ftruncate

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4957>
_______________________________________

From report at bugs.python.org  Fri Jan 16 03:55:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Jan 2009 02:55:40 +0000
Subject: [issue4946] Lib/test/test__locale uses is to compare strings
In-Reply-To: <1231930466.83.0.500418142072.issue4946@psf.upfronthosting.co.za>
Message-ID: <1232074540.51.0.84620208804.issue4946@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r68628.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4946>
_______________________________________

From report at bugs.python.org  Fri Jan 16 04:07:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Jan 2009 03:07:16 +0000
Subject: [issue4950] Redundant declaration in pyerrors.h
In-Reply-To: <1231958008.57.0.172561550702.issue4950@psf.upfronthosting.co.za>
Message-ID: <1232075236.59.0.260551587035.issue4950@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r68629.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4950>
_______________________________________

From report at bugs.python.org  Fri Jan 16 05:14:27 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Jan 2009 04:14:27 +0000
Subject: [issue4922] set.add and set.discard are not conformant to
	collections.MutableSet interface
In-Reply-To: <1231759440.37.0.125734005136.issue4922@psf.upfronthosting.co.za>
Message-ID: <1232079267.75.0.718323159869.issue4922@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Ported to py3k in r68630 and 3.0 in r68631.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4922>
_______________________________________

From report at bugs.python.org  Fri Jan 16 06:53:21 2009
From: report at bugs.python.org (dariusp)
Date: Fri, 16 Jan 2009 05:53:21 +0000
Subject: [issue4959] inspect.formatargspec fails for keyword args without
	defaults, affects help and likely pydoc
In-Reply-To: <1232085201.15.0.206392471567.issue4959@psf.upfronthosting.co.za>
Message-ID: <1232085201.15.0.206392471567.issue4959@psf.upfronthosting.co.za>


New submission from dariusp <dariusp at internode.on.net>:

Hi,

Suggested log message:
formatargspec now handles keyword only args that don't have defaults. 
Previously it expected an empty dict but was being given None.


Patch:
The patch contains a suggested fix to inspect.py and a new test in
test_inspect.py and inspect_fodder2.py to demonstrate the issue.


Before:
>>> def foo(*, a):
...  print(a)
... 
>>> help(foo)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/site.py", line 427, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python3.0/pydoc.py", line 1672, in __call__
    self.help(request)
  File "/usr/local/lib/python3.0/pydoc.py", line 1716, in help
    else: doc(request, 'Help on %s:')
  File "/usr/local/lib/python3.0/pydoc.py", line 1504, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/local/lib/python3.0/pydoc.py", line 1499, in render_doc
    return title % desc + '\n\n' + text.document(object, name)
  File "/usr/local/lib/python3.0/pydoc.py", line 322, in document
    if inspect.isroutine(object): return self.docroutine(*args)
  File "/usr/local/lib/python3.0/pydoc.py", line 1263, in docroutine
    formatannotation=inspect.formatannotationrelativeto(object))
  File "/usr/local/lib/python3.0/inspect.py", line 895, in formatargspec
    if kwonlyarg in kwonlydefaults:
TypeError: argument of type 'NoneType' is not iterable


After:
>>> def foo(*, a):
...  print(a)
... 
>>> help(foo)

Help on function foo in module __main__:

foo(*, a)

----------
components: Library (Lib)
files: inspect_keyworded_no_default.diff
keywords: patch
messages: 79932
nosy: dariusp
severity: normal
status: open
title: inspect.formatargspec fails for keyword args without defaults, affects help and likely pydoc
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12760/inspect_keyworded_no_default.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4959>
_______________________________________

From report at bugs.python.org  Fri Jan 16 07:16:03 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 16 Jan 2009 06:16:03 +0000
Subject: [issue4956] Py_Initialize needs to be done before file load (on
	msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232086563.23.0.560031800199.issue4956@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

what is WEIRD_DEBUG? 
why do you remove a test from string_tests.py? 
why do you modify a command in setup.py?

What do you mean "the file contents cannot be read under msys+wine"? 
What specific error you have?
The right thing to do would be to analize that error and fix the 
causes. Randomly flipping blocks of code isn't a good practice.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4956>
_______________________________________

From report at bugs.python.org  Fri Jan 16 07:29:08 2009
From: report at bugs.python.org (Martin Saturka)
Date: Fri, 16 Jan 2009 06:29:08 +0000
Subject: [issue4960] askdirectory from tkinter.filedialog does not work
In-Reply-To: <1232087348.49.0.185277091833.issue4960@psf.upfronthosting.co.za>
Message-ID: <1232087348.49.0.185277091833.issue4960@psf.upfronthosting.co.za>


New submission from Martin Saturka <kvutza at gmail.com>:

Directory selection from Tkinter part of Python 3.0, i.e. "askdirectory"
function from tkinter.filedialog does not work. It works for 2.x Python,
other Tkinter functions (askopenfilename, asksaveasfilename) work well
at both 2.x and 3.0 versions.

----------
components: Tkinter
messages: 79934
nosy: kvutza
severity: normal
status: open
title: askdirectory from tkinter.filedialog does not work
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4960>
_______________________________________

From report at bugs.python.org  Fri Jan 16 07:41:20 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 06:41:20 +0000
Subject: [issue4960] askdirectory from tkinter.filedialog does not work
In-Reply-To: <1232087348.49.0.185277091833.issue4960@psf.upfronthosting.co.za>
Message-ID: <1232088080.53.0.778336470706.issue4960@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please be more explicit: what does "not work" mean? What do you do, what
happens, what do you expect to happen instead?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4960>
_______________________________________

From report at bugs.python.org  Fri Jan 16 07:56:15 2009
From: report at bugs.python.org (Martin Saturka)
Date: Fri, 16 Jan 2009 06:56:15 +0000
Subject: [issue4960] askdirectory from tkinter.filedialog does not work
In-Reply-To: <1232087348.49.0.185277091833.issue4960@psf.upfronthosting.co.za>
Message-ID: <1232088975.15.0.173664282718.issue4960@psf.upfronthosting.co.za>


Martin Saturka <kvutza at gmail.com> added the comment:

When I do in Python 2.x (e.g. 2.6) next:
----------------------------
import Tkinter as T
import tkFileDialog as F
t = T.Tk()
dn = F.askdirectory()
----------------------------

It pop-ups the dialog, it is OK. Analogical case for Python 3.0 does not
work, at least on my Linux box:
----------------------------
import tkinter as T
import tkinter.filedialog as F
t = T.Tk()
dn = F.askdirectory()
----------------------------

It just writes an error message below:
----------------------------
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/tkinter/filedialog.py", line 430, in
askdirectory
    return Directory(**options).show()
  File "/usr/local/lib/python3.0/tkinter/dialog.py", line 20, in __init__
    cnf['title'], cnf['text'],
KeyError: 'title'
----------------------------

When I had tried to put there all the parameters it was asking for, it
just put some nonsense window.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4960>
_______________________________________

From report at bugs.python.org  Fri Jan 16 08:05:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 07:05:48 +0000
Subject: [issue4960] askdirectory from tkinter.filedialog does not work
In-Reply-To: <1232087348.49.0.185277091833.issue4960@psf.upfronthosting.co.za>
Message-ID: <1232089548.5.0.701928714471.issue4960@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah. That's a duplicate of issue 4406.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> In Lib\tkinter\filedialog.py, class Directory define loss a"_"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4960>
_______________________________________

From report at bugs.python.org  Fri Jan 16 08:32:08 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 16 Jan 2009 07:32:08 +0000
Subject: [issue4958] email/header.py ecre regular expression issue
In-Reply-To: <1232062389.84.0.560697403346.issue4958@psf.upfronthosting.co.za>
Message-ID: <1232091128.83.0.960785105517.issue4958@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Your example header is invalid. Excerpt from RFC2047 <http://
www.ietf.org/rfc/rfc2047.txt> section 5:

   + An 'encoded-word' MUST NOT be used in parameter of a MIME
     Content-Type or Content-Disposition field, or in any structured
     field body except within a 'comment' or 'phrase'.

Even in the places where an "encoded word" (the sequence =?...?=) is 
allowed, it must always be surrounded by whitespace -- this is by 
design in the RFC.

If you have many of those invalid headers, you'll have to "cook" the 
output of decode_header, posibly detecting malformed sequences and 
calling decode_header again with just the offending substring. 

I don't think that Python should accept malformed headers - but if you 
come to a good solution you may publish the recipe in the Python 
cookbook <http://www.activestate.com/ASPN/Python/Cookbook/>

I'd close this report as invalid.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4958>
_______________________________________

From report at bugs.python.org  Fri Jan 16 09:13:35 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 16 Jan 2009 08:13:35 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232093615.81.0.895298725753.issue4953@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

An attempt to more accurately describe the issue, to attract more 
knowledgeable people, I hope...

----------
components: +Library (Lib)
nosy: +gagenellina
title: Cannot upload binary file from form ? -> cgi module cannot handle POST with multipart/form-data in 3.0
type: performance -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 16 09:37:37 2009
From: report at bugs.python.org (Javen Wang)
Date: Fri, 16 Jan 2009 08:37:37 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232095057.09.0.659451785792.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

I narrowed down the root cause in the GIL of Python. I read the source
code of implementing os.fsync and found it's using
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS to enclose the calling
of _commit() in order to be thread safe. I tried to add them in my C
extension and then the issue was reproduced. 

It looks like the thread state operation or GIL caused a race condition
and let os.fsync() not flush the makefile in buffer to disk before it
returns.

The multi-thread scenario in my application is 

    a. the main thread produces makefile
    b. once a makefile is generated, the main thread launches a new
thread in which a separated process is launched to run the makefile
until it exits.

I think there's no issue in this multi-thread scenario. And the Python
2.5.2 Maunal, Python/C API Ch8.1, says GIL must be taken care when doing
some blocking I/O operations, but it caused thread unsafe. So I still
think there's a bug in the Python.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Fri Jan 16 10:10:43 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 16 Jan 2009 09:10:43 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1232097043.24.0.143029653462.issue4927@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

So you are saying that you see no problem with the repr of a fileobject 
being generated in different ways depending on the fileobject being 
unicode or string?
You see no danger of confusion when one is confonted with
<open file 'foo\bar' ...>
vs.
<open file u'foo\\bar' ...>
You don't think anyone will be surprised when they try to 
eval 'foo\bar' as they can with u'foo\\bar' and get nonsensical results?

I maintain that this is a bug in python that ought to be fixed and not 
hidden by changing the test suite.  If you are going to rely on using 
the repr of the fileobject to extract the filename, you better be able 
to do that in a consistent manner irrespective of the type of the 
underlying filename.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 10:12:52 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 16 Jan 2009 09:12:52 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1232097172.45.0.283290428679.issue4927@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

And btw,
This can be fixed in fileobject.c without affecting the testsuite at 
all, since test_file.py has never tested filenames with backslashes 
except by accident.  It is therefore quite unlikely to cause any 
problems.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 10:25:18 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 16 Jan 2009 09:25:18 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232097918.92.0.652526894164.issue4944@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

If you start the new thread *after* the file is closed, no race 
condition should exist. I'm sorry but I'm unable to follow the code you 
use to create threads and write the makefile; but you should verify 
that your original assertion "Once a makefile is generated, launch a 
separate process..." is true.

Alternatively, when using a Queue like in my last example, make sure 
the new job enters the queue *after* closing the file.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Fri Jan 16 10:38:25 2009
From: report at bugs.python.org (eb303)
Date: Fri, 16 Jan 2009 09:38:25 +0000
Subject: [issue4961] Inconsistent/wrong result of askyesno function in
	tkMessageBox
In-Reply-To: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>
Message-ID: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>


New submission from eb303 <eric.brunel at pragmadev.com>:

Scenario to reproduce the problem:
- Run the attached script.
- Click the 'Ask confirm' button and answer 'Yes'; it should print 
True, which is the expected answer.
- Click the 'Ask file' button, select any file and confirm.
- Click the 'Ask confirm' button and answer 'Yes'.
The script prints False, which is obviously wrong.
Problem reproduced on Linux Red Hat Fedora Core 4, Suse Enterprise 
Linux 9, Solaris 8 for Sparc and Solaris 10 on Intel. The script works 
as expected on Windows 2000, so it seems to be Unix-specific.

Possible cause: the result of the _show function in tkMessageBox is not 
always a string, apparently depending on what happened before. Changing 
the last line to:
return str(res)
seemed to correct the problem for me.

----------
components: Tkinter
files: dialog-bug.py
messages: 79944
nosy: eb303
severity: normal
status: open
title: Inconsistent/wrong result of askyesno function in tkMessageBox
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12761/dialog-bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4961>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:02:48 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Jan 2009 10:02:48 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1232100168.4.0.103828851843.issue4927@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think path names should be printed with forward slashes on Windows as
well as elsewhere to avoid this type of confusion, and this.
>>> sb
'tmp\\foo'
>>> print(sb)
tmp\foo
(Of course I know why.)

Users have been advised on python-list by various people to enter
literal paths with forward slashes for the same reason.  Printing them
out that way would encourage and reinforce this.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:28:24 2009
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_BRINER?=)
Date: Fri, 16 Jan 2009 10:28:24 +0000
Subject: [issue4962] urlparse & nfs url (rfc 2224)
In-Reply-To: <1232101704.89.0.669847506906.issue4962@psf.upfronthosting.co.za>
Message-ID: <1232101704.89.0.669847506906.issue4962@psf.upfronthosting.co.za>


New submission from C?dric BRINER <briner at infomaniak.ch>:

Hi,

I'd like to add the ability to parse nfs url (rfc2224). Which look like:
nfs://server/my/path

To do this, we only need to add 'nfs' in uses_netloc to make it work

cEd

----------
components: Extension Modules
messages: 79946
nosy: yuhl
severity: normal
status: open
title: urlparse & nfs url (rfc 2224)
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4962>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:30:43 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 16 Jan 2009 10:30:43 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1232101843.96.0.152647877026.issue4927@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

That's true, but a it's a different point entirely
You see, this is not a problem with backslashes only:
If you have any kind of control caracter or high bit character in your 
filename, you may be in for trouble, because interpolating that string 
verbatim into the repr can cause uforeseen problems when it is printed 
out.

(and forward slashes are't the same as backslashes on windows.  UNC 
paths (\\my-pc\my-share\...) need backslashes.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:33:07 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 16 Jan 2009 10:33:07 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232101987.4.0.442548814463.issue4954@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is Msys+Mingw32 (running on a regular Windows) an interesting
configuration to support?
The build tools are similar to the ones used by cygwin, except that the
C runtime is msvcrt.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:35:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Jan 2009 10:35:04 +0000
Subject: [issue1672332] cPickle cannot unpickle subnormal floats on some
	machines
Message-ID: <1232102104.61.0.818836961932.issue1672332@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch, against the trunk, that simply amends load_float to ignore 
errno on underflow (while retaining it on overflow).  This fixes the problem on my machine.

The added tests may be a little severe.  There's no *good* reason why 
dumping and then loading a float on the same machine shouldn't produce 
exactly the same value, but there are likely many bad reasons.  I propose 
to checkin the change and watch the buildbots carefully;  if there are 
failures I'll weaken the tests to check for approximate equality instead 
of exact equality.

----------
keywords: +patch
Added file: http://bugs.python.org/file12762/issue1672332.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:43:08 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 16 Jan 2009 10:43:08 +0000
Subject: [issue4962] urlparse & nfs url (rfc 2224)
In-Reply-To: <1232101704.89.0.669847506906.issue4962@psf.upfronthosting.co.za>
Message-ID: <7c42eba10901160243q496a6994maf0376df2d7a98cf@mail.gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

> I'd like to add the ability to parse nfs url (rfc2224). Which look like:
> nfs://server/my/path
>
> To do this, we only need to add 'nfs' in uses_netloc to make it work

Do you encounter any errors or weird behaviors while using nfs url?
The RFC2224 for NFS just says it is for local  and network files and
in turn uses specification in RFC 1738 "Uniform Resource Locators".
So, I don't think any problem or breakage should occur with NFS

('nfs', '', '//server//a/b/c/d/e/f', '', '', '')

If you have done the research already, can you please explain what
difference will adding 'nfs' to uses_netloc do in urlparse.py.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4962>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:53:51 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 10:53:51 +0000
Subject: [issue4956] Py_Initialize needs to be done before file load (on
	msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232103231.74.0.187504011976.issue4956@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

hi gabriel, thanks for looking at this, and my apologies for not editing
the patch to remove debug and other information: i'm in the middle of a
comprehensive porting session.

WEIRD_DEBUG was me endeavouring to find out what the hell is going on

test_str.py segfaulted python under wine due to HAVE_SNPRINTF not being
defined - but that's irrelevant to this issue

likewise ignore the modification to setup.py

regarding the advice to "seek out and understand the cause", i have
to say that i much prefer to ... how can i put this best...

@BEGIN CAVEAT THE FOLLOWING STATEMENTS ARE MADE WITH ABSOLUTELY NO
INTENTION TO CAUSE OFFENSE DO NOT TAKE THIS PERSONALLY IN ANY WAY DO NOT
TAKE IT AS A DELIBERATE INTENT TO OFFEND, CAUSE OFFENSE, CRITICISE OR
OTHERWISE INDICATE MALICIOUS OR HOSTILE INTENT

being absolutely honest: i genuinely do not care about "the cause".
what i care about is "working".  "does it work if this code is moved?
yes."  "does it work if the code is not moved? no".  does it _matter_
if the "cause" is identified? no.

will someone else, possibly in the future, accidentally encounter
or deliberately and actively seek out the "cause"?

possibly.

so - many many apologies for saying this, but i have much better
and more interesting and valuable things to be doing with my time
than _finding out_ why moving specific bits of code "makes things works".

yes it would be nice to know... but i don't care!!

because, most importantly, me _knowing_ makes absolutely xxxx-all
difference to the outcome of whether "it will work" or not.

so, on balance, i'd rather spend my time finding out the additional
code-moving and code-improving required to debug the additional
bug where "python.exe -i" will give me a prompt but "python.exe" with
no arguments will not (and hangs).

@END CAVEAT

gabriel, hi,

debugging python.exe under msys under wine under linux is _really_
tricky.

* gdb.exe under msys under wine under linux not only segfaults
on exit but also refuses to fork() in order to spawn the process
to be debugged!

* strace obviously cannot be used _inside_ msys / wine

* strace _outside_ - on the /usr/bin/wine process - often interferes
with the processes it is tracking, causing them to run out of resources
and also to fail to start up.

* gdb cannot be attached from _outside_ of wine (/usr/bin/winegdb) to
an internal process.

fortunately, segfaults inside wine result in quite a good stacktrace
report, including line numbers and filenames inside python, but in
this case it's "hanging" - and there's something _really_ weird going
on with the stdin, stdout and stderr.

overall, then, the payoff in time invested in "understanding" what
is going on by using non-standard and laborious debugging techniques
is extremely small.

small enough so that, i am very very sorry to say, i'm not going to
put any further time into this _other_ than to _actually_ fix bugs,
rather than "understand" bugs.

it's a development technique that has saved me _vast_ amounts of time.

i never worry about "why" - i just "get on with it".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4956>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:55:57 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 10:55:57 +0000
Subject: [issue4956] Py_Initialize needs to be done before file load (on
	msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232103357.79.0.812250665799.issue4956@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

here's a clue:

$ ./python.exe -i
Python 2.5.2 (r252:60911, Jan 16 2009, 10:34:33) [gcc] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> exit()
close failed: [Errno 0] Success
$

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4956>
_______________________________________

From report at bugs.python.org  Fri Jan 16 11:56:45 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 10:56:45 +0000
Subject: [issue4956] Py_Initialize needs to be done before file load (on
	msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232103405.44.0.616893751247.issue4956@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

here's another clue:
$ ./python.exe 
stdin_is_interactive: 0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4956>
_______________________________________

From report at bugs.python.org  Fri Jan 16 12:59:59 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 11:59:59 +0000
Subject: [issue4956] Py_Initialize needs to be done before file load (on
	msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232107199.72.0.794549660673.issue4956@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

here's an updated version, without the cruft.
this has a workaround for the problem of stdin
being seen as not a tty (!) until _after_
Py_Initialize() is run.

Added file: http://bugs.python.org/file12763/x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4956>
_______________________________________

From report at bugs.python.org  Fri Jan 16 13:04:55 2009
From: report at bugs.python.org (S Arrowsmith)
Date: Fri, 16 Jan 2009 12:04:55 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>


New submission from S Arrowsmith <siona at chiark.greenend.org.uk>:

Asking mimetypes to reload mime.types can cause guess_extension() to
return a different result if multiple extensions are mapped to that mime
type:

>>> import mimetypes
>>> mimetypes.guess_extension('image/jpeg')
'.jpe'
>>> mimetypes.init()
>>> mimetypes.guess_extension('image/jpeg')
'.jpeg'
>>>

This is because both the forward (extension to type) and inverse (type
to extension) type mapping dicts are populated by iterating through the
existing forward (extension to type) dict (types_map), then supplemented
by reading from mime.types (or any other files given to init()). The
fully populated forward dict becomes the new types_map. Initially,
types_map is hard-coded, but when the type mapping dicts are
repopulated, by explicitly or implicitly calling init() again, it is
done by iterating over the types_map created by the first init() call,
not the hard-coded one. If the iteration order for a set of extensions
with the same type is different in these two versions of the forward
dict, the order of extensions appearing for that type in the inverse
dict will change. And so the behavior of guess_all_extensions() and
hence guess_extension() will change.

----------
components: Library (Lib)
messages: 79955
nosy: siona
severity: normal
status: open
title: mimetypes.guess_extension result changes after mimetypes.init()
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Fri Jan 16 14:32:30 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 13:32:30 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232112750.55.0.893023709753.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

martin, hi, thanks for responding.

* graminit and configure were removed because they are built
automatically.  no project should ever include auto-generated files so i
assumed that it would be reasonable to remove them from the python_2.5.2
"original" git commit that i did, in order to produce the diff.  on a
build, graminit got _replaced_ with one that had ^M after evvvvery
siiingle line.

so - if graminit and configure _are_ in the main
python source tree, it's a serious mistake that should be
rectified _immediately_.

... but i doubt that, and so graminit and configure "appearing"
to be "removed" can be ignored.

* regarding your comment that compiling python under msys under wine
is a "minority platform", i believe that that is also a serious
assumption.

the reason why it's a minority platform is because... THERE WASN'T
ANY CHOICE.

i.e. msys and wine simply have not been good enough - and certainly
not _demonstrated_ as being "good enough" - which this patch shows
that they now most definitely are - to _have_ any choice about
whether python should be compiled with purely free software tools.

instead of depending on some xxxxing proprietary piece of double-xxxx
operating system _and_ the development IDE it walked in on.

sorry about that - just to emphasise how distasteful i find it to
be _forced_ to use proprietary software, and i'm not the only
person.

basically, it should be pretty clear that now that python _can_
be compiled for win32 using an entirely free-software platform,
the proprietary build chain should be absolutely dropped like a
red-hot stone.

... but regarding "minority platform"?  that's .... really quite
funny and ironic.

it was a _non-existent_ platform until about... yesterday :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 14:42:02 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 13:42:02 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232113322.34.0.939295794043.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

hi amaury, thanks for responding.

> Is Msys+Mingw32 (running on a regular Windows) an interesting
> configuration to support?

 [wine+]msys+mingw32 is used to _build_ python - not depend on it.
 [wine+]msys+mingw32 _replaces_ the proprietary build toolchain MSVC.

 clarification:

 * in the case of #3871, msys+mingw32 replaces MSVC.
 * in the case of #4954, wine+msys+mingw32 replaces MSVC _and_ windows

 but in either case, you end up with a complete build of python.exe,
 libpython2.5.dll and modules that is perfectly well capable of
 running under both wine _and_ native windows...

 ... WITHOUT requiring, in any way shape or form,
 EITHER msys OR mingw32.

 in other words, it's a big damn deal.

 no more proprietary dependence.

 ... let me put it this way, martin: if i told richard stallman that
 you said that "msys+mingw32 was a minority platform" he'd have
 a fit!! :)


> The build tools are similar to the ones used by cygwin, except that the
> C runtime is msvcrt.

 yeeees.... sort-of - but if you do s/#ifdef __CYGWIN__/#if defined
(__CYGWIN__) || defined(__MINGW32__) it all goes _horribly_ wrong :)

 you actually have to do s/#ifdef _MSC_VER/#if defined(_MSC_VER) ||
defined(__MINGW32__) because _MSC_VER is used alll over the place
 to detect and indicate a win32 build (as separate and distinct
 from a cygwin build).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 15:12:27 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 14:12:27 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232115147.85.0.617092857537.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

updated patch - also removes quotes removal quotes of graminit and
configure so that martin is happier :)

also included is an updated version of #4956 as it's an essential
integral part of compiling and using python.exe under msys that
it actually WORK! :)

Added file: http://bugs.python.org/file12764/x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 15:12:33 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 14:12:33 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232115153.81.0.720600554028.issue4954@psf.upfronthosting.co.za>


Changes by Luke Kenneth Casson Leighton <lkcl at lkcl.net>:


Removed file: http://bugs.python.org/file12755/f

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 15:13:36 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 14:13:36 +0000
Subject: [issue4956] Py_Initialize needs to be done before file load (on
	msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232115216.4.0.0578425821677.issue4956@psf.upfronthosting.co.za>


Changes by Luke Kenneth Casson Leighton <lkcl at lkcl.net>:


Removed file: http://bugs.python.org/file12758/f

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4956>
_______________________________________

From report at bugs.python.org  Fri Jan 16 16:54:10 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 15:54:10 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1232121250.94.0.563111987397.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

roumen, hi,
i'm interested in collaborating with you to get python compiled
under wine (running msys+mingw32 under wine, on linux).
#4954 incorporates much of your work, and takes a slightly
different direction for the configure setup - the time taken to
complete configure under wine is intolerable (3 hours).
also i have found that by setting PATH=%PATH%;c:/mingw/bin in the
environment vars, the python.exe that's produced can successfully
be used to run setup.py build.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri Jan 16 17:39:42 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 16 Jan 2009 16:39:42 +0000
Subject: [issue4955] inconsistent, perhaps incorrect,
	behavior with respect to entities parsed by xml.sax
In-Reply-To: <1232058872.83.0.627723376398.issue4955@psf.upfronthosting.co.za>
Message-ID: <1232123982.17.0.0392548116598.issue4955@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

After further investigation, I've learned a bit more.  External entities
are forbidden in attribute values.  Their presence constitutes a "fatal
error" according to <http://www.w3.org/TR/REC-xml/#forbidden>.  This
means that dropping entities in an attribute value is incorrect. 
Instead the fatal error hook must be called.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4955>
_______________________________________

From report at bugs.python.org  Fri Jan 16 17:40:59 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Jan 2009 16:40:59 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1232124059.61.0.218128264298.issue4963@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.0, WinXP
import mimetypes
print(mimetypes.guess_extension('image/jpeg'))
mimetypes.init()
print(mimetypes.guess_extension('image/jpeg'))
gives
.jpe
.jpe

I wonder at this answer since .jpg and occasionally .jpeg is standard in
Windows usage, but the doc is unclear to me as to the actual intent of
the function.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Fri Jan 16 17:43:39 2009
From: report at bugs.python.org (Sebastian Ramacher)
Date: Fri, 16 Jan 2009 16:43:39 +0000
Subject: [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1232124219.76.0.645882213142.issue4949@psf.upfronthosting.co.za>


Changes by Sebastian Ramacher <sebastinas at users.sourceforge.net>:


----------
nosy: +sebastinas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4949>
_______________________________________

From report at bugs.python.org  Fri Jan 16 18:10:14 2009
From: report at bugs.python.org (Collin Winter)
Date: Fri, 16 Jan 2009 17:10:14 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232125814.03.0.194300198254.issue4941@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter, jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Fri Jan 16 18:13:21 2009
From: report at bugs.python.org (S Arrowsmith)
Date: Fri, 16 Jan 2009 17:13:21 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1232126001.03.0.335608822789.issue4963@psf.upfronthosting.co.za>


S Arrowsmith <siona at chiark.greenend.org.uk> added the comment:

Ah, yes, forgot to mention this is on Debian 4.0. I doubt you're going
to run into it on a Windows system unless you explicitly give init() a
mime.types file, looking at the knownfiles list used by default.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Fri Jan 16 18:15:26 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 16 Jan 2009 17:15:26 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1232126126.87.0.856159948536.issue4896@psf.upfronthosting.co.za>


Changes by Jeffrey Yasskin <jyasskin at gmail.com>:


----------
nosy: +collinwinter, jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Fri Jan 16 18:33:29 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 16 Jan 2009 17:33:29 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1232127209.42.0.93716124871.issue4927@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think this is my fault.  I should have used the proper repr() of the
filename in the repr() of a file object from the beginning, then this
wouldn't have been a problem.

I think we should let this rest for Python 2.x (except for fixing the
test suite).  Fortunately this is gone in 3.x for any number of reasons.

Here's my "proof" that we should let it rest.

If nobody were parsing the repr() of file objects, then we could easily
fix this.  However, the reason this was brought up in the first place is
that people *are* parsing file object repr()s.  So now fixing it would
create backwards compatibility problems.  I'd rather live with an
inconsistency (until 2.x is dead) than introduce more backwards
incompatibility into 2.7.

----------
nosy: +gvanrossum
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 18:43:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 17:43:33 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1232097043.24.0.143029653462.issue4927@psf.upfronthosting.co.za>
Message-ID: <4970C742.2070200@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So you are saying that you see no problem with the repr of a fileobject 
> being generated in different ways depending on the fileobject being 
> unicode or string?

My question is: What is the issue at hand? Is it what the subject says
(inconsistent representation), or is it what your first message says
(problems on Vista)? If the former, I'm opposed to fixing it. If the
latter, I'm in favor of the straight-forward fix to the test suite.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 18:44:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 17:44:28 +0000
Subject: [issue4927] Inconsistent unicode repr for fileobject
In-Reply-To: <1232097172.45.0.283290428679.issue4927@psf.upfronthosting.co.za>
Message-ID: <4970C77A.3070206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It is therefore quite unlikely to cause any 
> problems.

That is a false conclusion. The test suite cannot speak
for all the code out there that might break with the
incompatible change that you are proposing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4927>
_______________________________________

From report at bugs.python.org  Fri Jan 16 18:54:31 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 17:54:31 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232101987.4.0.442548814463.issue4954@psf.upfronthosting.co.za>
Message-ID: <4970C9D4.70907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is Msys+Mingw32 (running on a regular Windows) an interesting
> configuration to support?

It is certainly desirable to be able to build extension modules
with this configuration; AFAIU, distutils already supports that
case. Whether or not it is desirable to be build Python from
source in this configuration, I don't know - most people that
want to build with mingw seem to be using the Python binaries
available from python.org, or from ActiveState. I'm not sure
whether mingw is capable of building Python correctly, with
assembly manifests and all.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 19:01:44 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 18:01:44 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232112750.55.0.893023709753.issue4954@psf.upfronthosting.co.za>
Message-ID: <4970CB85.4060000@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> * graminit and configure were removed because they are built
> automatically.  no project should ever include auto-generated files so i
> assumed that it would be reasonable to remove them from the python_2.5.2
> "original" git commit that i did, in order to produce the diff.

Please trust that Python puts generated files into the repository for
good reasons. This is not going to change, regardless of how evil you
consider it.

> ... but regarding "minority platform"?  that's .... really quite
> funny and ironic.
> 
> it was a _non-existent_ platform until about... yesterday :)

Ok, so feel free to continue to work on it; good luck with
that project. If the project is still alive in a few years
from now, and enjoys a significant user base, we should reconsider
accepting patches.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 19:04:52 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 18:04:52 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232113322.34.0.939295794043.issue4954@psf.upfronthosting.co.za>
Message-ID: <4970CC41.8010208@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>  no more proprietary dependence.

So what CRT do you link with? Is it msvcrt? Which version?

If building with mingw becomes wide-spread, care must
be taken that it uses the same CRT as the official binaries.
Otherwise, it will be a desaster for Python.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 19:09:53 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 18:09:53 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232129393.19.0.0321294767265.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> Please trust that Python puts generated files into the repository for
> good reasons. 

 i can respect that :)  for no reason other than if somone says
 "please trust", i do :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 19:23:53 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 18:23:53 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232130233.43.0.121263576432.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> So what CRT do you link with? Is it msvcrt? Which version?

i was _just_ beginning to wonder about that, after i saw
rpetrov's comments about MSCVER stuff.

http://www.mingw.org/wiki/SpecsFileHOWTO

aww, _frick_. :)

well... it's _going_ to be msvcr80.  why don't mingw ship with
a pre-prepared msvcr80 specfile??

*sigh*.

will get back to you on that one - it may make a difference on
the regression tests (250 passed, 12 failed, 8 skpped).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 19:33:45 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 18:33:45 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232130825.76.0.988134812102.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> It is certainly desirable to be able to build extension modules
> with this configuration;

 yeah, and the nice thing is - it works, too! :)

> AFAIU, distutils already supports that case.

 not without modification, it doesn't: #3871 adds "proper"
 mingw32 compiler detection and link options, such as support
 for dll.a which isn't auto-detected (but is on cygwin)

 etc. etc.

> Whether or not it is desirable to be build Python from
> source in this configuration, I don't know - most people that
> want to build with mingw seem to be using the Python binaries
> available from python.org, or from ActiveState.

 i tried that a few months ago.

 1) there is no .tgz for python-win32 so i was forced to
   install from a binary package

 2) there is no .exe so i was forced to install from msi,
   a proprietary installer - which as a free software
   developer, i have issues with, but i tried it anyway.

 3) msi installed, thanks to winetricks, but segfaulted
    and borked.  as i didn't really want to use it, i
    wasn't that unhappy.

 4) the msi turns out to be understood by the free software
    cabextract package.  but... the filenames are all borked
    and mangled.

 at that point, i decided i'd had enough: i wasn't going to
 go through 100 files looking for the one that _might_ be
 the python25.lib implib, plus other files that i'd need
 to do a non-proprietary-dependent build of python software.

> I'm not sure
> whether mingw is capable of building Python correctly, with
> assembly manifests and all.

 python setup.py build seems quite happy: rpetrov added .S
 to the compile-extensions and happily compiled win32.S
 in libffi with it.

 the only slight issue there is that the assembly file
 is incompatible with MSVC and so it borked (not at build
 time, unfortunately - at runtime).

 there's been a gcc bugreport raised, to get interoperability
 back (urk).

 GCC issue #36834.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 19:36:01 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 18:36:01 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232130961.96.0.428345160224.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

yaay!  here's the regression test log, including some
loovely wine segfaults :)

summary:

250 tests OK.

12 tests failed:
    test_builtin test_cpickle test_file test_gzip test_locale
    test_mailbox test_os test_pep277 test_socket test_unicode_file
    test_xpickle test_zipfile
60 tests skipped:
 ....
 ....
 ....
8 skips unexpected on win32:
    test_bz2 test_cProfile test_bsddb test_profile test_tcl
    test_sundry test_sqlite test_winsound

not baaad :)

Added file: http://bugs.python.org/file12765/regressiontest.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 19:40:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Jan 2009 18:40:42 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1232131242.97.0.596060491901.issue4910@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+1 for applying the last patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Fri Jan 16 20:30:29 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 19:30:29 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232130825.76.0.988134812102.issue4954@psf.upfronthosting.co.za>
Message-ID: <4970E052.5070208@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>  2) there is no .exe so i was forced to install from msi,
>    a proprietary installer - which as a free software
>    developer, i have issues with, but i tried it anyway.

Please understand that MSI is *not* a proprietary installer.
Instead, it is just a data format to be interpreted by the
installer. Whether that installer is proprietary or not
depends on whether you use the Microsoft one, or write one
yourself (or perhaps use a free interpreter for MSI that
somebody else might have written).

So to help Wine, it would be best to write a proper MSI
interpreter.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 21:44:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Jan 2009 20:44:09 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1232138649.59.0.572727961014.issue4293@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Kristj?n,

The r68461 checkin seems to be causing a number of the buildbots to fail,
typically with output like:

test_capi
test test_capi failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/test/test_capi.py", line 57, in 
test_pendingcalls_threaded
    self.pendingcalls_wait(l, n)
  File "/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/test/test_capi.py", line 42, in 
pendingcalls_wait
    "timeout waiting for %i callbacks, got %i"%(n, len(l)))
AssertionError: timeout waiting for 32 callbacks, got 23

Please could you look into this?


Also, I don't understand the code:

for i in xrange(1000):
    a = i*i

in pendingcalls_wait(), in test_capi.py.  Whatever you're
trying to do here, surely there's a better way?

----------
nosy: +marketdickinson
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Fri Jan 16 22:26:10 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 16 Jan 2009 21:26:10 +0000
Subject: [issue4964] UTF-16 stream codec barfs on valid input
In-Reply-To: <1232141169.6.0.562983030124.issue4964@psf.upfronthosting.co.za>
Message-ID: <1232141169.6.0.562983030124.issue4964@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

I am attaching a file encoded in UTF-16 (with bom) which causes the
stream codec employed by the file reader to barf when reading by lines.
 However reading the file in binary mode and decoding it in one fell
swoop works fine, and reading the whole text file with text() also works
fine; so I believe the data in the file is not corrupt (it started out
as an export of my Gmail contacts, but I x-ed out all printable ASCII
characters).

>>> x = open('contacts.csv', 'rb').read().decode('utf16')  # OK
>>> x = open('contacts.csv', encoding='utf16').read()  # OK
>>> x = open('contacts.csv', encoding='utf16').readlines()  # Dies
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/io.py", line 534, in readlines
    return list(self)
  File "/usr/local/lib/python3.0/io.py", line 1739, in __next__
    line = self.readline()
  File "/usr/local/lib/python3.0/io.py", line 1813, in readline
    while self._read_chunk():
  File "/usr/local/lib/python3.0/io.py", line 1562, in _read_chunk
    self._set_decoded_chars(self._decoder.decode(input_chunk, eof))
  File "/usr/local/lib/python3.0/io.py", line 1295, in decode
    output = self.decoder.decode(input, final=final)
  File "/usr/local/lib/python3.0/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
  File "/usr/local/lib/python3.0/encodings/utf_16.py", line 69, in
_buffer_decode
    return self.decoder(input, self.errors, final)
UnicodeDecodeError: 'utf16' codec can't decode byte 0x00 in position 0:
truncated data
>>>

Making certain modifications to the file elicits slightly different
error messages (e.g. "'utf16' codec can't decode bytes in position
90-91: illegal encoding" when I swap the second and first half of the
file) so it looks like some kind of data corruption in the codec's state
management or in the code in io.py that feeds the codec its data.

----------
components: Library (Lib)
files: contacts.csv
messages: 79976
nosy: gvanrossum
priority: critical
severity: normal
status: open
title: UTF-16 stream codec barfs on valid input
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12766/contacts.csv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4964>
_______________________________________

From report at bugs.python.org  Fri Jan 16 22:35:14 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 16 Jan 2009 21:35:14 +0000
Subject: [issue4964] UTF-16 stream codec barfs on valid input
In-Reply-To: <1232141169.6.0.562983030124.issue4964@psf.upfronthosting.co.za>
Message-ID: <1232141714.0.0.707197587771.issue4964@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Dang. Already fixed in trunk. (Is it fixed in 3.0.1 too?)

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4964>
_______________________________________

From report at bugs.python.org  Fri Jan 16 22:39:50 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 16 Jan 2009 21:39:50 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232141990.42.0.141397743189.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

http://www.winehq.org/pipermail/wine-users/2006-May/021624.html

_drat_.

a rebuild of wine, adding a workaround to cope with lack of
support for msvcrt80 xml-based process files, is required,
commenting out a couple of functions from kernel32!

euuw :)

so - that's going to delay things somewhat.  i'll test with
msvcr71, anyway, for the time-being, see if that is any
better than msvcrt (default).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 22:57:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 16 Jan 2009 21:57:28 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232143048.77.0.458777100231.issue4954@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm rejecting this patch for the moment, as it seems far from being
ready yet. If you consider it complete and applicable-as-is (i.e. if you
can't think of any possible further improvement to the patch), please
submit a new issue. If I had to review the patch "x", I would reject it
for many reasons, e.g. because it is not against the trunk, and because
it removes graminit.h.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Fri Jan 16 22:59:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Jan 2009 21:59:32 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1232143172.42.0.0476472694876.issue4753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch with a dedicated configure option
(--with-computed-gotos, disabled by default), rather than a compiler
detection switch.

(sorry, the patch is very long because it seems running autoconf changes
a lot of things in the configure script)

Added file: http://bugs.python.org/file12767/threadedceval6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan 16 23:09:00 2009
From: report at bugs.python.org (oopos)
Date: Fri, 16 Jan 2009 22:09:00 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232143740.43.0.753453177062.issue4953@psf.upfronthosting.co.za>


oopos <myoopos at gmail.com> added the comment:

Hehe.
I only want to use python to slove the upload files instead of PHP.but
it is hard to me or I have no much time to leran it.
Now,I learn Perl quickly and use it upload files, it works ok.

Thank you . I will take more time to learn Python language well.
Best Regards!

This is my code: (Perl Language)

Added file: http://bugs.python.org/file12768/opsuper.pl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 16 23:31:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Jan 2009 22:31:53 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1232145113.02.0.165509052206.issue4293@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

How about using a timer instead of the 'count += 1' loop:  after starting 
the 32 self.pendingcalls_submit threads, set up a threading.Event and 
start yet another thread that simply does a time.sleep(5.0) (or whatever) 
and then sets that event.

Then your waiting loop could be something like:

while not self.my_event.is_set():
    for i in range(1000):
        a = i*i
self.assertEqual(len(l), n)

There's probably a better way, but that's the best I can come up with this 
late on a Friday night...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Sat Jan 17 00:02:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Jan 2009 23:02:36 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232146956.14.0.886369296459.issue4941@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You could also test this principle with a few opcodes in ceval.c.
Especially, the error cases in LOAD_FAST, LOAD_GLOBAL etc. could be
flagged as unlikely.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Sat Jan 17 00:02:37 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 16 Jan 2009 23:02:37 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1232143172.42.0.0476472694876.issue4753@psf.upfronthosting.co.za>
Message-ID: <18801.4616.552114.873762@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> (sorry, the patch is very long because it seems running
    Antoine> autoconf changes a lot of things in the configure script)

Normal practice is to not include the configure script in such patches and
indicate to people that they will need to run autoconf.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 17 00:08:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Jan 2009 23:08:43 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1232147323.29.0.256449948051.issue4753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks Skip, it makes sense... so here is a patch without the configure
script.

(I wonder however if those huge configure changes, when checked into the
SVN, could break something silently somewhere)

Added file: http://bugs.python.org/file12769/threadedceval6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 17 00:08:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Jan 2009 23:08:57 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1232147337.97.0.831139487565.issue4753@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12767/threadedceval6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 17 00:30:33 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Jan 2009 23:30:33 +0000
Subject: [issue4965] Can doc index of html version be separately scrollable?
In-Reply-To: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za>
Message-ID: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In the Windows help version of the docs that come with the Windows .msi
installer, the index pane to the left scrolls separately from the
content pane to the right.  Very nice for jumping around even to other docs.

In the html versions at docs.python.org, there is one scroll bar and the
index disappears when one moves very far down the page.  If sensibly
possible, decoupling index and context would be nice.  Please pardon my
ignorance if not.

----------
assignee: georg.brandl
components: Documentation
messages: 79986
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Can doc index of html version be separately scrollable?
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4965>
_______________________________________

From report at bugs.python.org  Sat Jan 17 00:41:45 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Fri, 16 Jan 2009 23:41:45 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232149305.46.0.339435636102.issue4941@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

Yep, agreed. It could be quite cool to rely on __attribute__((cold)) to
mark format_exc_check_arg(), but that only works with newer gcc's. I
guess I'll add many likely() by hand - in some cases GCC might already
get it right, but the heuristics used to choose the likely path
statically are quite arguable and subject to change. Also, on other
archs such hints might have a bigger impact on the generated code.

I'll give a look at that not earlier than February, or you're welcome to
try this. However, at least on x86, an "if (successCondition) {
success(); dispatch(); } failure();" will be probably compiled to
assembly like follows, equivalent to adding likely to the test:

evaluate successCondition
if_false goto err:
call to success();
dispatch next instrutions.

err:
call to failure();

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Sat Jan 17 00:43:38 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Jan 2009 23:43:38 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Issues and suggestions for Python Standard Library / Built-in Types /
"Sequence Types ? str, bytes, bytearray, list, tuple, range"

1. Put subsections in the same order as in the title and main section. 
In particular, move bytes/bytearray subsection up to follow string
subsection and move range subsection down to bottom of this grouping.

2. String paragraph (the second) ends with the rather wordy sentence
"In addition to the functionality described here, there are also
string-specific methods described in the String Methods section."
where 'String Methods' is a forward link to that subsection.
Add similar possibly less wordy sentence-links for other types.

In particular, end next (byte/bytearray) paragraph with something like
"For specific methods, see String Methods and Bytes and Byte Array
Methods. For bytearrays, also see Mutable Sequence Types."

End the list/tuple paragraph after the Warning with
"For list methods, see Mutable Sequence Types."

After the following range paragraph, the following could be added:
"For more, see Range Type."
However, there is almost nothing more said (perhaps there was before
range objects were stripped down), so I suggest deleting that subsection
and adding anything more that is not duplication to the end of the
beginning section's range paragraph.  If tuples do not need their own
section, range needs one even less.

3. Bytes and Byte Array Method subsection correctly says that bytes and
bytearrays do not have (senseless) .encode but neglects to document the
corresponding inverse .decode method (while it does mention the
specialized .fromhex decoding method).

Also add .isdecimal, .isnumeric, .isprintable, and .maketrans to the
list of exceptions in the first sentence. (Based on dir(str), dir(bytes)
in 3.0)

4. I see three problems with the current documentation of count and
index methods.
a)  They are documented under both String Methods and Mutable Sequences.
 They do not really belong in the latter, which lists "additional
operations that allow in-place modification of the object", because they
do not mutate.
b) Tuples do not have their own a section, but (unlike range objects) do
have a couple of methods: count and index.  Being neither string-like
nor mutable, their having methods is undocumented.
c) Bytearrays, on the other hand, are both string-like and mutable.  So
they are (mis)documented as having two slightly different versions of
these methods. (They actually use the string-like definition, of course.)

Consequently, the definitions of count and index in the Mutable Sequence
subsection are not mutable sequence definitions but are really
list/tuple definitions.  So I suggest one of two variations:
A) In the main section, add the list/tuple version of .count() and
.index() to the table of common sequence operations with a footnote
either explaining the difference for the string group or referring to
String Methods.
B) In the main section, add both versions to the table with footnotes
explaining which is which.

The count/index/tuple doc issue has come up more than once on c.l.p.

----------
assignee: georg.brandl
components: Documentation
messages: 79988
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Improving Lib Doc Sequence Types Section
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4966>
_______________________________________

From report at bugs.python.org  Sat Jan 17 00:47:55 2009
From: report at bugs.python.org (Collin Winter)
Date: Fri, 16 Jan 2009 23:47:55 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1232149675.23.0.983621970989.issue4896@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Another data point: I've tested this patch applied to trunk on Core 2
Duo and Opteron 8214 HE machines using both gcc 4.0.3 and 4.3.1, and I'm
seeing mixed results. Pybench with warp 1 is between ~1.5% slower and
~1% faster, depending on gcc version (fairly consistent across
machines). 2to3 and two template systems I've tested are between 2.5%
slower and 2% faster depending on workload and gcc version.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Sat Jan 17 01:16:45 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Sat, 17 Jan 2009 00:16:45 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1232151405.76.0.556519707098.issue4896@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

Given a 10% speedup on some systems, and statistically insignificant
changes on other systems, I would still apply the patch, even simply
because the bitmask part simply makes more sense.

I'm not sure about the goto part, but still, it does straighten the
code. Anyway, simply call the label "why_is_WHY_NOT",
"why_set_to_WHY_NOT" or something like that. Verbosity on a use-once
label used with goto should be encouraged - we're not Java programmer,
but we need to pay for using goto by increasing readability in other ways.

@collinwinter: since the differences you report are so low (similar to
the statistical noise I get on my machine), I would expect that you're
just getting statistical noise instead of different results depending on
the GCC version, unless you performed statistical hypothesis testing
(confidence intervals and related stuff). And if I had done the needed
tens/hundreds of repetitions for hypothesis testing, I'd state that
clearly, so I suppose you didn't, and that's fully acceptable since the
result is likely to be statistically insignificant anyway.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Sat Jan 17 02:31:43 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 01:31:43 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232155903.52.0.859568103921.issue4874@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch:
 - Leave unicode_escape_decode() and raw_unicode_escape_decode() 
unchanged (still accept unicode string)
 - Test changes (reject unicode for most codecs decode functions)
 - Write tests for unicode_escape_decode() and 
raw_unicode_escape_decode() (there was no test for these functions)

Added file: http://bugs.python.org/file12770/_codecs_bytes-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Sat Jan 17 02:31:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 01:31:48 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232155908.5.0.156053931776.issue4874@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12641/_codecs_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Sat Jan 17 02:40:39 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 01:40:39 +0000
Subject: [issue4177] Crash in MIMEText on FreeBSD
In-Reply-To: <1224700839.13.0.201844476382.issue4177@psf.upfronthosting.co.za>
Message-ID: <1232156439.2.0.947333183125.issue4177@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4177>
_______________________________________

From report at bugs.python.org  Sat Jan 17 02:55:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 01:55:25 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1232157325.27.0.557450081897.issue4626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of my patch: add a regression test.

@brett.cannon: Could you review my patch?

Added file: http://bugs.python.org/file12771/tokenizer_ignore_cookie-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Sat Jan 17 02:55:29 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 01:55:29 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1232157329.96.0.677914216482.issue4626@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12589/tokenizer_ignore_cookie-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Sat Jan 17 03:02:20 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 02:02:20 +0000
Subject: [issue3826] Problem with SocketIO for closing the socket
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1232157740.33.0.129575582765.issue3826@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This still needs back porting to release30-maint 
> assuming no other issues are found with it

How can we check if they are new issues with the changes?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Jan 17 03:08:14 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 17 Jan 2009 02:08:14 +0000
Subject: [issue3826] Problem with SocketIO for closing the socket
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1232158094.81.0.0400466227007.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

That mostly meant let the buildbots run it and/or see if anyone 
complains on a list.  Go ahead and backport. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sat Jan 17 03:20:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 02:20:47 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1232158847.59.0.281992730118.issue4821@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

sha1module_small_locks.diff patch is very similar to the changes made 
in #4751, except:
 - SHA1_GIL_MINSIZE is 8192 whereas HASHLIB_GIL_MINSIZE is 2048
 - There is no test for PyThread_allocate_lock() failure

Instead of copy/paste code in hashlib, sha1, sha256 and sha512 (4 
modules), can't we share some constants, functions or macros? 
Examples:
 - the GIL minimum size constant
 - the long MY_GET_BUFFER_VIEW_OR_ERROUT macro (which can be a 
function)

And about sha, why using 3 files for sha? Are the source code so 
different? In the GNU libc, they use "template" files (it's possible 
even with the C language using the preprocessor!): strtof(), strtod() 
and strtold() share 99% of the source code. Interesting content of 
strtof.c :
----
#define	FLOAT		float
#define	FLT		FLT
#ifdef USE_WIDE_CHAR
#define STRTOF		wcstof
#define STRTOF_L	__wcstof_l
#else
# define STRTOF		strtof
# define STRTOF_L	__strtof_l
#endif

#include "strtod.c"
----

Refactoring to share code between hash modules will ease the changes, 
eg. release the GIL ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Sat Jan 17 03:36:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Jan 2009 02:36:52 +0000
Subject: [issue4967] Bugs in _ssl object read() when a buffer is specified
In-Reply-To: <1232159812.52.0.781690409094.issue4967@psf.upfronthosting.co.za>
Message-ID: <1232159812.52.0.781690409094.issue4967@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The read() method on ssl objects can take a buffer as a parameter, but
the method is buggy in this case:

- it only accepts bytearrays, while it should accept any object
supporting the buffer protocol in write mode
- when the object is not a bytearray, it returns NULL without setting
the current exception
- since it doesn't attempt to get a buffer export from the object, there
is no protection and the buffer could be resized while the method
releases the GIL, leading to a likely crash

This patch solves all three issues. Note that I'm not able to write an
unit test for it, because test_ssl.py is too high-level (it looks more
like functional tests than unit tests). Also, the only reason I
discovered this is that it made some tests fail on the io-in-C branch
(which uses readinto() a lot). I'm a complete SSL newbie.

----------
assignee: janssen
components: Extension Modules
files: ssl-readbuffer.patch
keywords: patch
messages: 79996
nosy: janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Bugs in _ssl object read() when a buffer is specified
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12772/ssl-readbuffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4967>
_______________________________________

From report at bugs.python.org  Sat Jan 17 03:37:17 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Jan 2009 02:37:17 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1232159837.47.0.845104231919.issue4626@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I will see when I can get to it (other stuff is taking priority). Not
going to assign to myself quite yet in case someone wants to beat me to
this. I won't lose track since I created the bug and have a saved query
to look at all bugs I make.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Sat Jan 17 04:25:22 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 17 Jan 2009 03:25:22 +0000
Subject: [issue4956] Py_Initialize needs to be done before file load (on
	msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232162722.51.0.841743565582.issue4956@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Ok, imagine for a moment that your patch is accepted and applied. 
Python runs in a wide variety of systems. Now imagine that, in a few of 
them, it stops running. What would you say to defend your changes? "I 
have no idea why, but it works for me!". I have no doubt your changes 
would be reverted in two nanoseconds, and your chances of getting a 
second patch accepted would drop near zero.

I understand your project and hope you successfully complete your 
goals, but it seems it's not madure enough yet. At this stage, blogging 
about your progresses and writing some sort of recipe would be more 
adequate, until you get a system that builds cleanly and passes most 
(if not all) test cases. This applies to your other pending patches too.

PS: I don't know the English term, but here in Argentina (Spanish) the 
way you "fix" bugs would be called "chapuza". No offense intended.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4956>
_______________________________________

From report at bugs.python.org  Sat Jan 17 04:26:09 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Jan 2009 03:26:09 +0000
Subject: [issue4968] Clarify inspect.is<callable> method docs
In-Reply-To: <1232162769.03.0.624026715862.issue4968@psf.upfronthosting.co.za>
Message-ID: <1232162769.03.0.624026715862.issue4968@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

inspect module in 3.0

.isclass: says "Return true if the object is a class." Since the issue
of builtin versus Python coded is involved in all the other methods
below, I would expand this to
"Return true if the object is a class, whether built-in or Python-coded."
to emphasize that this is not an issue for this one.

.isfunction: current "Return true if the object is a Python function or
unnamed (lambda) function." falsely implies that there is such a thing
as 'unnamed (lambda) function; different from 'Python function'.  By
test, it just returns True for 'function' objects. Suggestion:

"Return true for Python-coded functions, including unbound Python-coded
methods." or possibly
"Return true for functions created by def statements and lambda
expressions, including unbound Python-coded methods.

.ismethod: "Return true if the object is a method." should be specified
to something like
"Return true if the object is a bound method written in Python."

.isbuiltin: says "Return true if the object is a built-in function."
but actually tests for membership in class 'builtin_function_or_method'.
 I believe that truth is
"Return true if the object is a built-in function (but not a class) or a
bound built-in non-special method."
It is True, for instance, for [].append but not [].__hash__.  I am
assuming that this behavior is intended and not a bug.

.ismethoddescriptor: "Return true if the object is a method descriptor,
but not if ismethod() or isclass() or isfunction() are true." begs the
question of what a method descriptor is.  I believe the following is
both true and clearer.
"Return true if the object is a built-in method and isbuiltin() is false.

I would follow with
"The methods isclass, isfunction, ismethod, isbuiltin, and
ismethoddescriptor are mutually exclusive."
I believe the following is true, and could be added also.
"Exact one is true for any instance of a built-in callable class."

----------
assignee: georg.brandl
components: Documentation
messages: 79999
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Clarify inspect.is<callable> method docs
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4968>
_______________________________________

From report at bugs.python.org  Sat Jan 17 04:40:53 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 17 Jan 2009 03:40:53 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232163653.3.0.642636152405.issue4953@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

You should stick to Python 2.6 (or even 2.5) for web programming - 3.0 
is not mature enough. I thought this was a feasibility study on porting 
an existing application to Python 3.0 -- not your first steps in the 
language.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Sat Jan 17 04:58:34 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 03:58:34 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232164714.19.0.147708777513.issue4474@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch fixing PyUnicode_FromWideChar() for UCS-2 build: create 
surrogates for character > U+FFFF like PyUnicode_FromOrdinal() does.

----------
keywords: +patch
Added file: http://bugs.python.org/file12773/unicode_fromwidechar_surrogate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 05:00:34 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 04:00:34 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232164834.46.0.229724864068.issue4474@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: I wrote my patch against py3k r68646.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 05:15:17 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Jan 2009 04:15:17 +0000
Subject: [issue4959] inspect.formatargspec fails for keyword args without
	defaults, affects help and likely pydoc
In-Reply-To: <1232085201.15.0.206392471567.issue4959@psf.upfronthosting.co.za>
Message-ID: <1232165717.34.0.896342516328.issue4959@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Fixed in r68647.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4959>
_______________________________________

From report at bugs.python.org  Sat Jan 17 08:33:18 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Jan 2009 07:33:18 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1232177598.76.0.922426612141.issue4907@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I assume from the discussion that the patch was accepted/committed and
changed the resolution and stage field to match.

FWIW, list displays, for instance, are not literals either but are
successfully evaluated, so doing same for complex 'displays' seems
sensible to me too, and in line with the purpose of the method.

----------
nosy: +tjreedy
resolution:  -> accepted
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Sat Jan 17 08:44:58 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Jan 2009 07:44:58 +0000
Subject: [issue4914] trunc(x) erroneously documented as built-in
In-Reply-To: <1231652236.88.0.715538324364.issue4914@psf.upfronthosting.co.za>
Message-ID: <1232178298.11.0.921398484479.issue4914@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Confirmed for 3.0 that trunc does not exist in the builtins module and
is not listed in the Built-in functions section but is listed in the
Numeric Types section.  So I agree "trunc(x) x truncated to Integral "
should leave the Operation table.

Yes, MM, we do want to clean up such discrepancies.

trunc is in the math module and is listed in its doc.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4914>
_______________________________________

From report at bugs.python.org  Sat Jan 17 09:00:44 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Jan 2009 08:00:44 +0000
Subject: [issue4955] inconsistent, perhaps incorrect,
	behavior with respect to entities parsed by xml.sax
In-Reply-To: <1232058872.83.0.627723376398.issue4955@psf.upfronthosting.co.za>
Message-ID: <1232179244.23.0.489376608078.issue4955@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Neither the title nor your two posts identify the module you think needs
to be changed.  Changing the title to include that might better get
attention from someone who is familiar with that module and could deal
with the request.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4955>
_______________________________________

From report at bugs.python.org  Sat Jan 17 09:58:42 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 17 Jan 2009 08:58:42 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

The mimetypes module has a built-in default database, and, in addition, 
reads mime.types files from a list of standard places (/etc/mime.types 
by example)
On Windows, those files usually don't even present; MIME information is 
stored in the registry instead. Until now, the mimetypes module just 
ignored those settings; this patch adds support for reading the MIME 
database from the Windows registry.

----------
components: Library (Lib)
files: mimetypes.diff
keywords: patch
messages: 80007
nosy: gagenellina
severity: normal
status: open
title: mimetypes on Windows should read MIME database from registry (w/patch)
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12774/mimetypes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4969>
_______________________________________

From report at bugs.python.org  Sat Jan 17 10:41:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 09:41:47 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232185307.82.0.703488893991.issue4474@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch, Victor!

Looks pretty good at first glance, except that it seems that the UTF-32 to 
UTF-16 translation is skipped if HAVE_USABLE_WCHAR_T is defined.  Is that 
deliberate?

A test would be good, too.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 10:51:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 09:51:07 +0000
Subject: [issue4969] mimetypes on Windows should read MIME database from
	registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1232185867.91.0.165482359514.issue4969@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4969>
_______________________________________

From report at bugs.python.org  Sat Jan 17 12:09:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 11:09:45 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The x86 gentoo 3.0 and 3.x buildbots have been failing for a while at the test stage, with:

make: *** [buildbottest] Unknown signal 32
program finished with exit code 2

I noticed a common denominator with these failures, which is that they always seem to occur a few tests after 
test_os has been run.  So it looks as though something in test_os is causing this.

Can anyone reproduce this (I can't on any of the machines I have access to), and (e.g., by trial and error) identify 
which of the test_os tests is causing this?

----------
messages: 80009
nosy: marketdickinson
severity: normal
status: open
title: test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Sat Jan 17 12:43:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 11:43:37 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1232192617.44.0.681571319483.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Another observation is that after test_os has been run, the first test to 
actually cause the 'unknown signal' failure always seems to be one that 
involves threads (e.g., test_wait3, or test_queue, or test_logging...)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Sat Jan 17 13:24:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 12:24:26 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1232195066.28.0.590955305576.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

...and there's a related message from Neal Norwitz at:

http://mail.python.org/pipermail/python-3000/2007-August/009944.html

I suspect that

python Lib/test/regrtest.py test_os test_wait3

(possibly with some additional flags to regrtest.py) should
be enough to reliably reproduce the failure.

Neal, does this help to identify the problem at all?  Any suggestions 
about how to go about debugging this?

----------
nosy: +nnorwitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Sat Jan 17 14:00:03 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 13:00:03 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1232185307.82.0.703488893991.issue4474@psf.upfronthosting.co.za>
Message-ID: <200901171359.55129.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Looks pretty good at first glance, except that it seems that the UTF-32 to
> UTF-16 translation is skipped if HAVE_USABLE_WCHAR_T is defined.  Is that
> deliberate?

#ifdef HAVE_USABLE_WCHAR_T
    memcpy(unicode->str, w, size * sizeof(wchar_t));
#else
    ...
#endif

I understand this code as: sizeof(wchar_t) == sizeof(Py_UNICODE). If I 
misunderstood the code, it's a a heap overflow :-) So there is no not 
conversion from UTF-32 to UTF-16 using memcpy if HAVE_USABLE_WCHAR_T is 
defined, right?

> A test would be good, too.

PyUnicode_FromWideChar() is not a public API. Should I write a function in 
_testcapi?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 14:18:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 13:18:36 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232198316.49.0.939076812541.issue4474@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I understand this code as: sizeof(wchar_t) == sizeof(Py_UNICODE). If I 
> misunderstood the code, it's a a heap overflow :-)

Yep, sorry.  You're right.

>> A test would be good, too.
>
>PyUnicode_FromWideChar() is not a public API. Should I write a function 
>in _testcapi?

I was actually thinking of a test for the "No such file or directory" 
bug that's mentioned at the start of the discussion.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 14:36:29 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 13:36:29 +0000
Subject: [issue4828] patch suggestion for webbrowser
In-Reply-To: <1231063999.69.0.0846570539702.issue4828@psf.upfronthosting.co.za>
Message-ID: <1232199389.06.0.405203959807.issue4828@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I was to suggest to use the PATHEXT variable instead of a hardcoded list of extensions, 
but does all this work at all?

For example, I added a "opera.bat" in my current directory.
a browser named 'opera' was registered, but it did not start!

>>> webbrowser.get('opera').open('http://www.google.com')
False

And indeed, the subprocess module does not start .bat files unless "shell=True" is given.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4828>
_______________________________________

From report at bugs.python.org  Sat Jan 17 15:04:04 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 14:04:04 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1232201044.58.0.475366498107.issue3997@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is an updated version (zip-64k-3.patch).
Now the condition for writing a "ZIP64 end-of-archive" depends on the 
size of all three values.

Added file: http://bugs.python.org/file12775/zip-64k-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sat Jan 17 15:17:47 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 14:17:47 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1232201867.42.0.9681371058.issue3997@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looks fine to me. Please apply.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sat Jan 17 15:47:58 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 17 Jan 2009 14:47:58 +0000
Subject: [issue4967] Bugs in _ssl object read() when a buffer is specified
In-Reply-To: <1232159812.52.0.781690409094.issue4967@psf.upfronthosting.co.za>
Message-ID: <1232203678.3.0.959995454394.issue4967@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4967>
_______________________________________

From report at bugs.python.org  Sat Jan 17 16:12:54 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 17 Jan 2009 15:12:54 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <200901171359.55129.victor.stinner@haypocalc.com>
Message-ID: <4971F574.7050205@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-17 14:00, STINNER Victor wrote:
>> A test would be good, too.
> 
> PyUnicode_FromWideChar() is not a public API. Should I write a function in 
> _testcapi?

It is a public C API. Regardless of this aspect, we should always
add tests for bugs in order to make sure they don't pop up again.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 16:19:15 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 17 Jan 2009 15:19:15 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <200901171359.55129.victor.stinner@haypocalc.com>
Message-ID: <4971F6F1.4080001@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-17 14:00, STINNER Victor wrote:
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> Looks pretty good at first glance, except that it seems that the UTF-32 to
>> UTF-16 translation is skipped if HAVE_USABLE_WCHAR_T is defined.  Is that
>> deliberate?
> 
> #ifdef HAVE_USABLE_WCHAR_T
>     memcpy(unicode->str, w, size * sizeof(wchar_t));
> #else
>     ...
> #endif
> 
> I understand this code as: sizeof(wchar_t) == sizeof(Py_UNICODE). If I 
> misunderstood the code, it's a a heap overflow :-) So there is no not 
> conversion from UTF-32 to UTF-16 using memcpy if HAVE_USABLE_WCHAR_T is 
> defined, right?

If HAVE_USABLE_WCHAR_T is defined, Py_UNICODE is defined as wchar_t,
so a memcpy can be used. Note that this does not provide any information
about sizeof(wchar_t), e.g. with GLIBC, wchar_t is 4 bytes. MS C lib defines
it as 2 bytes.

That said, if Py_UNICODE is the same as wchar_t, no conversion is
necessary and that's why the function simply copies over the data.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 16:25:00 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 17 Jan 2009 15:25:00 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1232205900.19.0.435849973508.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Hi Luke,
Initially I start build in cross environment. Later I setup a posix
environment, based on msys and in the last patch is commented which
module has to be build-in for native build.

I'm not surprised that you succeed to build in emulated environment and
I know that born shell work slow in this environment.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Jan 17 16:42:31 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 17 Jan 2009 15:42:31 +0000
Subject: [issue4955] xml.sax.expatreader.ExpatParser incorrectly silently
	skips external character entities in attribute values
In-Reply-To: <1232058872.83.0.627723376398.issue4955@psf.upfronthosting.co.za>
Message-ID: <1232206951.02.0.815189476108.issue4955@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


----------
title: inconsistent, perhaps incorrect, behavior with respect to entities parsed by xml.sax -> xml.sax.expatreader.ExpatParser incorrectly silently skips external character entities in attribute values

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4955>
_______________________________________

From report at bugs.python.org  Sat Jan 17 17:13:44 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 17 Jan 2009 16:13:44 +0000
Subject: [issue4971] Incorrect title case
In-Reply-To: <1232208823.98.0.877639749298.issue4971@psf.upfronthosting.co.za>
Message-ID: <1232208823.98.0.877639749298.issue4971@psf.upfronthosting.co.za>


New submission from Matthew Barnett <python at mrabarnett.plus.com>:

I've found that the following 4 Unicode characters/codepoints don't
behave as I'd expect: ? (U+01C5), ? (U+01C8), ? (U+01CB), ? (U+01F2).

For example, u'\u01C5'.istitle() returns True and
unicodedata.category(u'\u01C5') returns 'Lt', but u'\u01C5'.title()
returns u'\u01C4' (?), which is the uppercase equivalent.

I believe that these 4 codepoints are the only ones where the titlecase
differs from uppercase.

I thought it might be a mistake in the Unicode database. However John
Machin says:

Doesn't look like it. AFAICT it's a mistake in Objects/unicodetype.c,
function _PyUnicode_ToTitlecase.

See
http://svn.python.org/view/python/trunk/Objects/unicodectype.c?rev=66362&view=markup

The code that says:
    if (ctype->title)
        delta = ctype->title;
    else
	delta = ctype->upper;
should IMHO merely be:
    delta = ctype->title;

A value of zero for ctype->title should be interpreted simply as the
offset to add to the ordinal, as it is in the sibling _PyUnicode_To
(Upper|Lower)case functions. See also Tools/unicode/makeunicodedata.py
which treats upper, lower and title identically when preparing the
tables used by those 3 functions.

AFAICT making that change will fix the problem for those four
characters and not ruin any others.

The error that you noticed occurs as far back as I've looked (2.1) and
also occurs in 3.0.

----------
components: Unicode
messages: 80020
nosy: mrabarnett
severity: normal
status: open
title: Incorrect title case
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4971>
_______________________________________

From report at bugs.python.org  Sat Jan 17 17:28:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Jan 2009 16:28:46 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1232209726.67.0.727526249028.issue1745@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Sat Jan 17 17:53:34 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 16:53:34 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232211214.83.0.0404790071475.issue4474@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch including a test in _testcapi module: create two 
PyUnicode objects from wide string (PyUnicode_FromWideChar) and 
another from utf-8 (PyUnicode_FromString) and compare the value. Patch 
is still for py3k branch and can be ported easily on python trunk.

Added file: http://bugs.python.org/file12776/unicode_fromwidechar_surrogate-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 17:55:41 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 16:55:41 +0000
Subject: [issue4971] Incorrect title case
In-Reply-To: <1232208823.98.0.877639749298.issue4971@psf.upfronthosting.co.za>
Message-ID: <1232211341.4.0.783814422524.issue4971@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4971>
_______________________________________

From report at bugs.python.org  Sat Jan 17 17:57:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 16:57:47 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1232211467.14.0.298683347712.issue3997@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r68661 (trunk), r68662 (py3k), r68663 (2.6) and r68664 (3.0)

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:07:12 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 17:07:12 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232212032.29.0.400359166767.issue4474@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I run my test on py3k on Linux with 32 bits wchar_t:
 - 16 bits Py_UNICODE: test is failing without 
PyUnicode_FromWideChar() patch
 - 32 bits Py_UNICODE: test pass without the patch, so the issue only 
impact 16 bits Py_UNICODE

Can someone test with 16 bits wchar_t (eg. Windows)? I think that the 
bug only impact 16 bits Py_UNICODE with 32 bits wchar_t.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:07:16 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 17:07:16 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232212036.46.0.877309589916.issue4474@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12773/unicode_fromwidechar_surrogate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:09:18 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Jan 2009 17:09:18 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232212158.41.0.595064575694.issue4474@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(with the full patch, all tests pass with 16 or 32 bits Py_UNICODE)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:12:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 17:12:20 +0000
Subject: [issue4930] Small optimization in type construction
In-Reply-To: <1231854527.51.0.654505109034.issue4930@psf.upfronthosting.co.za>
Message-ID: <1232212340.64.0.0839710670455.issue4930@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r68665.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4930>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:28:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 17 Jan 2009 17:28:58 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

In a program, I naturally wrote:

    >>> from ftplib import FTP
    >>> with FTP('ftp.somewhere.com') as ftp:
    ...     ftp.login('someone', 'pass')
    ...     ...

Until I realized this class is not equipped with __enter__ and __exit__,

I think it could be a simple and pleasant enhancement to add it.

----------
components: Library (Lib)
messages: 80026
nosy: tarek
severity: normal
status: open
title: let's equip ftplib.FTP with __enter__ and __exit__
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:38:00 2009
From: report at bugs.python.org (Zlm)
Date: Sat, 17 Jan 2009 17:38:00 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232213880.89.0.865650290639.issue3881@psf.upfronthosting.co.za>


Zlm <zemarialm at gmail.com> added the comment:

Hi. I have the same problem, but i'm running Pyhton 2.6.1. I'm using
Windows Vista 32bit SP1.

I installed Python to C:\Program Files\Python\2.6\ and when I try to run
idle from the start menu, it doesn't work.

When I try to run it from the command line, the same error is displayed:

"C:\Program Files\Python\2.6\Lib\idlelib>python idle.py
Traceback (most recent call last):
  File "idle.py", line 21, in <module>
    idlelib.PyShell.main()
  File "C:\Programas\Python\2.6\lib\idlelib\PyShell.py", line 1386, in main
    root = Tk(className="Idle")
  File "C:\Programas\Python\2.6\lib\lib-tk\Tkinter.py", line 1643, in
__init__
    self.tk = _tkinter.create(screenName, baseName, className,
interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following
directories:
    {C:\Programas\Python\2.6\tcl\tcl8.5}
C:/Programas/Python/2.6/lib/tcl8.5 C:/P
rogramas/Python/lib/tcl8.5 C:/Programas/lib/tcl8.5
C:/Programas/Python/library C
:/Programas/library C:/Programas/tcl8.5.2/library C:/tcl8.5.2/library



This probably means that Tcl wasn't installed properly."

----------
nosy: +zlm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:45:55 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 17 Jan 2009 17:45:55 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1232214355.1.0.913868891511.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

roumen, hi,
can you add:

       BASECFLAGS="-mthreads $BASECFLAGS"
       LDFLAGS="-mthreads $LDFLAGS"

when compiling with threads, and... a second request: _block_ people
from compiling without mthreads, because there's a bug in wine's
msvcrt _filbuf routine where it doesn't perform CRLF (at all)
and it should.

http://bugs.winehq.org/show_bug.cgi?id=16970

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:53:13 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 17:53:13 +0000
Subject: [issue4971] Incorrect title case
In-Reply-To: <1232208823.98.0.877639749298.issue4971@psf.upfronthosting.co.za>
Message-ID: <1232214793.88.0.130017892579.issue4971@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I do think this is a bug in the Unicode database. The current approach
(of falling back to uppercase if there is no title case in the Unicode
database) goes back to r17708. However, even the prior version only
contained explicitly the cases where a titlecase was specified and
different from the uppercase.

I think part of the motivation is this note from

http://www.unicode.org/Public/UNIDATA/UCD.html

Note: The simple titlecase may be omitted in the data file if the
titlecase is the same as the uppercase.

(notice that for uppercase, it says instead "The simple uppercase is
omitted in the data file if the uppercase is the same as the code point
itself", likewise for lowercase)

Considering this note, the simple titlecase of U+01C5 *is* U+01C4: the
titlecase value is omitted, hence it is the same as uppercase, hence it
is U+01C4.

Most likely, the algorithm to produce the database was different from
the documented algorithm, and it is a bug in UCD.html. However, if
UCD.html is correct, it is likely a bug in UnicodeData.txt.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4971>
_______________________________________

From report at bugs.python.org  Sat Jan 17 18:57:54 2009
From: report at bugs.python.org (Michael Newman)
Date: Sat, 17 Jan 2009 17:57:54 +0000
Subject: [issue4973] calendar formatyearpage returns bytes, not str
In-Reply-To: <1232215074.9.0.340477624129.issue4973@psf.upfronthosting.co.za>
Message-ID: <1232215074.9.0.340477624129.issue4973@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

formatyearpage is returning "bytes", not "str"

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import calendar
>>> calendar.HTMLCalendar().formatyearpage(2009)[0:50]
b'<?xml version="1.0" encoding="utf-8"?>\n<!DOCTYPE h'
>>> type(calendar.HTMLCalendar().formatyearpage(2009)[0:50])
<class 'bytes'>

# For the time being, to fix it I can use "decode"...
>>> calendar.HTMLCalendar().formatyearpage(2009).decode("utf-8")[0:50]
'<?xml version="1.0" encoding="utf-8"?>\n<!DOCTYPE h'
>>> type(calendar.HTMLCalendar().formatyearpage(2009).decode("utf-8")[0:50])
<class 'str'>

----------
components: Extension Modules
messages: 80030
nosy: mnewman
severity: normal
status: open
title: calendar formatyearpage returns bytes, not str
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4973>
_______________________________________

From report at bugs.python.org  Sat Jan 17 19:09:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 18:09:04 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1232215744.24.0.167052868602.issue4910@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks again for reviewing, Benjamin.  nb_long renamed in r68651, merged 
to 3.0 (along with a few other long->int cleanups) in r68666.

There seems to be a consensus on deprecating PyNumber_Int.  I'll leave 
this open until that's taken care of.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Sat Jan 17 19:09:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 18:09:14 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232215754.07.0.667718012576.issue3881@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

zlm, did you chose to install Tcl/Tk when installing Python?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 19:13:25 2009
From: report at bugs.python.org (Zlm)
Date: Sat, 17 Jan 2009 18:13:25 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232216005.71.0.158493496634.issue3881@psf.upfronthosting.co.za>


Zlm <zemarialm at gmail.com> added the comment:

Yes, I did.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 19:33:47 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 18:33:47 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1232216005.71.0.158493496634.issue3881@psf.upfronthosting.co.za>
Message-ID: <497223CC.7050600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Yes, I did.

So do you have a file C:\Programas\Python\2.6\tcl\tcl8.5\init.tcl ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 19:44:28 2009
From: report at bugs.python.org (Zlm)
Date: Sat, 17 Jan 2009 18:44:28 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232217868.98.0.400645623895.issue3881@psf.upfronthosting.co.za>


Zlm <zemarialm at gmail.com> added the comment:

> So do you have a file C:\Programas\Python\2.6\tcl\tcl8.5\init.tcl ?

Yes, I have.


Could this problem be related to paths with slashes and backslashes? In
the error log, the first path (the right one) has backslashes, but the
others have slashes.

"    {C:\Programas\Python\2.6\tcl\tcl8.5}
C:/Programas/Python/2.6/lib/tcl8.5 C:/P
rogramas/Python/lib/tcl8.5 C:/Programas/lib/tcl8.5
C:/Programas/Python/library C
:/Programas/library C:/Programas/tcl8.5.2/library C:/tcl8.5.2/library"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 19:52:01 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 18:52:01 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1232217868.98.0.400645623895.issue3881@psf.upfronthosting.co.za>
Message-ID: <4972288C.2010001@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Could this problem be related to paths with slashes and backslashes?

Unlikely. The exact same package works on many other machines, so there
must be something strange with your machine.

Can you run the Sysinternals filemon to find out what files it is accessing?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 19:54:22 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 17 Jan 2009 18:54:22 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1232218462.08.0.0377070950395.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

roumen, hi,
can you add:

       BASECFLAGS="-mthreads $BASECFLAGS"
       LDFLAGS="-mthreads $LDFLAGS"

when compiling with threads, and... a second request: _block_ people
from compiling without mthreads, because there's a bug in wine's
msvcrt _filbuf routine where it doesn't perform CRLF (at all)
and it should.

http://bugs.winehq.org/show_bug.cgi?id=16970

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Jan 17 20:17:00 2009
From: report at bugs.python.org (Jacob)
Date: Sat, 17 Jan 2009 19:17:00 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232219820.72.0.401228641433.issue3881@psf.upfronthosting.co.za>


Jacob <jacoberen at gmail.com> added the comment:

I don't think it's just his machine (and mine), but i don't think so.
Unfortunealy, i don't have a Windows Vista key ready, else i'd have
testet it on a clean install, but i'll try to install the same package
on the next computer with Vista i stumple upon.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 20:40:26 2009
From: report at bugs.python.org (Zlm)
Date: Sat, 17 Jan 2009 19:40:26 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232221226.67.0.714982283245.issue3881@psf.upfronthosting.co.za>


Zlm <zemarialm at gmail.com> added the comment:

> Can you run the Sysinternals filemon to find out what files it is
accessing?

I tried Sysinternals ProcessMonitor (equivalent of filemon to Windows
Vista), but the simple act of trying to open IDLE produces thousands of
entries to the log window.

I also don't think this is a problem of my machine, because i'm not the
only one with this problem. I think this situation can be easily
reproduced by installing Pyhton to other than the default path on
Windows Vista.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 21:01:26 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Jan 2009 20:01:26 +0000
Subject: [issue4937] Mac DMG install missing version.plist required by
	bundlebuilder.py
In-Reply-To: <1231880551.46.0.128485851272.issue4937@psf.upfronthosting.co.za>
Message-ID: <1232222486.43.0.280185783896.issue4937@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

As a workaround, you can copy the missing file from a 2.5 (or earlier) 
Python and edit it, if necessary.

sudo
cd /Library/Frameworks/Python.framework/Versions/
cp -p 2.5/Resources/version.plist 2.6/Resources/

Or look at the one in the Apple-supplied Python.

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4937>
_______________________________________

From report at bugs.python.org  Sat Jan 17 21:04:37 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 20:04:37 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1232221226.67.0.714982283245.issue3881@psf.upfronthosting.co.za>
Message-ID: <49723998.9090904@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I think this situation can be easily
> reproduced by installing Pyhton to other than the default path on
> Windows Vista.

I could not reproduce it that way. I just installed Python 2.6.1 into
c:\tmp\python26, on Vista SP1 x64 (although I installed the 32-bit
version of Python), and IDLE works just fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 21:20:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 20:20:37 +0000
Subject: [issue4077] Py_FatalError cleanup patch
In-Reply-To: <1223481025.87.0.784441664166.issue4077@psf.upfronthosting.co.za>
Message-ID: <1232223637.55.0.161175914033.issue4077@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

committed with r68667.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4077>
_______________________________________

From report at bugs.python.org  Sat Jan 17 21:39:54 2009
From: report at bugs.python.org (Jacob)
Date: Sat, 17 Jan 2009 20:39:54 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232224794.21.0.424683231299.issue3881@psf.upfronthosting.co.za>


Jacob <jacoberen at gmail.com> added the comment:

Okay, i'll try to find a key for Vista in all my drawers, and install a
clean version, try it, and then i'll tell you the result.
I just can't see what could produce the error at our computers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 17 21:45:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Jan 2009 20:45:48 +0000
Subject: [issue4838] md_state is not released
In-Reply-To: <1231110990.47.0.0796872141326.issue4838@psf.upfronthosting.co.za>
Message-ID: <1232225148.24.0.907828378085.issue4838@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. I'm not sure if I'm missing something here, since it
looks trivial.

----------
keywords: +patch
nosy: +pitrou
Added file: http://bugs.python.org/file12777/issue4838.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4838>
_______________________________________

From report at bugs.python.org  Sat Jan 17 21:48:16 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 20:48:16 +0000
Subject: [issue4838] md_state is not released
In-Reply-To: <1231110990.47.0.0796872141326.issue4838@psf.upfronthosting.co.za>
Message-ID: <1232225296.77.0.180650905706.issue4838@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looks fine, please apply.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4838>
_______________________________________

From report at bugs.python.org  Sat Jan 17 21:52:28 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 17 Jan 2009 20:52:28 +0000
Subject: [issue4974] Redundant mention of lists and tuples at start of
	Sequence Types documentation
In-Reply-To: <1232225548.25.0.868641329064.issue4974@psf.upfronthosting.co.za>
Message-ID: <1232225548.25.0.868641329064.issue4974@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Under Built-in Types in the Library documentation the section on "Sequence 
Types" begins with the paragraph:

There are five sequence types: strings, byte sequences, byte arrays, 
lists, tuples, and range objects. (For other containers see the built-in 
dict, list, set, and tuple classes, and the collections module.)

list and tuple "classes" shouldn't be in that second sentence, should 
they? They are already in the first.

----------
assignee: georg.brandl
components: Documentation
messages: 80046
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Redundant mention of lists and tuples at start of Sequence Types documentation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4974>
_______________________________________

From report at bugs.python.org  Sat Jan 17 22:03:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Jan 2009 21:03:47 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1232226227.74.0.907858010029.issue3997@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening, some tests have started deterministically failing:

======================================================================
ERROR: testAbsoluteArcnames (test.test_zipfile.TestZip64InSmallFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 506, in testAbsoluteArcnames
    zipfp = zipfile.ZipFile(TESTFN2, "r", zipfile.ZIP_STORED)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 710, in __init__
    self._GetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 730, in _GetContents
    self._RealGetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 767, in _RealGetContents
    raise BadZipfile, "Bad magic number for central directory"
BadZipfile: Bad magic number for central directory

======================================================================
ERROR: testDeflated (test.test_zipfile.TestZip64InSmallFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 499, in testDeflated
    self.zipTest(f, zipfile.ZIP_DEFLATED)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 434, in zipTest
    zipfp = zipfile.ZipFile(f, "r", compression)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 710, in __init__
    self._GetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 730, in _GetContents
    self._RealGetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 767, in _RealGetContents
    raise BadZipfile, "Bad magic number for central directory"
BadZipfile: Bad magic number for central directory

======================================================================
ERROR: testStored (test.test_zipfile.TestZip64InSmallFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 493, in testStored
    self.zipTest(f, zipfile.ZIP_STORED)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 434, in zipTest
    zipfp = zipfile.ZipFile(f, "r", compression)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 710, in __init__
    self._GetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 730, in _GetContents
    self._RealGetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 767, in _RealGetContents
    raise BadZipfile, "Bad magic number for central directory"
BadZipfile: Bad magic number for central directory

----------------------------------------------------------------------

----------
nosy: +pitrou
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sat Jan 17 22:33:01 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Jan 2009 21:33:01 +0000
Subject: [issue4975] 3.0 base64 doc examples lack bytes 'b' indicator
In-Reply-To: <1232227980.99.0.219231642791.issue4975@psf.upfronthosting.co.za>
Message-ID: <1232227980.99.0.219231642791.issue4975@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

This unconverted example in the 3.1a doc needs a 'b' for 'bytes' added
before the three input and output string literals.

>>> import base64
>>> encoded = base64.b64encode('data to be encoded') # here
>>> encoded
'ZGF0YSB0byBiZSBlbmNvZGVk' # here
>>> data = base64.b64decode(encoded)
>>> data
'data to be encoded' #and here

Otherwise,
TypeError: expected bytes, not str

----------
assignee: georg.brandl
components: Documentation
messages: 80048
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: 3.0 base64 doc examples lack bytes 'b' indicator

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4975>
_______________________________________

From report at bugs.python.org  Sat Jan 17 22:39:50 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 21:39:50 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1232228390.32.0.898036843235.issue3997@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Oops, I did see this before, but forgot to merge the patches.

It appears that "centDirOffset == 0xffffffff" is not the correct test 
for detecting zip64 structure. From the PKZip notes, a value of 
0xffffffff does imply a zip64 format, not the other way round.

So it seems necessary to always try to read the zip64 info (the _EndRecData64 function does not fail if the format is not zip64 - is 
simply returns the previous structure)
Patch is attached, and now the test passes.

----------
keywords: +needs review
Added file: http://bugs.python.org/file12778/zip64-alwaystry.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sat Jan 17 22:41:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Jan 2009 21:41:00 +0000
Subject: [issue4838] md_state is not released
In-Reply-To: <1231110990.47.0.0796872141326.issue4838@psf.upfronthosting.co.za>
Message-ID: <1232228460.58.0.129903428941.issue4838@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r68669.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4838>
_______________________________________

From report at bugs.python.org  Sat Jan 17 22:50:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 17 Jan 2009 21:50:26 +0000
Subject: [issue4976] Documentation of the set intersection and difference
	operators is inaccurate
In-Reply-To: <1232229026.33.0.903700187167.issue4976@psf.upfronthosting.co.za>
Message-ID: <1232229026.33.0.903700187167.issue4976@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

A quibble about the documentation of sets in the library documentation: 
the union and intersection operators are shown with ellipsis, as is the 
difference operator. However, they inaccurately refer to "both sets" in 
their documentation. They should refer to "all sets" or "the others" the 
way the set difference operator documentation does.

----------
assignee: georg.brandl
components: Documentation
messages: 80051
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of the set intersection and difference operators is inaccurate
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4976>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:01:00 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 17 Jan 2009 22:01:00 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

the assumption is made that the result will fit into a PyInt.
obviously, on a 32-bit system, where SIZEOF_LONG is 4 bytes,
that ain't happening.

a complex test would be something like this:

if len <= 9: it's an int, definitely.
if len > 10: it's a long, definitely.
if len == 10, and first char is a "-", it's an int, definitely
if len == 10, and first char is 5,6,7,8,9, it's a long, definitely.
if len == 10, and first char is 0,1,2,3, it's an int, definitely.
if len == 10, and first char is 4, it _might_ be a long, but it might
also be an int, so... uh... let's assume it's a long!

and you know what?  xxxx that for a game of soldiers: just use
"if len >= 10" assume it's a long :)




diff --git a/Modules/cPickle.c b/Modules/cPickle.c
index 537276c..e56f8e5 100644
--- a/Modules/cPickle.c
+++ b/Modules/cPickle.c
@@ -3143,7 +3143,15 @@ load_int(Unpicklerobject *self)
    errno = 0;
    l = strtol(s, &endptr, 0);

-   if (errno || (*endptr != '\n') || (endptr[1] != '\0')) {
+   if (errno || (*endptr != '\n') || (endptr[1] != '\0')
+#if SIZEOF_LONG == 4
+        /* integers of 10 chars or over could be bigger than 32-bit.
+         * just keep it simple: 10 or more chars, it goes into
+         * a PyLong.
+         */
+        || (len >= 10)
+#endif
+       ) {
        /* Hm, maybe we've got something long.  Let's try reading
           it as a Python long object. */
        errno = 0;

----------
components: Build
messages: 80052
nosy: lkcl
severity: normal
status: open
title: test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into "long"
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:27:19 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 22:27:19 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1232231239.93.0.231003925401.issue3997@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Added file: http://bugs.python.org/file12779/zip64-alwaystry2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:27:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 22:27:27 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1232231247.47.0.67531400858.issue3997@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file12778/zip64-alwaystry.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:27:30 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 17 Jan 2009 22:27:30 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232231250.16.0.342991056875.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

workarounds for a couple of wine bugs,
also includes e.g. #4977 64-bit assumptions on 32-bit systems.

Added file: http://bugs.python.org/file12780/f

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:27:42 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 17 Jan 2009 22:27:42 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232231262.01.0.58919323608.issue4954@psf.upfronthosting.co.za>


Changes by Luke Kenneth Casson Leighton <lkcl at lkcl.net>:


Removed file: http://bugs.python.org/file12764/x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:28:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Jan 2009 22:28:09 +0000
Subject: [issue1225107] inspect.isclass() fails with custom __getattr__
Message-ID: <1232231289.55.0.41733288165.issue1225107@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Finally fixed in r68676.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225107>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:31:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 22:31:39 +0000
Subject: [issue4910] Remove uses of nb_long slot, and rename to nb_reserved.
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1232231499.72.0.627836745.issue4910@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that deprecates PyNumber_Int in favour of PyNumber_Long:

- move PyNumber_Int definition from abstract.h to intobject.h (and
  fix up comments at the top of intobject.h)
- mark PyNumber_Int as deprecated in the c-api docs, with a promise
  to remove it for 3.1.

I suppose that in theory this goes too far:  we should really deprecate in 
3.1 and remove in 3.2.  But given all the other stuff that's going on for 
3.0.1, this doesn't seem too bad.  Benjamin, what do you think?

N.B.  We should remember to actually remove intobject.h for 3.1. :)

Added file: http://bugs.python.org/file12781/issue4910_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4910>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:37:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Jan 2009 22:37:00 +0000
Subject: [issue2614] Console UnicodeDecodeError s once more
In-Reply-To: <1207903659.28.0.871159161104.issue2614@psf.upfronthosting.co.za>
Message-ID: <1232231820.3.0.625312031048.issue2614@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think this had been addressed by PEP 3138 [1].

[1] http://www.python.org/dev/peps/pep-3138/

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2614>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:44:57 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 17 Jan 2009 22:44:57 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1232232297.26.0.605315246326.issue3997@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Applied the zip64-alwaystry2.patch in trunk, waiting for buildbots.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:51:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 22:51:12 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232232672.39.0.13268942592.issue4977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

>From the included patch, I assume you're talking about a failure of
test_pickle.

I'm not seeing any such failure on my (32-bit) system, and the code in 
Modules/cPickle.c looks correct to me.  I suspect that the problem is that 
in your setup, strtol is failing to set errno correctly on overflow.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Sat Jan 17 23:57:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 22:57:50 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232233070.88.0.0299042188641.issue4977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

You might try replacing the strtol call with a call to PyOS_strtol.  
Please let us know if this works!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Sun Jan 18 00:06:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 17 Jan 2009 23:06:10 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232233570.37.0.667424662844.issue4954@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy:  -loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Sun Jan 18 00:07:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Jan 2009 23:07:25 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

This allows unicode arguments to be passed as keywords to functions to
help "from __future__ import unicode_literals". See
http://mail.python.org/pipermail/python-dev/2009-January/085113.html.

----------
components: Library (Lib)
messages: 80060
nosy: benjamin.peterson
severity: normal
status: open
title: allow unicode keyword args
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4978>
_______________________________________

From report at bugs.python.org  Sun Jan 18 00:30:50 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Jan 2009 23:30:50 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232235050.12.0.160993216368.issue4978@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12782/unicode_kwds.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4978>
_______________________________________

From report at bugs.python.org  Sun Jan 18 00:46:23 2009
From: report at bugs.python.org (John Machin)
Date: Sat, 17 Jan 2009 23:46:23 +0000
Subject: [issue4971] Incorrect title case
In-Reply-To: <1232208823.98.0.877639749298.issue4971@psf.upfronthosting.co.za>
Message-ID: <1232235983.84.0.135501490923.issue4971@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Martin:"""Considering this note, the simple titlecase of U+01C5 *is*
U+01C4: the titlecase value is omitted, hence it is the same as
uppercase, hence it is U+01C4."""

Perhaps we are looking at different files; in the Unicode 5.1
UnicodeData.txt that I downloaded
(http://www.unicode.org/Public/UNIDATA/UnicodeData.txt), the title field
for U+01C5 is *NOT* omitted, it is set to 01C5. AFAICT the intention is
that the four characters in question are their own titlecase, which is
not altogether unexpected given their visual representation.

Here's the record for U+01C5:
01C5;LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH
CARON;Lt;0;L;<compat> 0044 017E;;;;N;LATIN LETTER CAPITAL D SMALL Z
HACEK;;01C4;01C6;01C5

The note (which I hadn't noticed and explains the mention of
ctype->upper in the _PyUnicode_ToTitlecase function) says that the
titlecase value may be omitted if it is the same as the uppercase. FWIW
there are *no* examples in the current (5.1) file where the title field
is empty and the upper field is not empty. 

ISTM the problem is that implementing the default-to-uppercase was not
done in Tools/unicode/makeunicodedata.py where full information is
available. This left no way in _PyUnicode_ToTitlecase of resolving the
ambiguity of a zero value for ctype->title -- is it "no titlecase
supplied so use uppercase" or is it "titlecase supplied, delta == 0,
means ch.title() -> ch"?

----------
nosy: +sjmachin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4971>
_______________________________________

From report at bugs.python.org  Sun Jan 18 01:03:18 2009
From: report at bugs.python.org (Max Hailperin)
Date: Sun, 18 Jan 2009 00:03:18 +0000
Subject: [issue4979] random.uniform can return its upper limit
In-Reply-To: <1232236998.05.0.906555449746.issue4979@psf.upfronthosting.co.za>
Message-ID: <1232236998.05.0.906555449746.issue4979@psf.upfronthosting.co.za>


New submission from Max Hailperin <max at gustavus.edu>:

The documentation for random.uniform says that random.uniform(a,b) 
should return a number strictly less than b, assuming a<b.  (The result 
should be strictly less than a if a>b.)  Thus both of the following 
expressions should always evaluate to False:

a<b and b in [random.uniform(a,b) for i in range(20)]
a<b and b in [random.uniform(b,a) for i in range(20)]

Yet both of them evaluate to True (except, presumably, one time in a 
million) after doing the following assignments:

a = 1.0
b = 1.0 + 2.0**-52

Other values of a and b also exist for which random.uniform will 
sometimes return its upper limit.  (For example, the -52 can be 
increased to -51, -50, etc., with correspondingly less frequent 
violations of the spec.)

Because this is a case where the code is violating an explicit 
specification in the documentation, I'm reporting it as a behavior bug.  
But perhaps the behavior is as intended and the documentation is at 
fault.  For that reason, I'm also emailing docs at python.org.
 
The documentation would in any case need a little touching up, in that 
it has a self-contradictory specification for the case where a=b.  There 
is no value N for which a<=N<b, given a=b.  That minor touch-up could be 
combined with allowing the behavior described in this bug report, if 
that behavior is in fact desired.

----------
components: Library (Lib)
messages: 80062
nosy: hailperin
severity: normal
status: open
title: random.uniform can return its upper limit
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4979>
_______________________________________

From report at bugs.python.org  Sun Jan 18 01:09:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 18 Jan 2009 00:09:14 +0000
Subject: [issue4971] Incorrect title case
In-Reply-To: <1232235983.84.0.135501490923.issue4971@psf.upfronthosting.co.za>
Message-ID: <49727327.5060203@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Perhaps we are looking at different files; 

Indeed, I was looking at the 3.2.0 database (assuming that it would be
the same in subsequent versions).

> ISTM the problem is that implementing the default-to-uppercase was not
> done in Tools/unicode/makeunicodedata.py where full information is
> available. This left no way in _PyUnicode_ToTitlecase of resolving the
> ambiguity of a zero value for ctype->title -- is it "no titlecase
> supplied so use uppercase" or is it "titlecase supplied, delta == 0,
> means ch.title() -> ch"?

Correct. So it seems this needs to be fixed in makeunicodedata.py
already. This was not the case with earlier versions of Unicode (which
never had a mapping to the same code point).

The logic for using deltas is also incorrect, so makeunicodedata.py
needs to be fixed anyway.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4971>
_______________________________________

From report at bugs.python.org  Sun Jan 18 01:18:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 00:18:13 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1232237893.52.0.326793625557.issue4879@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Kristj?n, could you merge this change into the Py3k branch, please?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Sun Jan 18 01:42:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 00:42:54 +0000
Subject: [issue4980] Documentation for "y#" does not mention PY_SSIZE_T_CLEAN
In-Reply-To: <1232239374.34.0.275487506145.issue4980@psf.upfronthosting.co.za>
Message-ID: <1232239374.34.0.275487506145.issue4980@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Documentation for "y#" does not mention PY_SSIZE_T_CLEAN, it lets
believe that the length result is unconditionally int-sized.
(in http://docs.python.org/3.0/c-api/arg.html)

----------
assignee: georg.brandl
components: Documentation
messages: 80065
nosy: georg.brandl, pitrou
severity: normal
status: open
title: Documentation for "y#" does not mention PY_SSIZE_T_CLEAN
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4980>
_______________________________________

From report at bugs.python.org  Sun Jan 18 01:45:38 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 18 Jan 2009 00:45:38 +0000
Subject: [issue4508] distutils compiler not handling spaces in path to
	output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1232239538.3.0.997814915287.issue4508@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I couldn't reproduce the problem yet, using your sample.

I tried to compile on Mac OSX (Python 2.5 GCC) and Windows XP (Python
2.5 , MinGW 5.1.4 and SWIG 1.2.3) and it worked well.

The output was right, (the .o file has a space, but the pyd/so files
come out properly), and I could use the gcd() function without any problem.

The call to the compiler quotes the c file correctly:

    ...
    c:\Program Files\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall
-Ic:\Python25\include -Ic:\Python25\PC -c "ex ample.c" -o
"build\temp.win32-2.5\Release\ex ample.o"
    ...

This is done automatically with distutils.spawn._nt_quote_args under
Windows for instance. And this is basically what your patch is doing.

When does it crash exactly for you ? Do you have a traceback ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4508>
_______________________________________

From report at bugs.python.org  Sun Jan 18 02:06:15 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 18 Jan 2009 01:06:15 +0000
Subject: [issue4981] Incorrect statement regarding mutable sequences in
	datamodel Reference
In-Reply-To: <1232240775.28.0.564077407765.issue4981@psf.upfronthosting.co.za>
Message-ID: <1232240775.28.0.564077407765.issue4981@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Early in the datamodel document in the Reference documentation is the 
statement:

      There is currently a single intrinsic mutable sequence type:

This statement is followed by the documentation of Lists and Byte Arrays. 
The statement should read "There are currently two intrinsic mutable 
sequence types".

----------
assignee: georg.brandl
components: Documentation
messages: 80067
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Incorrect statement regarding mutable sequences in datamodel Reference
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4981>
_______________________________________

From report at bugs.python.org  Sun Jan 18 02:29:48 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 01:29:48 +0000
Subject: [issue4981] Incorrect statement regarding mutable sequences in
	datamodel Reference
In-Reply-To: <1232240775.28.0.564077407765.issue4981@psf.upfronthosting.co.za>
Message-ID: <1232242188.23.0.99503796704.issue4981@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r68707.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4981>
_______________________________________

From report at bugs.python.org  Sun Jan 18 02:30:07 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 01:30:07 +0000
Subject: [issue4981] Incorrect statement regarding mutable sequences in
	datamodel Reference
In-Reply-To: <1232240775.28.0.564077407765.issue4981@psf.upfronthosting.co.za>
Message-ID: <1232242207.38.0.671261572108.issue4981@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Never mind, I meant r68706.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4981>
_______________________________________

From report at bugs.python.org  Sun Jan 18 02:42:56 2009
From: report at bugs.python.org (William Stevenson)
Date: Sun, 18 Jan 2009 01:42:56 +0000
Subject: [issue4982] Running python 3 as Non-admin User requests the Runtime
	to terminate in an unusual way.
In-Reply-To: <1232242976.03.0.32299361581.issue4982@psf.upfronthosting.co.za>
Message-ID: <1232242976.03.0.32299361581.issue4982@psf.upfronthosting.co.za>


New submission from William Stevenson <yhvh2000 at googlemail.com>:

AMD64 msi install seemed to work fine when running python3.0 as admin 
but fails immediately as any other user.

Command Line output:
C:\Python30>python.exe
Fatal Python error: Py_Initialize: can't initialize sys standard streams
  File "C:\Python25\Lib\encodings\__init__.py", line 120
    raise CodecRegistryError,\
                            ^
SyntaxError: invalid syntax

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.

C:\Python30>


GUI output:
---------------------------
Visual Studio Just-In-Time Debugger
---------------------------
An unhandled win32 exception occurred in python.exe [2028]. Just-In-Time 
debugging this exception failed with the following error: No installed 
debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-
Time debugging can be enabled from Tools/Options/Debugging/Just-In-Time.

Check the documentation index for 'Just-in-time debugging, errors' for 
more information.
---------------------------
OK   
---------------------------

----------
components: Installation, Windows
messages: 80070
nosy: yhvh
severity: normal
status: open
title: Running python 3 as Non-admin User requests the Runtime to terminate in an unusual way.
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4982>
_______________________________________

From report at bugs.python.org  Sun Jan 18 03:32:23 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 02:32:23 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1232245943.5.0.0348421927491.issue4449@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

FYI, there was a small issue in the patch - namely the only way to get the 
AttributeError to raise in the Value/Array creation is to not pass in a 
lock, True/None or False - the latter three get to a lock/RLock while the 
former will have the acquire method. I changed the test to reflect this:

    self.assertRaises(AttributeError, self.Value, 'i', 5, lock='navalue')
    self.assertRaises(AttributeError,
                      self.Array, 'i', range(10), lock='notalock')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Sun Jan 18 03:33:43 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 02:33:43 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1232246023.85.0.711213729786.issue4449@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Sun Jan 18 03:35:10 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 02:35:10 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1232246110.29.0.153250086775.issue4449@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

FYI, there was a small issue in the patch - namely the only way to get 
the 
AttributeError to raise in the Value/Array creation is to not pass in a 
lock, True/None - the latter two get to a lock/RLock while the 
former will have the acquire method. If you pass in False, you 
immediately get the RawValue() object back.

I changed the test to reflect this:

    self.assertRaises(AttributeError, self.Value, 'i', 5, 
lock='navalue')
    self.assertRaises(AttributeError,
                      self.Array, 'i', range(10), lock='notalock')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Sun Jan 18 03:47:19 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 02:47:19 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1232246839.27.0.574626367973.issue4449@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Checked into trunk in r68708 - I pinged benjamin to see how we're handling 
merges right now as this needs to go into py3k

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Sun Jan 18 05:01:40 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 18 Jan 2009 04:01:40 +0000
Subject: [issue4983] Spurious reference to "byte sequences" in Library
	stdtypes sequence documentation
In-Reply-To: <1232251300.25.0.53795146873.issue4983@psf.upfronthosting.co.za>
Message-ID: <1232251300.25.0.53795146873.issue4983@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The first sentence under "Sequence Types" in the Library stdtypes document 
is:

There are five sequence types: strings, byte sequences, byte arrays, 
lists, tuples, and range objects

However, subsequent discussion, as well as reality, use the term "bytes" 
not "byte sequences".

----------
assignee: georg.brandl
components: Documentation
messages: 80074
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Spurious reference to "byte sequences" in Library stdtypes sequence documentation
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4983>
_______________________________________

From report at bugs.python.org  Sun Jan 18 05:08:18 2009
From: report at bugs.python.org (Thomas Lee)
Date: Sun, 18 Jan 2009 04:08:18 +0000
Subject: [issue4347] Circular dependency causes SystemError when adding new
	syntax
In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
Message-ID: <1232251698.03.0.961801207.issue4347@psf.upfronthosting.co.za>


Thomas Lee <tom at vector-seven.com> added the comment:

Brett, any feedback on this one?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4347>
_______________________________________

From report at bugs.python.org  Sun Jan 18 05:09:20 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 18 Jan 2009 04:09:20 +0000
Subject: [issue4984] Inconsistent count of sequence types in Library stdtypes
	document
In-Reply-To: <1232251760.56.0.36573894326.issue4984@psf.upfronthosting.co.za>
Message-ID: <1232251760.56.0.36573894326.issue4984@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Sorry I didn't notice all the problems I've reported today about this 
paragraph at one time so I could have submitted only one report. Anyway, 
here's another problem with the first sentence of the Sequence Types 
section of the library stdtypes document. The sentence:

There are five sequence types: strings, byte sequences, byte arrays, 
lists, tuples, and range objects

lists six types but says their are five.

----------
assignee: georg.brandl
components: Documentation
messages: 80076
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Inconsistent count of sequence types in Library stdtypes document
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4984>
_______________________________________

From report at bugs.python.org  Sun Jan 18 05:29:17 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 18 Jan 2009 04:29:17 +0000
Subject: [issue4981] Incorrect statement regarding mutable sequences in
	datamodel Reference
In-Reply-To: <1232242188.23.0.99503796704.issue4981@psf.upfronthosting.co.za>
Message-ID: <p06240816c5985ffd7cf5@[10.0.1.222]>


Mitchell Model <mlm at acm.org> added the comment:

>Benjamin Peterson <benjamin at python.org> added the comment:
>
>Fixed in r68707.

Sorry if I missed that.  I checked some of the documentation problems I reported today against an updated subversion copy of 3.0 and 3.1, but I didn't check all.  Got impatient. I'll be more careful.

>----------
>nosy: +benjamin.peterson
>resolution:  -> fixed
>status: open -> closed
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue4981>
>_______________________________________

-- 

        --- Mitchell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4981>
_______________________________________

From report at bugs.python.org  Sun Jan 18 05:31:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 04:31:47 +0000
Subject: [issue4981] Incorrect statement regarding mutable sequences in
	datamodel Reference
In-Reply-To: <p06240816c5985ffd7cf5@10.0.1.222>
Message-ID: <1afaf6160901172031n6cfee8b1r1d60e3eb15783285@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Sat, Jan 17, 2009 at 10:29 PM, Mitchell Model <report at bugs.python.org> wrote:
>
> Mitchell Model <mlm at acm.org> added the comment:
>
>>Benjamin Peterson <benjamin at python.org> added the comment:
>>
>>Fixed in r68707.
>
> Sorry if I missed that.  I checked some of the documentation problems I reported today against an updated subversion copy of > > 3.0 and 3.1, but I didn't check all.  Got impatient. I'll be more careful.

No, don't worry! That checkin was in response to your bug report.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4981>
_______________________________________

From report at bugs.python.org  Sun Jan 18 06:27:54 2009
From: report at bugs.python.org (Romeo Victor Dellarocco)
Date: Sun, 18 Jan 2009 05:27:54 +0000
Subject: [issue4985] Idle hangs when given a nonexistent filename.
In-Reply-To: <1232256473.01.0.852239057685.issue4985@psf.upfronthosting.co.za>
Message-ID: <1232256473.01.0.852239057685.issue4985@psf.upfronthosting.co.za>


New submission from Romeo Victor Dellarocco <della1rv at gmail.com>:

Idle hangs when given the name of a nonexistent file. The idle window
briefly appears, then disappears, the process hangs and has to be
terminated.

Platform:
  Linux 2.6.22-16-rt #1 SMP PREEMPT RT Mon Nov 24 21:03:25 GMT 2008 i686
GNU/Linux
  Ubuntu 7.10
  Python3.0 Final built from source.
  tk8.4
  I upgraded to tk8.5, idle still does the same thing.

To recreate type:
  rm foo.py
  idle foo.py
  # The idle window briefly appears, then disappears, the process hangs
  # and has to be terminated.

In previous versions of idle any nonexistent files would be created by
idle. This is what one would expect.

I have a patch for idlelib/PyShell.py that will make idle create any
nonexisting files.

----------
components: IDLE
files: idle_create_file_if_not_exist.python3_0.patch
keywords: patch
messages: 80079
nosy: della1rv
severity: normal
status: open
title: Idle hangs when given a nonexistent filename.
versions: Python 3.0
Added file: http://bugs.python.org/file12783/idle_create_file_if_not_exist.python3_0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4985>
_______________________________________

From report at bugs.python.org  Sun Jan 18 07:42:23 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 18 Jan 2009 06:42:23 +0000
Subject: [issue4347] Circular dependency causes SystemError when adding new
	syntax
In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
Message-ID: <1232260943.31.0.992015982953.issue4347@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I will take a look when I can.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4347>
_______________________________________

From report at bugs.python.org  Sun Jan 18 10:34:42 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 18 Jan 2009 09:34:42 +0000
Subject: [issue4973] calendar formatyearpage returns bytes, not str
In-Reply-To: <1232215074.9.0.340477624129.issue4973@psf.upfronthosting.co.za>
Message-ID: <1232271282.53.0.203558907333.issue4973@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This is the expected behavior; that's why the function takes an 
"encoding" argument. As it returns a complete XML document, it must be 
already encoded. Other methods return just document pieces, so str is 
fine. Probably should be better explained in the documentation.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4973>
_______________________________________

From report at bugs.python.org  Sun Jan 18 10:42:25 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 18 Jan 2009 09:42:25 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232271744.99.0.731630202841.issue3881@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

> I installed Python to C:\Program Files\Python\2.6\ and when I try to
> run idle from the start menu, it doesn't work.

> "C:\Program Files\Python\2.6\Lib\idlelib>python idle.py
> Traceback (most recent call last):
>   File "idle.py", line 21, in <module>
>     idlelib.PyShell.main()
>   File "C:\Programas\Python\2.6\lib\idlelib\PyShell.py", line 1386, 

Note the TWO different paths: C:\Program Files\Python\2.6\ and C:
\Programas\Python\2.6

Do you have a PYTHONPATH environment variable?
Did you install twice, once per directory? Perhaps one of them without 
tcl support?

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sun Jan 18 10:47:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 18 Jan 2009 09:47:14 +0000
Subject: [issue4979] random.uniform can return its upper limit
In-Reply-To: <1232236998.05.0.906555449746.issue4979@psf.upfronthosting.co.za>
Message-ID: <1232272034.73.0.199286768553.issue4979@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The distinction between < and <= is fairly meaningless when applied to a 
computed floating-point result.  I think the docs should be fixed to 
replace the < with <=.  In any case, the b <= N < a bit has the 
inequalities the wrong way around: presumably it was intended to read b < 
N <= a.  The docs for random.triangular should also be fixed in the same 
way.

(N.B. What *is* always true is that the result of random.random() is never 
1.0.  And that's a useful property---without it, random.uniform(a, b) can 
even return values *outside* the closed interval [a, b].)

To me, it doesn't seem worth slowing down random.uniform itself with extra 
checks: it's the sort of function that often gets called millions of times 
within a simulation, or numerical algorithm (e.g. Monte-Carlo 
integration), and it's trivial for the user to add his or her own check if 
necessary.

I also think it's a nice property that random.uniform currently degrades 
gracefully when a == b, producing the expected point distribution at a.  I 
wouldn't want to change that.

So:  +1 for amending the docs.  -1 for changing random.uniform.

----------
nosy: +marketdickinson
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4979>
_______________________________________

From report at bugs.python.org  Sun Jan 18 11:38:28 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 10:38:28 +0000
Subject: [issue4984] Inconsistent count of sequence types in Library stdtypes
	document
In-Reply-To: <1232251760.56.0.36573894326.issue4984@psf.upfronthosting.co.za>
Message-ID: <1232275108.15.0.688816022579.issue4984@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r68716.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4984>
_______________________________________

From report at bugs.python.org  Sun Jan 18 11:40:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 10:40:38 +0000
Subject: [issue4983] Spurious reference to "byte sequences" in Library
	stdtypes sequence documentation
In-Reply-To: <1232251300.25.0.53795146873.issue4983@psf.upfronthosting.co.za>
Message-ID: <1232275238.75.0.457157509347.issue4983@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r68717.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4983>
_______________________________________

From report at bugs.python.org  Sun Jan 18 11:42:45 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 10:42:45 +0000
Subject: [issue4976] Documentation of the set intersection and difference
	operators is inaccurate
In-Reply-To: <1232229026.33.0.903700187167.issue4976@psf.upfronthosting.co.za>
Message-ID: <1232275365.22.0.472302271705.issue4976@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r68718.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4976>
_______________________________________

From report at bugs.python.org  Sun Jan 18 11:44:06 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 10:44:06 +0000
Subject: [issue4975] 3.0 base64 doc examples lack bytes 'b' indicator
In-Reply-To: <1232227980.99.0.219231642791.issue4975@psf.upfronthosting.co.za>
Message-ID: <1232275446.89.0.849987393805.issue4975@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r68719.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4975>
_______________________________________

From report at bugs.python.org  Sun Jan 18 11:45:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 10:45:42 +0000
Subject: [issue4974] Redundant mention of lists and tuples at start of
	Sequence Types documentation
In-Reply-To: <1232225548.25.0.868641329064.issue4974@psf.upfronthosting.co.za>
Message-ID: <1232275542.16.0.441230891088.issue4974@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r68720.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4974>
_______________________________________

From report at bugs.python.org  Sun Jan 18 11:48:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 10:48:25 +0000
Subject: [issue4914] trunc(x) erroneously documented as built-in
In-Reply-To: <1231652236.88.0.715538324364.issue4914@psf.upfronthosting.co.za>
Message-ID: <1232275705.47.0.69959279193.issue4914@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r68721.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4914>
_______________________________________

From report at bugs.python.org  Sun Jan 18 11:55:41 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 18 Jan 2009 10:55:41 +0000
Subject: [issue4979] random.uniform can return its upper limit
In-Reply-To: <1232236998.05.0.906555449746.issue4979@psf.upfronthosting.co.za>
Message-ID: <1232276141.81.0.359535835398.issue4979@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Doc update

----------
keywords: +patch
nosy: +gagenellina
Added file: http://bugs.python.org/file12784/random.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4979>
_______________________________________

From report at bugs.python.org  Sun Jan 18 11:59:19 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 18 Jan 2009 10:59:19 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1232276359.43.0.441562921163.issue4293@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

checked in r68722, let's hope this fixes things.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Sun Jan 18 13:11:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 12:11:42 +0000
Subject: [issue4565] Rewrite the IO stack in C
In-Reply-To: <1228576260.5.0.752040739396.issue4565@psf.upfronthosting.co.za>
Message-ID: <1232280702.8.0.014971669371.issue4565@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The work to rewrite the IO stack in C will solve this problem as it will
probably solve most performance-related IO problems in py3k.

Amaury and I have been progressing a lot, the rewrite is now a real
branch in SVN at branches/io-c/. On this very issue, it is only 30%
slower than 2.x, which is quite good given the layered nature of the IO
stack and the fact that text IO does a lot more than in 2.x (it
translates newlines and encodes the text).

(actually, if I add an explicit .encode('utf8') call to the 2.x version
of the script, it becomes slower than our io-c rewrite)

----------
components: +Extension Modules, Library (Lib) -Interpreter Core
stage:  -> needs patch
title: io write() performance very slow -> Rewrite the IO stack in C
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4565>
_______________________________________

From report at bugs.python.org  Sun Jan 18 13:13:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 12:13:01 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1232280781.53.0.0800100847522.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Making this a duplicate of #4565 ("Rewrite the IO stack in C").
If anyone disagrees, please reopen!

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Rewrite the IO stack in C

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Sun Jan 18 13:17:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 12:17:57 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1232281077.83.0.0935412878592.issue1675951@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Sun Jan 18 13:33:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 12:33:28 +0000
Subject: [issue4561] Optimize new io library
In-Reply-To: <1228565691.76.0.695581669443.issue4561@psf.upfronthosting.co.za>
Message-ID: <1232282008.21.0.879713774292.issue4561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Marking this as a duplicate of #4565 "Rewrite the IO stack in C".

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Rewrite the IO stack in C

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4561>
_______________________________________

From report at bugs.python.org  Sun Jan 18 14:24:19 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 13:24:19 +0000
Subject: [issue4979] random.uniform can return its upper limit
In-Reply-To: <1232236998.05.0.906555449746.issue4979@psf.upfronthosting.co.za>
Message-ID: <1232285059.06.0.337475277149.issue4979@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r68724.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4979>
_______________________________________

From report at bugs.python.org  Sun Jan 18 14:26:28 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 13:26:28 +0000
Subject: [issue4980] Documentation for "y#" does not mention PY_SSIZE_T_CLEAN
In-Reply-To: <1232239374.34.0.275487506145.issue4980@psf.upfronthosting.co.za>
Message-ID: <1232285188.56.0.662397601361.issue4980@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Duplicate of #1729742.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> missing int->Py_ssize_t in documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4980>
_______________________________________

From report at bugs.python.org  Sun Jan 18 14:26:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 13:26:39 +0000
Subject: [issue1729742] Document effects of PY_SSIZE_T_CLEAN on argument
	parsing
Message-ID: <1232285199.29.0.422630494686.issue1729742@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl
priority: normal -> high
title: missing int->Py_ssize_t in documentation -> Document effects of PY_SSIZE_T_CLEAN on argument parsing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729742>
_______________________________________

From report at bugs.python.org  Sun Jan 18 14:40:37 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 18 Jan 2009 13:40:37 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1232286037.36.0.739031096489.issue3873@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

With the io-c branch I see much better unpickling performance than
before. But it still seems to be around 2 or 3 times slower than with
cPickle in 2.6.

Is this expected at this point of io-c development? Otherwise perhaps
this issue should stay open until it can be verified that nothing else
can be done to get closer to the old cPickle performance.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Sun Jan 18 14:45:51 2009
From: report at bugs.python.org (andrew cooke)
Date: Sun, 18 Jan 2009 13:45:51 +0000
Subject: [issue4986] Augmented Assignment / Operations Confusion in
	Documentation
In-Reply-To: <1232286351.49.0.0947913998579.issue4986@psf.upfronthosting.co.za>
Message-ID: <1232286351.49.0.0947913998579.issue4986@psf.upfronthosting.co.za>


New submission from andrew cooke <andrew at acooke.org>:

There's a small confusion in terminology in the documentation related to
methods that implement augmented assignment.

The "Expressions" section of the language reference ("Simple
statements") refers to augmented assignment -
http://docs.python.org/3.0/reference/simple_stmts.html#augmented-assignment-statements
- and this seems to be a carefully chosen (and correct) phrase because
the parsing is related to assignments, which are augmented with various
operators.

It is important to note that augmented assignments ("+=" etc) are *not*
parsed as operators.  It is syntax error to use them in many places
where an operator would be accepted.

In the "Data Model" section, however, things are less clear
http://docs.python.org/3.0/reference/datamodel.html#emulating-numeric-types
.  The methods used to implement augmented assignment are grouped near
those used to implement arithmetic operators.  That seems natural.  But
the text confuses the two more than is strictly necessary.  In
particular there is the phrase "augmented arithmetic operations".

As I have already tried to make clear, these are not operations.  They
are augmented assignments.  Calling them operations is misleading,
because they cannot be used in the same places as "real" operations -
the parser simply will not accept them.

Apart from changing "augmented arithmetic operations" to "augmented
assignments" it might be worth adding some kind of note that explains to
the user that the parser calls those methods to implement assignment,
and that they are not valid in the same syntax as operations.

I am not sure the following will help, but it does illustrate the
confusion caused -
http://groups.google.com/group/comp.lang.python/browse_thread/thread/f1322928300b2b71

Cheers, Andrew

----------
assignee: georg.brandl
components: Documentation
messages: 80098
nosy: acooke, georg.brandl
severity: normal
status: open
title: Augmented Assignment / Operations Confusion in Documentation
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4986>
_______________________________________

From report at bugs.python.org  Sun Jan 18 14:47:53 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 13:47:53 +0000
Subject: [issue4857] syntax: no unpacking in augassign
In-Reply-To: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>
Message-ID: <1232286473.08.0.172197332891.issue4857@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r68725.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4857>
_______________________________________

From report at bugs.python.org  Sun Jan 18 14:51:34 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 13:51:34 +0000
Subject: [issue4882] Behavior of backreferences to named groups in regular
	expressions unclear
In-Reply-To: <1231428946.66.0.0747408022841.issue4882@psf.upfronthosting.co.za>
Message-ID: <1232286694.84.0.157789544349.issue4882@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm happy to review such a patch.

----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4882>
_______________________________________

From report at bugs.python.org  Sun Jan 18 15:01:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 14:01:20 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1232286037.36.0.739031096489.issue3873@psf.upfronthosting.co.za>
Message-ID: <1232287301.6604.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

> With the io-c branch I see much better unpickling performance than
> before. But it still seems to be around 2 or 3 times slower than with
> cPickle in 2.6.

It's much closer here.

With 2.7 (trunk) and cPickle:
0.439934968948
0.669679880142
With the io-c branch:
0.136367082596
0.798221111298

> Is this expected at this point of io-c development?

20-30% slower is expected for binary I/O (which is what I get above),
not 2x or 3x slower.
What is your system?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Sun Jan 18 15:06:18 2009
From: report at bugs.python.org (Jacob)
Date: Sun, 18 Jan 2009 14:06:18 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232287578.06.0.383016884749.issue3881@psf.upfronthosting.co.za>


Jacob <jacoberen at gmail.com> added the comment:

I don't think thats the solution.
"C:\Program Files\Python\2.6\" and
"C:\Programas\Python\2.6\"
are the same, as "C:\Program Files\Python\2.6\" is a symbolic link to
"C:\Programas\Python\2.6\" to allow compatibility with different
operation system languages.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sun Jan 18 15:14:12 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 18 Jan 2009 14:14:12 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1232288052.54.0.602637972744.issue3873@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


Removed file: http://bugs.python.org/file11497/pickletst.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Sun Jan 18 15:17:54 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 18 Jan 2009 14:17:54 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1232288274.92.0.298774550388.issue3873@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

I uploaded a new pickletst.py which specifies protocol 2, otherwise
we're comparing apples with oranges. With this I get:

0.211881160736
0.322369813919

for Python 2.6 and

0.158488035202
1.21621990204

on the io-c branch. Can you confirm this?

Added file: http://bugs.python.org/file12785/pickletst.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Sun Jan 18 15:25:44 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 14:25:44 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1232288744.06.0.339525804599.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nice catch! I can confirm your figures with protocol=2 (and protocol=-1
as well).

----------
resolution: duplicate -> 
status: closed -> open
superseder: Rewrite the IO stack in C -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Sun Jan 18 15:42:37 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 14:42:37 +0000
Subject: [issue4923] time.strftime documentation needs update
In-Reply-To: <1231759881.41.0.312941806858.issue4923@psf.upfronthosting.co.za>
Message-ID: <1232289757.06.0.0348389924494.issue4923@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

%f and %z are not standardized by C89 and therefore not always
available.  They fall under the clause "Additional directives may be
supported on certain platforms, but only the ones listed here have a
meaning standardized by ANSI C." which is noted for time.strftime().

datetime.strftime() implements %z (and %f from 2.6) separately,
therefore it is available there.

I've added a bit of clarification in r68726.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4923>
_______________________________________

From report at bugs.python.org  Sun Jan 18 16:18:23 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 18 Jan 2009 15:18:23 +0000
Subject: [issue4987] update distutils.README
In-Reply-To: <1232291903.8.0.000403573304081.issue4987@psf.upfronthosting.co.za>
Message-ID: <1232291903.8.0.000403573304081.issue4987@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

This file is out of date (6 years old), let's update it

http://www.python.org/community/sigs/current/distutils-sig/ needs to be
revamped too.

----------
assignee: tarek
components: Distutils, Documentation
messages: 80106
nosy: tarek
severity: normal
status: open
title: update distutils.README
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4987>
_______________________________________

From report at bugs.python.org  Sun Jan 18 16:52:02 2009
From: report at bugs.python.org (Michael Newman)
Date: Sun, 18 Jan 2009 15:52:02 +0000
Subject: [issue4973] calendar formatyearpage returns bytes, not str
In-Reply-To: <1232215074.9.0.340477624129.issue4973@psf.upfronthosting.co.za>
Message-ID: <1232293922.48.0.380080404241.issue4973@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

It seems to be working consistently (see UTF-16 extreme example below),
but I had expected it to act similarly to Python 2.6, which it does not.
I suppose this is due to the distinction now made between strings and
bytes in Python 3.0.

I was initially concerned that Python 3.0 was always just giving an
ASCII byte stream no matter what encoding was chosen (since you can't
tell between ASCII and UTF-8 for the characters being used in the
example), but the UTF-16 example shows its fine.

I agree that as long as the documentation in Python 3.X notes it will
return "bytes", then its fine. Thanks for the clarification/confirmation.

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import calendar
>>> calendar.HTMLCalendar().formatyearpage(2009, encoding="utf-8")[0:50]
b'<?xml version="1.0" encoding="utf-8"?>\n<!DOCTYPE h'
>>> calendar.HTMLCalendar().formatyearpage(2009, encoding="ascii")[0:50]
b'<?xml version="1.0" encoding="ascii"?>\n<!DOCTYPE h'
>>> calendar.HTMLCalendar().formatyearpage(2009, encoding="utf-16")[0:50]
b'\xff\xfe<\x00?\x00x\x00m\x00l\x00
\x00v\x00e\x00r\x00s\x00i\x00o\x00n\x00=\x00"\x001\x00.\x000\x00"\x00
\x00e\x00n\x00c\x00o\x00'

Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import calendar
>>> calendar.HTMLCalendar().formatyearpage(2009, encoding="utf-8")[0:50]
'<?xml version="1.0" encoding="utf-8"?>\n<!DOCTYPE h'
>>> calendar.HTMLCalendar().formatyearpage(2009, encoding="ascii")[0:50]
'<?xml version="1.0" encoding="ascii"?>\n<!DOCTYPE h'
>>> calendar.HTMLCalendar().formatyearpage(2009, encoding="utf-16")[0:50]
'\xff\xfe<\x00?\x00x\x00m\x00l\x00
\x00v\x00e\x00r\x00s\x00i\x00o\x00n\x00=\x00"\x001\x00.\x000\x00"\x00
\x00e\x00n\x00c\x00o\x00'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4973>
_______________________________________

From report at bugs.python.org  Sun Jan 18 17:25:38 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 18 Jan 2009 16:25:38 +0000
Subject: [issue4987] update distutils.README
In-Reply-To: <1232291903.8.0.000403573304081.issue4987@psf.upfronthosting.co.za>
Message-ID: <1232295938.26.0.444687693558.issue4987@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

How about svn rm "svn.python.org/projects/distutils/" to avoid confusion?

----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4987>
_______________________________________

From report at bugs.python.org  Sun Jan 18 17:39:29 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 18 Jan 2009 16:39:29 +0000
Subject: =?utf-8?q?[issue4988]_A_link_to_"What=E2=80=99s_New_in_Python_2.0"_on_"The_Python_Tutorial"_release_2.6?=
In-Reply-To: <1232296769.88.0.210431601252.issue4988@psf.upfronthosting.co.za>
Message-ID: <1232296769.88.0.210431601252.issue4988@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

It might be not a bug, but I think it's weird to see
an ancient What's New link on the new Python tutorial page.
http://docs.python.org/tutorial/

----------
assignee: georg.brandl
components: Documentation
messages: 80109
nosy: akitada, georg.brandl
severity: normal
status: open
title: A link to "What?s New in Python 2.0" on "The Python Tutorial" release 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4988>
_______________________________________

From report at bugs.python.org  Sun Jan 18 18:53:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 18 Jan 2009 17:53:11 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1232287578.06.0.383016884749.issue3881@psf.upfronthosting.co.za>
Message-ID: <49736C84.403@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't think thats the solution.
> "C:\Program Files\Python\2.6\" and
> "C:\Programas\Python\2.6\"
> are the same, as "C:\Program Files\Python\2.6\" is a symbolic link to
> "C:\Programas\Python\2.6\" to allow compatibility with different
> operation system languages.

It could be a hint to the problem, though.

Jacob: what language version is your Vista installation? Is
"c:\Programmer" the local translation of "c:\Program Files"?

Perhaps something doesn't work right with symbolic links on Vista.
Unfortunately, I have only the English version of Vista for testing.

Can you two please install Python into a non-standard folder that
isn't a symbolic link?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sun Jan 18 19:05:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 18:05:14 +0000
Subject: =?utf-8?q?[issue4988]_A_link_to_"What=E2=80=99s_New_in_Python_2.0"_on_"The_Python_Tutorial"_release_2.6?=
In-Reply-To: <1232296769.88.0.210431601252.issue4988@psf.upfronthosting.co.za>
Message-ID: <1232301914.16.0.187059898313.issue4988@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, this isn't going to change; the last topic of the docs (and
therefore the "previous" one to the tutorial) is the 2.0 whatsnew.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4988>
_______________________________________

From report at bugs.python.org  Sun Jan 18 19:27:22 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jan 2009 18:27:22 +0000
Subject: [issue4986] Augmented Assignment / Operations Confusion in
	Documentation
In-Reply-To: <1232286351.49.0.0947913998579.issue4986@psf.upfronthosting.co.za>
Message-ID: <1232303242.29.0.315489485086.issue4986@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r68727.

IMO, "augmented operation" was an acceptable term -- the term "operator"
is not strictly limited to operators usable in expressions in Python.
However, since it's called "augmented assignment" everywhere else, it's
better here too for consistency.

A real mistake was that the same paragraph called "a += b" an expression
-- it really is a statement. Fixed that too.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4986>
_______________________________________

From report at bugs.python.org  Sun Jan 18 19:35:39 2009
From: report at bugs.python.org (andrew cooke)
Date: Sun, 18 Jan 2009 18:35:39 +0000
Subject: [issue4986] Augmented Assignment / Operations Confusion in
	Documentation
In-Reply-To: <1232286351.49.0.0947913998579.issue4986@psf.upfronthosting.co.za>
Message-ID: <1232303739.87.0.580660682238.issue4986@psf.upfronthosting.co.za>


andrew cooke <andrew at acooke.org> added the comment:

thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4986>
_______________________________________

From report at bugs.python.org  Sun Jan 18 20:02:12 2009
From: report at bugs.python.org (Jacob)
Date: Sun, 18 Jan 2009 19:02:12 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232305332.15.0.424811002642.issue3881@psf.upfronthosting.co.za>


Jacob <jacoberen at gmail.com> added the comment:

Great idea :)
Maybe we're starting to find the problem.
I'm using a Danish version of Windows Vista Home Premium SP1, and
C:\Programmer is the danish path for C:\Program Files.
I'll try that, and leave another message when i'we tried it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sun Jan 18 20:35:13 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 19:35:13 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1232307313.28.0.670861639239.issue4892@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> normal
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Sun Jan 18 20:36:52 2009
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Pasternak?=)
Date: Sun, 18 Jan 2009 19:36:52 +0000
Subject: [issue4989] 'calendar' module is crummy and should be removed
In-Reply-To: <1232307412.23.0.393188506109.issue4989@psf.upfronthosting.co.za>
Message-ID: <1232307412.23.0.393188506109.issue4989@psf.upfronthosting.co.za>


New submission from Micha? Pasternak <michal.dtz at gmail.com>:

I was looking for some library to handle calendar events. Something PIM-
style, something useful, that could check if, for example, 2 weekly 
repeated events that start on Monday morning and last until December 
conflict with each other.

Then I found 'calendar' module in the standard library.

My question: how this thing ever made it to the standard library?

Maybe it was useful back in the days, if somebody could not get BSD or 
GNU sources for cal(1) . Nowadays, even if it is able to print HTML 
calendars, lets face it - who will use that functionality? You can 
easily find HTML calendars with a lot of JavaScript support, that can be 
customised in a thousands of ways.

I suggest we delete this module completly.

----------
components: None
messages: 80115
nosy: dotz
severity: normal
status: open
title: 'calendar' module is crummy and should be removed
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4989>
_______________________________________

From report at bugs.python.org  Sun Jan 18 20:37:18 2009
From: report at bugs.python.org (Sandy Barbour)
Date: Sun, 18 Jan 2009 19:37:18 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1232307438.33.0.338922186484.issue4566@psf.upfronthosting.co.za>


Sandy Barbour <sandybarbour at btinternet.com> added the comment:

Over 3 years ago I wrote a plugin for the Xplane Flight Simulator.
This uses a SDK that Ben Supnik and myself created 6 years ago.
Our plugins are DLL's that our plugin manager DLL loads at run time.

The plugin embeds python and allows python scripts to be run from within
Xplane.
This has worked fine with python 2.3.x, 2.4.x, 2.5.x and 2.6.0.
I see the same problem as described here when using 2.6.1 with the
ctypes, socket libraries etc.
This also affects PyOpenGL as it uses ctypes.

I applied the patch that Mark posted and rebuilt python26.dll.
I tested this on Windows XP and Windows 7 Beta.
With the patched python26.dll my scripts now load properly.
The script that uses PyOpenGL also works fine now.

I thought that this feedback may be useful.

----------
nosy: +SandyBarbour

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Sun Jan 18 20:46:00 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 19:46:00 +0000
Subject: [issue3325] use of cPickle in multiprocessing
In-Reply-To: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za>
Message-ID: <1232307960.7.0.460888981871.issue3325@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Checked into python-3000 as r68728

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3325>
_______________________________________

From report at bugs.python.org  Sun Jan 18 20:46:38 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 19:46:38 +0000
Subject: [issue4449] AssertionError in Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1232307998.91.0.555130599463.issue4449@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________

From report at bugs.python.org  Sun Jan 18 20:47:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 19:47:10 +0000
Subject: [issue4989] 'calendar' module is crummy and should be removed
In-Reply-To: <1232307412.23.0.393188506109.issue4989@psf.upfronthosting.co.za>
Message-ID: <1232308030.77.0.899859723187.issue4989@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We cannot just remove modules because of backwards compatibility. Feel
free to submit patches for improvements you would like to see in the module.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4989>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:18:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 18 Jan 2009 20:18:14 +0000
Subject: [issue4008] IDLE: checksyntax() doesn't support Unicode?
In-Reply-To: <1222875475.18.0.22602254781.issue4008@psf.upfronthosting.co.za>
Message-ID: <1232309894.0.0.832166048628.issue4008@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Committed as r68730 and r68731.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4008>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:26:17 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 18 Jan 2009 20:26:17 +0000
Subject: [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1232310377.9.0.983620092216.issue4815@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Committed as r68732, r68733.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4815>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:27:02 2009
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Sun, 18 Jan 2009 20:27:02 +0000
Subject: [issue4990]
	test_codeccallbacks.CodecCallbackTest.test_badhandlerresult is
	not testing anything
In-Reply-To: <1232310422.76.0.435302840888.issue4990@psf.upfronthosting.co.za>
Message-ID: <1232310422.76.0.435302840888.issue4990@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

the reason is that it of course raises TypeError, since number of args
is wrong.

----------
files: out.diff
keywords: patch
messages: 80121
nosy: fijal
severity: normal
status: open
title: test_codeccallbacks.CodecCallbackTest.test_badhandlerresult is not testing anything
Added file: http://bugs.python.org/file12786/out.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4990>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:36:44 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 20:36:44 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1232311004.32.0.754671827347.issue4301@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

This is a patch to fix the logging module, and remove the crufty code in 
multiprocessing.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file12787/issue4301.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:44:31 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 20:44:31 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1232311471.5.0.4837952719.issue4301@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file12787/issue4301.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:44:58 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 20:44:58 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1232311498.4.0.201899578666.issue4301@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

fix copy/paste error, new patch

Added file: http://bugs.python.org/file12788/issue4301.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:47:47 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 20:47:47 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1232311667.22.0.785756508528.issue4301@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:48:08 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 20:48:08 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1232311688.01.0.881136956665.issue4301@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

remove the import, not needed. switch to the property

Added file: http://bugs.python.org/file12789/issue4301.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Sun Jan 18 21:54:51 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 20:54:51 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1232312091.77.0.11822935368.issue4301@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file12788/issue4301.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Sun Jan 18 22:02:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 21:02:03 +0000
Subject: [issue4991] os.fdopen doesn't raise on invalid file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Since os.fdopen is now implemented with io.open, it doesn't use fdopen
and check for invalid file descriptors. This isn't a huge issue since
subsequent actions on the file will raise an error.

----------
components: Library (Lib)
messages: 80125
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: os.fdopen doesn't raise on invalid file descriptors
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4991>
_______________________________________

From report at bugs.python.org  Sun Jan 18 22:12:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 21:12:13 +0000
Subject: [issue4990]
	test_codeccallbacks.CodecCallbackTest.test_badhandlerresult is
	not testing anything
In-Reply-To: <1232310422.76.0.435302840888.issue4990@psf.upfronthosting.co.za>
Message-ID: <1232313133.16.0.575676752033.issue4990@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for noticing! Fixed in r68736.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4990>
_______________________________________

From report at bugs.python.org  Sun Jan 18 22:13:16 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 18 Jan 2009 21:13:16 +0000
Subject: [issue4301] incorrect and inconsistent logging in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1232313196.27.0.966367614331.issue4301@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

fixed in r68737, merged to py3k in 68740

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________

From report at bugs.python.org  Sun Jan 18 22:23:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 21:23:42 +0000
Subject: [issue4991] os.fdopen doesn't raise on invalid file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232313822.58.0.160606813603.issue4991@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps io.open should be fixed, then?
(or the _FileIO constructor)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4991>
_______________________________________

From report at bugs.python.org  Sun Jan 18 22:51:25 2009
From: report at bugs.python.org (Zlm)
Date: Sun, 18 Jan 2009 21:51:25 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232315485.46.0.0286773096072.issue3881@psf.upfronthosting.co.za>


Zlm <zemarialm at gmail.com> added the comment:

"Programas" is the portuguese translation to "Program Files".

I have just installed it to C:\Test\Python and IDLE is working!

The problem should be related to the Vista symbolic links.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sun Jan 18 22:54:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 21:54:49 +0000
Subject: [issue4991] os.fdopen doesn't raise on invalid file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232315689.65.0.824286534795.issue4991@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here's a patch for _FileIO.

----------
keywords: +patch
Added file: http://bugs.python.org/file12790/raise_on_bad_fd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4991>
_______________________________________

From report at bugs.python.org  Sun Jan 18 22:55:25 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 18 Jan 2009 21:55:25 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1232315485.46.0.0286773096072.issue3881@psf.upfronthosting.co.za>
Message-ID: <4973A536.1020801@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The problem should be related to the Vista symbolic links.

Unfortunately, it isn't as simple as "install into a symbolic
link, and it fails". I created c:\temp -> c:\tmp, and installed
into c:\temp (i.e. into the symlink), and it still worked fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sun Jan 18 22:59:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 18 Jan 2009 21:59:14 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232315954.09.0.607716108578.issue4474@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks good to me.

I'm not in a position to test with 16-bit wchar_t, but I can't see why 
anything would go wrong.  I think we can take our chances: check this in 
and watch the buildbots for signs of trouble.

Some minor whitespace issues in the unicodeobject.c part of the patch 
(mixing of tabs and spaces, one brace indented oddly), but those can 
easily be taken care of before committing;  not worth regenerating the 
patch for.

Marc-Andr?, is it okay with you to check this in?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Sun Jan 18 23:33:37 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 18 Jan 2009 22:33:37 +0000
Subject: [issue4989] 'calendar' module is crummy and should be removed
In-Reply-To: <1232307412.23.0.393188506109.issue4989@psf.upfronthosting.co.za>
Message-ID: <1232318017.13.0.974874028032.issue4989@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The other option is to propose its removal on python-dev, get support,
and then submit patches for the module's deprecation.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4989>
_______________________________________

From report at bugs.python.org  Sun Jan 18 23:55:12 2009
From: report at bugs.python.org (Petr Viktorin)
Date: Sun, 18 Jan 2009 22:55:12 +0000
Subject: [issue4992] yield's documentation not updated
In-Reply-To: <1232319312.46.0.667626052793.issue4992@psf.upfronthosting.co.za>
Message-ID: <1232319312.46.0.667626052793.issue4992@psf.upfronthosting.co.za>


New submission from Petr Viktorin <encukou at gmail.com>:

In the yield statement documentation
(http://docs.python.org/3.0/reference/simple_stmts.html#the-yield-statement),
the old way of calling generators is used:

"The body of the generator function is executed by calling the
generator?s next() method repeatedly until it raises an exception."

This should be changed to something like:

"The body of the generator function is executed by calling the next()
function on the generator repeatedly until it raises an exception."

Or just replace next() with __next__(), and fix the next paragraph as well.

----------
assignee: georg.brandl
components: Documentation
messages: 80134
nosy: En-Cu-Kou, georg.brandl
severity: normal
status: open
title: yield's documentation not updated
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4992>
_______________________________________

From report at bugs.python.org  Mon Jan 19 00:21:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 23:21:52 +0000
Subject: [issue4991] os.fdopen doesn't raise on invalid file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232320912.67.0.888255055946.issue4991@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think EBADF is defined everywhere, so you can drop the defined()
conditional.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4991>
_______________________________________

From report at bugs.python.org  Mon Jan 19 00:52:23 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 23:52:23 +0000
Subject: [issue4991] os.fdopen doesn't raise on invalid file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232322743.56.0.400399454738.issue4991@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Attaching new patch...

Added file: http://bugs.python.org/file12791/raise_on_bad_fd2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4991>
_______________________________________

From report at bugs.python.org  Mon Jan 19 01:03:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 00:03:54 +0000
Subject: [issue4991] os.fdopen doesn't raise on invalid file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232323434.39.0.746735889214.issue4991@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure Windows has a valid fstat btw, I'll guess we'll see on the
Windows buildbots (in that case, some code can be taken from
posixmodule.c to emulate fstat behaviour...). Other than that, the patch
looks fine to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4991>
_______________________________________

From report at bugs.python.org  Mon Jan 19 01:09:39 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Jan 2009 00:09:39 +0000
Subject: [issue4991] os.fdopen doesn't raise on invalid file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232323779.48.0.971501695815.issue4991@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r68755. Will watch Windows.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4991>
_______________________________________

From report at bugs.python.org  Mon Jan 19 01:34:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 00:34:43 +0000
Subject: [issue4993] Typo in importlib
In-Reply-To: <1232325282.91.0.864148022751.issue4993@psf.upfronthosting.co.za>
Message-ID: <1232325282.91.0.864148022751.issue4993@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In importlib/_bootstrap.py, line 435 reads:

        with closing(_fileio_FileIO(source_path, 'r')) as file:

which whould probably be:

        with closing(_fileio._FileIO(source_path, 'r')) as file:

----------
assignee: brett.cannon
messages: 80139
nosy: brett.cannon, pitrou
severity: normal
status: open
title: Typo in importlib
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4993>
_______________________________________

From report at bugs.python.org  Mon Jan 19 01:58:06 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 19 Jan 2009 00:58:06 +0000
Subject: [issue4989] 'calendar' module is crummy and should be removed
In-Reply-To: <1232307412.23.0.393188506109.issue4989@psf.upfronthosting.co.za>
Message-ID: <1232326686.53.0.271539793457.issue4989@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Look at the oldest checkin comment for a line still in the module:

  r2166 | guido | 1990-10-13 14:23:40 -0500 (Sat, 13 Oct 1990) | 2 lines

  Initial revision

In short, it's been there for a long, long time.  Long before PEPs.  
Long before Tkinter.  Long before cmath.  Probably long before any code 
which would satisfy your needs was written.  Of all the checkin comments 
for lines still in the current trunk, calendar.py has code which is 
within a few revisions of the earliest code in the repository.

Skip

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4989>
_______________________________________

From report at bugs.python.org  Mon Jan 19 02:52:27 2009
From: report at bugs.python.org (simonbcn)
Date: Mon, 19 Jan 2009 01:52:27 +0000
Subject: [issue4994] subprocess (Popen) doesn't works properly
In-Reply-To: <1232329947.27.0.222828544087.issue4994@psf.upfronthosting.co.za>
Message-ID: <1232329947.27.0.222828544087.issue4994@psf.upfronthosting.co.za>


New submission from simonbcn <simonbcn at gmail.com>:

Python 2.5.2
Ubuntu 8.04.1 64 bits
**************************************************************
-- ATTEMPT 1 --

Python:

Popen(['mplayer','/tvixhd2/Pelis para montar/00049.m2ts','-msglevel
all=4','-vo null','-ao null','-vf cropdetect','-vid 4113','-frames 500'])

stdout & stderr:

Option vf cropdetect: unknown postfix  cropdetect
Supported postfixes are:
  vf-add
 Append the given list to the current list
  vf-pre
 Prepend the given list to the current list
  vf-del x,y,...
 Remove the given elements. Take the list element index (starting from 0).
 Negative index can be used (i.e. -1 is the last element)
  vf-clr
 Clear the current list.
Error analizando la opci?n en la l?nea de comandos: -msglevel all=4
MPlayer dev-SVN-r28340-4.2.4 (C) 2000-2009 MPlayer Team
CPU: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz (Family: 6, Model:
23, Stepping: 10)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compilado para CPU x86 con extensiones: MMX MMX2 SSE SSE2

---------------------------------------------------------

In this first example, I get severals errors from ?python? and then
python executes mplayer without parameters ??

**************************************************************
-- ATTEMPT 2 --

Python:

Popen(args=['/tvixhd2/Pelis para montar/00049.m2ts','-msglevel
all=4','-vo null','-ao null','-vf cropdetect','-vid 4113','-frames
500'], executable='mplayer')

stdout & stderr:

Option vf cropdetect: unknown postfix  cropdetect
Supported postfixes are:
  vf-add
 Append the given list to the current list
  vf-pre
 Prepend the given list to the current list
  vf-del x,y,...
 Remove the given elements. Take the list element index (starting from 0).
 Negative index can be used (i.e. -1 is the last element)
  vf-clr
 Clear the current list.
Error analizando la opci?n en la l?nea de comandos: -msglevel all=4
MPlayer dev-SVN-r28340-4.2.4 (C) 2000-2009 MPlayer Team
CPU: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz (Family: 6, Model:
23, Stepping: 10)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compilado para CPU x86 con extensiones: MMX MMX2 SSE SSE2
---------------------------------------------------------

The same result

**************************************************************
-- ATTEMPT 3 --

Python:

Popen('mplayer /tvixhd2/Pelis para montar/00049.m2ts -msglevel all=4 -vo
null -ao null -vf cropdetect -vid 4113 -frames 500')

stdout & stderr:

Traceback (most recent call last):
  File ".../temp/eclipse-workspace/gConvM2TS/src/gConvM2TS.py", line
858, in <lambda>
    xml.signal_connect('on_btnCrop_pressed', lambda w:
calcularCrop(ficheroEntrada))
  File ".../temp/eclipse-workspace/gConvM2TS/src/gConvM2TS.py", line
810, in calcularCrop
    Popen('mplayer /tvixhd2/Pelis para montar/00049.m2ts -msglevel all=4
-vo null -ao null -vf cropdetect -vid 4113 -frames 500')
  File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
    errread, errwrite)
  File "/usr/lib/python2.5/subprocess.py", line 1147, in _execute_child
    raise child_exception
OSError: [Errno 2] No existe el fichero ? directorio
---------------------------------------------------------

The error is now: "No such file or directory", What!? I don't understand
nothing!

**************************************************************
-- ATTEMPT 4 --

Python:

Popen(args='/tvixhd2/Pelis para montar/00049.m2ts -msglevel all=4 -vo
null -ao null -vf cropdetect -vid 4113 -frames 500', executable='mplayer')

stdout & stderr:

MPlayer dev-SVN-r28340-4.2.4 (C) 2000-2009 MPlayer Team
CPU: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz (Family: 6, Model:
23, Stepping: 10)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compilado para CPU x86 con extensiones: MMX MMX2 SSE SSE2
---------------------------------------------------------

No error, but the command mplayer is executed without parameters, ??

This subprocess Module really works?

---------------------------------------------------------

Python:

Popen(args='mplayer "/tvixhd2/Pelis para montar/00049.m2ts" -msglevel
all=4 -vo null -ao null -vf cropdetect -vid 4113 -frames 500', shell=True)

With "shell=True" it works but I don't want to execute it in this
manner, because thus Python creates two subprocess and it returns the
PID of the open shell but not of the real process of Mplayer.

----------
components: Library (Lib)
messages: 80141
nosy: simonbcn
severity: normal
status: open
title: subprocess (Popen) doesn't works properly
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4994>
_______________________________________

From report at bugs.python.org  Mon Jan 19 03:00:06 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 02:00:06 +0000
Subject: [issue4065] _multiprocessing doesn't build on macosx 10.3
In-Reply-To: <1223376772.75.0.564119782301.issue4065@psf.upfronthosting.co.za>
Message-ID: <1232330406.49.0.998994815471.issue4065@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

This issues was fixed on 2008-11-04 by Martin Loewis in r67098

Index: multiprocessing.h
===================================================================
--- multiprocessing.h	(revision 67097)
+++ multiprocessing.h	(revision 67098)
@@ -20,7 +20,9 @@
 #  define SEM_VALUE_MAX LONG_MAX
 #else
 #  include <fcntl.h>                 /* O_CREAT and O_EXCL */
+#  include <netinet/in.h>
 #  include <sys/socket.h>
+#  include <sys/uio.h>
 #  include <arpa/inet.h>             /* htonl() and ntohl() */
 #  if HAVE_SEM_OPEN
 #    include <semaphore.h>

Closing

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4065>
_______________________________________

From report at bugs.python.org  Mon Jan 19 03:12:55 2009
From: report at bugs.python.org (Muayyad Alsadi)
Date: Mon, 19 Jan 2009 02:12:55 +0000
Subject: [issue4995] sqlite3 module gives SQL logic error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>


New submission from Muayyad Alsadi <alsadi at ojuba.org>:

when I use transactions I got errors I won't get with sqlite3 cli

[alsadi at pc1 ~]$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> cn=sqlite3.connect(':memory:')
>>> c=cn.cursor()
>>> c.execute('BEGIN TRANSACTION')
<sqlite3.Cursor object at 0xb7efada0>
>>> c.execute('create temp table tmp_main (id integer, b text)')
<sqlite3.Cursor object at 0xb7efada0>
>>> c.execute('insert into tmp_main (id) values (10);')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
sqlite3.OperationalError: SQL logic error or missing database
>>> 


[alsadi at pc1 ~]$ sqlite3 ':memory:'
SQLite version 3.5.9
Enter ".help" for instructions
sqlite> BEGIN TRANSACTION;
sqlite> create temp table tmp_main (id integer, b text);
sqlite> insert into tmp_main (id) values (10);
sqlite> select * from tmp_main;
10|
sqlite> 

and if the transaction line removed I get no error

[alsadi at pc1 ~]$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> cn=sqlite3.connect(':memory:')
>>> c=cn.cursor()
>>> c.execute('create temp table tmp_main (id integer, b text)')
<sqlite3.Cursor object at 0xb7ff6da0>
>>> c.execute('insert into tmp_main (id) values (10);')
<sqlite3.Cursor object at 0xb7ff6da0>
>>>

----------
components: Extension Modules
messages: 80143
nosy: alsadi
severity: normal
status: open
title: sqlite3 module gives SQL logic error only in transactions
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4995>
_______________________________________

From report at bugs.python.org  Mon Jan 19 03:13:22 2009
From: report at bugs.python.org (Muayyad Alsadi)
Date: Mon, 19 Jan 2009 02:13:22 +0000
Subject: [issue4995] sqlite3 module gives SQL logic error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232331202.7.0.545939566421.issue4995@psf.upfronthosting.co.za>


Changes by Muayyad Alsadi <alsadi at ojuba.org>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4995>
_______________________________________

From report at bugs.python.org  Mon Jan 19 03:21:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 02:21:19 +0000
Subject: [issue4994] subprocess (Popen) doesn't works properly
In-Reply-To: <1232329947.27.0.222828544087.issue4994@psf.upfronthosting.co.za>
Message-ID: <1232331679.9.0.652289401538.issue4994@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please investigate a bit more before posting.
Try the following:

Popen(['mplayer','/tvixhd2/Pelis para montar/00049.m2ts','-msglevel', 
'all=4','-vo', 'null','-ao', 'null','-vf', 'cropdetect','-vid',
'4113','-frames', '500'])

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4994>
_______________________________________

From report at bugs.python.org  Mon Jan 19 03:22:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 02:22:56 +0000
Subject: [issue4995] sqlite3 module gives SQL logic error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232331776.59.0.423143190046.issue4995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What if you commit before the insert?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4995>
_______________________________________

From report at bugs.python.org  Mon Jan 19 03:34:23 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Mon, 19 Jan 2009 02:34:23 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232332463.11.0.684773919002.issue3881@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Maybe it's "install into a symbolic link pointing to a path with spaces
in it, and idle fails"?

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Mon Jan 19 03:41:25 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 19 Jan 2009 02:41:25 +0000
Subject: [issue4994] subprocess (Popen) doesn't works properly
In-Reply-To: <1232329947.27.0.222828544087.issue4994@psf.upfronthosting.co.za>
Message-ID: <1232332885.77.0.135539697898.issue4994@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4994>
_______________________________________

From report at bugs.python.org  Mon Jan 19 07:56:49 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 19 Jan 2009 06:56:49 +0000
Subject: [issue4993] Typo in importlib
In-Reply-To: <1232325282.91.0.864148022751.issue4993@psf.upfronthosting.co.za>
Message-ID: <1232348209.3.0.0600180830049.issue4993@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yeah, that code has not been tested yet as that is farther down the todo
list. Thanks for the catch!

Fixed in r68761.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4993>
_______________________________________

From report at bugs.python.org  Mon Jan 19 08:57:28 2009
From: report at bugs.python.org (Zach Hirsch)
Date: Mon, 19 Jan 2009 07:57:28 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling with
	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1232351848.84.0.359564594961.issue4120@psf.upfronthosting.co.za>


Zach Hirsch <zhirsch at umich.edu> added the comment:

Without msvc9compiler_stripruntimes.diff, or a patch like it, it doesn't
seem possible to use pywin32 (or other binary extensions) with
Python-2.6+ installed "just for me" (i.e., without the VC90 runtime
installed globally).

Using the python-2.6.1 MSI installed "just for me" and the pywin32-212
installer, I get the following error when trying to import win32api:

    Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import win32api
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ImportError: DLL load failed: This application has failed to start
because the application configuration is incorrect. Reinstalling the
application may fix this problem.

Removing the manifest from all the .pyd files installed by pywin32
allows me to import win32api without issue.

----------
nosy: +zhirsch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Mon Jan 19 09:00:38 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Mon, 19 Jan 2009 08:00:38 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1232352038.27.0.802450566878.issue4769@psf.upfronthosting.co.za>


Changes by HiroakiKawai <kawai at apache.org>:


----------
nosy: +kawai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Mon Jan 19 09:04:21 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Mon, 19 Jan 2009 08:04:21 +0000
Subject: [issue3613] base64.encodestring does not actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1232352261.22.0.0308690269704.issue3613@psf.upfronthosting.co.za>


Changes by HiroakiKawai <kawai at apache.org>:


----------
nosy: +kawai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3613>
_______________________________________

From report at bugs.python.org  Mon Jan 19 10:02:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 19 Jan 2009 09:02:06 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1232355726.62.0.431127164822.issue4842@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

We should really start maintaining a specification of the pickle
format(s). Pickle is designed to be independent of the Python version,
although protocol extensions may be added over time. In such a
specification, it would say that the format of the L code is "ascii
decimal digits, followed by L".

The patches look fine to me, please apply.

A further change might be that on pickling a long in text mode, the I
code could be used if the value is in range(-2**31,2**31). However, this
is independent of the issue at hand.

----------
assignee:  -> marketdickinson
nosy: +loewis
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Mon Jan 19 10:50:09 2009
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_BRINER?=)
Date: Mon, 19 Jan 2009 09:50:09 +0000
Subject: [issue4962] urlparse & nfs url (rfc 2224)
In-Reply-To: <1232101704.89.0.669847506906.issue4962@psf.upfronthosting.co.za>
Message-ID: <1232358609.79.0.478133208006.issue4962@psf.upfronthosting.co.za>


C?dric BRINER <briner at infomaniak.ch> added the comment:

> Do you encounter any errors or weird behaviors while using nfs url?

Do you mean: Do I have problem using the python module in conjunction of
urlparse ?
No, because, I'm not yet using it. But I would like to do it. And I find
it strange that it can not find the host by itself.

>('nfs', '', '//server//a/b/c/d/e/f', '', '', '')
>If you have done the research already, can you please explain what
>difference will adding 'nfs' to uses_netloc do in urlparse.py.

As much as I've looked at the code, the uses_netloc provide an easy way
to tell urlparse.py if such scheme as nfs is composed
by a net location (host[:port]). Which is the case. Modifying
uses_netloc by addind 'nfs' into it will transform the following:
nfsurl : 'nfs://server//a/b/c/d/e/f'
in  urlparse from:
('nfs', '', '//server//a/b/c/d/e/f', '', '', '')
to
('nfs', 'server', '//a/b/c/d/e/f', '', '', '')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4962>
_______________________________________

From report at bugs.python.org  Mon Jan 19 10:52:25 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 19 Jan 2009 09:52:25 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1232315954.09.0.607716108578.issue4474@psf.upfronthosting.co.za>
Message-ID: <49744D55.10607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-18 22:59, Mark Dickinson wrote:
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Looks good to me.
> 
> I'm not in a position to test with 16-bit wchar_t, but I can't see why 
> anything would go wrong.  I think we can take our chances: check this in 
> and watch the buildbots for signs of trouble.
> 
> Some minor whitespace issues in the unicodeobject.c part of the patch 
> (mixing of tabs and spaces, one brace indented oddly), but those can 
> easily be taken care of before committing;  not worth regenerating the 
> patch for.
> 
> Marc-Andr?, is it okay with you to check this in?

I'd structure the patch differently, ie. put the whole support code
into a single #ifndef Py_UNICODE_WIDE section as part of the
#ifdef HAVE_USABLE_WCHAR_T pre-processor statement.

Also note that on platforms with 16-bit wchar_t, the comparison
(0xffff < *w) will always be false, so an additional check for
(Py_UNICODE_SIZE > 2) is needed.

BTW: Please always use upper-case hex literals, or at leat don't
mix the case within the same function.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Mon Jan 19 11:09:56 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Mon, 19 Jan 2009 10:09:56 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>


New submission from HiroakiKawai <kawai at apache.org>:

The documentation says io.TextIOWrapper wraps io.BufferedIOBase raw 
stream. In the code, io.TextIOWrapper.read(), 
io.TextIOWrapper._read_chunk() calls buffer.read1() which seems 
expecting buffer to be an instance of io.BufferedReader. I'm not sure 
which is correct right now.

----------
components: Library (Lib)
messages: 80152
nosy: kawai
severity: normal
status: open
title: io.TextIOWrapper calls buffer.read1()
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 11:29:43 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 10:29:43 +0000
Subject: [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1232360983.88.0.217344803254.issue4336@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

note, this has been ported to Py3k in http://svn.python.org/view?
view=rev&rev=68458

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________

From report at bugs.python.org  Mon Jan 19 11:31:51 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 10:31:51 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1232361111.41.0.347299782399.issue3582@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Note, this has been ported to py3k in http://svn.python.org/view?
view=rev&rev=68543

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Mon Jan 19 11:35:57 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Mon, 19 Jan 2009 10:35:57 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>


New submission from HiroakiKawai <kawai at apache.org>:

xml.sax.saxutils.XMLGenerator._write tests the argument by 
isinstance(text, str), but this is problematic in Python 3.0. 
XMLGenerator accepts encoding and the produced file is encoded by that 
encoding, i.e., the XML is a binary sequence. So IMHO, the XMLGenerator 
constructor argument should be a subclass of io.RawIOBase.

----------
components: Library (Lib), XML
messages: 80155
nosy: kawai
severity: normal
status: open
title: xml.sax.saxutils.XMLGenerator should write to io.RawIOBase.
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Mon Jan 19 11:38:32 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 10:38:32 +0000
Subject: [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1232361512.06.0.999594924187.issue4929@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Note, this has been ported to py3k in http://svn.python.org/view?
view=rev&rev=68736

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4929>
_______________________________________

From report at bugs.python.org  Mon Jan 19 11:39:24 2009
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 19 Jan 2009 10:39:24 +0000
Subject: [issue2563] embed manifest in windows extensions
In-Reply-To: <1207489949.8.0.458848189984.issue2563@psf.upfronthosting.co.za>
Message-ID: <1232361564.33.0.168179998029.issue2563@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Given bug 4120, this seems the most appropriate resolution...

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2563>
_______________________________________

From report at bugs.python.org  Mon Jan 19 11:43:28 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Jan 2009 10:43:28 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232361808.76.0.829851210615.issue4972@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

positive feedbacks on python-ideas, so I'll start to write the patches.

targets : 

   - smtplib.SMTP
   - imaplib.IMAP4
   - ftplib.FTP

first patch : smtplib

(will do ftplib and imaplib as well, then propose this enhancement to
python-dev)

----------
keywords: +patch
Added file: http://bugs.python.org/file12792/smtplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Mon Jan 19 12:06:38 2009
From: report at bugs.python.org (Muayyad Alsadi)
Date: Mon, 19 Jan 2009 11:06:38 +0000
Subject: [issue4995] sqlite3 module gives SQL logic error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232363198.38.0.929913909213.issue4995@psf.upfronthosting.co.za>


Muayyad Alsadi <alsadi at ojuba.org> added the comment:

same thing

[alsadi at pc1 ~]$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> cn=sqlite3.connect(':memory:')
>>> c=cn.cursor()
>>> c.execute('BEGIN TRANSACTION')
<sqlite3.Cursor object at 0xb7f99da0>
>>> c.execute('create temp table tmp_main (id integer, b text)')
<sqlite3.Cursor object at 0xb7f99da0>
>>> cn.commit()
>>> c.execute('insert into tmp_main (id) values (10);')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
sqlite3.OperationalError: SQL logic error or missing database
>>> 

to make it easy for you to try it yourself

import sqlite3
cn=sqlite3.connect(':memory:')
c=cn.cursor()
c.execute('BEGIN TRANSACTION')
c.execute('create temp table tmp_main (id integer, b text)')
cn.commit() # this was added on your request
c.execute('insert into tmp_main (id) values (10);')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4995>
_______________________________________

From report at bugs.python.org  Mon Jan 19 12:58:13 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 11:58:13 +0000
Subject: [issue4448] should socket readline() use default_bufsize instead of
	_rbufsize?
In-Reply-To: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
Message-ID: <1232366293.94.0.833023900388.issue4448@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Hi,
I'm reawakening this because http://bugs.python.org/issue4879 needs to 
be ported to py3k.
In py3k, a socket.fileobject() is still created with bufsize(0), 
although now the reasoning is different:

 def __init__(self, sock, debuglevel=0, strict=0, method=None):
        # XXX If the response includes a content-length header, we
        # need to make sure that the client doesn't read more than the
        # specified number of bytes.  If it does, it will block until
        # the server times out and closes the connection.  (The only
        # applies to HTTP/1.1 connections.)  Since some clients access
        # self.fp directly rather than calling read(), this is a little
        # tricky.
        self.fp = sock.makefile("rb", 0)

I think that this is just a translation of the old comment, i.e. a 
warning that some people may choose to call .recv() on the underlying 
socket.
Now, this should be far more difficult now, with the newfangled IO 
library and all, and since the sock.makefile() is now a SocketIO object 
which inherits from RawIOBase and all that.  It's tricky to excracth 
the socket to do .recv() on it.  So, I don't think we need to fear 
buffering for readline() anymore.

Or, is the comment about someone doing a HTTPResponse.fp.read() in 
stead of a HTTPResponse.read()?  In that case, I don't see the 
problem.  Of course, anyone reading N characters from a socket stream 
may cause blocking.

My proposal is to remove the comment above and use default buffering 
for the fileobject.  Any thoughts?

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4448>
_______________________________________

From report at bugs.python.org  Mon Jan 19 13:41:22 2009
From: report at bugs.python.org (Somelauw)
Date: Mon, 19 Jan 2009 12:41:22 +0000
Subject: [issue4998] fractions are mutable
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>


New submission from Somelauw <Somelauw at yahoo.com>:

>>> f = Fraction()
>>> f.a = 5
>>> f.__slots__
('_numerator', '_denominator')
>>> f.a
5
>>> f.__dict__
{}

When I create my own object, this doesn't happen.

>>> class Slots:
	__slots__ = ("slot1", "slot2")

	
>>> a = Slots()
>>> a.slot3 = 6
Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    a.slot3 = 6
AttributeError: 'Slots' object has no attribute 'slot3'
>>> 

In python2 this only happens when __slots__ is a tuple. (When __slots__ 
is a list, it works correctly)
>>> class Slots:
	__slots__ = ("slot1", "slot2")

	
>>> a = Slots()
>>> a.slot3 = 8
>>> 

Here is a copy-paste from the python3 documentation:
Without a __dict__ variable, instances cannot be assigned new variables 
not listed in the __slots__ definition. Attempts to assign to an 
unlisted variable name raises AttributeError. If dynamic assignment of 
new variables is desired, then add '__dict__' to the sequence of strings 
in the __slots__ declaration.

Any non-string iterable may be assigned to __slots__. Mappings may also 
be used; however, in the future, special meaning may be assigned to the 
values corresponding to each key.

----------
components: Library (Lib)
messages: 80161
nosy: Somelauw
severity: normal
status: open
title: fractions are mutable
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Mon Jan 19 13:57:25 2009
From: report at bugs.python.org (=?utf-8?q?Fr=C3=A9d=C3=A9ric_Sagnes?=)
Date: Mon, 19 Jan 2009 12:57:25 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>


New submission from Fr?d?ric Sagnes <speedup+python at gmail.com>:

Objects contained in a multiprocessing.Queue object are not comming out
of the queue in the same order as they went in. For instance, if I put
in object1, object2 and object3 in this very time sequence from multiple
processes, they can end up comming out of the queue as object2, object1
then object3 instead of the original order.

When using the threading module instead of multiprocessing everything is
fine.

The provided test script adds strings to the queue with timestamps.
These messages are not ordered by timestamp when they are printed. This
is an output of the test script with format "[pid at time] message":

[2120 at 00406] Got lock
[2120 at 02424] Released lock
[2121 at 02426] Got lock
[2121 at 04439] Released lock
[...]
[2121 at 16459] Released lock
[2120 at 16461] Got lock
[2121 at 18464] Got lock
[2120 at 18462] Released lock
[2121 at 20466] Released lock

Using print to print the message immediatly prints the messages in the
right order.

See this mailing-list thread for details:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/11a5c4ce4ff4382d/033dcd3607eacbf9

----------
components: Extension Modules
files: testthreads.py
messages: 80162
nosy: ndfred
severity: normal
status: open
title: multiprocessing.Queue does not order objects
versions: Python 2.6
Added file: http://bugs.python.org/file12793/testthreads.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Mon Jan 19 13:58:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 12:58:22 +0000
Subject: [issue4995] sqlite3 module gives SQL logic error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232369902.92.0.181051465805.issue4995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've just tried. While it fails in Python 2.5.2, it works in 2.6.1
and in trunk (what will become 2.7). So I suggest you upgrade to 2.6.1,
or simply drop the "BEGIN TRANSACTION" statement in this particular case.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4995>
_______________________________________

From report at bugs.python.org  Mon Jan 19 14:01:46 2009
From: report at bugs.python.org (=?utf-8?q?Fr=C3=A9d=C3=A9ric_Sagnes?=)
Date: Mon, 19 Jan 2009 13:01:46 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232370106.14.0.250717712424.issue4999@psf.upfronthosting.co.za>


Fr?d?ric Sagnes <speedup+python at gmail.com> added the comment:

Tested using Python 2.6.1 on Mac OS 10.5 and Linux 2.6.26

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Mon Jan 19 14:10:56 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 13:10:56 +0000
Subject: [issue4957] os.ftruncate raises IOError instead of OSError
In-Reply-To: <1232060462.22.0.637111039397.issue4957@psf.upfronthosting.co.za>
Message-ID: <1232370656.14.0.424344422572.issue4957@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

submitted as r68763

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4957>
_______________________________________

From report at bugs.python.org  Mon Jan 19 14:28:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 13:28:19 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232371699.15.0.958768755813.issue4996@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, read1() is not documented as a standard method of either IOBase,
RawIOBase or BufferedIOBase. I suggest that it becomes a standard method
of IOBase, with a default implementation simply calling read(n).

It also means unbuffered stdio as it was recently committed doesn't work
for stdin:

$ ./python -u
Python 3.1a0 (py3k:68756, Jan 19 2009, 01:17:26) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.read(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/io.py", line 1739, in read
    eof = not self._read_chunk()
  File "/home/antoine/py3k/__svn__/Lib/io.py", line 1565, in _read_chunk
    input_chunk = self.buffer.read1(self._CHUNK_SIZE)
AttributeError: 'FileIO' object has no attribute 'read1'
>>> 

I had been misguided by the fact that the interpreter prompt did work,
but it doesn't seem to use sys.stdin...

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 14:28:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 13:28:34 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232371714.26.0.962427128757.issue4996@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, read1() is not documented as a standard method of either IOBase,
RawIOBase or BufferedIOBase. I suggest that it becomes a standard method
of IOBase, with a default implementation simply calling read(n).

It also means unbuffered stdio as it was recently committed doesn't work
for stdin:

$ ./python -u
Python 3.1a0 (py3k:68756, Jan 19 2009, 01:17:26) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.read(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/io.py", line 1739, in read
    eof = not self._read_chunk()
  File "/home/antoine/py3k/__svn__/Lib/io.py", line 1565, in _read_chunk
    input_chunk = self.buffer.read1(self._CHUNK_SIZE)
AttributeError: 'FileIO' object has no attribute 'read1'
>>> 

I had been misguided by the fact that the interpreter prompt did work,
but it doesn't seem to use sys.stdin...

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 14:29:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 13:29:18 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232371758.49.0.0294220628766.issue4996@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 14:50:52 2009
From: report at bugs.python.org (0x666)
Date: Mon, 19 Jan 2009 13:50:52 +0000
Subject: [issue5000] multiprocessing - Pool.map() slower about 5 times than
	map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>


New submission from 0x666 <vasiliauskas.agnius at gmail.com>:

I think something wrong with implementation of multiprocessing module.
I`ve run this very simple test on my machine (core 2, vista):
import multiprocessing as mul
from time import time

def f(x):
    return x*x

if __name__ == '__main__':
    print "-------- testing multiprocessing on ",mul.cpu_count(),"cores
----------"
    print ""

    elements = 100000

    pool = mul.Pool(processes=mul.cpu_count())
    t1 = time()
    res_par = pool.map(f, range(elements))
    t2 = time()
    res_seq = map(f, range(elements))
    t3 = time()
    res_app = [pool.apply_async(f,(x,)) for x in range(elements)]
    res_app = [result.get() for result in res_app]
    t4 = time()

    print len(res_seq),"elements","map() time",(t3-t2),"s"
    print len(res_par),"elements","pool.map() time",(t2-t1),"s"
    print len(res_app),"elements","pool.apply_async() time", (t4-t3),"s"
    
    print
    raw_input("press enter to exit...")
__________________________________________
Results:
-------- testing multiprocessing on  2 cores -----------

100000 elements map() time 0.0269 s
100000 elements pool.map() time 0.108 s
100000 elements pool.apply_async() time 10.567 s
--------------------------------------------------------

IMHO, execution on 2 cores should be 1.x - 2 times faster than compared
with non-parallel execution. (at least in simple cases).
If you dont believe in this, check http://www.parallelpython.com/
module (demo example sum_primes.py), which fits very well this idea.

So how it can be that parallel pool.map() method executes in about 5
times SLOWER, than ordinary map() function ?
So please correct multiprocessing package to work in more-less
perfomance predictable way (like parallelpython).

----------
components: Library (Lib)
messages: 80168
nosy: 0x666
severity: normal
status: open
title: multiprocessing - Pool.map() slower about 5 times than map() on 2 cores machine
type: performance
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5000>
_______________________________________

From report at bugs.python.org  Mon Jan 19 14:58:17 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 13:58:17 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232373497.6.0.416293771918.issue4999@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Mon Jan 19 15:46:23 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 14:46:23 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232376383.41.0.300781912398.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Attached is a patch+test for this condition, which is not used if we're 
running on windows.

Added file: http://bugs.python.org/file12794/issue_3321.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 15:46:40 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 14:46:40 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232376400.77.0.925704872411.issue3321@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file10861/_multiprocessing_connection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 15:46:43 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 14:46:43 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232376403.9.0.968186682748.issue3321@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file11007/test_multiprocessing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 15:46:47 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 14:46:47 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232376407.54.0.87716449661.issue3321@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file11485/another_solution.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 15:56:19 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 14:56:19 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232376979.79.0.186051489848.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Curse you hard-tabs. Here's the new patch w/ fixed comment

Added file: http://bugs.python.org/file12795/issue_3321.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 15:56:25 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 14:56:25 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232376985.16.0.400531761321.issue3321@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file12794/issue_3321.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:00:52 2009
From: report at bugs.python.org (Javen Wang)
Date: Mon, 19 Jan 2009 15:00:52 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232377252.48.0.047243357301.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

I'm quite certain that the makefile is generated before the "make"
program is launched in separated process. Follow is the original code
where the makefile is created (line 14) and a task is put in queue (line
19). It's executed in the main thread (no parallel execution here).
There's no way that the process is launched before the makefile generation. 
 
01    for Module in Pa.Platform.Modules:
02        Ma = ModuleAutoGen(Wa, Module, BuildTarget, ToolChain, Arch,
self.PlatformFile)
03        if Ma == None:
04            continue
05        # generate AutoGen files and Makefile here
06        if self.Target not in ['clean', 'cleanlib', 'cleanall', 'run',
'fds']:
07            # for target which must generate AutoGen code and makefile
08            if not self.SkipAutoGen or self.Target == 'genc':
09                Ma.CreateCodeFile(True)
10            if self.Target == "genc":
11                continue
12   
13            if not self.SkipAutoGen or self.Target == 'genmake':
14                Ma.CreateMakeFile(True)
15            if self.Target == "genmake":
16                continue
17
18        # Generate build task for the module which will be launched
separately
19        Bt = BuildTask.New(ModuleMakeUnit(Ma, self.Target))

I think the Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS should not
be used for fsync in the Python core code (in posixmodule.c, right?).
Because fsync is mostly used to solve file operation issue in parallel
execution context, it should not give out CPU time to other threads or
processes when it's running.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:03:45 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 15:03:45 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1232377425.87.0.656749178776.issue4804@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Okay, here is a second patch.
open now verifies the 'mode' string properly, and all uses of a 'fp' 
turn off the CRT error handling temporarily, while holding the GIL

Added file: http://bugs.python.org/file12796/crterror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:08:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 15:08:14 +0000
Subject: [issue5000] multiprocessing - Pool.map() slower about 5 times than
	map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232377694.68.0.898455992858.issue5000@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You should try with something less trivial than your "f" function. For
such a short function, it seems expectable that the dispatch overhead
will dominate the actual computation time.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5000>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:10:45 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:10:45 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232377845.7.0.212759700063.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Removed raise TestSkip per code review from bpeterson

Added file: http://bugs.python.org/file12797/issue_3321.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:10:50 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:10:50 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232377850.73.0.500345662955.issue3321@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file12795/issue_3321.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:12:47 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:12:47 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232377967.09.0.602465904258.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Committed patch as r68768 to python-trunk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:14:38 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Jan 2009 15:14:38 +0000
Subject: [issue4991] os.fdopen doesn't raise on invalid file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232378078.71.0.490257279825.issue4991@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Well, the Windows bot is failing but not from test_fileio, so I'll go
ahead and merge it. r68767.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4991>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:19:04 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:19:04 +0000
Subject: [issue5000] multiprocessing - Pool.map() slower about 5 times than
	map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232378344.72.0.483859100591.issue5000@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5000>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:22:24 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 15:22:24 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232378544.02.0.432585909871.issue3321@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@jnoller: Hey, you removed my patch! My patch used fstat() in 
Connection constructor, whereas your just check file descriptor bounds 
in the poll() method. And what is the "save" new argument? Is it 
related to this issue?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:24:15 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:24:15 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232378655.53.0.607814406019.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

The save was needed for the Py_BLOCK_THREADS call.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:26:36 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:26:36 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232378796.16.0.70844611688.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Ugh, I didn't mean to chuck your original patch, but it also wasn't 
correct for win32

Additionally, if you close the handle from underneath it, it behaves 
properly:

>>> obj.poll()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:28:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Jan 2009 15:28:20 +0000
Subject: [issue5000] multiprocessing - Pool.map() slower about 5 times than
	map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232378900.04.0.630291269187.issue5000@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The multiprocessing module indeed has some overhead:

- the processes are spawned when needed. Before you perform performance
timings, you should "warm up" the Pool with a line like
    pool.map(f, range(mul.cpu_count()))
(starting a process is a slowish operation specially on Windows)
This reduces timings by a factor of two.

- the dispatch overhead of multiprocessing is certainly greater than a
single multiplication. multiprocessing is for CPU-bound functions!
And do not forget that you have *tree* processes here: two from the
Pool, and your main program.

As Antoine said, try with this function instead:

def f(x):
    for i in range(10):
        x = x * x
    return x

And the timings are much better...

----------
assignee: jnoller -> 
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5000>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:32:54 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:32:54 +0000
Subject: [issue5000] multiprocessing - Pool.map() slower about 5 times than
	map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232379174.86.0.377024193436.issue5000@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

My results don't match yours. (8 cores, Mac OS/X):

-------- testing multiprocessing on  8 cores ----------

100000 elements map() time 0.0444118976593 s
100000 elements pool.map() time 0.0366489887238 s
100000 elements pool.apply_async() time 24.3125801086 s

Now, this could be for a variety of reasons: More cores, different OS 
(which means different speed at which processes can be forked) and so 
on. As Antoine/Amaury point out you really need a use case that is large 
enough to offset the cost of forking the processes in the first place.

I also ran this on an 8 core Ubuntu box with kernel 2.6.22.19 and 
py2.6.1 and
16gb of ram:

-------- testing multiprocessing on  8 cores ----------

100000 elements map() time 0.0258889198303 s
100000 elements pool.map() time 0.0339770317078 s
100000 elements pool.apply_async() time 11.0373139381 s

OS/X is pretty snappy when it comes for forking. 

Now, if you cut the example you provided over to Amaury's example, you 
see a significant difference:

OS/X, 8 cores:

-------- testing multiprocessing on  8 cores ----------

100000 elements map() time 30.704061985 s
100000 elements pool.map() time 4.95880293846 s
100000 elements pool.apply_async() time 23.6090102196 s

Ubuntu, kernel 2.6.22.19 and py2.6.1:

-------- testing multiprocessing on  8 cores ----------

100000 elements map() time 38.3818569183 s
100000 elements pool.map() time 5.65878105164 s
100000 elements pool.apply_async() time 14.1757941246 s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5000>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:33:20 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:33:20 +0000
Subject: [issue5000] multiprocessing - Pool.map() slower about 5 times than
	map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232379200.95.0.12527313031.issue5000@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Closing as not an issue.

----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5000>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:33:36 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Jan 2009 15:33:36 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232379216.97.0.0689278231168.issue4998@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The problem is that Fraction inherits from a class without __slots__
(Rationale), so it's useless. I suggest that the __slots__ be removed or
Rationale.register() is used instead of inheritance.

----------
assignee:  -> jyasskin
nosy: +benjamin.peterson, jyasskin
title: fractions are mutable -> __slots__ on Fraction is useless

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:34:52 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Jan 2009 15:34:52 +0000
Subject: [issue5000] multiprocessing - Pool.map() slower about 5 times than
	map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232379292.94.0.625577940453.issue5000@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5000>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:41:40 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:41:40 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232379700.79.0.658229729888.issue3321@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:41:52 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:41:52 +0000
Subject: [issue4065] _multiprocessing doesn't build on macosx 10.3
In-Reply-To: <1223376772.75.0.564119782301.issue4065@psf.upfronthosting.co.za>
Message-ID: <1232379712.43.0.973730934443.issue4065@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4065>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:47:14 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 15:47:14 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232380034.13.0.421432152609.issue3321@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Why don't you check the file descriptor directly in connection_new()? 
conn->handle is read only and so can't be changed before the call to 
poll(). So other methods will also be "protected" and the error will 
be raised earlier.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:49:03 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 15:49:03 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232380143.6.0.695417903257.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

That's an enhancement - not a bad idea, I just noticed that this issue is 
pretty close to issue http://bugs.python.org/issue3311 as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 16:56:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 15:56:19 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232380579.54.0.578467439212.issue3321@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

jnoller> issue #3311

Oh, I forgot this issue :-) But the fix doesn't solve #3311, because 
it is disabled on Windows and only protect poll() method.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:05:34 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:05:34 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1232381134.62.0.596233804976.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Oh, I agree - I think we should update 3311 with the enhancement to move 
the check to connection_new

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:14:02 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Jan 2009 16:14:02 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232381642.8.0.456559200334.issue4996@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

IOBase doesn't even define read(), though! I think we should make it
part of BufferIOBase.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:20:56 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 16:20:56 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232382056.51.0.656554321016.issue4996@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:25:32 2009
From: report at bugs.python.org (Zlm)
Date: Mon, 19 Jan 2009 16:25:32 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232382332.63.0.0379572952725.issue3881@psf.upfronthosting.co.za>


Zlm <zemarialm at gmail.com> added the comment:

I reinstalled Python to "C:\Program Files\Python\" (I wrote this path in
the installer) and IDLE works fine. I can access the Python folder by
going to "C:\Programas\Python".

Then, I unninstalled and installed again to "C:\Programas\Python". IDLE
doesn't work. I can still access the Python folder by going to
"C:\Programas\Python".

Jacob, can you try installing it to "C:\Program Files\Python" to sse if
that works?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:27:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 16:27:27 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232382447.96.0.342000450674.issue4705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening, since sys.stdin is actually broken in unbuffered mode:

$ ./python -u
Python 3.1a0 (py3k:68756, Jan 19 2009, 01:17:26) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdin.read(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/io.py", line 1739, in read
    eof = not self._read_chunk()
  File "/home/antoine/py3k/__svn__/Lib/io.py", line 1565, in _read_chunk
    input_chunk = self.buffer.read1(self._CHUNK_SIZE)
AttributeError: 'FileIO' object has no attribute 'read1'
>>> 

What I propose is that stdin be always opened in buffered mode (even
with -u), since I don't see how the behaviour can differ for a read-only
non-seekable stream.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:30:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 19 Jan 2009 16:30:46 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1232382646.32.0.720015497584.issue4804@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Kristjan, please understanding that setting the CRT error handling is
not thread-safe, and trying to do it in a fine-grained way can cause all
kinds of crazy races. With your patch, the following sequencce of events
is possible if two threads T1 and T2 simultaneously try to access the CRT:

1. T1 saves the old mode (O), installs its own mode (N1)
2. T1 releases the GIL, invokes CRT operation
3. T2 starts running, saves the old mode (N1), installs its own mode (N2)
4. T1 completes, restores the old mode (O)
5. T2 completes, restores the old mode (N1)

As a net result, the original error handling is *not* restored.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:32:42 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:32:42 +0000
Subject: [issue5001] Remove assertion-based checking in multiprocessing
In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za>
Message-ID: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

Right now, the multiprocessing code is littered with statements like:

        assert self._popen is None, 'cannot start a process twice'
        assert self._parent_pid == os.getpid(), \
               'can only start a process object created by current 
process'
        assert not _current_process._daemonic, \
               'daemonic processes are not allowed to have children'

These will obviously be stripped out if running in optimized mode - 
however its not cool to rely on these anyway, the code should be 
refactored to proper checks, e.g.:

    if not hasattr(lock, 'acquire'):
        raise AttributeError("'%r' has no method 'acquire'" % lock)

----------
assignee: jnoller
components: Library (Lib)
messages: 80192
nosy: jnoller
priority: normal
severity: normal
status: open
title: Remove assertion-based checking in multiprocessing
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5001>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:38:54 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:38:54 +0000
Subject: [issue4708] os.pipe should return inheritable descriptors (Windows)
In-Reply-To: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za>
Message-ID: <1232383134.4.0.988088067002.issue4708@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4708>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:40:18 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:40:18 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1232383218.84.0.153653408654.issue3807@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:42:08 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:42:08 +0000
Subject: [issue3272] Multiprocessing hangs when multiprocessing.Pool methods
	are called
In-Reply-To: <1215103718.59.0.127699249536.issue3272@psf.upfronthosting.co.za>
Message-ID: <1232383328.92.0.843355719082.issue3272@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3272>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:42:35 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:42:35 +0000
Subject: [issue3273] multiprocessing and meaningful errors
In-Reply-To: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za>
Message-ID: <1232383355.04.0.704953981775.issue3273@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3273>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:42:58 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:42:58 +0000
Subject: [issue3283] multiprocessing.connection doesn't import
	AuthenticationError, while using it
In-Reply-To: <1215179111.5.0.100147287247.issue3283@psf.upfronthosting.co.za>
Message-ID: <1232383378.25.0.608576401565.issue3283@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3283>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:43:35 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:43:35 +0000
Subject: [issue3093] Namespace polution from multiprocessing
In-Reply-To: <1213300660.18.0.995213086332.issue3093@psf.upfronthosting.co.za>
Message-ID: <1232383415.85.0.596287139729.issue3093@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3093>
_______________________________________

From report at bugs.python.org  Mon Jan 19 17:57:54 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 16:57:54 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232384274.71.0.721657610254.issue4996@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Usage of read1():
 * _BytesIO.read1(n) (_bytesio.c): calls bytesio_read(n)
 * _BytesIO.read1(n) (io.py): return self.read(n)
 * BufferedReader._read_unlocked(n=None): 
   - if n is None or n==-1, call self.raw.read() in a "while 
True: ..." until EOF
   - else, call self.raw.read() until we get enough bytes
 * BufferedReader.read1(n): calls self._read_unlocked(...) but make 
sure that we don't call self.raw.read() more than once
 * BufferedRWPair.read1(n): return self.reader.read1(n)
 * BufferedRandom.read1(n): self.flush(); return BufferedReader.read1
(self, n)
 * TextIOWrapper._read_chunk() calls self.buffer.read1
(self._CHUNK_SIZE)

IOBase, RawIOBase, FileIO, BufferedIOBase, TextIOBase, TextIOWrapper, 
StringIO have no read1() method.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 18:03:58 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 19 Jan 2009 17:03:58 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1232377252.48.0.047243357301.issue4944@psf.upfronthosting.co.za>
Message-ID: <481906.4710.qm@web32805.mail.mud.yahoo.com>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

> I'm quite certain that the makefile is generated before
> the "make"
> program is launched in separated process. Follow is the
> original code
> where the makefile is created (line 14) and a task is put
> in queue (line
> 19). It's executed in the main thread (no parallel
> execution here).
> There's no way that the process is launched before the
> makefile generation. 

It isn't obvious that this is the case, at least to me, due to those "if" and "continue" in the code.
Try instrumenting it a bit and see what happens; a few "print" around lines 14 and 19 should suffice. 

Also, try to come with a *short* example that shows the problem. Remove all irrelevant details: if you write a "constant" makefile and still fails, omit all dependences for makefile generation; if you invoke a simple .exe (like the one I posted) and it still fails, replace the call to nmake.exe. And so on, until you can't remove anything. It may happen that you find yourself the problem doing this.

Another strategy is to start with a simple example that works (like the one I posted) and adding more and more things until it doesn't work anymore.

With the code as it is now, it's difficult to say whether this is a Python bug or not; there are tons of other factors involved.

> I think the Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS
> should not
> be used for fsync in the Python core code (in
> posixmodule.c, right?).
> Because fsync is mostly used to solve file operation issue
> in parallel
> execution context, it should not give out CPU time to other
> threads or
> processes when it's running.

Why not? All I/O operations release the GIL, and that's a good thing. In this case, if (as you assert) the other thread that accesses the file hasn't started yet, it doesn't matter if the GIL is released or not.

      Yahoo! Cocina
Recetas pr?cticas y comida saludable
http://ar.mujer.yahoo.com/cocina/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Mon Jan 19 18:15:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 17:15:59 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232385359.44.0.140322912401.issue4705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

Added file: http://bugs.python.org/file12798/unbuffered-stdin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Mon Jan 19 18:45:21 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 17:45:21 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1232387121.18.0.400542036598.issue4804@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I understand thread-safe.  This usage is safe from Python threads 
because it is all done in the context of the GIL.

It is, however, unsafe if some other random thread is also modifying 
these settings during runtime.

In your example, T2 doesn't hold the GIL and so, this is the scenario 
that I believe you are invoking.

This is however not likely to be the case because these settings are 
normally left alone.  The only reason we have to worry about this is 
because we are allowing through file descriptors that are out of the 
control of compiled C code.  Nobody is likely to be messing with this 
stuff except for us.

Furthermore, since your argument assumes a rogue thread modifying the 
CRT settings, this thread may just as well be active during startup 
when we are modifying these values under the current system.  So there 
is not a fundamental difference here, only a difference in scale.

I think that the drawbacks of modifying the CRT behaviour unexpectedly 
for all code in the process far outweigh the risk of there being 
another unknown thread also heavily modifying these obscure settings.

Now, I can see a compromise we could make.  I could make this a compile 
time choice.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Mon Jan 19 18:50:55 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 17:50:55 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1232387455.02.0.264058241711.issue4804@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ooops, ignore my last comment.
I just realized the point you were making Martin, and it doesn't 
involve rogue threads at all.

Hmm, back to the drawing board, I suppose.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Mon Jan 19 18:59:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 17:59:42 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232387982.19.0.218689047476.issue4996@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Short example to reproduce the problem:
---
import io, os
fd = os.open("/etc/issue", os.O_RDONLY)
raw = open(fd, "rb", buffering=0)
text = io.TextIOWrapper(raw, line_buffering=False)
print(text.read(1))
---

Traceback (most recent call last):
  File "x.py", line 6, in <module>
    print(text.read(1))
  File "/home/SHARE/SVN/py3k/Lib/io.py", line 1739, in read
    eof = not self._read_chunk()
  File "/home/SHARE/SVN/py3k/Lib/io.py", line 1565, in _read_chunk
    input_chunk = self.buffer.read1(self._CHUNK_SIZE)
AttributeError: 'FileIO' object has no attribute 'read1'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 19:02:08 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Jan 2009 18:02:08 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232387982.19.0.218689047476.issue4996@psf.upfronthosting.co.za>
Message-ID: <1afaf6160901191002k7c82662cxc3e6e9d848a3097@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Mon, Jan 19, 2009 at 11:59 AM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Short example to reproduce the problem:
> ---
> import io, os
> fd = os.open("/etc/issue", os.O_RDONLY)
> raw = open(fd, "rb", buffering=0)
> text = io.TextIOWrapper(raw, line_buffering=False)
> print(text.read(1))

You can only use TextIOWrapper over a buffered stream, so this example
is invalid anyway.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 19:10:30 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Jan 2009 18:10:30 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232388630.86.0.554377813252.issue4978@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch works when the unicode contains only ascii, but crashes with
the following input:

>>> def f(hehe): return 42
... 
>>> f(**{u'hehe': 1})
42
>>> f(**{u'h?h?': 1})
Segmentation fault

The two PyString_AsString(keyword) calls are now wrong and should be
changed.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4978>
_______________________________________

From report at bugs.python.org  Mon Jan 19 19:17:59 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 18:17:59 +0000
Subject: [issue4996] io.TextIOWrapper calls buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232389079.69.0.0309001274653.issue4996@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand the motivation of having two different methods 
for "raw" streams: read1() and read(). I would prefer to have only a 
method read() (because "read" is the most common name, whereas read1() 
is only used on Python3), but read() will have to follow the read1() 
rule: at most one syscall. If someone requires a read() method with 
the "one syscall" rule, he can use a raw stream. If you don't care, 
use high level classes (TextIOWrapper, BufferedReader, etc.).

_fileio._FileIO.read() and _socket.socket.recv_into() already respect 
the syscall rule.

Since BytesIO and StringIO don't use kernel object, the syscall rule 
is meaningles.

Note: socket.SocketIO() implements RawIOBase but it has no read() nor 
write() methods ;-) That's maybe why IOBase has no read()/write() 
method.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4996>
_______________________________________

From report at bugs.python.org  Mon Jan 19 19:46:13 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jan 2009 18:46:13 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232390773.1.0.213172759967.issue4972@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What is the rationale for swallowing all socket exceptions except 
"Connection reset by peer" in __exit__? In any case, it is better to use errno.ECONNRESET instead of literal 54.

Note that SMTP.quit() calls SMTP.close(), so in the normal termination 
case, close will be called twice.  This is not a real problem since SMTP.close() is a noop on a closed SMTP object, but it does not look 
right.

The double call to close() also makes error path harder to analyze.  It 
appears that if a socket error is raised in the first call to close, it 
gets caught only to be raised again in the second call (assuming a 
persistent error).

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Mon Jan 19 20:01:23 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Jan 2009 19:01:23 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232391683.93.0.000703948725121.issue4972@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> What is the rationale for swallowing all socket exceptions except 
> "Connection reset by peer" in __exit__? 

I am catching just the error that raises if the connection is closed
when calling quit()


> In any case, it is better to use errno.ECONNRESET instead of literal 54.

Right

> Note that SMTP.quit() calls SMTP.close(), so in the normal termination 
> case, close will be called twice.  This is not a real problem since 
> SMTP.close() is a noop on a closed SMTP object, but it does not look 
> right.

Right i'll fix that

Thanks for teh feedback
The double call to close() also makes error path harder to analyze.  It 
appears that if a socket error is raised in the first call to close, it 
gets caught only to be raised again in the second call (assuming a 
persistent error).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Mon Jan 19 20:03:48 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 19 Jan 2009 19:03:48 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232391828.31.0.77514692072.issue4972@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Added file: http://bugs.python.org/file12799/ftplib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Mon Jan 19 20:14:44 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 19 Jan 2009 19:14:44 +0000
Subject: [issue5002] multiprocessing/pipe_connection.c compiler warning
	(conn_poll)
In-Reply-To: <1232392483.91.0.505084549833.issue5002@psf.upfronthosting.co.za>
Message-ID: <1232392483.91.0.505084549833.issue5002@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I got compiler warning "conn_poll takes too many arguments".
I hope the attached patch is right fix.

----------
components: Library (Lib)
files: pipe_connection_c.patch
keywords: patch
messages: 80204
nosy: ocean-city
severity: normal
status: open
title: multiprocessing/pipe_connection.c compiler warning (conn_poll)
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file12800/pipe_connection_c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5002>
_______________________________________

From report at bugs.python.org  Mon Jan 19 20:17:11 2009
From: report at bugs.python.org (0x666)
Date: Mon, 19 Jan 2009 19:17:11 +0000
Subject: [issue5000] multiprocessing - Pool.map() slower about 5 times than
	map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232392631.43.0.537068028857.issue5000@psf.upfronthosting.co.za>


0x666 <vasiliauskas.agnius at gmail.com> added the comment:

Thanks for quick response and for informative answers, especially 
thanks to Antoine Pitrou/Amaury Forgeot.

p.s.
By seting bigger range - range(15) and elements = 1000, I was able to 
get speed-up factor up to 1.8. Wow, I`m amazed :-)
Good library, keep it up.
BTW, about warp-up,- forking first processes. User can forget 
to "warpup" pool. It would be cool if pool somehow warm-ups itself in 
initialization phase (in step mul.Pool(processes=mul.cpu_count())).
Maybe you can define another initialization parameter=function ? (if 
not None, first processes should be spawned, not waiting map function) 
or something like that. But it is only cosmetics :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5000>
_______________________________________

From report at bugs.python.org  Mon Jan 19 20:19:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Jan 2009 19:19:20 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232392760.29.0.703206834624.issue4978@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This patch should fix that.

Added file: http://bugs.python.org/file12801/unicode_keyword_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4978>
_______________________________________

From report at bugs.python.org  Mon Jan 19 21:26:33 2009
From: report at bugs.python.org (Sravani Gogineni)
Date: Mon, 19 Jan 2009 20:26:33 +0000
Subject: [issue5003] Error while installing Python-3
In-Reply-To: <1232396793.72.0.127068504094.issue5003@psf.upfronthosting.co.za>
Message-ID: <1232396793.72.0.127068504094.issue5003@psf.upfronthosting.co.za>


New submission from Sravani Gogineni <goginenis at corning.com>:

i was trying to install python 3 using the folowing command 
$ python setup.py --home=~/python3

and i got the below error:

  File "setup.py", line 232
    except (CCompilerError, DistutilsError) as why:
                                             ^
SyntaxError: invalid syntax

Could anyone please help me with the problem?

Thanks,
Vani

----------
components: Installation
messages: 80207
nosy: goginenis at corning.com
severity: normal
status: open
title: Error while installing Python-3
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5003>
_______________________________________

From report at bugs.python.org  Mon Jan 19 21:52:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 20:52:17 +0000
Subject: [issue5003] Error while installing Python-3
In-Reply-To: <1232396793.72.0.127068504094.issue5003@psf.upfronthosting.co.za>
Message-ID: <1232398337.45.0.260964488757.issue5003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

setup.py is not meant to be called directly (it will be called by the
Python 3 interpreter as part of the build process and is, therefore,
written in Python 3 syntax).

The proper command sequence to build and install Python is:

./configure --prefix=~/python3
make
make install

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5003>
_______________________________________

From report at bugs.python.org  Mon Jan 19 22:06:45 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 19 Jan 2009 21:06:45 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1232399205.66.0.885693952438.issue4804@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here is what I think is a better attempt at the selective-disabling.  I 
did away with the messy macros and added a function in errors.c.  This 
maintans a global 'level' variable, implicitly guarded by the GIL.  Now 
only the thread that first enters a guarded block will set the hendler, 
and the thread that is last to leave will reset it.  This should 
guarantee that between the two macros, our custom handler is set, and 
that no thread pulls the rug from underneath another.

Added file: http://bugs.python.org/file12802/crterror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Mon Jan 19 22:21:58 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jan 2009 21:21:58 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232391683.93.0.000703948725121.issue4972@psf.upfronthosting.co.za>
Message-ID: <d38f5330901191321o4ccb01bcv3b4dcc12a332b473@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Jan 19, 2009 at 2:01 PM, Tarek Ziad? <report at bugs.python.org> wrote:
>
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
>
>> What is the rationale for swallowing all socket exceptions except
>> "Connection reset by peer" in __exit__?
>
> I am catching just the error that raises if the connection is closed
> when calling quit()
>

I see. I misread the double negative "except errno NOT equals 54", but
I still don't see the rationale for that exception.  I any case, I
don't think your patch implements that because SMTP transforms socket
errors into SMTPServer* errors in send():

        if self.sock:
            try:
                self.sock.sendall(str)
            except socket.error:
                self.close()
                raise SMTPServerDisconnected('Server not connected')
        else:
            raise SMTPServerDisconnected('please run connect() first')

so you will never see a socket error from quit().

Furthermore, I don't think you should ignore return code from quit():
you should raise an error if it returns anything but 221.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Mon Jan 19 22:27:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 21:27:42 +0000
Subject: [issue4862] utf-16 BOM is not skipped after seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <1232400462.41.0.336183679251.issue4862@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I support Amaury's suggestion (actually I implemented it in the io-c
branch). Resetting the decoder when seeking to the beginning of the
stream is a reasonable way to deal with those incremental decoders for
which the start state is something else than (b"", 0).

(and, you're right, opening in append mode is a different problem...)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4862>
_______________________________________

From report at bugs.python.org  Mon Jan 19 22:35:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Jan 2009 21:35:40 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232400940.75.0.0870439151473.issue4998@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I believe that __slots__ was used for performance (memory, speed) reasons 
here rather than for preventing random attribute assignments.  But maybe 
inheriting from Rational invalidates those reasons as well...

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Mon Jan 19 22:37:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Jan 2009 21:37:23 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232401043.38.0.446807977269.issue4998@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The Decimal class has the same issue in py3k (but not in the trunk).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Mon Jan 19 22:56:45 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 19 Jan 2009 21:56:45 +0000
Subject: [issue4448] should socket readline() use default_bufsize instead of
	_rbufsize?
In-Reply-To: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
Message-ID: <1232402205.48.0.912915971319.issue4448@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4448>
_______________________________________

From report at bugs.python.org  Mon Jan 19 23:14:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 19 Jan 2009 22:14:21 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1232387121.18.0.400542036598.issue4804@psf.upfronthosting.co.za>
Message-ID: <4974FB3A.70809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I understand thread-safe.  This usage is safe from Python threads 
> because it is all done in the context of the GIL.

No, it is not. See below.

> In your example, T2 doesn't hold the GIL and so, this is the scenario 
> that I believe you are invoking.

Assume that T2 is a Python thread. First, it doesn't hold the GIL.
However, when T1 releases the GIL to invoke the CRT, T2 can acquire
the GIL (which it had been waiting for, anyway), and then proceed
as described.

> Furthermore, since your argument assumes a rogue thread modifying the 
> CRT settings

No, it does not. Regular Python threads can break under this patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Mon Jan 19 23:14:59 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 19 Jan 2009 22:14:59 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1232387455.02.0.264058241711.issue4804@psf.upfronthosting.co.za>
Message-ID: <4974FB61.5030703@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Ooops, ignore my last comment.

(sorry, too late - I only read this after responding to the earlier one)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Mon Jan 19 23:23:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 19 Jan 2009 22:23:04 +0000
Subject: [issue4922] set.add and set.discard are not conformant to
	collections.MutableSet interface
In-Reply-To: <1231759440.37.0.125734005136.issue4922@psf.upfronthosting.co.za>
Message-ID: <1232403784.62.0.237888884135.issue4922@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4922>
_______________________________________

From report at bugs.python.org  Mon Jan 19 23:29:03 2009
From: report at bugs.python.org (Daniel Frnake)
Date: Mon, 19 Jan 2009 22:29:03 +0000
Subject: [issue5004] socket.getfqdn() doesn't cope properly with purely
	DNS-based setups
In-Reply-To: <1232404142.93.0.545475464378.issue5004@psf.upfronthosting.co.za>
Message-ID: <1232404142.93.0.545475464378.issue5004@psf.upfronthosting.co.za>


New submission from Daniel Frnake <dfranke at wellohorld.com>:

On Linux and presumably on other POSIX-like systems, socket.getfqdn()
doesn't work if a system resolves its own FQDN using DNS rather than
/etc/hosts.

My system's FQDN is 'fugue.tank.wellohorld.com'.  My /etc/hosts is empty
except for loopback entries, and /etc/resolv.conf contains the line
'domain tank.wellohorld.com'.  This is sufficient for 'hostname -f' to
do the Right Thing, but socket.getfqdn() simply returns 'fugue':

dfranke at fugue:~/Python-2.6.1$ hostname
fugue
dfranke at fugue:~/Python-2.6.1$ hostname -f
fugue.tank.wellohorld.com
dfranke at fugue:~/Python-2.6.1$ ./python
Python 2.6.1 (r261:67515, Jan 19 2009, 13:56:59)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn()
'fugue'
>>>
dfranke at fugue:~/Python-2.6.1$ echo -e '$a\n172.17.0.120
fugue.tank.wellohorld.com fugue\n.\nwq' | sudo ed /etc/hosts
305
350
dfranke at fugue:~/Python-2.6.1$ ./python
Python 2.6.1 (r261:67515, Jan 19 2009, 13:56:59)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn()
'fugue.tank.wellohorld.com'
>>>
dfranke at fugue:~/Python-2.6.1$

----------
components: Library (Lib)
messages: 80216
nosy: dfranke
severity: normal
status: open
title: socket.getfqdn() doesn't cope properly with purely DNS-based setups
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5004>
_______________________________________

From report at bugs.python.org  Mon Jan 19 23:33:59 2009
From: report at bugs.python.org (Daniel Franke)
Date: Mon, 19 Jan 2009 22:33:59 +0000
Subject: [issue5004] socket.getfqdn() doesn't cope properly with purely
	DNS-based setups
In-Reply-To: <1232404142.93.0.545475464378.issue5004@psf.upfronthosting.co.za>
Message-ID: <1232404439.96.0.130365704842.issue5004@psf.upfronthosting.co.za>


Changes by Daniel Franke <dfranke at wellohorld.com>:


----------
components: +Extension Modules -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5004>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:05:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Jan 2009 23:05:06 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232406306.9.0.891362438163.issue4978@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry, but _PyUnicode_AsDefaultEncodedString returns either a borrowed reference (if 
errors==NULL) or a new reference (if errors!=NULL).
In either case it's wrong to DECREF the string when you simply take the buffer's 
address:

>>> f(**{u'someLongString':2})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() got an unexpected keyword argument '???????gString'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4978>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:15:10 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Jan 2009 23:15:10 +0000
Subject: [issue5005] 3.0 sqlite doc: most refers to pysqlite2, use 2.x syntax.
In-Reply-To: <1232406910.8.0.623178386993.issue5005@psf.upfronthosting.co.za>
Message-ID: <1232406910.8.0.623178386993.issue5005@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

1. Several examples start with
>>> from pysqlite2 import dbapi2 as sqlite3

Traceback (most recent call last):
  File "<pyshell#23>", line 1, in <module>
    from pysqlite2 import dbapi2 as sqlite3
ImportError: No module named pysqlite2

I presume that should be just 'import sqlite3'.

2. Print statements need conversion and future import deleted (2to3?).

3. Cut and paste crashes due to 'bad' blank line.  For instance,
# A minimal SQLite shell for experiments
...
>>> while True:
...     line = raw_input()
...     if line == "":
...         break
...     buffer += line
...     if sqlite3.complete_statement(buffer):
...         try:
...             buffer = buffer.strip()
...             cur.execute(buffer)
...
  File "<stdin>", line 10

    ^
IndentationError: unexpected unindent
>>>             if buffer.lstrip().upper().startswith("SELECT"):
  File "<stdin>", line 1
    if buffer.lstrip().upper().startswith("SELECT"):
    ^
IndentationError: unexpected indent

----------
messages: 80218
nosy: tjreedy
severity: normal
status: open
title: 3.0 sqlite doc: most refers to pysqlite2, use 2.x syntax.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5005>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:20:30 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Jan 2009 23:20:30 +0000
Subject: [issue5002] multiprocessing/pipe_connection.c compiler warning
	(conn_poll)
In-Reply-To: <1232392483.91.0.505084549833.issue5002@psf.upfronthosting.co.za>
Message-ID: <1232407230.24.0.655947156314.issue5002@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

On Windows only, since r68768. Patch seems OK to me.

----------
assignee:  -> jnoller
nosy: +amaury.forgeotdarc, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5002>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:22:46 2009
From: report at bugs.python.org (Muayyad Alsadi)
Date: Mon, 19 Jan 2009 23:22:46 +0000
Subject: [issue4995] sqlite3 module gives SQL logic error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232407366.41.0.110549164296.issue4995@psf.upfronthosting.co.za>


Muayyad Alsadi <alsadi at ojuba.org> added the comment:

can you please tell me how to detect the version so that my application
will not crash on Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) 

which of these values should I use
    apilevel = '2.0'
    sqlite_version = '3.5.9'
    sqlite_version_info = (3, 5, 9)
    version = '2.3.2'
    version_info = (2, 3, 2)
    x = '9'

that are different in your python 2.6
for example
import sqlite3
if sqlite3.version_info<(3,0,0): c.execute('BEGIN TRANSACTION')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4995>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:24:35 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 23:24:35 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Copy/paste of message79330 from the issue #4862:
--------------
>>> f = open('utf16.txt', 'w', encoding='utf-16')
>>> f.write('abc')
3
>>> f.close()

>>> f = open('utf16.txt', 'a', encoding='utf-16')
>>> f.write('def')
3
>>> f.close()
>>> open('utf16.txt', 'r', encoding='utf-16').read()
'abc\ufeffdef'
--------------

----------
messages: 80221
nosy: haypo
severity: normal
status: open
title: Duplicate UTF-16 BOM if a file is open in append mode
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:25:00 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 23:25:00 +0000
Subject: [issue4862] utf-16 BOM is not skipped after seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <1232407500.9.0.619051376862.issue4862@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I opened a different issue (#5006) for the duplicate BOM in append 
mode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4862>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:37:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 23:37:23 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1232408243.22.0.713871931179.issue5006@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Bug is reproductible with:
 * Python 2.5 : charset utf-8-sig and utf-16 for codecs.open()
 * trunk : charset utf-8-sig, utf-16 and utf-32 for codecs.open()
 * py3k : charset utf-8-sig, utf-16 and utf-32 for open()

With utf-7 or utf-8, no BOM is written.

Note: with UTF-32, the BOM is 4 bytes long (0xff 0xfe 0x00 0x00 on 
little endian) but it's still the character (BOM) \ufeff (little 
endian).

----------
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:45:10 2009
From: report at bugs.python.org (ak)
Date: Mon, 19 Jan 2009 23:45:10 +0000
Subject: [issue5007] urllib2 HTTPS connection failure (BadStatusLine Exception)
In-Reply-To: <1232408710.01.0.641128080754.issue5007@psf.upfronthosting.co.za>
Message-ID: <1232408710.01.0.641128080754.issue5007@psf.upfronthosting.co.za>


New submission from ak <aktests at gmail.com>:

https://www.orange.sk/ is served by an Oracle HTTPS server, and works
with firefox or opera but not urllib2.

code snippet:

--------
import cookiejar
import urllib2

cookiejar = cookielib.LWPCookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))
url = 'https://www.orange.sk/'
req = urllib2.Request(url, None)
s=opener.open(req)
-------- 

Here's some output with debuglevel=1 :

>>> opener.open(urllib2.Request('http://www.orange.sk/', None, headers))

reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Mon, 19 Jan 2009 21:44:03 GMT
header: Server: Oracle-Application-Server-10g/10.1.3.1.0 Oracle-HTTP-
Server
header: Set-Cookie:
JSESSIONID=0a19055a30d630c427bda71d4e26a37ca604b9f590dc.e3eNaNiRah4Pe3aSch8Sc3yOc40;
path=/web
header: Expires: Mon, 19 Jan 2009 21:44:13 GMT
header: Surrogate-Control: max-age="10"
header: Content-Type: text/html; charset=ISO-8859-2
header: X-Cache: MISS from www.orange.sk
header: Connection: close
header: Transfer-Encoding: chunked
<addinfourl at 137417292 whose fp = <socket._fileobject object at
0x831348c>>

>>> opener.open(urllib2.Request('https://www.orange.sk/', None, headers))

reply: ''
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/urllib2.py", line 381, in open
    response = self._open(req, data)
  File "/usr/lib/python2.5/urllib2.py", line 399, in _open
    '_open', req)
  File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.5/urllib2.py", line 1115, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.5/urllib2.py", line 1080, in do_open
    r = h.getresponse()
  File "/usr/lib/python2.5/httplib.py", line 928, in getresponse
    response.begin()
  File "/usr/lib/python2.5/httplib.py", line 385, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.5/httplib.py", line 349, in _read_status
    raise BadStatusLine(line)
httplib.BadStatusLine 

As you can see the reply from the server seems empty (which results in
the BadStatusLine exception)

----------
components: Library (Lib)
messages: 80224
nosy: ak
severity: normal
status: open
title: urllib2 HTTPS connection failure (BadStatusLine Exception)
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5007>
_______________________________________

From report at bugs.python.org  Tue Jan 20 00:46:29 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Jan 2009 23:46:29 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232408789.88.0.983638209667.issue4998@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Arghh!  Decimal is NOT supposed to inherit or register with numbers. 
Guido has pronounced on this and we've discussed it multiple times.  See
the comments in numbers.py which were supposed to serve as a reminder. 
  Decimals are not interoperable with floats.  All instances of Real are
supposed to interoperate but Decimal('1.1') does not add to float(1.1).

Please rip this out of Py3.0's Decimal module.

----------
nosy: +rhettinger
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 01:03:07 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Jan 2009 00:03:07 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232409787.77.0.779452381686.issue4998@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

For the Fractions issue, consider adding an empty __slots__ declaration
to every level in numbers.py.  That will preclude unintended dictionary
creation for anything inheriting from the numbers abcs.

We should also be an issue for the other abcs.  The collections ABCs are
less affected because they are not as granular as number objects.  So
their overall memory footprint only grows by a small percentage from the
inclusion of an instance dictionary.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 01:03:31 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Jan 2009 00:03:31 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232409811.74.0.820796920744.issue4998@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Py3.0.1 should not go out without this being fixed.

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 01:12:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 00:12:20 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1232410340.17.0.599197174268.issue5006@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Tue Jan 20 01:18:20 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 20 Jan 2009 00:18:20 +0000
Subject: [issue5002] multiprocessing/pipe_connection.c compiler warning
	(conn_poll)
In-Reply-To: <1232392483.91.0.505084549833.issue5002@psf.upfronthosting.co.za>
Message-ID: <1232410700.44.0.568244826566.issue5002@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

checked in, trunk, r68787 tests pass. Sorry about that, don't have a 
windows machine handy and I hadn't had a chance to check the buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5002>
_______________________________________

From report at bugs.python.org  Tue Jan 20 01:25:56 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 20 Jan 2009 00:25:56 +0000
Subject: [issue5002] multiprocessing/pipe_connection.c compiler warning
	(conn_poll)
In-Reply-To: <1232392483.91.0.505084549833.issue5002@psf.upfronthosting.co.za>
Message-ID: <1232411156.07.0.354368056498.issue5002@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

r68788 on py3k

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5002>
_______________________________________

From report at bugs.python.org  Tue Jan 20 01:49:30 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Jan 2009 00:49:30 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following code must display 3 instead of 0:
---
with open("x", "w") as f:
    f.write("xxx")
with open("x", "a") as f:
    print(f.tell())
---

The example works with Python 2.x, because file object is implemented 
using the FILE structure (fopen, ftell, etc.). fopen() "fixes" the 
offset if the file is opened in append mode, whereas open() doesn't do 
this for us :
---
import os
with open("x", "w") as f:
    f.write("xxx")
fd = os.open("x", os.O_RDONLY | os.O_APPEND)
print(os.lseek(fd, 0, 1))
---
display 0 instead of 3 on Python 2.x and 3.x.

It becomes a little bit more weird when you write something :-)
---
with open("x", "w") as f:
    f.write("xxx")
with open("x", "a") as f:
    f.write("y")
    print(f.tell())
---
displays... 4 (the correct position) on Python 2.x and 3.x.

I see (in GNU libc source code) that fopen() call lseek(fd, 0, 
SEEK_END) if the file is opened in append mode.

----------
messages: 80230
nosy: haypo
severity: normal
status: open
title: Wrong tell() result for a file opened in append mode
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Tue Jan 20 01:53:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 00:53:56 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232412836.21.0.938972319042.issue5008@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> release blocker
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Tue Jan 20 02:00:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Jan 2009 01:00:38 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232413238.8.0.958689217898.issue5008@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch _including a test_:

+	if (append)
+		lseek(self->fd, 0, SEEK_END);

----------
keywords: +patch
Added file: http://bugs.python.org/file12803/fileio_append.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Tue Jan 20 02:01:40 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Jan 2009 01:01:40 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232413300.86.0.753273096784.issue5008@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12803/fileio_append.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Tue Jan 20 02:02:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Jan 2009 01:02:27 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232413347.9.0.360713642123.issue5008@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file12804/fileio_append.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Tue Jan 20 02:20:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Jan 2009 01:20:13 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232414413.26.0.569855638764.issue4978@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Interesting, I didn't know that about _PyUnicode_AsDefaultEncodedString.
Here's another patch.

Added file: http://bugs.python.org/file12805/unicode_kwargs3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4978>
_______________________________________

From report at bugs.python.org  Tue Jan 20 04:07:14 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 20 Jan 2009 03:07:14 +0000
Subject: [issue5005] 3.0 sqlite doc: most examples refer to pysqlite2,
	use 2.x syntax.
In-Reply-To: <1232406910.8.0.623178386993.issue5005@psf.upfronthosting.co.za>
Message-ID: <1232420834.09.0.853994301687.issue5005@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: 3.0 sqlite doc: most refers to pysqlite2, use 2.x syntax. -> 3.0 sqlite doc: most examples refer to pysqlite2, use 2.x syntax.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5005>
_______________________________________

From report at bugs.python.org  Tue Jan 20 05:03:02 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 20 Jan 2009 04:03:02 +0000
Subject: [issue3826] Problem with SocketIO for closing the socket
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1232424182.36.0.966987563388.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

backported to release30-maint in r68796.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Jan 20 05:16:55 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 20 Jan 2009 04:16:55 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1232425015.58.0.274745745762.issue4428@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file12157/issue4428-io-bufwrite-gps02.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Tue Jan 20 06:03:51 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 20 Jan 2009 05:03:51 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1232427831.87.0.877565287405.issue4428@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Added file: http://bugs.python.org/file12806/issue4428-io-bufwrite-gps04.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Tue Jan 20 06:07:07 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 20 Jan 2009 05:07:07 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1232428027.29.0.956098438254.issue4428@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Updated patch with unit tests to verify the write behavior attached in
-gps04.  Up for code review at http://codereview.appspot.com/12470/show

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Tue Jan 20 06:07:20 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 20 Jan 2009 05:07:20 +0000
Subject: [issue4428] io.BufferedWriter does not observe buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1232428040.24.0.370793102015.issue4428@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file12158/issue4428-io-bufwrite-gps03.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Tue Jan 20 08:29:26 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Jan 2009 07:29:26 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232436566.64.0.256129717431.issue4998@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed the decimal issue in r68800 and r68799 .

Still needs a fix to Fractions, preferably adding an empty __slots__ to
all levels of numbers.py.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 10:00:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 09:00:26 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232442026.83.0.846727683636.issue4977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Tue Jan 20 10:03:18 2009
From: report at bugs.python.org (Javen Wang)
Date: Tue, 20 Jan 2009 09:03:18 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232442198.77.0.523727743682.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

I did trace the order of file creation and process launch. It shows the
file is indeed created before the process launch.

I did another investigation. I added a new process, "cmd.exe /c copy
Makefile NewMakefile", to copy the the Makefile created, just before
launching the "nmake.exe" process. The strangest thing happened again:
each makefile was copied successful but there's still "makefile not
found" reported by "nmake.exe" process. I tried standalone copy
application "xcopy.exe" and the result was the same. So I guess that
"cmd.exe", "xcopy.exe" and "nmake.exe" might use different families of
API or different mode (sync vs async) to access file.

I decided to try the code you provided. In checkfile.c, fopen is used to
test the file existence. I changed it to the Windows native API
CreateFile and I also added a file write operation in order to make it
more similar to the real case. Eventually, the problem was reproduced in
your code. Following are the successful number of creating 1000 files 5
times in different file sizes:

Create file in 403 bytes,
  985, 992, 984, 989, 992 (no flush after creation)
  883, 886, 907, 909, 915 (flush after creation)
  
Create file in 4061 bytes
  983, 976, 982, 977, 983 (no flush after creation)
  654, 672, 684, 686, 648 (flush after creation)
  
Create file in 16461 bytes:
  970, 967, 963, 963, 971 (no flush after creation)
  598, 664, 711, 653, 623 (flush after creation)

In summary:
  a. Using fopen to test a file existence in check_file.c will never
report failure, no matter buffer is flushed or not.
  b. Using CreateFile (read mode) to test a file existence in
check_file.c will always report failure. The bigger the file size will
cause more failure reported; the flush operation after file creation in
test_file_flush.py will cause more failure reported; the flush operation
after new file creation in check_file.c will cause more failure
reported; no flush operation in both check_file.c and test_file_flush.py
almost cause no failure.

I don't know what's root cause: GIL, Python thread state switch, Python
file buffer or Windows FileCreate API. I'm just certain there's race
condition between Python and Windows.

Added file: http://bugs.python.org/file12807/checkfile.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Tue Jan 20 10:05:40 2009
From: report at bugs.python.org (Javen Wang)
Date: Tue, 20 Jan 2009 09:05:40 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232442339.81.0.780111458162.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

The test code and script which can reproduce the problem has been uploaded.

Added file: http://bugs.python.org/file12808/test_file_flush.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Tue Jan 20 10:22:52 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 20 Jan 2009 09:22:52 +0000
Subject: [issue5009] multiprocessing: failure in manager._debug_info()
In-Reply-To: <1232443372.05.0.683507657371.issue5009@psf.upfronthosting.co.za>
Message-ID: <1232443372.05.0.683507657371.issue5009@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

http://mail.python.org/pipermail/python-checkins/2009-January/077474.html
probably indicates some other error in the manager's shared objects, but
the debug_info() function fails to display anything.

It seems that most keys in id_to_obj are strings ('%x' % id(obj)) except
the first one which is zero. And since python 3, you cannot compare 0
and '1' anymore...

Patch attached. I'm not sure whether this zero is used elsewhere...
and BTW, what is it useful for?

----------
assignee: jnoller
files: mp_zeroid.patch
keywords: needs review, patch
messages: 80239
nosy: amaury.forgeotdarc, jnoller
severity: normal
status: open
title: multiprocessing: failure in manager._debug_info()
versions: Python 3.0
Added file: http://bugs.python.org/file12809/mp_zeroid.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5009>
_______________________________________

From report at bugs.python.org  Tue Jan 20 10:40:33 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 20 Jan 2009 09:40:33 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232444433.68.0.240499437631.issue4978@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4978>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:12:18 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Tue, 20 Jan 2009 11:12:18 +0000
Subject: [issue5010] repoened "test_maxint64 fails on 32-bit systems due to
	assumption that 64-bit fits into "long"" due to it being closed
	without asking me whether there was anything else involved
In-Reply-To: <1232449938.32.0.409064545439.issue5010@psf.upfronthosting.co.za>
Message-ID: <1232449938.32.0.409064545439.issue5010@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

this is reopening http://bugs.python.org/issue4977 because it was closed
without asking whether there was any further information or anything
else that required investigation.

there is no way for me to reopen the bug so i am forced to open a
new one.

mark - don't do that again, please.

the suggestion to use PyOS_strtol was a good one: you should have
left the bug as-is after that suggestion, and WAITED until i had
tested that.

the bug involves 64-bit zip files.

the fact that a 32-bit int is being returned, as -4932893211 (whatever)
instead of 44951 (whatever) is causing the problem.

so will you be kind enough and courteous enough to wait until
i have provided full information and investigated this issue?

or do you not want me to bother?

----------
components: Build
messages: 80241
nosy: lkcl, marketdickinson
severity: normal
status: open
title: repoened "test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into "long"" due to it being closed without asking me whether there was anything else involved
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5010>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:12:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 11:12:51 +0000
Subject: [issue5011] issue4428 - make io.BufferedWriter observe
	max_buffer_size limits
In-Reply-To: <0016e644ddec7c678f0460e81ef8@google.com>
Message-ID: <0016e644ddec7c678f0460e81ef8@google.com>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://codereview.appspot.com/12470/diff/1/2
File Lib/io.py (right):

http://codereview.appspot.com/12470/diff/1/2#newcode1055
Line 1055: # b is an iterable of ints, it won't always support len().
There is no reason for write() to accept arbitrary iterable of ints,
only bytes-like and buffer-like objects. It will make the code simpler.

http://codereview.appspot.com/12470/diff/1/2#newcode1060
Line 1060: # No buffer API?  Make intermediate slice copies instead.
Objects without the buffer API shouldn't be supported at all.

http://codereview.appspot.com/12470/diff/1/2#newcode1066
Line 1066: while chunk and len(self._write_buf) > self.buffer_size:
What if buffer_size == max_buffer_size? Is everything still written ok?

http://codereview.appspot.com/12470/diff/1/2#newcode1070
Line 1070: written += e.characters_written
e.characters_written can include bytes which were already part of the
buffer before write() was called, but the newly raised BlockingIOError
should only count those bytes which were part of the object passed to
write().

http://codereview.appspot.com/12470/diff/1/3
File Lib/test/test_io.py (right):

http://codereview.appspot.com/12470/diff/1/3#newcode496
Line 496: def testWriteNoLengthIterable(self):
This shouldn't work at all. If it works right now, it is only a
side-effect of the implementation.
(it won't work with FileIO, for example)

http://codereview.appspot.com/12470

----------
messages: 80242
nosy: gregory.p.smith, pitrou
severity: normal
status: open
title: issue4428 - make io.BufferedWriter observe max_buffer_size limits

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5011>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:19:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 11:19:40 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232450380.77.0.333995344016.issue4977@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening at OP's request.

----------
nosy: +pitrou
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:20:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 11:20:38 +0000
Subject: [issue5010] repoened "test_maxint64 fails on 32-bit systems due to
	assumption that 64-bit fits into "long"" due to it being closed
	without asking me whether there was anything else involved
In-Reply-To: <1232449938.32.0.409064545439.issue5010@psf.upfronthosting.co.za>
Message-ID: <1232450438.9.0.671333366353.issue5010@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Let's put everything in one place :)

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into "long"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5010>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:22:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 11:22:16 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232450536.06.0.0857719526213.issue4977@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Two comments:
- please be more specific when mentioning a problem (when reading your
bug report, I had a hard time figuring out what "test_maxint64" could be)
- I hope you're testing against trunk or at least 2.6, because the 2.5
branch will only receive security fixes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:30:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 11:30:48 +0000
Subject: [issue5011] issue4428 - make io.BufferedWriter observe
	max_buffer_size limits
In-Reply-To: <0016e644ddec7c678f0460e81ef8@google.com>
Message-ID: <1232451048.31.0.521029095754.issue5011@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Mmmh, adding <report at bugs.python.org> in the Rietveld CC field didn't
have the expected effect :)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5011>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:32:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 11:32:02 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232451122.09.0.213914501258.issue4977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Luke,

I closed this as invalid because it's not a Python bug:  your system's
strtol is buggy, so your bug report should go elsewhere.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:40:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 11:40:45 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232451645.89.0.19220507025.issue5008@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Comments on the patch:
- you should check the error return of lseek() (and possibly wrap it in
Py_BEGIN/END_ALLOW_THREADS, see portable_lseek() in the same file)
- there should be a test for each of unbuffered IO (buffering=0),
buffered IO ("rb") and text IO ("r"). For text IO, the test shouldn't
test the actual value returned by tell(), only that it is > 0 (because
tell() in text mode is an opaque value and is not necessarily equal to a
byte position)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Tue Jan 20 12:54:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 11:54:09 +0000
Subject: [issue4995] sqlite3 module gives SQL logic error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232452449.82.0.0277793341207.issue4995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well I'm no sqlite expert, but here are the values I get on the 2.6 branch:

>>> sqlite3.apilevel
'2.0'
>>> sqlite3.sqlite_version
'3.6.1'
>>> sqlite3.sqlite_version_info
(3, 6, 1)
>>> sqlite3.version
'2.4.1'
>>> sqlite3.version_info
(2, 4, 1)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4995>
_______________________________________

From report at bugs.python.org  Tue Jan 20 13:02:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 12:02:08 +0000
Subject: [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1232452928.08.0.203360587734.issue4293@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That seems to have done the trick.  Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________

From report at bugs.python.org  Tue Jan 20 13:18:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 12:18:06 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232453886.73.0.00894439472818.issue4977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Antoine, I leave it to you to decide what to do with this.

As far as I can see, the only action that one might want to take
as a result of this issue is to replace strtol with PyOS_strol
in the codebase (in the struct module, and there's also an
occurrence in Objects/floatobject.c in the fromhex method).

I recommend against this though, for a few reasons:

1. PyOS_strtol is likely slower than strtol.

2. PyOS_strtol is itself buggy:  for example, it incorrectly
accepts strings like "- 3", with whitespace between the sign
and the unsigned part.  This is the reason that Python accepts
'- 3' as an input to int;  this is a Python bug that can't be
changed in 2.x for compatibility reasons.  It's fixed in 3.x.

3. There's nothing wrong with the existing code, and changing
it risks introducing new bugs.  It's the platform that's buggy here: 
its strtol method doesn't comply with the C89 standard (or the C99
standard, for that matter).

It's true that Python has code to work around problems with standards
compliance on some platforms, and if this were a supported platform
then I'd be okay with making the change.  As it is, though, I think this
should be reclosed (as invalid, or won't fix if that makes people feel
happier).

BTW, Luke, note that you can still add comments to an issue even after
the issue has been closed:  people subscribed to that issue (via nosy)
will still see the messages.

----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Tue Jan 20 13:18:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 12:18:22 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232453902.58.0.612967179147.issue4977@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy:  -marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Tue Jan 20 13:33:27 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 20 Jan 2009 12:33:27 +0000
Subject: [issue5009] multiprocessing: failure in manager._debug_info()
In-Reply-To: <1232443372.05.0.683507657371.issue5009@psf.upfronthosting.co.za>
Message-ID: <1232454807.94.0.159587742183.issue5009@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Dang, and here I was thinking I was making progress :)

I'll review and check in later today

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5009>
_______________________________________

From report at bugs.python.org  Tue Jan 20 13:50:17 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Tue, 20 Jan 2009 12:50:17 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232455817.03.0.717672563152.issue4977@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

hiya folks,

lots of comments here.  in no particular order:

1) thanks for reopening the bug

2) apologies for not being clearer - it's Lib/test/test_testzip.py
specifically the  TestZip64InSmallFiles case that's failing.

3) it's not yet _clear_ whether strtol is the cause of the
problem - i haven't yet got round to testing that because
i'm in the middle of a rebuild trying to get msvcr80
assemblies to work, and i'll need to back out of that and
rebuild with msvcrt or msvcrt71 first.

4) i'm not yet certain as to whether it's the mingw 3.4.5
_compiler_ that's broken (!) there's some empirical evidence
suggesting that it might well be, but again, that's not
yet determined

5) under wine, strtol goes through to msvcrt, which goes through
to ntdll, which goes through to the _unix_ system's strtol.
wine is compiled with -m32, so it _should_ still all be doing
32-bit stuff, even though i'm using a 64-bit host (debian/amd64).

on balance, i'd very much appreciate this being kept open so that i
can keep track of determining what the heck is going on - i have
about five or six different things to investigate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Tue Jan 20 15:12:11 2009
From: report at bugs.python.org (Akira Kitada)
Date: Tue, 20 Jan 2009 14:12:11 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1232460731.16.0.284625365981.issue1054967@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Tue Jan 20 15:17:09 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 20 Jan 2009 14:17:09 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1232461029.82.0.330372588088.issue4879@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Adding crossref to http://bugs.python.org/issue4448 regarding the 
porting of this feature to 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Tue Jan 20 15:21:45 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Jan 2009 14:21:45 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232461305.91.0.0534658065685.issue4978@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the reviews! Applied in r68805.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4978>
_______________________________________

From report at bugs.python.org  Tue Jan 20 16:18:59 2009
From: report at bugs.python.org (Sravani Gogineni)
Date: Tue, 20 Jan 2009 15:18:59 +0000
Subject: [issue5012] How to test python 3 was installed properly in my
	directory?
In-Reply-To: <1232464739.45.0.206650125051.issue5012@psf.upfronthosting.co.za>
Message-ID: <1232464739.45.0.206650125051.issue5012@psf.upfronthosting.co.za>


New submission from Sravani Gogineni <goginenis at corning.com>:

Hello,

I am a beginner and i installed python 3 in my Home directory. i want 
to test that the installation was done properly. is their a test suite 
to see the installation was good? Could anyone please help me with the 
problem? Also could i have both gcc and icc as compilers in python 3? 
if yes how do i use them in python3?

Thanks,
Vani

----------
components: Tests
messages: 80256
nosy: vani
severity: normal
status: open
title: How to test python 3 was installed properly in my directory?
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5012>
_______________________________________

From report at bugs.python.org  Tue Jan 20 16:21:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Jan 2009 15:21:40 +0000
Subject: [issue5012] How to test python 3 was installed properly in my
	directory?
In-Reply-To: <1232464739.45.0.206650125051.issue5012@psf.upfronthosting.co.za>
Message-ID: <1232464900.38.0.154225215433.issue5012@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please ask your question on a mailing list like comp.lang.python. This
tracker is for bug reports in Python not general requests for help.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5012>
_______________________________________

From report at bugs.python.org  Tue Jan 20 17:21:22 2009
From: report at bugs.python.org (Fons Dijkstra)
Date: Tue, 20 Jan 2009 16:21:22 +0000
Subject: [issue5013] Problems with delay parm of
	logging.handlers.RotatingFileHandler
In-Reply-To: <1232468482.31.0.912117314029.issue5013@psf.upfronthosting.co.za>
Message-ID: <1232468482.31.0.912117314029.issue5013@psf.upfronthosting.co.za>


New submission from Fons Dijkstra <fdij at xs4all.nl>:

When you set the delay parameter of the 
logging.handlers.RotatingFileHandler.__init__() function to True, two 
things go wrong:

1) A previously set formatter is reset (to None) upon lazy creating the 
StreamHandler. That means in practice that you always will have the 
default formatter which just formats the message.

2) Upon a roll-over, the delay parm does not seem to be used anymore as, 
even if there are no records to log, the new current logfile is always 
created.

----------
components: Library (Lib)
messages: 80258
nosy: pycurry
severity: normal
status: open
title: Problems with delay parm of logging.handlers.RotatingFileHandler
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5013>
_______________________________________

From report at bugs.python.org  Tue Jan 20 17:22:48 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Jan 2009 16:22:48 +0000
Subject: [issue5013] Problems with delay parm of
	logging.handlers.RotatingFileHandler
In-Reply-To: <1232468482.31.0.912117314029.issue5013@psf.upfronthosting.co.za>
Message-ID: <1232468568.57.0.424175394861.issue5013@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> vsajip
nosy: +vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5013>
_______________________________________

From report at bugs.python.org  Tue Jan 20 17:24:34 2009
From: report at bugs.python.org (Jacob)
Date: Tue, 20 Jan 2009 16:24:34 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232468674.76.0.701634416934.issue3881@psf.upfronthosting.co.za>


Jacob <jacoberen at gmail.com> added the comment:

Installing to C:\Program Files\Python\ worked.
Now we just have to find out WHY it doesn't work with the
C:\[Programmer/Programmas]\ to C:\Program Files\ link.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Tue Jan 20 18:52:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 17:52:40 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232473960.36.0.519183388347.issue4998@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A random data point:  just for fun, I just tried assessing the impact of 
__slots__ on Decimal instances, by the crude method of putting all of the 
Decimal instances that are created during a complete run of the Decimal 
test suite (over 100000 of them) into a list and watching memory usage.  
This was on a non-debug 32-bit build of py3k, with 16-bit Py_UNICODE 
(which is relevant because the coefficients of Decimal instances are 
strings).

Results: (*)

~44 bytes per Decimal on average with __slots__
~183 bytes per Decimal on average without __slots__

The effect on speed wasn't really significant:  removing __slots__ gives
at worst a 1-2% slowdown on a complete run of the test-suite.

So please let's not remove __slots__ from Fraction!



(*) raw numbers: 120343 total number of Decimals.  The following
are memory readings from the RSIZE column of top.

with __slots__:
    putting 8 copies of each Decimal into list -> 33M total usage
    putting 4 copies of each Decimal into list -> 55M total usage
without __slots__:
    putting 8 copies of each Decimal into list -> 182M total usage
    putting 4 copies of each Decimal into list -> 96M total usage.

I took the liberty of subtracting 4 bytes per list entry, to compensate
for the memory taken by the list itself.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 18:57:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 17:57:24 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232474244.64.0.663730845394.issue4998@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> ~44 bytes per Decimal on average with __slots__
> ~183 bytes per Decimal on average without __slots__

...and of course a difference of 140 bytes shouldn't really be
much of a surprise:

Python 3.1a0 (py3k:68809M, Jan 20 2009, 16:55:13) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(dict())
140

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 19:11:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 18:11:40 +0000
Subject: [issue5014] Kernel Protection Failure
In-Reply-To: <1232473953.43.0.830370266834.issue5014@psf.upfronthosting.co.za>
Message-ID: <1232475100.96.0.0596474301418.issue5014@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looking at your stack trace, do you have a recursive function somewhere?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5014>
_______________________________________

From report at bugs.python.org  Tue Jan 20 19:52:31 2009
From: report at bugs.python.org (Muayyad Alsadi)
Date: Tue, 20 Jan 2009 18:52:31 +0000
Subject: [issue4995] sqlite3 module gives SQL logic error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232477551.43.0.405492221519.issue4995@psf.upfronthosting.co.za>


Muayyad Alsadi <alsadi at ojuba.org> added the comment:

a fedora-devel fellow gave me a solution

cn=sqlite3.connect(':memory:', isolation_level=None)

and it worked
I hope that does not affect other versions


$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> cn=sqlite3.connect(':memory:', isolation_level=None)
>>> c=cn.cursor()
>>> c.execute('BEGIN TRANSACTION')
<sqlite3.Cursor object at 0x9cb9c20>
>>> c.execute('create temp table tmp_main (id integer, b text)')
<sqlite3.Cursor object at 0x9cb9c20>
>>> c.execute('insert into tmp_main (id) values (10);')
<sqlite3.Cursor object at 0x9cb9c20>
>>> c.execute('END TRANSACTION')
<sqlite3.Cursor object at 0x9cb9c20>
>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4995>
_______________________________________

From report at bugs.python.org  Tue Jan 20 20:10:42 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Jan 2009 19:10:42 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232478642.87.0.200852862764.issue4998@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: jyasskin -> marketdickinson
keywords: +patch
priority: release blocker -> critical
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12810/fractions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 20:43:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 19:43:24 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232480604.13.0.161963245816.issue4998@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch, Raymond.

I'm don't really have any experience with ABCs.  I've read the PEP (a few 
times), but am not convinced that I fully understand all the ideas 
involved.

What are the practical differences between having Fraction inherit from 
Rational directly, and registering Fraction as a subclass of Rational?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 20:49:13 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 20 Jan 2009 19:49:13 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232480953.04.0.652817975191.issue4242@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I would definitely appreciate having a well-defined set of "required
tests" that Cython should pass for compliance.

However, something like sys.vm won't easily work for Cython: it runs
within the CPython VM but only after converting the Python code to C.
Emulating platform.python_implementation() to make it return "Cython"
does not sound correct.

You can currently detect Cython compilation by doing this:

    import cython
    print cython.compiled

Obviously, the import will fail when running as Python code without
having Cython installed.

However, in Cython, you would often get a compile time error in cases
where implementation details apply, so checking for implementation
details programmatically may not work at all.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 20 20:55:18 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 20 Jan 2009 19:55:18 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232481318.65.0.335609080372.issue4998@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Rational has default definitions for some of its methods and properties.
If Fraction inherits from Rational, it gets those definitions
implicitly. If it's registered with Rational, it has to define them itself.

I don't know that much about __slots__ (or I'd have known that just
defining it on Fraction wouldn't work :-/) but if it doesn't prevent
subclasses from having dicts, it seems like a good idea to add an empty
__slots__ to most classes in the ABC hierarchy, and definitely the
numeric ones.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:07:54 2009
From: report at bugs.python.org (pb)
Date: Tue, 20 Jan 2009 20:07:54 +0000
Subject: [issue5014] Kernel Protection Failure
In-Reply-To: <1232475100.96.0.0596474301418.issue5014@psf.upfronthosting.co.za>
Message-ID: <7A622DCE-BBD3-42B7-BBE2-5F828A49DCD8@gmail.com>


pb <peterbraden at peterbraden.co.uk> added the comment:

Thanks for the feedback - looking again at the code it does seem like  
a recursive function may be stack overflowing.

I've managed to resolve the issue by rewriting some code, and suspect  
I was probably at fault. Thanks again, and please mark the bug as  
invalid if nobody else has any problems.

Peter Braden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5014>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:19:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 20:19:44 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232482784.68.0.767825624215.issue4998@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Got it.  Thanks, Jeffrey.  The patch looks good to me---please go ahead 
and apply.

----------
assignee: marketdickinson -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:21:17 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 20 Jan 2009 20:21:17 +0000
Subject: [issue5014] Kernel Protection Failure
In-Reply-To: <1232473953.43.0.830370266834.issue5014@psf.upfronthosting.co.za>
Message-ID: <1232482877.05.0.112817205581.issue5014@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5014>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:24:22 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Jan 2009 20:24:22 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232483062.68.0.617302955965.issue4242@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Would a C API in CPython to set the value returned by sys.vm be enough
to help Cython out Stefan?

Such a feature would help with any CPython based variant - the
implementers could either leave sys.vm as "cpython" and attempt to be
fully compatible, or else set it to something different (e.g "stackless"
or "cython") and target the common subset of the test suite.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:33:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 20:33:00 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1232483062.68.0.617302955965.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232483604.6061.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why would Cython be affected? This is about tests of the stdlib, which
have nothing to whether you use Cython or not.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:35:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Jan 2009 20:35:17 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232483717.04.0.804877732916.issue4998@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in the trunk: r68813.

Benjamin, can you please apply to 2.6, 3.0 and 3.1.

----------
assignee: rhettinger -> benjamin.peterson
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:36:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 20:36:10 +0000
Subject: [issue5014] Kernel Protection Failure
In-Reply-To: <1232473953.43.0.830370266834.issue5014@psf.upfronthosting.co.za>
Message-ID: <1232483770.66.0.842416987191.issue5014@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I do not think it is invalid. The interpreter should have raised a
RuntimeError "recursion limit exceeded" rather than crashing.

Does the error still occur if you try to enlarge the stack limit using
thread.stack_size() ?

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5014>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:39:37 2009
From: report at bugs.python.org (pb)
Date: Tue, 20 Jan 2009 20:39:37 +0000
Subject: [issue5014] Kernel Protection Failure
In-Reply-To: <1232483770.66.0.842416987191.issue5014@psf.upfronthosting.co.za>
Message-ID: <79990F05-56F1-4514-BE34-5FC355610A5D@gmail.com>


pb <peterbraden at peterbraden.co.uk> added the comment:

I believe it was an infinite recursion, so the stack limit would never  
be big enough, however a recursion limit exceeded exception does sound  
like the correct response. The code was running in mod_python, so I'm  
not sure how apache deals with stack overflows.

Thanks for the help.

Peter Braden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5014>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:46:37 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Jan 2009 20:46:37 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232484397.77.0.321833559033.issue4242@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I got the impression from Stefan's question that he would like to be
able to run the stdlib tests with Cython enabled for all of the stdlib
Python modules and know which tests still needed to pass and which could
be safely skipped as being specific to vanilla CPython.

Without some way to change the value of sys.vm (either from Python or
from C), that kind of thing wouldn't be possible.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:49:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 20:49:38 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232484578.04.0.921487889906.issue4998@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, Raymond, it looks as though your earlier commit, r68799, changed 
distutils/command/wininst-8.0.exe.  Was that deliberate?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:53:08 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 20 Jan 2009 20:53:08 +0000
Subject: [issue4977] test_maxint64 fails on 32-bit systems due to assumption
	that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232484788.06.0.641342301952.issue4977@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> i'd very much appreciate this being kept open so that i
> can keep track of determining what the heck is going on

Please understand that the purpose of the bug tracker is not to keep
your personal progress notes. A tracker item, in theory, must be
formulated such that it can immediately be responded to. If not, we may
ask for further information (closing it when it is not forthcoming), or
close it right aways as invalid.

I'm tempted to close this report immediately as completely confused and
lacking focus. Please clarify immediately

a) what action you are performing
b) what is happening
c) what you expect to happen instead
d) why you believe this is a problem with Python (and not, say, with
your target system)

Please be *EXTREMELY* cautious when using the bug tracker, as any
message you post will consume somebody else's time.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4977>
_______________________________________

From report at bugs.python.org  Tue Jan 20 21:59:55 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 20 Jan 2009 20:59:55 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1232468674.76.0.701634416934.issue3881@psf.upfronthosting.co.za>
Message-ID: <49763B47.8030200@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Installing to C:\Program Files\Python\ worked.
> Now we just have to find out WHY it doesn't work with the
> C:\[Programmer/Programmas]\ to C:\Program Files\ link.

With process monitor, I made partial progress (after installing
the German Vista version). It looks like that there is an explicit
Deny ACL entry for read for Everyone in the Programme symlink.
As a consequence, os.listdir(r"c:\programme") fails, even though
os.listdir(r"c:\program files") succeeds. It looks like Tcl wants
to list the contents of the symlink (I'm not yet sure why), and
that this fails (ACCESS_DENIED).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Tue Jan 20 22:06:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 20 Jan 2009 21:06:48 +0000
Subject: [issue5014] Kernel Protection Failure
In-Reply-To: <1232473953.43.0.830370266834.issue5014@psf.upfronthosting.co.za>
Message-ID: <1232485608.31.0.821103440707.issue5014@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

[I'm closing the report for the following reasons:]
This bug is not appropriate for the Python bug tracker. We only deal
with bugs in Python proper, not in any add-on libraries (such as a MySQL
adapter or Django). In addition, we need a way to reproduce the bug,
such as a piece of code that reliably reproduces the problem.

Antoine: It might well be that Python fails to detect the stack
overflow. However, it appears that the OP is happy with the work-around
he found, so investigating it to the end might not be worth the effort.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5014>
_______________________________________

From report at bugs.python.org  Tue Jan 20 22:07:54 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Jan 2009 21:07:54 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232485674.27.0.907634541787.issue4972@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> so you will never see a socket error from quit().

It did happen but on the close() call inside the quit() call.
I couldn't reproduce it in the tests yet, still working on it.

I have changed the patch and took car of the return code.

I have also commited a first version of the imaplib one. This one
required to write a dummy imap server in the tests, and I am not fully
happy with it yet (the returns are based on trials-errors, and I am not
fully understanding this protocol yet)

but imaplib is undertested, this fake server might be a good start for
more tests in test_imaplib imho.

Added file: http://bugs.python.org/file12811/smtplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Tue Jan 20 22:08:12 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 20 Jan 2009 21:08:12 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232485692.79.0.405588312028.issue4972@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Added file: http://bugs.python.org/file12812/imaplib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Tue Jan 20 22:24:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 21:24:33 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1232486673.84.0.335262688799.issue4842@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Martin.

Fixed in py3k in r68814 and r68815, and merged to 3.0 release branch in 
r68818.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Tue Jan 20 22:27:48 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Jan 2009 21:27:48 +0000
Subject: [issue4998] __slots__ on Fraction is useless
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232486868.51.0.27549125405.issue4998@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks Mark.  Fixed in r68819 .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4998>
_______________________________________

From report at bugs.python.org  Tue Jan 20 22:32:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 21:32:46 +0000
Subject: [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1232487166.9.0.823095616794.issue4842@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Re: specification of the pickle formats.  There's a fairly detailed 
description of all the opcodes already in the pickletools module, so the 
main task would be to extract those descriptions and put them into the 
documentation somewhere.

Perhaps the documentation for the pickletools module itself would be an 
appropriate place, if there were also a link from the pickle 
documentation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4842>
_______________________________________

From report at bugs.python.org  Tue Jan 20 22:40:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Jan 2009 21:40:14 +0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1232487614.6.0.832017435848.issue2121@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this one as won't fix.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
_______________________________________

From report at bugs.python.org  Tue Jan 20 22:50:04 2009
From: report at bugs.python.org (Leonardo Soto)
Date: Tue, 20 Jan 2009 21:50:04 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232488204.32.0.969203534967.issue4242@psf.upfronthosting.co.za>


Changes by Leonardo Soto <leo.soto at gmail.com>:


----------
nosy: +leosoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:06:43 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 20 Jan 2009 22:06:43 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232489203.21.0.254906955747.issue4242@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

@Antoine: Cython already compiles a major part of CPython's test suite
successfully (although we didn't actually try to compile the stdlib
itself but only the tests). It's an announced goal for Cython 1.0 to
compile 'all' Python code, and it would be great to have an official
subset of the test suite that would allow us to prove compliance and to
know when we're done.

Thinking about this some more, I guess that fairness would require us to
also compile the pure Python modules in the stdlib that are being
tested. I really like that idea. That would allow a Cython-enabled
CPython to compile its entire stdlib into fast extension modules and to
ship them right next to the pure Python code modules, so that people
could still read the Python code that gets executed at C speed. Looks
like all we'd need to do is to install a global import hook for .py
files (but that's definitely off-topic for this bug).

@Nick: It's not a technical problem. We could special case sys.vm in
Cython by simply replacing it by a constant string when we find it in
the source tree (that should do for 'normal' usage, although
"getattr(sys, vm_string)" won't work). Being able to change the value of
sys.vm programmatically isn't a good solution, as it would affect all
Python code in the VM, not only code that was compiled by Cython.

I'm more concerned about the semantics. It wouldn't be correct to tell
code that it runs in Cython when it was actually interested in the *VM*
it runs in. But some things might still behave different in Cython than
in CPython, due to static compilation, exception handling nuances, the
placement of reference counting calls, etc. The information about the
running VM isn't enough here, whereas "platform.python_implementation()"
makes at least a bit more sense by its name. The main problem seems to
be that Cython has some specialties in its own right, while it inherits
others from CPython. So code that branches based on
"platform.python_implementation()" must be aware of both. There will
definitely be cases where CPython will work but Cython compilation won't
(and maybe even vice versa :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:09:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 22:09:17 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232489357.62.0.942186268431.issue4705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:09:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 22:09:30 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232489370.45.0.964589746551.issue4705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12475/unbufferedstdout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:09:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 22:09:34 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232489374.37.0.520249194182.issue4705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12479/test_stdin.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:10:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 22:10:02 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232489402.41.0.665650522461.issue4705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12556/unbufferedstdout-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:10:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 22:10:05 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232489405.92.0.678159860853.issue4705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file12657/unbufferedstdout-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:15:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 22:15:00 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1232489203.21.0.254906955747.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232489725.6061.5.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> @Antoine: Cython already compiles a major part of CPython's test suite
> successfully (although we didn't actually try to compile the stdlib
> itself but only the tests). It's an announced goal for Cython 1.0 to
> compile 'all' Python code, and it would be great to have an official
> subset of the test suite that would allow us to prove compliance and to
> know when we're done.

Wow! I guess I was still living in the Pyrex era... That's an impressive
achievement.
So, let me retract what I said about Cython not being relevant to this
issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:38:46 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 20 Jan 2009 22:38:46 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232491126.26.0.107721804161.issue4941@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


Removed file: http://bugs.python.org/file12731/likely_decref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:39:19 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 20 Jan 2009 22:39:19 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1232491159.22.0.169526919956.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Closed, as no further feedback received.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:44:01 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 20 Jan 2009 22:44:01 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232491441.65.0.0775503891579.issue4941@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

New version of the patch, as well as one that doesn't touch Py_DECREF
but defines likely and unlikely. Then, three ceval patches that result
in small speedups (2% to 8% here), but don't play well together (neither
with the Py_DECREF one).

Since I get speedups for some changes and slowdowns when more than one
is applied, I suspect my system is hitting some limitation (register
stavation?) and contributing more noise that signal :/

Added file: http://bugs.python.org/file12813/likely_decref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:44:41 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 20 Jan 2009 22:44:41 +0000
Subject: [issue5011] issue4428 - make io.BufferedWriter observe
	max_buffer_size limits
In-Reply-To: <0016e644ddec7c678f0460e81ef8@google.com>
Message-ID: <001485f922dcbbdf7b0460f1c8cf@google.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Reviewers: Antoine Pitrou,

Message:
Just responding to your comments on the support for generators and non
buffer api supporting inputs.

I'll get to the other comments in the code soon with new unit tests for
those cases.

http://codereview.appspot.com/12470/diff/1/2
File Lib/io.py (right):

http://codereview.appspot.com/12470/diff/1/2#newcode1055
Line 1055: # b is an iterable of ints, it won't always support len().
On 2009/01/20 11:12:47, Antoine Pitrou wrote:
> There is no reason for write() to accept arbitrary iterable of ints,
only
> bytes-like and buffer-like objects. It will make the code simpler.
>

Agreed.  But since I want to merge this into release30-maint doing that
sounds like a behavior change.  I'd be fine with removing it for the
3.1/2.7 version of this code (though I hope people will be using the C
implementation instead).

http://codereview.appspot.com/12470/diff/1/2#newcode1060
Line 1060: # No buffer API?  Make intermediate slice copies instead.
On 2009/01/20 11:12:47, Antoine Pitrou wrote:
> Objects without the buffer API shouldn't be supported at all.

Same reason as above.

http://codereview.appspot.com/12470/diff/1/3
File Lib/test/test_io.py (right):

http://codereview.appspot.com/12470/diff/1/3#newcode496
Line 496: def testWriteNoLengthIterable(self):
On 2009/01/20 11:12:47, Antoine Pitrou wrote:
> This shouldn't work at all. If it works right now, it is only a
side-effect of
> the implementation.
> (it won't work with FileIO, for example)
>

hmm in that case it might not be too large of a thing to break when
merged into release30-maint.  I'll leave that up to the release manager
& bdfl.  my gut feeling for a release branch change is to say we have to
live with this being supported for now.

Description:
http://bugs.python.org/issue4428 - patch gps04.

Please review this at http://codereview.appspot.com/12470

Affected files:
   Lib/io.py
   Lib/test/test_io.py

Index: Lib/io.py
===================================================================
--- Lib/io.py	(revision 68796)
+++ Lib/io.py	(working copy)
@@ -1047,11 +1047,42 @@
                      self._flush_unlocked()
                  except BlockingIOError as e:
                      # We can't accept anything else.
-                    # XXX Why not just let the exception pass through?
+                    # Reraise this with 0 in the written field as none of  
the
+                    # data passed to this call has been written.
                      raise BlockingIOError(e.errno, e.strerror, 0)
              before = len(self._write_buf)
-            self._write_buf.extend(b)
-            written = len(self._write_buf) - before
+            bytes_to_consume = self.max_buffer_size - before
+            # b is an iterable of ints, it won't always support len().
+            if hasattr(b, '__len__') and len(b) > bytes_to_consume:
+                try:
+                    chunk = memoryview(b)[:bytes_to_consume]
+                except TypeError:
+                    # No buffer API?  Make intermediate slice copies  
instead.
+                    chunk = b[:bytes_to_consume]
+                # Loop over the data, flushing it to the underlying raw IO
+                # stream in self.max_buffer_size chunks.
+                written = 0
+                self._write_buf.extend(chunk)
+                while chunk and len(self._write_buf) > self.buffer_size:
+                    try:
+                        self._flush_unlocked()
+                    except BlockingIOError as e:
+                        written += e.characters_written
+                        raise BlockingIOError(e.errno, e.strerror, written)
+                    written += len(chunk)
+                    assert not self._write_buf, "_write_buf should be  
empty"
+                    if isinstance(chunk, memoryview):
+                        chunk = memoryview(b)[written:
+                                              written +  
self.max_buffer_size]
+                    else:
+                        chunk = b[written:written + self.max_buffer_size]
+                    self._write_buf.extend(chunk)
+            else:
+                # This could go beyond self.max_buffer_size as we don't  
know
+                # the length of b.  The alternative of iterating over it  
one
+                # byte at a time in python would be slow.
+                self._write_buf.extend(b)
+                written = len(self._write_buf) - before
              if len(self._write_buf) > self.buffer_size:
                  try:
                      self._flush_unlocked()
Index: Lib/test/test_io.py
===================================================================
--- Lib/test/test_io.py	(revision 68796)
+++ Lib/test/test_io.py	(working copy)
@@ -479,6 +479,33 @@

          self.assertEquals(b"abcdefghijkl", writer._write_stack[0])

+    def testWriteMaxBufferSize(self):
+        writer = MockRawIO()
+        bufio = io.BufferedWriter(writer, buffer_size=8,  
max_buffer_size=13)
+
+        bufio.write(b"abcdefghij")
+        bufio.write(b"klmnopqrstuvwxyz")
+        bufio.write(b"0123456789"*3)
+
+        expected_writes = [b"abcdefghij", b"klmnopqrstuvw",  
b"xyz0123456789",
+                           b"0123456789012"]
+        self.assertEquals(expected_writes, writer._write_stack)
+        bufio.close()
+        self.assertEquals(b"3456789", writer._write_stack[4])
+
+    def testWriteNoLengthIterable(self):
+        writer = MockRawIO()
+        bufio = io.BufferedWriter(writer, buffer_size=8)
+
+        def Generator(value):
+            for x in value:
+                yield x
+        iterable = Generator(b'ABCDEFGHIJKLMNOPQRSTUVWXYZ')
+        self.assertRaises(TypeError, len, iterable)
+        bufio.write(iterable)
+
+        self.assertEquals(b'ABCDEFGHIJKLMNOPQRSTUVWXYZ',  
writer._write_stack[0])
+
      def testWriteNonBlocking(self):
          raw = MockNonBlockWriterIO((9, 2, 22, -6, 10, 12, 12))
          bufio = io.BufferedWriter(raw, 8, 16)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5011>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:44:50 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 20 Jan 2009 22:44:50 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232491490.48.0.374172416562.issue4941@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


Added file: http://bugs.python.org/file12814/likely_object.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:46:30 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 20 Jan 2009 22:46:30 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232491590.49.0.253907530278.issue4941@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


Added file: http://bugs.python.org/file12815/ceval_exception.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:48:18 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 20 Jan 2009 22:48:18 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232491698.54.0.492860835368.issue4941@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


Added file: http://bugs.python.org/file12816/ceval_tuple_unpack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:49:33 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 20 Jan 2009 22:49:33 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232491773.69.0.939089933847.issue4941@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


Added file: http://bugs.python.org/file12817/ceval_function.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Tue Jan 20 23:57:13 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 20 Jan 2009 22:57:13 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232492233.77.0.999981842539.issue4941@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Minor comments on likely_object.diff:
* Py_LIKELY() and Py_UNLIKELY() would be better spellings than likely()
and unlikely().
* The definitions should go in pyport.h instead of object.h
* Usually don't put spaces after the "#".
* Probably #if the definitions of Py_LIKELY and Py_UNLIKELY instead of
__builtin_expect so new compilers can easily add their own definitions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Wed Jan 21 00:23:54 2009
From: report at bugs.python.org (Kylotan)
Date: Tue, 20 Jan 2009 23:23:54 +0000
Subject: [issue5015] The Py_SetPythonHome C API function is undocumented
In-Reply-To: <1232493833.95.0.946934351035.issue5015@psf.upfronthosting.co.za>
Message-ID: <1232493833.95.0.946934351035.issue5015@psf.upfronthosting.co.za>


New submission from Kylotan <kylotan at gmail.com>:

I found out recently that Py_SetPythonHome() might solve my problem with
embedding Python in a C++ app. I felt a bit stupid for not finding this
myself in the documentation, until I noticed that it's not in the
documentation. :)  I would expect to find it at
http://docs.python.org/c-api/init.html but it is absent.

----------
assignee: georg.brandl
components: Documentation
messages: 80291
nosy: Kylotan, georg.brandl
severity: normal
status: open
title: The Py_SetPythonHome C API function is undocumented
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5015>
_______________________________________

From report at bugs.python.org  Wed Jan 21 00:27:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 23:27:51 +0000
Subject: [issue4428] make io.BufferedWriter observe max_buffer_size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <00151750ddaa1ce0250460f263b7@google.com>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi!

that sounds
> like a behavior change.  I'd be fine with removing it for the 3.1/2.7
version of
> this code (though I hope people will be using the C implementation
instead).

Well, either it's supported and it will have to go through a deprecation
phase, or it's unsupported and it can be ripped out right now...

I don't think it should be supported at all, given that the semantics of
writing an iterable of ints are totally non-obvious. Reading both the
PEP and the docstrings in io.py, I only see mentions of "bytes" and
"buffer", not of an iterable of ints. Perhaps Guido should pronounce.

(do you know of any code relying on this behaviour? the C version
obviously does not support it and all regression tests pass fine, except
for an SSL bug I filed)

http://codereview.appspot.com/12470

----------
nosy: +pitrou
title: io.BufferedWriter does not observe buffer size limits -> make io.BufferedWriter observe max_buffer_size limits

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Wed Jan 21 00:28:45 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 20 Jan 2009 23:28:45 +0000
Subject: [issue5013] Problems with delay parm of
	logging.handlers.RotatingFileHandler
In-Reply-To: <1232468482.31.0.912117314029.issue5013@psf.upfronthosting.co.za>
Message-ID: <1232494125.59.0.872593238484.issue5013@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fixes now in trunk and release26-maint.

Note that RotatingFileHandler will open the file when shouldRollover()
is called - which it is from emit() - and doRollover() will also open
the file even if a delay parameter is set.

TimedRotatingFileHandler will not open a file if delay is set until
rollover actually occurs, as shouldRollover goes by time only rather
than file size.

The delay parameter is intended only as a hint to the handlers to delay
opening until as long as possible, and they will try to honour this as
far as is practicable.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5013>
_______________________________________

From report at bugs.python.org  Wed Jan 21 00:30:41 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Jan 2009 23:30:41 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232494241.37.0.791971329332.issue5008@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 2:
 - raise raise PyErr_SetFromErrno(PyExc_IOError) on lseek() error
 - add tests for unbuffered binary file and (buffered) text file

I use the type "long" to store the lseek() result, because I don't 
know if off_t is available on all OS. Py_off_t may be used, but it's 
defined above (after fileio_init). fileio_seekable() uses the 
type "int" for lseek() result, which looks worse than long :-)

Added file: http://bugs.python.org/file12818/fileio_append-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 00:38:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 23:38:38 +0000
Subject: [issue5016] FileIO.seekable() can return False
In-Reply-To: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>
Message-ID: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

FileIO.seekable() can return False if we first seek to a position such
that, when truncated to a signed int, it becomes negative:

>>> f = open('largefile', 'wb', buffering=0)
>>> f.seek(2**31, 0)
2147483648
>>> f.write(b'x')
1
>>> f.close()
>>> f = open('largefile', 'rb', buffering=0)
>>> f.seek(0, 2)
2147483649
>>> f.seekable()
False

----------
components: Extension Modules
messages: 80295
nosy: pitrou
severity: normal
status: open
title: FileIO.seekable() can return False
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5016>
_______________________________________

From report at bugs.python.org  Wed Jan 21 00:40:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 23:40:33 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232494241.37.0.791971329332.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232494857.6061.12.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I use the type "long" to store the lseek() result, because I don't 
> know if off_t is available on all OS. Py_off_t may be used, but it's 
> defined above (after fileio_init).

Instead of checking the return type, you can first set errno to 0, and
then check errno after the function returns.

> fileio_seekable() uses the 
> type "int" for lseek() result, which looks worse than long :-)

Nice catch! http://bugs.python.org/issue5016

PS : about the patch, "0 < f.tell()" is really strange coding style...
"f.tell() > 0" looks much more consistent with the rest of the Python
code base

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 00:47:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 23:47:33 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232495253.85.0.368705363009.issue5008@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Last thing, in your patch there is a forward declaration to
portable_lseek but it doesn't look used anywhere...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 00:57:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 23:57:39 +0000
Subject: [issue5016] FileIO.seekable() can return False
In-Reply-To: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>
Message-ID: <1232495859.87.0.990649632883.issue5016@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> high
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5016>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:07:37 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 00:07:37 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232496457.35.0.197408745901.issue5008@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New try (version 3):
 - reuse Py_off_t in fileio_init() instead of long
 - use Python coding style: f.tell() > 0
 - remove the unused forward declaration of portable_lseek()

This patch also prepares a fix for #5016.

Added file: http://bugs.python.org/file12819/fileio_append-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:07:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 00:07:42 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232496462.57.0.645178399174.issue5008@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12804/fileio_append.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:07:44 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 00:07:44 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232496464.39.0.722473380139.issue5008@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12818/fileio_append-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:18:11 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 21 Jan 2009 00:18:11 +0000
Subject: [issue4428] make io.BufferedWriter observe max_buffer_size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1232497091.82.0.461206020632.issue4428@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I know of no code relying on this behavior, I merely duplicated the 
behavior that existed while writing the patch.  I'm happy to simplify.  
Adding Guido to the CC list for a pronouncement.

Guido is it okay to change io.BufferedWriter.write() in release30-maint 
to no longer accept iterables that do not support len() and things that 
do not support the buffer API?

Antoine already notes in the codereview that other existing io classes 
such as FileIO currently do not support non bytes/buffer or buffer-api 
supporting inputs:  http://codereview.appspot.com/12470/patch/1/3

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:26:24 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 00:26:24 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232497584.67.0.377542547993.issue5008@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12819/fileio_append-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:27:44 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 00:27:44 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232497664.43.0.922406205987.issue5008@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 4: ok, let's use *portable*_lseek() instead of the "ugly" 
lseek() function (not compatible with large files on Windows).

Added file: http://bugs.python.org/file12820/fileio_append-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:38:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Jan 2009 00:38:36 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232498316.9.0.118897653707.issue5008@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:38:53 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 00:38:53 +0000
Subject: [issue5016] FileIO.seekable() can return False
In-Reply-To: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>
Message-ID: <1232498333.1.0.087269051004.issue5016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch with regression test in test_largefile: test 2**31-1, 2**31, 
2**31+1.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file12821/fileio_append.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5016>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:40:11 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 00:40:11 +0000
Subject: [issue5016] FileIO.seekable() can return False
In-Reply-To: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>
Message-ID: <1232498411.43.0.659018197043.issue5016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #5008.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5016>
_______________________________________

From report at bugs.python.org  Wed Jan 21 01:41:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 00:41:47 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1232498507.47.0.920388572976.issue5006@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issues #5008 (f.tell()) and #5016 (f.seekable()), not 
directly related to this issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Wed Jan 21 02:01:22 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 21 Jan 2009 01:01:22 +0000
Subject: [issue4428] make io.BufferedWriter observe max_buffer_size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1232499681.99.0.414304086879.issue4428@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

@Gregory, that sounds like an odd enough use case to skip.  However you
might want to look for __length_hint__ before giving up?

OTOH unless the use case is real, why not support it but making it slow?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________

From report at bugs.python.org  Wed Jan 21 02:06:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Jan 2009 01:06:35 +0000
Subject: [issue5008] Wrong tell() result for a file opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232499995.65.0.354976654811.issue5008@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r68835, r68836, r68837, r68838.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5008>
_______________________________________

From report at bugs.python.org  Wed Jan 21 02:36:41 2009
From: report at bugs.python.org (Peter Bobroff)
Date: Wed, 21 Jan 2009 01:36:41 +0000
Subject: [issue5017] import suds help( suds ) fails
In-Reply-To: <1232501801.2.0.242744979679.issue5017@psf.upfronthosting.co.za>
Message-ID: <1232501801.2.0.242744979679.issue5017@psf.upfronthosting.co.za>


New submission from Peter Bobroff <pjb253 at gmail.com>:

Python Interactive Shell 2.6.1 r261:67517
easy_install suds  #seemed to succeed
import suds
help( suds ) fails in Python26\lib\inspect.py with index out of range
I fixed the obvious problem, then failed on another. After fixing 3 0r 4 
it worked but there is probably one correct fix to the problem.

A bit beyond my present competence to fix it properly.

----------
components: Demos and Tools
messages: 80306
nosy: pjb
severity: normal
status: open
title: import suds help( suds ) fails
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5017>
_______________________________________

From report at bugs.python.org  Wed Jan 21 02:54:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 21 Jan 2009 01:54:26 +0000
Subject: [issue5018] Overly general claim about sequence unpacking in tutorial
In-Reply-To: <1232502866.59.0.0196070815621.issue5018@psf.upfronthosting.co.za>
Message-ID: <1232502866.59.0.0196070815621.issue5018@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The datastructures section of the tutorial states with respect to 
"sequence unpacking" that "there is a small bit of asymmetry here: packing 
multiple values always creates a tuple, and unpacking works for any 
sequence". This is too general, as shown by the definition of assignment 
statement target in the simple_stmts section of the reference shows: 
tuples and lists are the only kinds of sequences that can appear on the 
left-hand side of an assignment statement.

----------
assignee: georg.brandl
components: Documentation
messages: 80307
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Overly general claim about sequence unpacking in tutorial
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5018>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:00:39 2009
From: report at bugs.python.org (Robin Dunn)
Date: Wed, 21 Jan 2009 02:00:39 +0000
Subject: [issue5019] Specifying common controls DLL in manifest
In-Reply-To: <1232503239.64.0.982507078752.issue5019@psf.upfronthosting.co.za>
Message-ID: <1232503239.64.0.982507078752.issue5019@psf.upfronthosting.co.za>


New submission from Robin Dunn <robin at alldunn.com>:

This may have already been discussed but my searches didn't turn up
anything concrete other than issue 4120 which is a similar but different
problem.  The problem I'm facing is that wxPython requires that version
6 of the common controls DLL be loaded in order for the GUI applications
to use the themed version of the widgets on XP+ platforms, but it
appears that this can only be done reliably if the manifest for the .exe
is the one that specifies that version of the common controls assembly.

Prior to 2.6 I was able to install python[w].exe.manifest files next to
the python executables from my installer and it would work fine, but now
that Python 2.6 is built with MSVC9 and it has its own manifest that
does not always work.  Initial testing seems to indicate that using an
external manifest still works ok on 32-bit platforms, but not on the
64-bit versions of Windows.  

I've tried ensuring that the wxPython .pyd's and the wxWidgets DLLs have
an internal manifest that specifies the common controls assembly but
that has not helped.  The only thing I've been able to find that works
for both 32 and 64 bit is to replace the internal manifest in python.exe
with a new one that specifies both the CRT and the Common Controls
assemblies, but that is obviously a Bad Thing for the install of an
extension module to do, so I'm opening this issue to look for alternatives.

So, does anybody have any experience or ideas on how to enable the
wxPython extensions to load the new common controls assembly without
needing to change the stock Python executables' manifest?  If not, are
there any objections to adding the common controls assembly to the stock
manifest used for python.exe and pythonw.exe?

----------
components: Build, Windows
messages: 80308
nosy: robind
severity: normal
status: open
title: Specifying common controls DLL in manifest
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5019>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:01:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Jan 2009 02:01:16 +0000
Subject: [issue5018] Overly general claim about sequence unpacking in tutorial
In-Reply-To: <1232502866.59.0.0196070815621.issue5018@psf.upfronthosting.co.za>
Message-ID: <1232503276.72.0.226890795591.issue5018@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Suggested rewording?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5018>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:01:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 21 Jan 2009 02:01:20 +0000
Subject: [issue5017] import suds help( suds ) fails
In-Reply-To: <1232501801.2.0.242744979679.issue5017@psf.upfronthosting.co.za>
Message-ID: <1232503280.44.0.921154959029.issue5017@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The inspect module seems to have problems with modules directly imported 
from a zip file.
When installing with "easy_install -Z suds", the problem disappears.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5017>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:05:11 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 02:05:11 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232503511.22.0.28498485797.issue4474@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Also note that on platforms with 16-bit wchar_t, the comparison
> (0xffff < *w) will always be false, so an additional check for
> (Py_UNICODE_SIZE > 2) is needed.

Yes, but the right test is (SIZEOF_WCHAR_T > 2). I wrote a new test:

#if (Py_UNICODE_SIZE == 2) && (SIZEOF_WCHAR_T > 2)
#define USE_WCHAR_SURROGATE
    const wchar_t *orig_w;
#endif

> BTW: Please always use upper-case hex literals, or at leat don't
> mix the case within the same function.

I try, but it would be easier if the rule was already respected: they 
are many tabs and many lower-case hex literals. I used copy/paste from 
existing code of unicodeobject.c...

Patch version 3:
 - disable the UTF-16 surrogate for 16 bits wchar_t: so my patch is 
only used for 16 bits Py_UNICODE and 32 bits wchar_t... which is the 
default case for python 2.6 and 3.0 on Linux
 - replace tabulation by spaces (in existing code)
 - use upper case literals

Added file: http://bugs.python.org/file12822/unicode_fromwidechar_surrogate-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:05:17 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Jan 2009 02:05:17 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232503517.55.0.509724123787.issue4474@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12776/unicode_fromwidechar_surrogate-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:19:54 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Jan 2009 02:19:54 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232504394.74.0.78060375357.issue4242@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Like Brett, I think the long term solution is to segregate
implementation-specific tests into a separate file or subdirectory of
files.  Then the main directory of tests could (and I would like)
constitute an executable definition-by-example for the language.  (To
aid this, I would also like the naming of files and tests and sequencing
of tests within files to reflect the structure of the manual as much as
possible -- and would help to make it so.  Separate patches of course.)

Would alternative implementors prefer to wait or have a *temporary*
addition to test_support?

If something is added, I would give it a leading underscore name and
document it as something probably temporary for alternate
implementations to use until a permanent solution is implemented.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:24:46 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 21 Jan 2009 02:24:46 +0000
Subject: [issue5009] multiprocessing: failure in manager._debug_info()
In-Reply-To: <1232443372.05.0.683507657371.issue5009@psf.upfronthosting.co.za>
Message-ID: <1232504686.61.0.389934520484.issue5009@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Checked in, r68839

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5009>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:27:00 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 21 Jan 2009 02:27:00 +0000
Subject: [issue3093] Namespace pollution from multiprocessing
In-Reply-To: <1213300660.18.0.995213086332.issue3093@psf.upfronthosting.co.za>
Message-ID: <1232504820.05.0.576760584453.issue3093@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
title: Namespace polution from multiprocessing -> Namespace pollution from multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3093>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:27:52 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Jan 2009 02:27:52 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232504872.75.0.148975029046.issue4972@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Please remove the old smtplib.patch: it is confusing to have two 
attachments with the same name.  It will still be available in the 
history, so nothing will be lost.

A nit-pick: 221 is a success code (in smtp 2xx codes are successes and 
5xx are errors IIRC), so vars should be simply 'code' (or 'rc' for 
return code) and 'msg', not 'errcode' and 'errmsg'.

Your new code may leave socket open in the case when self.docmd("quit") 
raises an exception other than SMTPServerDisconnected.

BTW, I think your code will be simpler if you don't reuse quit() and 
simply call docmd("quit") and close()directly in an appropriate 
try/except/finally statement.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Wed Jan 21 03:51:02 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 21 Jan 2009 02:51:02 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1232504394.74.0.78060375357.issue4242@psf.upfronthosting.co.za>
Message-ID: <bbaeab100901201850w41cbe909lff79cf5e9abbe3f5@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Tue, Jan 20, 2009 at 18:19, Terry J. Reedy <report at bugs.python.org> wrote:
>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> Like Brett, I think the long term solution is to segregate
> implementation-specific tests into a separate file or subdirectory of
> files.  Then the main directory of tests could (and I would like)
> constitute an executable definition-by-example for the language.  (To
> aid this, I would also like the naming of files and tests and sequencing
> of tests within files to reflect the structure of the manual as much as
> possible -- and would help to make it so.  Separate patches of course.)
>
> Would alternative implementors prefer to wait or have a *temporary*
> addition to test_support?

Well, if the idea of breaking out the language stuff into its own
repository happens, then the tests will have to be crawled through
anyway so decorating now to act as a marker of what has to be
separated out shouldn't lead to too much extra work.

>
> If something is added, I would give it a leading underscore name and
> document it as something probably temporary for alternate
> implementations to use until a permanent solution is implemented.

Well, this might be the permanent solution. Plus the entire test
directory tends to be somewhat optional thanks to the Linux distros
leaving it out most of the time so even if it is put in there they can
just not document it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Wed Jan 21 06:20:06 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 21 Jan 2009 05:20:06 +0000
Subject: [issue5018] Overly general claim about sequence unpacking in tutorial
In-Reply-To: <1232502866.59.0.0196070815621.issue5018@psf.upfronthosting.co.za>
Message-ID: <1232515206.78.0.559564203982.issue5018@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

I've read those paragraphs many times.  Oddly enough when you asked me 
for a rewording and I went back and read them again I found a very 
different interpretation than all the other times.  I've always thought 
of unpacking as being about the variables on the left rather than the 
values on the right. 

Now that I am rethinking this I realize (a) that unpacking is always 
about both sides of the assignment and (b) the wording I criticized is 
actually precise and accurate, if a bit subtle.  What I noticed this 
time is that "the sequence" in the sentence beginning "Sequence 
unpacking" refers to the sequence on the right, not the variables on the 
left, especially since "the variables on the left" are mentioned earlier 
in the sentence.

Part of how I backed into the wrong corner with this is that the left-
hand side of an unpacking can be a list as well as a tuple. I was 
checking to see if any other kinds of sequences could go on the left, 
which of course they can't. That's why I thought "works for any 
sequence" was wrong.  If only a tuple could be on the left I think I 
would have realized what this was saying sooner. It was the fact that 
more than one kind of sequence could go on the left that got be 
sidetracked.

Moreover, the example shows a target list and doesn't even show an 
explicit tuple or a list.  So, it's being fairly informal, as is 
appropriate for a tutorial.  However, with all that sorted out I now see 
a different problem: "multiple assignment is really just a combination 
of tuple packing and sequence unpacking".  If there is an explicit 
tuple, or a list, on the left-hand side then there's no packing 
involved. In fact it's rather strange that one could put something like 
[x,y,z] on the left-hand side of the assignment. I suppose it must get 
converted during compilation to a tuple for multiple assignment -- it's 
not as if a list-valued variable could go there.

Sorry about the long-winded meditation.  Hope the exploration proves 
interesting and or valuable to someone!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5018>
_______________________________________

From report at bugs.python.org  Wed Jan 21 06:52:36 2009
From: report at bugs.python.org (sleepyfish)
Date: Wed, 21 Jan 2009 05:52:36 +0000
Subject: [issue5020] Regex Expression Error
In-Reply-To: <1232517156.3.0.804486335225.issue5020@psf.upfronthosting.co.za>
Message-ID: <1232517156.3.0.804486335225.issue5020@psf.upfronthosting.co.za>


New submission from sleepyfish <huangpeng1126 at gmail.com>:

import re
re.match(r'[/- ]','/') crash, but re.match(r'[ /-]','/'), or
re.match(r'[/ -]','/'), or re.match(r'[ -/]','/') ...

only when the match pattern is r'[/-]', the program crash

I run it in version 2.6.1 and version 3.0, both having the same problem

----------
components: Regular Expressions
messages: 80317
nosy: sleepyfish
severity: normal
status: open
title: Regex Expression Error
type: crash
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5020>
_______________________________________

From report at bugs.python.org  Wed Jan 21 07:48:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 21 Jan 2009 06:48:46 +0000
Subject: [issue5019] Specifying common controls DLL in manifest
In-Reply-To: <1232503239.64.0.982507078752.issue5019@psf.upfronthosting.co.za>
Message-ID: <1232520526.82.0.750990020539.issue5019@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

See issue4566. If you explicitly create "activation contexts", you might
be able to have it load the right DLLs.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5019>
_______________________________________

From report at bugs.python.org  Wed Jan 21 08:36:02 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 21 Jan 2009 07:36:02 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232523362.83.0.182241636779.issue4944@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Thanks for adapting the smaller example. I think I figured out what's 
the problem.

The error reported by checkfile.c is 0x20 = ERROR_SHARING_VIOLATION
"The process cannot access the file because it is being used by 
another process."

I modified the subprocess call, adding the parameter close_fds=True -- 
and now I see no errors. 
Please do a similar change in your application and see if it works.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Wed Jan 21 10:03:03 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 21 Jan 2009 09:03:03 +0000
Subject: [issue5020] Regex Expression Error
In-Reply-To: <1232517156.3.0.804486335225.issue5020@psf.upfronthosting.co.za>
Message-ID: <1232528583.51.0.73687549042.issue5020@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> the program crash
Well, it's not a crash, but a graceful exception:
    sre_constants.error: bad character range

Your regular expression is invalid: the '-' has a special meaning inside
square brackets.
Please consult the documentation: http://docs.python.org/library/re.html

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5020>
_______________________________________

From report at bugs.python.org  Wed Jan 21 11:44:07 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 21 Jan 2009 10:44:07 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232534647.48.0.950896475935.issue4972@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file12792/smtplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Wed Jan 21 12:21:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 21 Jan 2009 11:21:04 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232536864.99.0.670285602104.issue4972@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I've simplified the code
accordinglyhttp://bugs.python.org/issue4972?@ok_message=issue%204972%20files%20edited%20ok&@template=item

about the name of the vars. while I agree with you, I have use those names
(errcode, errmsg) because they are used in getreply() so I thought it
was more homogeneous.

about the return code , i am wondering if it would be good to add in
ftplib all the constantes
(http://www.ftpplanet.com/ftpresources/ftp_codes.htm) so things are clearer

Added file: http://bugs.python.org/file12823/smtplib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Wed Jan 21 12:21:15 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 21 Jan 2009 11:21:15 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232536875.22.0.486880443751.issue4972@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file12811/smtplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Wed Jan 21 13:23:08 2009
From: report at bugs.python.org (Tom Lynn)
Date: Wed, 21 Jan 2009 12:23:08 +0000
Subject: [issue5021] doctest.testfile should set __name__, can't use namedtuple
In-Reply-To: <1232540587.99.0.985129988543.issue5021@psf.upfronthosting.co.za>
Message-ID: <1232540587.99.0.985129988543.issue5021@psf.upfronthosting.co.za>


New submission from Tom Lynn <tlynn at users.sourceforge.net>:

This file fails when run with doctest.testfile::

  >>> print __name__
  __builtin__
  >>> print globals()['__name__']  # fails with KeyError: __name__
  __builtin__

"__builtin__" is probably not a good value, but more importantly, this 
means that you can't use namedtuples in text file doctests, since 
namedtuple() inspects the calling frame::

  >>> from namedtuple import namedtuple
  >>> t = namedtuple('fred', 'x')  # fails

(I presume this is the same for "from collections import namedtuple", 
but I've not tested with 2.6+.)

A workaround is to add this line at the start of the test::

   >>> __name__ = 'test'

----------
components: Library (Lib)
messages: 80322
nosy: tlynn
severity: normal
status: open
title: doctest.testfile should set __name__, can't use namedtuple
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5021>
_______________________________________

From report at bugs.python.org  Wed Jan 21 13:27:42 2009
From: report at bugs.python.org (Tom Lynn)
Date: Wed, 21 Jan 2009 12:27:42 +0000
Subject: [issue5022] doctest should allow running tests with "python -m
	doctest"
In-Reply-To: <1232540862.78.0.478308305039.issue5022@psf.upfronthosting.co.za>
Message-ID: <1232540862.78.0.478308305039.issue5022@psf.upfronthosting.co.za>


New submission from Tom Lynn <tlynn at users.sourceforge.net>:

It would be good to be able to do something like::

  $ python -m doctest foo.py
  $ python -m doctest --text foo.txt bar.txt

(or preferably some command line options design which could handle 
both .py and .txt files).

----------
components: Library (Lib)
messages: 80323
nosy: tlynn
severity: normal
status: open
title: doctest should allow running tests with "python -m doctest"
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5022>
_______________________________________

From report at bugs.python.org  Wed Jan 21 15:02:30 2009
From: report at bugs.python.org (Stefan Ring)
Date: Wed, 21 Jan 2009 14:02:30 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1232546550.64.0.0835758034002.issue4753@psf.upfronthosting.co.za>


Stefan Ring <e9725446 at student.tuwien.ac.at> added the comment:

Hi,

I ported threadedceval6.patch to Python 2.5.4, in case anyone is
interested...

Note that you need to run autoconf and autoheader.

----------
nosy: +Ringding
Added file: http://bugs.python.org/file12824/threadedceval6-py254.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan 21 15:09:56 2009
From: report at bugs.python.org (Michiel Overtoom)
Date: Wed, 21 Jan 2009 14:09:56 +0000
Subject: [issue2995] Idle, some Linuxes, cannot position Cursor by mouseclick
In-Reply-To: <1211995180.72.0.174580651078.issue2995@psf.upfronthosting.co.za>
Message-ID: <1232546996.51.0.691594054089.issue2995@psf.upfronthosting.co.za>


Michiel Overtoom <motoom at xs4all.nl> added the comment:

I experience the same, on FreeBSD 7.0-REL, with tkinter compiled to use
Tk8.5 instead of Tk8.4.  Tkinter compiled for Tk8.4 doesn't have the
problem.

Moving the mouse over the text widget changes the cursor to the I-beam
as expected, but click on text doesn't position the beam at the mouse
position.  It is also impossible to select text with the mouse. 
Selecting text with shift-arrow keys works, however.

The same bug has been reported on the OLPC wiki:

http://dev.laptop.org/ticket/7661
http://wiki.laptop.org/go/User:Rmyers/IDLE_on_the_XO

----------
nosy: +michiel.overtoom

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2995>
_______________________________________

From report at bugs.python.org  Wed Jan 21 15:44:30 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 21 Jan 2009 14:44:30 +0000
Subject: [issue4774] threding, bsddb and double free or corruption (fasttop)
In-Reply-To: <1230592853.0.0.0445648356303.issue4774@psf.upfronthosting.co.za>
Message-ID: <1232549070.07.0.767485262222.issue4774@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Closing the issue.

Python 2.5.x is only open for security patches. bsddb library in Python
2.6 doesn't have this issue.

People needing recent pybsddb in old python releases can download from
http://www.jcea.es/programacion/pybsddb.htm

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4774>
_______________________________________

From report at bugs.python.org  Wed Jan 21 16:17:53 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 21 Jan 2009 15:17:53 +0000
Subject: [issue1391] Adds the .compact() method to bsddb db.DB objects
In-Reply-To: <1194227398.84.0.43254190344.issue1391@psf.upfronthosting.co.za>
Message-ID: <1232551073.06.0.353257978653.issue1391@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I committed this patch to the imminent pybsddb 4.6.4. This will be
available soon in http://www.jcea.es/programacion/pybsddb.htm, and in
future Python 2.7.

The function is only available if you are using Berkeley DB 4.7 or
newer, since 4.6 was very buggy.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1391>
_______________________________________

From report at bugs.python.org  Wed Jan 21 16:27:16 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 21 Jan 2009 15:27:16 +0000
Subject: [issue5022] doctest should allow running tests with "python -m
	doctest"
In-Reply-To: <1232540862.78.0.478308305039.issue5022@psf.upfronthosting.co.za>
Message-ID: <1232551636.23.0.598499465275.issue5022@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Already implemented in Python 2.6; please upgrade.
2.5 only gets security fixes at this time.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5022>
_______________________________________

From report at bugs.python.org  Wed Jan 21 16:42:06 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 21 Jan 2009 15:42:06 +0000
Subject: [issue5021] doctest.testfile should set __name__, can't use namedtuple
In-Reply-To: <1232540587.99.0.985129988543.issue5021@psf.upfronthosting.co.za>
Message-ID: <1232552526.72.0.225620826723.issue5021@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

After updating the import line, it still fails in 2.6, 3.0 and the 
current trunk.

----------
nosy: +gagenellina
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5021>
_______________________________________

From report at bugs.python.org  Wed Jan 21 16:43:29 2009
From: report at bugs.python.org (Torsten Bronger)
Date: Wed, 21 Jan 2009 15:43:29 +0000
Subject: [issue2980] Pickle stream for unicode object may contain non-ASCII
	characters.
In-Reply-To: <1211902695.6.0.958731947697.issue2980@psf.upfronthosting.co.za>
Message-ID: <1232552609.49.0.655275641566.issue2980@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

I ran into this problem today when writing python data structures into a
database.  Only ASCII is safe in this situation.  I understood the
Python docs that protocol 0 was ASCII-only.

I use pickle+base64 now, however, this makes debugging more difficult.

Anyway, I think that the docs should clearly say that protocol 8 is not
ASCII-only because this is important in the Python world.  For example,
I saw this issue because Django makes an implicit unicode() conversion
with my input which fails with non-ASCII.

----------
nosy: +bronger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2980>
_______________________________________

From report at bugs.python.org  Wed Jan 21 16:45:00 2009
From: report at bugs.python.org (Torsten Bronger)
Date: Wed, 21 Jan 2009 15:45:00 +0000
Subject: [issue2980] Pickle stream for unicode object may contain non-ASCII
	characters.
In-Reply-To: <1211902695.6.0.958731947697.issue2980@psf.upfronthosting.co.za>
Message-ID: <1232552700.51.0.121397271522.issue2980@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

"protocol 8" --> "protocol 0" of course.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2980>
_______________________________________

From report at bugs.python.org  Wed Jan 21 17:44:45 2009
From: report at bugs.python.org (Eric Wald)
Date: Wed, 21 Jan 2009 16:44:45 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>


New submission from Eric Wald <pythonista at brainshell.org>:

Execution of "make test" for Python 2.6.1 halts with a segmentation 
fault on line 2198 of Python-2.6.1/Lib/test/test_datetime.py; also 
occurs using the attached script, narrowing it down to the %z sequence 
in the format argument to datetime.time.strftime(), but only when the 
time object has a non-None tzinfo.  The segfault disappears when I 
comment out line 1133 of Python-2.6.1/Modules/datetimemodule.c:

PyOS_snprintf(buf, buflen, "%c%02d%s%02d", sign, hours, sep, minutes);

Compiled with GCC 3.4.3 with Smashing Stack Protector on LFS 5.1.1 
(Linux 2.6.11.12 and glibc 2.3.5 with ssp patches).  Using BASECFLAGS=-
fno-stack-protector has no effect on the segfault.  All other Python 
tests pass.  HAVE_SNPRINTF has been defined to 1 in pyconfig.h by the 
config script.

I have not yet compiled gdb, but I can if requested.

----------
components: Library (Lib)
files: zone_failure.py
messages: 80332
nosy: eswald
severity: normal
status: open
title: Segfault in datetime.time.strftime("%z")
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file12825/zone_failure.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5023>
_______________________________________

From report at bugs.python.org  Wed Jan 21 18:19:42 2009
From: report at bugs.python.org (Robert Pyle)
Date: Wed, 21 Jan 2009 17:19:42 +0000
Subject: [issue5024] sndhdr.whathdr returns -1 for WAV file frame count
In-Reply-To: <1232558382.92.0.547995552561.issue5024@psf.upfronthosting.co.za>
Message-ID: <1232558382.92.0.547995552561.issue5024@psf.upfronthosting.co.za>


New submission from Robert Pyle <rpyle at post.harvard.edu>:

Seems like test_wav() could easily return the actual frame count by 
calling wave.py just as test_aifc() uses aifc.py.

----------
components: Library (Lib)
messages: 80333
nosy: rpyle
severity: normal
status: open
title: sndhdr.whathdr returns -1 for WAV file frame count
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5024>
_______________________________________

From report at bugs.python.org  Wed Jan 21 18:57:38 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 21 Jan 2009 17:57:38 +0000
Subject: [issue2980] Pickle stream for unicode object may contain non-ASCII
	characters.
In-Reply-To: <1232552609.49.0.655275641566.issue2980@psf.upfronthosting.co.za>
Message-ID: <4977620D.6080504@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-21 16:43, Torsten Bronger wrote:
> Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:
> 
> I ran into this problem today when writing python data structures into a
> database.  Only ASCII is safe in this situation.  I understood the
> Python docs that protocol 0 was ASCII-only.
> 
> I use pickle+base64 now, however, this makes debugging more difficult.

Databases can handle binary data just fine, so pickle protocol 2
should be better in your situation.

If you require ASCII-only data, you can also use pickle protocol 2,
zlib and base64 to get a compact version of a serialized Python object.

> Anyway, I think that the docs should clearly say that protocol 8 is not
> ASCII-only because this is important in the Python world.  For example,
> I saw this issue because Django makes an implicit unicode() conversion
> with my input which fails with non-ASCII.

That sounds like an issue with Django - it shouldn't try to convert
binary data to Unicode (which is reserved for text data).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2980>
_______________________________________

From report at bugs.python.org  Wed Jan 21 18:58:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Jan 2009 17:58:18 +0000
Subject: [issue5025] test_kqueue failure on OS X
In-Reply-To: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>
Message-ID: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I just got a one-off, non-reproducible test_kqueue failure, during a 'make 
test' of the trunk, on OS X 10.5.6.  Here's the output:

test_kqueue
test test_kqueue failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python_source/trunk/Lib/test/test_kqueue.py", line 
136, in test_queue_event
    (server.fileno(), select.KQ_FILTER_READ, flags)])
AssertionError: [(5L, -2, 5L), (6L, -2, 5L), (6L, -1, 5L)] != [(5, -2, 5), 
(5, -1, 5), (6, -2, 5), (6, -1, 5)]

Looking at the test_queue.py file just before line 136, I see:

        events = kq.control(None, 4, 1)
        # We may need to call it several times
        for i in range(5):
            if len(events) == 4:
                break
            events = kq.control(None, 4, 1)

Would adding a time.sleep(1.0) to the for loop make this test more robust?

My first impression was that the '1' in 'kq.control(None, 4, 1)' already 
did this;  i.e., that it meant that the kq.control function would wait up 
to 1 second for a response, but that doesn't seem to be true.  I tried 
replacing the 1 with 1000000 and the test still runs nearly 
instantaneously, even in the case where the kq.control call doesn't get 4 
events first time around.

Out of curiosity, *why* is there a need to call this several times? I 
fully believe there *is* such a need;  I just don't know what it is.  
Something to do with waiting for the socket send calls to complete, I 
assume?

----------
assignee: christian.heimes
components: Tests
messages: 80335
nosy: christian.heimes, marketdickinson
severity: normal
status: open
title: test_kqueue failure on OS X
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5025>
_______________________________________

From report at bugs.python.org  Wed Jan 21 19:04:52 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 21 Jan 2009 18:04:52 +0000
Subject: [issue5025] test_kqueue failure on OS X
In-Reply-To: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>
Message-ID: <1232561092.79.0.474840592955.issue5025@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> My first impression was that the '1' in 'kq.control(None, 4, 1)'
already did this;  i.e., that it meant that the kq.control function
would wait up to 1 second for a response, but that doesn't seem to be true.

Since there are events in the result, the call succeeds immediately. 
The timeout only defines an upper bound on how long control will block
before returning with *no* results.  Since the loop doesn't handle any
of the events, there's always some ready right away after the first call.

> Out of curiosity, *why* is there a need to call this several times?

It's out of the control of the test what the kernel does to deliver the
event notifications.  Since the test is waiting for multiple events, the
loop helps it get them all (although clearly it's not totally reliable).

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5025>
_______________________________________

From report at bugs.python.org  Wed Jan 21 19:34:45 2009
From: report at bugs.python.org (Torsten Bronger)
Date: Wed, 21 Jan 2009 18:34:45 +0000
Subject: [issue2980] Pickle stream for unicode object may contain non-ASCII
	characters.
In-Reply-To: <1211902695.6.0.958731947697.issue2980@psf.upfronthosting.co.za>
Message-ID: <1232562885.54.0.993704268462.issue2980@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

Well, Django doesn't story binary data at all but wants you to store
image files etc in the file system.  Whether this was a good design
decision, is beyond the scope of this issue.  My points actually are
only these:

a) the docs strongly suggest that protocol 0 is ASCII-only and this
should be clarified (one sentence would be fully sufficient I think)

b) currently, there is no way in the standard lib to serialise data in a
debuggable, ASCII-only format

Probably b) is not important.  *I* want to have it currently but this
doesn't mean much.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2980>
_______________________________________

From report at bugs.python.org  Wed Jan 21 20:02:31 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 21 Jan 2009 19:02:31 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232564551.07.0.912748641341.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

updated. incorporating roumen's work as well.

Added file: http://bugs.python.org/file12826/f

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Wed Jan 21 20:08:24 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 21 Jan 2009 19:08:24 +0000
Subject: [issue5026] [reopening] native build of python win32 using msys under
	wine.
In-Reply-To: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>
Message-ID: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

reopening a new bug with the exact same title due to #4954 having
been unilaterally closed without discussion, nor reasons specified.

simple courtesy would dictate that some sort of dialog is entered
into especially when someone is putting in significant amounts of
work in developing python, and has plans to forward-port the patch
to python2.6 and trunk, merge it with #3844 and much more.

----------
components: Build
files: f
messages: 80339
nosy: lkcl
severity: normal
status: open
title: [reopening] native build of python win32 using msys under wine.
versions: Python 2.5
Added file: http://bugs.python.org/file12827/f

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5026>
_______________________________________

From report at bugs.python.org  Wed Jan 21 20:09:49 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 21 Jan 2009 19:09:49 +0000
Subject: [issue5026] [reopening] native build of python win32 using msys under
	both wine and native win32
In-Reply-To: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>
Message-ID: <1232564989.72.0.489393759962.issue5026@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

so.

let me be clear.

this bug is a continuation of work to port python to mingw,
with a specific BUT NOT UNIQUE focus of ensuring that python
can be compiled under wine.

THE ATTACHED PATCH CAN ALSO BE USED TO COMPILE PYTHON UNDER WIN32.

----------
title: [reopening] native build of python win32 using msys under wine. -> [reopening] native build of python win32 using msys under both wine and native win32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5026>
_______________________________________

From report at bugs.python.org  Wed Jan 21 20:15:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Jan 2009 19:15:47 +0000
Subject: [issue5025] test_kqueue failure on OS X
In-Reply-To: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>
Message-ID: <1232565347.89.0.0469349029558.issue5025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch:

 - add a time.sleep(1.0) in between calls to kq.control
 - restructure for loop slightly: move initial kq.control call inside it 
 - bump number of trials from 5 to 10 (why not?!)
 - produce more meaningful error message in the unlikely event
   that we never get the 4 events we're waiting for

----------
keywords: +patch
Added file: http://bugs.python.org/file12828/issue5025.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5025>
_______________________________________

From report at bugs.python.org  Wed Jan 21 20:16:29 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 21 Jan 2009 19:16:29 +0000
Subject: [issue5026] [reopening] native build of python win32 using msys under
	both wine and native win32
In-Reply-To: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>
Message-ID: <1232565389.42.0.0298792798147.issue5026@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

attached also manifests and rc files for building on msvcr80

Added file: http://bugs.python.org/file12829/x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5026>
_______________________________________

From report at bugs.python.org  Wed Jan 21 20:17:15 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 21 Jan 2009 19:17:15 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232565435.09.0.459186681325.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

manifests and rc files for msvcr80 build

Added file: http://bugs.python.org/file12830/x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Wed Jan 21 20:58:53 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 21 Jan 2009 19:58:53 +0000
Subject: [issue4954] native build of python win32 using msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232567933.59.0.843773001751.issue4954@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

martin, so sorry, i didn't see your comments - no dang hell no i'm
not done yet.

regarding graminit.h: graminit.h isn't being removed - i keep editing it
out of the patch.
i'm not _submitting_ it as part of the patch because what happens is that
Parser/pgen.exe generates CRLF and EVVVVERY single line of graminit.h
gets replaced.

so it's a bit irritating to keep having to even see it, so i removed
it from my local repository.

if i accidentally submit its removal please ignore it, entirely.

people _are_ tracking the progress of this development, and assisting
in the work.  i'm using the bugtracker to communicate the progress.

closing the bug looks... like... i dunno - it's not very helpful,
though, i have to say.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4954>
_______________________________________

From report at bugs.python.org  Wed Jan 21 21:00:55 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 21 Jan 2009 20:00:55 +0000
Subject: [issue5026] [reopening] native build of python win32 using msys under
	both wine and native win32
In-Reply-To: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>
Message-ID: <1232568055.78.0.590982824178.issue5026@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

martin - apologies for shouting: i hadn't seen your explanations
of why #4954 was closed.  i'm not happy that it _was_ closed, but
that's another story.

yes of course i will be going on to python2.6 and up - first though
is to focus on python2.5 and get _that_ into shape, then moving
on to 2.6 and 2.7 is easy.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5026>
_______________________________________

From report at bugs.python.org  Wed Jan 21 21:59:42 2009
From: report at bugs.python.org (Soren Roug)
Date: Wed, 21 Jan 2009 20:59:42 +0000
Subject: [issue5027] xml namespace not understood by
	xml.sax.saxutils.XMLGenerator
In-Reply-To: <1232571582.02.0.360824752482.issue5027@psf.upfronthosting.co.za>
Message-ID: <1232571582.02.0.360824752482.issue5027@psf.upfronthosting.co.za>


New submission from Soren Roug <soren.roug at eea.europa.eu>:

The 'xml' namespace in XML files is special in that it need not be
declared. When xml.sax.saxutils.XMLGenerator is used with the namespace
feature it does not know how to handle it.

Example. The code:

import xml.sax, xml.sax.saxutils
parser = xml.sax.make_parser()
parser.setFeature(xml.sax.handler.feature_namespaces, 1)
c = xml.sax.saxutils.XMLGenerator()
parser.setContentHandler(c)
parser.parse('testfile.xml')

executed on the testfile.xml with this content:

<?xml version="1.0"?>
<a:greetings xmlns:a="http://example.com/ns">
  <a:greet xml:lang="en">Hello world</a:greet>
</a:greetings>

will produce this error:
...
  File "/usr/lib/python2.5/xml/sax/saxutils.py", line 149, in startElementNS
    self._write(' %s=%s' % (self._qname(name), quoteattr(value)))
  File "/usr/lib/python2.5/xml/sax/saxutils.py", line 107, in _qname
    prefix = self._current_context[name[0]]
KeyError: u'http://www.w3.org/XML/1998/namespace'


It can be fixed by making an exception for the xml namespace (as
required by W3C - See http://www.w3.org/XML/1998/namespace) in
xml/sax/saxutils.py. The _qname method could then look like this:

    def _qname(self, name):
        """Builds a qualified name from a (ns_url, localname) pair"""
        if name[0]:
            if name[0] == u'http://www.w3.org/XML/1998/namespace':
                return u'xml' + ":" + name[1]
            # The name is in a non-empty namespace
            prefix = self._current_context[name[0]]
            if prefix:
                # If it is not the default namespace, prepend the prefix
                return prefix + ":" + name[1]
        # Return the unqualified name
        return name[1]

----------
components: Library (Lib), XML
messages: 80346
nosy: roug
severity: normal
status: open
title: xml namespace not understood by xml.sax.saxutils.XMLGenerator
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5027>
_______________________________________

From report at bugs.python.org  Wed Jan 21 22:25:49 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Jan 2009 21:25:49 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1232573149.89.0.364404018284.issue3871@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Does this supercede #3754? If so, please add this as superseder and
close it.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jan 21 22:52:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 21 Jan 2009 21:52:30 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232574750.7.0.521604427898.issue4972@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Feedback from my blog :

other places where a context manager could be good to have :

- gzip
- zipfile
- urllib2.urlopen and urllib.request.urlopen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Wed Jan 21 22:53:26 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 21 Jan 2009 21:53:26 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1232574806.42.0.431505876054.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Does this supercede #3754?  - no.
The issue #3754 introduce macro AC_CANONICAL_HOST(add standardize "host
triplets") + fixes for cross-compilation.
Changes to configure script in this patch show how to use "host triplet"
for mingw builds.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jan 21 22:55:45 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 21 Jan 2009 21:55:45 +0000
Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR)
	which can cause Cygwin build to fail
In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za>
Message-ID: <1232574945.03.0.19191974186.issue2233@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

No response from py-dev list :( . May be solution has to work in all cases.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2233>
_______________________________________

From report at bugs.python.org  Wed Jan 21 22:58:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Jan 2009 21:58:00 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232575080.35.0.455604592443.issue4972@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Tarek: gzip and bz2 are already done
(http://code.python.org/hg/trunk/rev/d9555936ded9).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Wed Jan 21 23:11:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 21 Jan 2009 22:11:30 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232575890.07.0.386772545537.issue4972@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ah great, thanks for telling Antoine, I missed it on gzip. And the test
on bz2 makes me see that my tests are not sufficient (calling with on an
instance that has already been used and close)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Thu Jan 22 02:39:03 2009
From: report at bugs.python.org (Duncan Findlay)
Date: Thu, 22 Jan 2009 01:39:03 +0000
Subject: [issue5028] tokenize.generate_tokens doesn't always return logical
	line
In-Reply-To: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>
Message-ID: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>


New submission from Duncan Findlay <duncf at apache.org>:

According to the documentation for tokenize.generate_tokens:

"The generator produces 5-tuples with these members: the token type; the
token string; a 2-tuple (srow, scol) of ints specifying the row and
column where the token begins in the source; a 2-tuple (erow, ecol) of
ints specifying the row and column where the token ends in the source;
and the line on which the token was found. The line passed (the last
tuple item) is the logical line; continuation lines are included."

It seems though that the "logical line" -- the last element of the tuple
is the physical line unless the token being returned spans beyond the
end of the line. As an example, consider a test file test.py:

foo = """
%s """ % 'bar'

>>> import pprint, tokenize
>>> pprint.pprint(list(tokenize.generate_tokens(open('test.py').readline)))
[(1, 'foo', (1, 0), (1, 3), 'foo = """\n'),
 (51, '=', (1, 4), (1, 5), 'foo = """\n'),
 (3, '"""\n%s """', (1, 6), (2, 6), 'foo = """\n%s """ % \'bar\'\n'),
 (51, '%', (2, 7), (2, 8), '%s """ % \'bar\'\n'),
 (3, "'bar'", (2, 9), (2, 14), '%s """ % \'bar\'\n'),
 (4, '\n', (2, 14), (2, 15), '%s """ % \'bar\'\n'),
 (0, '', (3, 0), (3, 0), '')]
>>> 

Since there is only one logical line, I would expect the first 6 tokens
to have the same 5th element.

----------
components: Library (Lib)
messages: 80353
nosy: duncf
severity: normal
status: open
title: tokenize.generate_tokens doesn't always return logical line
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5028>
_______________________________________

From report at bugs.python.org  Thu Jan 22 03:01:14 2009
From: report at bugs.python.org (=?utf-8?q?Dinko_Galeti=C4=87?=)
Date: Thu, 22 Jan 2009 02:01:14 +0000
Subject: [issue5029] Odd slicing behaviour
In-Reply-To: <1232589674.41.0.799165802013.issue5029@psf.upfronthosting.co.za>
Message-ID: <1232589674.41.0.799165802013.issue5029@psf.upfronthosting.co.za>


New submission from Dinko Galeti? <dinko.galetic at gmail.com>:

#the following code should return an empty list, but returns the 0th
member of the list

>>> foo = [1, 2, 3]
>>> foo[0::-1]
[1]

----------
components: Regular Expressions
messages: 80354
nosy: dgaletic
severity: normal
status: open
title: Odd slicing behaviour
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5029>
_______________________________________

From report at bugs.python.org  Thu Jan 22 03:19:16 2009
From: report at bugs.python.org (David Schultz)
Date: Thu, 22 Jan 2009 02:19:16 +0000
Subject: [issue5030] Typo in class tkinter.filedialog.Directory prevents
	compilation
In-Reply-To: <1232590756.63.0.287799731331.issue5030@psf.upfronthosting.co.za>
Message-ID: <1232590756.63.0.287799731331.issue5030@psf.upfronthosting.co.za>


New submission from David Schultz <ringhome at cox.net>:

class tkinter.filedialog.Directory incorrectly derives from Dialog instead 
of _Dialog.  Adding the "_" allows the code to compile and run as 
expected.

This also explains why tkinter.filedialog.askdirectory() doesn't work.

----------
components: Tkinter
messages: 80355
nosy: ringhome
severity: normal
status: open
title: Typo in class tkinter.filedialog.Directory prevents compilation
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5030>
_______________________________________

From report at bugs.python.org  Thu Jan 22 03:24:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 22 Jan 2009 02:24:00 +0000
Subject: [issue5030] Typo in class tkinter.filedialog.Directory prevents
	compilation
In-Reply-To: <1232590756.63.0.287799731331.issue5030@psf.upfronthosting.co.za>
Message-ID: <1232591040.66.0.605623671811.issue5030@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Duplicate of #4406.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5030>
_______________________________________

From report at bugs.python.org  Thu Jan 22 03:46:48 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 22 Jan 2009 02:46:48 +0000
Subject: [issue5028] tokenize.generate_tokens doesn't always return logical
	line
In-Reply-To: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>
Message-ID: <1232592408.17.0.533217907913.issue5028@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5028>
_______________________________________

From report at bugs.python.org  Thu Jan 22 03:48:24 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 22 Jan 2009 02:48:24 +0000
Subject: [issue5029] Odd slicing behaviour
In-Reply-To: <1232589674.41.0.799165802013.issue5029@psf.upfronthosting.co.za>
Message-ID: <1232592504.5.0.309279872143.issue5029@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5029>
_______________________________________

From report at bugs.python.org  Thu Jan 22 03:52:52 2009
From: report at bugs.python.org (dashing)
Date: Thu, 22 Jan 2009 02:52:52 +0000
Subject: [issue1048820] Only "Overwrite" mode possible with
	curses.textpad.Textbox
Message-ID: <1232592772.2.0.794191948006.issue1048820@psf.upfronthosting.co.za>


dashing <dashing at hushmail.com> added the comment:

I am getting
"RuntimeError: maximum recursion depth exceeded"

as soon as I type a character in a textbox made with insert_mode=True.

----------
nosy: +dashing
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1048820>
_______________________________________

From report at bugs.python.org  Thu Jan 22 03:55:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 22 Jan 2009 02:55:09 +0000
Subject: [issue5022] doctest should allow running tests with "python -m
	doctest"
In-Reply-To: <1232540862.78.0.478308305039.issue5022@psf.upfronthosting.co.za>
Message-ID: <1232592909.64.0.967587965692.issue5022@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5022>
_______________________________________

From report at bugs.python.org  Thu Jan 22 03:58:30 2009
From: report at bugs.python.org (Javen Wang)
Date: Thu, 22 Jan 2009 02:58:30 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232593110.04.0.601078190268.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

I'm using Python2.5 in which close_fds is not available in Windows. And
I cannot use Python2.6 because I need to redirect the stdout and stderr
and there's performance concern.

I have questions on the root cause:

  a. why doesn't fopen() has sharing issue?
  b. why don't os.close() and FileObject.close() really close the file?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Thu Jan 22 09:20:19 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 22 Jan 2009 08:20:19 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232612419.07.0.991820266892.issue4944@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

python2.6 is not so different from python2.5. Which performance concerns
do you have?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Thu Jan 22 09:27:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 08:27:53 +0000
Subject: [issue5029] Odd slicing behaviour
In-Reply-To: <1232589674.41.0.799165802013.issue5029@psf.upfronthosting.co.za>
Message-ID: <1232612873.9.0.651359273696.issue5029@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why should it return an empty list?

>>> foo = [1,2,3]
>>> foo[1::-1]
[2, 1]
>>> foo[0::-1]
[1]

looks quite consistent to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5029>
_______________________________________

From report at bugs.python.org  Thu Jan 22 09:45:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Jan 2009 08:45:17 +0000
Subject: [issue5029] Odd slicing behaviour
In-Reply-To: <1232589674.41.0.799165802013.issue5029@psf.upfronthosting.co.za>
Message-ID: <1232613917.81.0.870011220583.issue5029@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5029>
_______________________________________

From report at bugs.python.org  Thu Jan 22 10:26:30 2009
From: report at bugs.python.org (steve21)
Date: Thu, 22 Jan 2009 09:26:30 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

In the threading module the Thread.daemon documentation says:

"The thread?s daemon flag. This must be set before start() is called,
otherwise RuntimeError is raised.

    The initial value is inherited from the creating thread.

    The entire Python program exits when no alive non-daemon threads are
left."

I think the docs should state Thread.daemon's type (boolean, or integer,
or something else?) and its default value (when you have not set .daemon
in the creating thread.)

----------
assignee: georg.brandl
components: Documentation
messages: 80361
nosy: georg.brandl, steve21
severity: normal
status: open
title: Thread.daemon docs
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Thu Jan 22 11:10:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 10:10:20 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232619020.51.0.397027184546.issue4874@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan 22 11:32:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 10:32:08 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232620328.44.0.630241681832.issue4874@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r68855, r68856. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan 22 11:46:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 22 Jan 2009 10:46:12 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232621172.48.0.946317385509.issue4874@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IMO, Modules/cjkcodecs/multibytecodec.c should be changed as well.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan 22 11:55:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 10:55:57 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232621757.9.0.630856245052.issue4874@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Right, I hadn't thought of that.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan 22 12:05:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 11:05:11 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232622311.46.0.32785075646.issue4874@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"Fixing" multibytecodec.c produces a TypeError in the following test:

    def test_errorcallback_longindex(self):
        dec = codecs.getdecoder('euc-kr')
        myreplace  = lambda exc: ('', sys.maxsize+1)
        codecs.register_error('test.cjktest', myreplace)
        self.assertRaises(IndexError, dec,
                          'apple\x92ham\x93spam', 'test.cjktest')

TypeError: decode() argument 1 must be bytes or buffer, not str

Since the test is meant to test recovery from a misbehaving callback, I
guess the type of the input string is not really important and can be
changed to a bytes string instead. What do you think?

(in any case, here is a patch)

Added file: http://bugs.python.org/file12831/mbdecode-unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan 22 12:56:19 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 22 Jan 2009 11:56:19 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232625379.49.0.405277908897.issue4874@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good. 
I think the missing b in test_errorcallback_longindex is an overlook
when the tests were updated for py3k. You are right to change the test.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan 22 13:25:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 12:25:57 +0000
Subject: [issue4874] decoding functions in _codecs module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1232627157.89.0.211724839178.issue4874@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r68857, r68858.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4874>
_______________________________________

From report at bugs.python.org  Thu Jan 22 14:14:31 2009
From: report at bugs.python.org (steve21)
Date: Thu, 22 Jan 2009 13:14:31 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

I'd like to request a 'step' argument be added for itertools.count. It
would be useful in the same way that step is useful for the 'range'
function.

('range' and 'count' are very similar - 'count' could even be merged into
'range', for example by making 'range(None)' equivalent to 'count()')

----------
components: None
messages: 80368
nosy: steve21
severity: normal
status: open
title: itertools.count step
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Thu Jan 22 16:48:36 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 22 Jan 2009 15:48:36 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232639316.06.0.260544209754.issue3881@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch that should fix the problem. It uses Vista's
GetFinalPathNameByHandleW to expand symbolic links before passing the
path to Tcl.

----------
keywords: +patch
Added file: http://bugs.python.org/file12832/symlink.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Thu Jan 22 16:48:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 22 Jan 2009 15:48:48 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232639328.33.0.0273601460465.issue3881@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Thu Jan 22 17:23:26 2009
From: report at bugs.python.org (blahblahwhat)
Date: Thu, 22 Jan 2009 16:23:26 +0000
Subject: [issue5033] setup.py crashes if sqlite version contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>


New submission from blahblahwhat <blahblah57 at mailinator.com>:

When I try to 'make' Python 2.6.1:

Traceback (most recent call last):
  File "./setup.py", line 1880, in <module>
    main()
  File "./setup.py", line 1875, in main
    'Lib/smtpd.py']
  File "/home/apps/Python-2.6.1/Lib/distutils/core.py", line 152, in 
setup
    dist.run_commands()
  File "/home/apps/Python-2.6.1/Lib/distutils/dist.py", line 975, in 
run_commands
    self.run_command(cmd)
  File "/home/apps/Python-2.6.1/Lib/distutils/dist.py", line 995, in 
run_command
    cmd_obj.run()
  File "/home/apps/Python-2.6.1/Lib/distutils/command/build.py", line 
134, in run
    self.run_command(cmd_name)
  File "/home/apps/Python-2.6.1/Lib/distutils/cmd.py", line 333, in 
run_command
    self.distribution.run_command(command)
  File "/home/apps/Python-2.6.1/Lib/distutils/dist.py", line 995, in 
run_command
    cmd_obj.run()
  File "/home/apps/Python-2.6.1/Lib/distutils/command/build_ext.py", 
line 343, in run
    self.build_extensions()
  File "./setup.py", line 103, in build_extensions
    missing = self.detect_modules()
  File "./setup.py", line 915, in detect_modules
    for x in sqlite_version.split(".")])
ValueError: invalid literal for int() with base 10: '1beta'

This was solved by replacing

  m = re.search(r'\s*.*#\s*.*define\s.*SQLITE_VERSION\W*"(.*)"', incf)

with

  m = re.search(r'\s*.*#\s*.*define\s.*SQLITE_VERSION\W*"([\d\.]*)"', 
incf)

on line 911

----------
components: Build
messages: 80370
nosy: blahblahwhat
severity: normal
status: open
title: setup.py crashes if sqlite version contains 'beta'
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5033>
_______________________________________

From report at bugs.python.org  Thu Jan 22 17:29:10 2009
From: report at bugs.python.org (Javen Wang)
Date: Thu, 22 Jan 2009 16:29:10 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1232641750.69.0.778477184948.issue4944@psf.upfronthosting.co.za>


Javen Wang <javen72 at gmail.com> added the comment:

I don't have Python2.6 installed. I just have ever read a bench article
comparing the performance between different version of Python, including
2.5, 2.6 and 3.0. That article shows, for the same script, Python2.6 has
longer running time than Python2.5. My application is a build system and
the users are very care about the time spent in build. That's why I have
the performance concern.

What concerns me more is the stdout/stderr redirection. Python2.6 manual
says they cannot be redirected if close_fds is set to True. My
application relies on the I/O redirection to control the screen output
from subprocess.

Actually I have had a work-around for this issue. It works very well so
far. I reported a bug here just because I want the Python to be better.
I learned it one year ago but I love this language. I just hope nobody
else encounter such problem again. If you guys think it won't be fixed
in Python 2.5 or has been fixed in Python 2.6, it's OK to close this
tracker. Thanks for your time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Thu Jan 22 17:29:48 2009
From: report at bugs.python.org (Jim Baker)
Date: Thu, 22 Jan 2009 16:29:48 +0000
Subject: [issue4242] Classify language vs. impl-detail tests, step 1
In-Reply-To: <1225386180.53.0.475585271298.issue4242@psf.upfronthosting.co.za>
Message-ID: <1232641788.58.0.396446611288.issue4242@psf.upfronthosting.co.za>


Changes by Jim Baker <jbaker at zyasoft.com>:


----------
nosy: +jbaker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________

From report at bugs.python.org  Thu Jan 22 19:18:41 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 22 Jan 2009 18:18:41 +0000
Subject: [issue5034] itertools.fixlen
In-Reply-To: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>
Message-ID: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

As raised recently on python-ideas [1]_, an itertools method fixing
iterators to a certain length might be handy (where fixing is either
cutting elements off or appending values).

I appended a patch implementing this feature in Python/C, unit tests and
documentation included.

.. [1] http://thread.gmane.org/gmane.comp.python.ideas/2472/focus=2479

----------
components: Library (Lib)
files: fixlen.patch
keywords: patch
messages: 80372
nosy: lehmannro
severity: normal
status: open
title: itertools.fixlen
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file12833/fixlen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5034>
_______________________________________

From report at bugs.python.org  Thu Jan 22 19:43:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Jan 2009 18:43:00 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1232649780.47.0.730533441.issue5032@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
components: +Extension Modules -None
nosy: +rhettinger
priority:  -> low
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Thu Jan 22 19:44:38 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Jan 2009 18:44:38 +0000
Subject: [issue5034] itertools.fixlen
In-Reply-To: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>
Message-ID: <1232649878.56.0.521591650397.issue5034@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5034>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:14:37 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:14:37 +0000
Subject: [issue3093] Namespace pollution from multiprocessing
In-Reply-To: <1213300660.18.0.995213086332.issue3093@psf.upfronthosting.co.za>
Message-ID: <1232651677.23.0.381673003685.issue3093@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3093>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:16:45 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:16:45 +0000
Subject: [issue3283] multiprocessing.connection doesn't import
	AuthenticationError, while using it
In-Reply-To: <1215179111.5.0.100147287247.issue3283@psf.upfronthosting.co.za>
Message-ID: <1232651805.46.0.0407121910384.issue3283@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Fixed in 66023 by nnorwitz

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3283>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:17:24 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:17:24 +0000
Subject: [issue3273] multiprocessing and meaningful errors
In-Reply-To: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za>
Message-ID: <1232651844.19.0.695780165313.issue3273@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3273>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:18:37 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:18:37 +0000
Subject: [issue3551] multiprocessing.Pipe terminates with
	ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
In-Reply-To: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>
Message-ID: <1232651917.65.0.820755506861.issue3551@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> normal
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3551>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:20:39 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:20:39 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1232652039.05.0.662836825691.issue3831@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:22:12 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:22:12 +0000
Subject: [issue3273] multiprocessing and meaningful errors
In-Reply-To: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za>
Message-ID: <1232652132.65.0.983583969186.issue3273@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I am going to track this as part of issue 5001

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Remove assertion-based checking in multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3273>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:25:52 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:25:52 +0000
Subject: [issue3272] Multiprocessing hangs when multiprocessing.Pool methods
	are called
In-Reply-To: <1215103718.59.0.127699249536.issue3272@psf.upfronthosting.co.za>
Message-ID: <1232652352.87.0.13889814624.issue3272@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

This is now covered in the multiprocessing documentation:

"Note Functionality within this package requires that the __main__ method 
be importable by the children. This is covered in Programming guidelines 
however it is worth pointing out here. This means that some examples, such 
as the multiprocessing.Pool examples will not work in the interactive 
interpreter."

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3272>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:51:44 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:51:44 +0000
Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue
In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>
Message-ID: <1232653904.9.0.643031504399.issue4660@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4660>
_______________________________________

From report at bugs.python.org  Thu Jan 22 20:54:54 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 19:54:54 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1232654094.37.0.837938149712.issue3578@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Thu Jan 22 21:51:54 2009
From: report at bugs.python.org (Jacob)
Date: Thu, 22 Jan 2009 20:51:54 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232657514.14.0.089281783847.issue3881@psf.upfronthosting.co.za>


Jacob <jacoberen at gmail.com> added the comment:

Fantastic.
I started this post in October, and now we finaly found a solution.
Thank you Martin.
Will this patch be included in future versions of python?
Best regards, Jacob.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Thu Jan 22 21:56:07 2009
From: report at bugs.python.org (Robert Kern)
Date: Thu, 22 Jan 2009 20:56:07 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1232657767.45.0.147850668877.issue4111@psf.upfronthosting.co.za>


Changes by Robert Kern <robert.kern at gmail.com>:


----------
nosy: +robert.kern

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Jan 22 22:04:24 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 21:04:24 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1232658264.14.0.238192419427.issue3807@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Here's a simplified patch, unfortunately I can't test this as an OS/X 
build with --without-threads enabled has other issues besides this.

Added file: http://bugs.python.org/file12834/issue3807.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Thu Jan 22 22:15:26 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Jan 2009 21:15:26 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1232658926.83.0.766488972972.issue4111@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Jan 22 22:21:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 21:21:41 +0000
Subject: [issue5034] itertools.fixlen
In-Reply-To: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>
Message-ID: <1232659301.51.0.810654967218.issue5034@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"Return an iterator fixing *iterable*\ 's length to *length* by either
cutting elements off or adding *value* to the iterable."

Rather than mixing both, it would be more flexible to have a separate
function for each IMO.
Cutting off is already be handled by islice() (isn't it?), and padding
should be done with a function called e.g. pad() or rpad().

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5034>
_______________________________________

From report at bugs.python.org  Thu Jan 22 22:24:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 21:24:22 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

libpython2.7.a(object.o): In function `_PyObject_Dump':
/home/antoine/cpython/__svn__/Objects/object.c:341: undefined reference
to `PyGILState_Ensure'
/home/antoine/cpython/__svn__/Objects/object.c:343: undefined reference
to `PyGILState_Release'

----------
messages: 80379
nosy: jnoller, pitrou
priority: normal
severity: normal
status: open
title: Compilation --without-threads fails
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Thu Jan 22 22:27:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 21:27:42 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232659662.86.0.213264836252.issue5035@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem seems to have appeared with:

[svn r67802] #3632: the "pyo" macro from gdbinit can now run when the
GIL is released.

Patch by haypo.


diff -r 68d511e1c4bc -r 584e97b40be9 Objects/object.c
--- a/Objects/object.c  Mon Dec 15 22:47:57 2008 +0100
+++ b/Objects/object.c  Mon Dec 15 23:29:14 2008 +0100
@@ -331,8 +331,11 @@
        if (op == NULL)
                fprintf(stderr, "NULL\n");
        else {
+               PyGILState_STATE gil;
                fprintf(stderr, "object  : ");
+               gil = PyGILState_Ensure();
                (void)PyObject_Print(op, stderr, 0);
+               PyGILState_Release(gil);
                /* XXX(twouters) cast refcount to long until %zd is
                   universally available */
                fprintf(stderr, "\n"

----------
nosy: +amaury.forgeotdarc, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Thu Jan 22 22:35:06 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 22 Jan 2009 21:35:06 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1232660106.09.0.428211294778.issue4111@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

So I completely dropped the ball on this.  It appears we have some
folks from Sun and Brett surmised that Ronald Oussoren would be the
likely person to do the heavy lifting on the Apple side of things.
Ronald, I've made you nosy.  I will try to get the Solaris patch Ted
referenced running against the trunk (2.7) and py3k (3.1) code bases,
but it would be helpful if you could take a quick stab at it as well.

----------
assignee:  -> skip.montanaro
nosy: +ronaldoussoren
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Jan 22 22:41:30 2009
From: report at bugs.python.org (Ted Leung)
Date: Thu, 22 Jan 2009 21:41:30 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1232660106.09.0.428211294778.issue4111@psf.upfronthosting.co.za>
Message-ID: <8B3233ED-3F2A-4F00-B607-71A4A897F64A@sauria.com>


Ted Leung <twl at sauria.com> added the comment:

On Jan 22, 2009, at 1:35 PM, Skip Montanaro wrote:

>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> So I completely dropped the ball on this.  It appears we have some
> folks from Sun and Brett surmised that Ronald Oussoren would be the
> likely person to do the heavy lifting on the Apple side of things.
> Ronald, I've made you nosy.  I will try to get the Solaris patch Ted
> referenced running against the trunk (2.7) and py3k (3.1) code bases,
> but it would be helpful if you could take a quick stab at it as well.

Great.  Actually the latest version of the patch is this one: <http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/Python26-07-dtrace.diff 
 >.   I tried to quickly compile it on MacOS 10.5, Python 2.6.1, but  
it didn't work right out of the box.

Ted

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090122/d8cb6679/attachment-0001.txt>

From report at bugs.python.org  Thu Jan 22 22:50:53 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Jan 2009 21:50:53 +0000
Subject: [issue5034] itertools.fixlen
In-Reply-To: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>
Message-ID: <1232661053.46.0.207881122951.issue5034@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am taking this under advisement but am initially disinclined.  It is not
a basic itertool since it can be composed from the others.  Also, it's
use cases seem to be few.  One challenge for the module is that adding
more tools makes the overall toolkit harder to use because the number of
choices is increased.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5034>
_______________________________________

From report at bugs.python.org  Thu Jan 22 22:56:04 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Jan 2009 21:56:04 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1232661364.12.0.0672139090715.issue5032@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am not too excited about this one.  As a heavy itertools user myself,
I've never had occasion to need a step argument.  As an implementer, I'm
aware that it would make the code for count() much more complex (because
of the internal optimizations and because step can be positive,
negative, or zero).

Have you had any real world use cases where count(start, step) would
have been the best solution?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Thu Jan 22 23:06:47 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 22:06:47 +0000
Subject: [issue4593] Documentation for multiprocessing - Pool.apply()
In-Reply-To: <1228751120.11.0.178840080456.issue4593@psf.upfronthosting.co.za>
Message-ID: <1232662007.19.0.453272544063.issue4593@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

fixed in trunk, r68862, merged to 3k in r68863

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4593>
_______________________________________

From report at bugs.python.org  Thu Jan 22 23:08:42 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 22:08:42 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232662122.93.0.13030053362.issue4999@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Thu Jan 22 23:16:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 22:16:11 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232662571.46.0.181450770361.issue4999@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Rather than providing strict ordering of Queue input/output, perhaps a
separate or derived class (PriorityQueue?) should be provided just for
that matter (heapq-based?).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Thu Jan 22 23:46:08 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Jan 2009 22:46:08 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232664368.21.0.56421406725.issue4999@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The Queue module design should be followed as closely as possible.  It
provides FIFO order as the default, with options for LIFO and priority
order.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Thu Jan 22 23:53:59 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 22 Jan 2009 22:53:59 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1232664839.66.0.586713352276.issue4111@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

After applying the patch and reconfiguring I get compilation errors in
Python/ceval.c.  I suspect it's because there is a new header file,
Python/python.h.  That's probably found by the #include directive in
favor of Include/Python.h because of the Mac's case-insensitive file
system.  Changing the Makefile targets and actions so it's named
python-dtrace.h seems to work a bit better.  I get an error later
running dtrace which I have yet to investigate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Jan 23 00:10:44 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 22 Jan 2009 23:10:44 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232665844.2.0.205187563909.issue4999@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I agree, at very least it should provide the same default behavior that 
Queue does, however, it is not obvious to me how to resolve this in 
mp.Queue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Fri Jan 23 00:20:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 23:20:41 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232666441.67.0.46789522609.issue4999@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That's why I was suggesting to leave Queue as it is and provide a
separate PriorityQueue. With a PriorityQueue the user is free to put
(timestamp, object) tuples in it if he wants a strict chronologic
ordering. He can also use sequence numbers instead of timestamps, etc.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Fri Jan 23 00:23:17 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 22 Jan 2009 23:23:17 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232666597.79.0.54851231165.issue4999@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Jesse, can you explain the cause of the bug?  Maybe that will inspire
someone to come up with an idea for a fix.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Fri Jan 23 00:38:33 2009
From: report at bugs.python.org (Eric Wald)
Date: Thu, 22 Jan 2009 23:38:33 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1232667513.09.0.73502826463.issue5023@psf.upfronthosting.co.za>


Eric Wald <pythonista at brainshell.org> added the comment:

Update: Undefining HAVE_SNPRINTF does not correct the problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5023>
_______________________________________

From report at bugs.python.org  Fri Jan 23 02:44:23 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 23 Jan 2009 01:44:23 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232675063.76.0.114823678626.issue4972@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

As for ftplib patch you should make sure that close() gets called in any
case but never more than once.
You can use "finally" to satisfy the first requirement and "self.sock is
not None" to check the second condition:



+    def __exit__(self, *args):
+        """Context management protocol.
+
+        Will try to quit() if active, then close().
+        If not active, a simple close() call is made.
+        """
+        if self.sock is not None and self.getwelcome() is not None:
+            try:
+                self.quit()
+            except socket.error, e:
+                # [Errno 61] is Connection refused
+                # if the error is different, we want to raise it.
+                if e.errno != 61:
+                    raise
+            finally:
+                if self.sock is not None:
+                    self.close()
+        else:
+            self.close()

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Fri Jan 23 02:59:17 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 01:59:17 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232675957.96.0.287751217052.issue4999@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

As a note to myself: adding a simple print to the multiprocessing.Queue 
put method, I can see the calls occurring from the children in order, 
for example:

obj:  0.025193 [proc1] Got lock
obj:  0.227725 [proc1] Released lock
obj:  0.228401 [proc2] Got lock
obj:  0.430501 [proc2] Released lock
obj:  0.431082 [proc0] Got lock
obj:  0.633048 [proc0] Released lock
obj:  0.633723 [proc4] Got lock
obj:  0.835692 [proc4] Released lock
obj:  0.836262 [proc3] Got lock
obj:  1.038197 [proc3] Released lock
obj:  1.038753 [proc1] Got lock
obj:  1.239288 [proc1] Released lock
obj:  1.240079 [proc2] Got lock
obj:  1.440773 [proc2] Released lock
obj:  1.441577 [proc0] Got lock
obj:  1.642142 [proc0] Released lock
obj:  1.642959 [proc4] Got lock
obj:  1.843331 [proc4] Released lock
obj:  1.844178 [proc3] Got lock
obj:  2.044549 [proc3] Released lock

Also attaching the process-based script

Added file: http://bugs.python.org/file12836/nick.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Fri Jan 23 03:00:47 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 23 Jan 2009 02:00:47 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1232664839.66.0.586713352276.issue4111@psf.upfronthosting.co.za>
Message-ID: <18809.9414.256714.237712@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

me> I get an error later running dtrace which I have yet to investigate.

Apple's dtrace program doesn't support the -G flag.  When I remove it from
Makefile.pre.in and rebuild I get an error about privileges:

    dtrace -o Python/dtrace.o  -C -s ./Python/python.d Python/ceval.o
    dtrace: failed to initialize dtrace: DTrace requires additional privileges

I tried adding "sudo" to the dtrace command.  Then it prompts for my
password and emits this error:

    sudo dtrace -o Python/dtrace.o  -C -s ./Python/python.d Python/ceval.o
    Password:
    dtrace: failed to compile script ./Python/python.d: line 11: extraneous argument 'Python/ceval.o' ($1 is not referenced)

I'm not sure what to do at this point.  I'm not really a dtrace person.
Perhaps the Apple and Sun dtrace experts can offer a way out of this little
corner.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Jan 23 03:48:02 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 02:48:02 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232678882.62.0.0245597998703.issue4999@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

On a put to the queue, the object is appended onto a deque (self._buffer) 
- this buffer is managed by a thread (_start_thread) which is handed the 
_feed method as the target. I suspect the bug is actually in the _feed 
method.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Fri Jan 23 04:35:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Jan 2009 03:35:26 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1232681726.0.0.861969642648.issue3677@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This fix needs to be ported to the py3k branch. Can somebody please do it?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Fri Jan 23 04:52:22 2009
From: report at bugs.python.org (Takeshi Matsuyama)
Date: Fri, 23 Jan 2009 03:52:22 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>


New submission from Takeshi Matsuyama <tksmashiw at gmail.com>:

When I make a dictionary by parsing "legacy-icon-mapping.xml"(which is a
part of
icon-naming-utils[http://tango.freedesktop.org/Tango_Icon_Library]) with
the following script, the three keys of the dictionary are collapsed if
the "buffer_text" attribute is False.

=====================
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from __future__ import with_statement
import sys
from xml.parsers.expat import ParserCreate
import codecs

class Database:
  """Make a dictionary which is accessible by Databese.dict"""
  def __init__(self, buffer_text):
    self.cnt = None
    self.name = None
    self.data = None
    self.dict = {}
    p = ParserCreate()
    p.buffer_text = buffer_text

    p.StartElementHandler = self.start_element
    p.EndElementHandler = self.end_element
    p.CharacterDataHandler = self.char_data

    with open("/usr/share/icon-naming-utils/legacy-icon-mapping.xml",
'r') as f:
      p.ParseFile(f)

  def start_element(self, name, attrs):
    if name == 'context':
      self.cnt = attrs["dir"]
    if name == 'icon':
      self.name = attrs["name"]
  
  def end_element(self, name):
    if name == 'link':
      self.dict[self.data] = (self.cnt, self.name)

  def char_data(self, data):
    self.data = data.strip()

def print_set(aset):
  for e in aset:
    print '\t' + e

if __name__ == '__main__':
  sys.stdout = codecs.getwriter('utf_8')(sys.stdout)
  map_false_dict = Database(False).dict
  map_true_dict = Database(True).dict
  print "The keys which exist if buffer_text=False but don't exist if
buffer_text=True are"
  print_set(set(map_false_dict.keys()) - set(map_true_dict.keys()))
  print "The keys which exist if buffer_text=True but don't exist if
buffer_text=False are"
  print_set(set(map_true_dict.keys()) - set(map_false_dict.keys()))
=====================

The result of running this script is
======================
The keys which exist if buffer_text=False but don't exist if
buffer_text=True are
	rt-descending
	ock_text_right
	lc
The keys which exist if buffer_text=True but don't exist if
buffer_text=False are
	stock_text_right
	gnome-mime-application-vnd.stardivision.calc
	gtk-sort-descending
======================
I confirmed it in Python-2.5.2 on Fedora 10.

----------
components: XML
messages: 80398
nosy: tksmashiw
severity: normal
status: open
title: xml.parsers.expat make a dictionary which keys are broken if buffer_text is False.
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Fri Jan 23 05:36:58 2009
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 23 Jan 2009 04:36:58 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1232685418.91.0.847105184628.issue5032@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Fri Jan 23 08:24:02 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 23 Jan 2009 07:24:02 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1232695442.0.0.0269171278959.issue3677@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Merged in r68873(py3k).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Fri Jan 23 09:13:05 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 08:13:05 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232698385.73.0.608929276991.issue5035@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, here is a fix for my regression.

----------
keywords: +patch
Added file: http://bugs.python.org/file12837/object_dump_nothread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 09:14:51 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 08:14:51 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232698491.74.0.42701418033.issue5035@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Why is PyGILState_Ensure() defined in Include/pystate.h in there is not
thread? PyGILState_Ensure() implementation is conditional (in
Python/pystate.c). Here is a patch to make the definition optional.

Added file: http://bugs.python.org/file12838/gil_nothread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 09:16:12 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 08:16:12 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232698572.45.0.705066486091.issue5035@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another patch to fix _sqlite without thread support.

Added file: http://bugs.python.org/file12839/_sqlite_nothread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 09:19:45 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 08:19:45 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232698785.08.0.905353343032.issue5035@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_multiprocessing modules doesn't compile but I don't know how to fix it:
 - conn_poll() has a _save argument, but the argument is not used in
both conn_poll() implementations (pipe_connection.c and socket_connection.c)
 - Modules/_multiprocessing/semaphore.c contains a lot of functions and
macros for semaphore managment but it looks like thread support is
required. Eg. compilation fails on a missing symbol: sem_unlink(). The
function sem_unlink() is defined in system <semaphore.h> and requires
-lrt or -lpthread compiler flag.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 09:25:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 08:25:27 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232699127.42.0.0976672841273.issue5035@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch to remove the unused _save argument of conn_poll()
function from the _multiprocessing mode. It fixes one of the compilation
problem without thread support.

Added file: http://bugs.python.org/file12840/_multiprocessing_remove_save.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 11:28:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Jan 2009 10:28:27 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232706507.94.0.105416178158.issue5035@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There is already a separate issue for multiprocessing compilation: #3807

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 12:37:16 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 11:37:16 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232699127.42.0.0976672841273.issue5035@psf.upfronthosting.co.za>
Message-ID: <05A11A26-167A-4D28-9C49-4DB5A4BED6CA@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

Victor - there is already another bug and a pending patchbto fix  
multiprocessing when thread support is enabled. Please do not focus on  
that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 13:06:20 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 12:06:20 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232712380.96.0.943300537906.issue5035@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12840/_multiprocessing_remove_save.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 13:07:07 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 12:07:07 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232712427.82.0.497497734155.issue5035@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@pitou and @jnoller: Ok ok, fine, I will check #3807.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 13:07:51 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 23 Jan 2009 12:07:51 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1232712471.58.0.795059701676.issue3807@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This second patch is good and does fix the error.

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Fri Jan 23 13:10:11 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 12:10:11 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1232712611.45.0.4028092766.issue3807@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand the usage of _save argument of conn_poll() function
(of the _multiprocessing module). Here is a patch to remove it. I first
wrote this patch to try to compile _multiprocessing without thread
support (which is stupid because _multiprocessing requires semaphore).

Just ignore my patch if the _save is used somewhere.

----------
nosy: +haypo
Added file: http://bugs.python.org/file12841/_multiprocessing_remove_save.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Fri Jan 23 14:39:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 23 Jan 2009 13:39:12 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1232717952.3.0.0538447050872.issue3807@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

_save is used, by the Py_BLOCK_THREADS macros.
(when threads are enabled, of course).

I think that you should not try to compile _multiprocessing without
threads enabled. multiprocessing does need multiple threads to work.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Fri Jan 23 14:59:51 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 13:59:51 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1232719191.6.0.623195722651.issue3807@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Amaury is correct - without thread support, a lot of mp internals will 
yak, so we're just going to disable it

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Fri Jan 23 15:11:19 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 14:11:19 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1232719879.67.0.107645097339.issue3807@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

my patch is in py3k as 68875 and trunk as r68874

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Fri Jan 23 15:16:33 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 14:16:33 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232720193.42.0.471208310302.issue5035@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've committed the fix for issue 3807 to resolve the mp issues.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Fri Jan 23 15:17:29 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Jan 2009 14:17:29 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1232720249.49.0.707712993486.issue3807@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12841/_multiprocessing_remove_save.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Fri Jan 23 15:23:47 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 14:23:47 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232720627.71.0.421570229488.issue5031@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Attached is a patch to the docs which reflects the nature of the daemon 
property based on trunk

----------
keywords: +needs review, patch
nosy: +jnoller
Added file: http://bugs.python.org/file12842/issue5031.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Fri Jan 23 15:32:10 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 23 Jan 2009 14:32:10 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1232721130.47.0.702587392736.issue2527@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve at pearwood.info>:


----------
nosy: +stevenjd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2527>
_______________________________________

From report at bugs.python.org  Fri Jan 23 15:47:40 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 14:47:40 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1232722060.31.0.841190367761.issue4106@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Skip, using this:

 while ((x++ < 500)) ; do echo '!'$i ; ./python.exe test_proc.py; done | 
egrep '!'

I don't see the exception in python-trunk, freshly compiled. It could be 
an OS thing (I'm on OS/X) - I just want to confirm that you're still 
seeing this on trunk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Fri Jan 23 16:03:31 2009
From: report at bugs.python.org (Taldor)
Date: Fri, 23 Jan 2009 15:03:31 +0000
Subject: [issue5037] unexpected unicode behavior for proxy objects
In-Reply-To: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>
Message-ID: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>


New submission from Taldor <tinusvl at skynet.be>:

Calling the unicode function on a proxy object, doesn't use the proxi-ed
object's __unicode__ method, but its __str__ method.

>>> class A(object):
...   def __str__(self):
...     return "str"    
...   def __unicode__(self):
...     return "unicode"    
...                         
>>> a = A()
>>> unicode(a)
u'unicode'
>>> import weakref
>>> b = weakref.proxy(a)
>>> unicode(b)
u'str'

I expected the last result to be u'unicode'. I did get u'unicode' in
Python 2.5 (but not in 2.6).

----------
components: None
messages: 80416
nosy: Taldor
severity: normal
status: open
title: unexpected unicode behavior for proxy objects
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5037>
_______________________________________

From report at bugs.python.org  Fri Jan 23 16:18:30 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 15:18:30 +0000
Subject: [issue3551] multiprocessing.Pipe terminates with
	ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
In-Reply-To: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>
Message-ID: <1232723910.95.0.597255809699.issue3551@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
type: resource usage -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3551>
_______________________________________

From report at bugs.python.org  Fri Jan 23 16:27:17 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 23 Jan 2009 15:27:17 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1232724437.98.0.332195628965.issue4106@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Ah ha. I see it if I run it with the loop set to 3000 - it is pretty rare.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Fri Jan 23 16:34:21 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Fri, 23 Jan 2009 15:34:21 +0000
Subject: [issue5034] itertools.fixlen
In-Reply-To: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>
Message-ID: <1232724861.96.0.373421322876.issue5034@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

When I started writing this patch this was actually what I intended. But
having ``fixlen(range(3), 2)`` return 0 1 2 struck me as odd. Renaming
the function to `pad` would help there indeed.

It depends on which use case is more common: either fixing an iterator
to a certain length (slicing/padding applied as required) or obtaining
an iterator of *at least* some number of elements (padded as required)?

The thread on python-ideas suggests the latter while the example Python
code brought up there implements the former. OTOH the latter cannot be
composed *that easily* of other itertools but the former is more useful
for unpacking.

On a related note: what should happen if `length` is negative?
`itertools.repeat` just defaults to 0 in such cases but I am unsure how
applicable that is in this case.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5034>
_______________________________________

From report at bugs.python.org  Fri Jan 23 18:07:19 2009
From: report at bugs.python.org (jan matejek)
Date: Fri, 23 Jan 2009 17:07:19 +0000
Subject: [issue5038] urrlib2/httplib doesn't reset file position between
	requests
In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za>
Message-ID: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za>


New submission from jan matejek <jmatejek at suse.cz>:

since 2.6 httplib supports reading from file-like objects.

Now consider the following situation:
There are two handlers in urrlib2, first is plain http, second is basic
auth.
I want to POST a file to a service, and pass the open file object as
data parameter to urllib2.urlopen.
First handler is invoked, it sends the file data, but gets 401
Unauthorized return code and fails with that.
Second handler in chain is invoked (at least that's how i understand
urrlib2, please correct me if i'm talking rubbish). At that point the
open file is at EOF, so empty data is sent.

furthermore, the obvious solution "you can't do this through urllib so
go read the file yourself" doesn't apply that well - the file object in
question is actually a mmap.mmap instance.
This code is in production since python 2.4. Until file object support
in httplib was introduced, it worked fine, handling the mmap'ed file as
a string. Now it is picked up as read()-able and this problem occurs.
Only workaround to restore pre-2.6 behavior that comes to mind is
building a wrapper class for the mmap object that hides its read() method.

----------
components: Library (Lib)
messages: 80419
nosy: matejcik
severity: normal
status: open
title: urrlib2/httplib doesn't reset file position between requests
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5038>
_______________________________________

From report at bugs.python.org  Fri Jan 23 20:48:26 2009
From: report at bugs.python.org (Collin Winter)
Date: Fri, 23 Jan 2009 19:48:26 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1232740106.66.0.823517842219.issue1518@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter, jyasskin
type: feature request -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Fri Jan 23 22:32:16 2009
From: report at bugs.python.org (Zlm)
Date: Fri, 23 Jan 2009 21:32:16 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232746336.56.0.707465164469.issue3881@psf.upfronthosting.co.za>


Zlm <zemarialm at gmail.com> added the comment:

I got my problem fixed in 4 days!
Thank you for all your help, Martin!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Fri Jan 23 22:38:50 2009
From: report at bugs.python.org (Ray)
Date: Fri, 23 Jan 2009 21:38:50 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1232746730.91.0.0873832656734.issue4908@psf.upfronthosting.co.za>


Ray <rayjohnterrill at gmail.com> added the comment:

any chance of getting a patch that would work in 2.4?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Sat Jan 24 00:28:56 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 23 Jan 2009 23:28:56 +0000
Subject: [issue5038] urrlib2/httplib doesn't reset file position between
	requests
In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za>
Message-ID: <1232753336.27.0.194301596929.issue5038@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This happens in other implementations too, not just urllib2.

If the server supports it, the best way is to send an 'Expect: 100-
Continue' header field before attempting to send the actual file.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5038>
_______________________________________

From report at bugs.python.org  Sat Jan 24 01:06:07 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 24 Jan 2009 00:06:07 +0000
Subject: [issue5037] unicode(x) for weakref.proxy objects invokes __str__
	instead of __unicode__
In-Reply-To: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>
Message-ID: <1232755567.94.0.766998998103.issue5037@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Same results on trunk.

----------
components: +Interpreter Core -None
nosy: +gagenellina
title: unexpected unicode behavior for proxy objects -> unicode(x) for weakref.proxy objects invokes __str__ instead of __unicode__
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5037>
_______________________________________

From report at bugs.python.org  Sat Jan 24 01:11:59 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Jan 2009 00:11:59 +0000
Subject: [issue5039] Adjust reference-counting note
In-Reply-To: <1232755919.64.0.595244867135.issue5039@psf.upfronthosting.co.za>
Message-ID: <1232755919.64.0.595244867135.issue5039@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Language / Data model / Objects, values and types (2.6-3.1)
third paragraph, has the following note:

"(Implementation note: the current implementation uses a
reference-counting scheme with (optional) delayed detection of
cyclically linked garbage, which collects most objects as soon as they
become unreachable, but is not guaranteed to collect garbage containing
circular references. See the documentation of the gc module for
information on controlling the collection of cyclic garbage.)"

There are two issues here: there are now other implementations that act
differently; CPython may change (as GvR reiterated strongly today in the
PyDev thread "__del__ and tp_dealloc in the IO lib", in response to a
request that the current behavior be defined and documented as not
permanent).  So I suggest:
change 'the current implementation' to 'CPython currently'
add "Other implementations act differently and CPython may change." (at
the end)

----------
assignee: georg.brandl
components: Documentation
messages: 80424
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Adjust reference-counting note
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5039>
_______________________________________

From report at bugs.python.org  Sat Jan 24 01:29:03 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 24 Jan 2009 00:29:03 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232756943.27.0.858281119222.issue5031@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

"This is a boolean value, and is False by default."

Not true; the next sentence in the description explains where the 
default value comes from.

I'd join both paragraphs to make it more clear:

"""A boolean value indicating whether this thread is a daemon thread 
(True) or not (False). This must be set before start() is called, 
otherwise RuntimeError is raised. Its initial value is inherited from 
the creating thread; the main thread is not a daemon thread.

The entire Python program exits ..."""

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 01:54:06 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 24 Jan 2009 00:54:06 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232756943.27.0.858281119222.issue5031@psf.upfronthosting.co.za>
Message-ID: <4222a8490901231654k4c8d2816y75cb5deec8fe724a@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

> Not true; the next sentence in the description explains where the
> default value comes from.

Hmm, unless your threads are spawned by daemonized threads; the value
always defaults to false. That's why I said it defaults to False. Hows
this:

"""A boolean value indicating whether this thread is a daemon thread
(True) or not (False). This must be set before start() is called,
otherwise RuntimeError is raised. Its initial value is inherited from
the creating thread; the main thread is not a daemon thread therefore
all threads created in the main thread default to daemon = False.

The entire Python program exits ..."""

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 01:59:11 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 24 Jan 2009 00:59:11 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232758751.58.0.809233592892.issue5031@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file12842/issue5031.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 01:59:35 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Jan 2009 00:59:35 +0000
Subject: [issue4992] yield's documentation not updated
In-Reply-To: <1232319312.46.0.667626052793.issue4992@psf.upfronthosting.co.za>
Message-ID: <1232758775.23.0.536842367064.issue4992@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would go with the first suggestion as that was the intent of adding
next() as a builtin function.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4992>
_______________________________________

From report at bugs.python.org  Sat Jan 24 01:59:44 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 24 Jan 2009 00:59:44 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232758784.49.0.447170985182.issue5031@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Hows this Gabriel?

Added file: http://bugs.python.org/file12843/issue5031.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 01:59:55 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 24 Jan 2009 00:59:55 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232758795.72.0.947788172328.issue5031@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 02:00:08 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 24 Jan 2009 01:00:08 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232758808.41.0.117294784772.issue5031@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Hows the new patch Gabriel?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 02:10:13 2009
From: report at bugs.python.org (William Fulton)
Date: Sat, 24 Jan 2009 01:10:13 +0000
Subject: [issue4672] Distutils SWIG support blocks use of SWIG -outdir option
In-Reply-To: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za>
Message-ID: <1232759413.02.0.932875609132.issue4672@psf.upfronthosting.co.za>


William Fulton <wsf at fultondesigns.co.uk> added the comment:

This error can be replicated on the command line with suitable quoting
of the -outdir option: 
swig -c++ "-outdir ." 

You need to pass the options correctly by separating them out, so use:

swig_opts=['-c++', '-I at HEPMCINCPATH@', '-outdir', '.']

I suggest distutils is fixed to show the quotes it is effectively adding
when displaying the command, so for the example Andy gave it should display:

swigging ./hepmc.i to ./hepmc_wrap.cpp
swig -python -c++ -I/home/andy/heplocal/include "-outdir ." -o
./hepmc_wrap.cpp ./hepmc.i

The quotes would need adding for display when a user has a space in any
of the options passed to SWIG (including the include_dirs etc).

----------
nosy: +postofficered

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4672>
_______________________________________

From report at bugs.python.org  Sat Jan 24 02:20:15 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 24 Jan 2009 01:20:15 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232760015.95.0.914677720191.issue5031@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Looks fine to me. Bah, perhaps purists would write `daemon` = 
``False`` , but I think the meaning is perfectly clear now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 02:31:03 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 24 Jan 2009 01:31:03 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232760663.99.0.438063470106.issue5036@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

If the xml file is small enough, could you attach it to the issue? Or 
provide a download location? I could not find it myself (without 
downloading the whole package)

(Note that Python 2.5 only gets security fixes now, so unless this 
still fails with 2.6 or later, this issue is likely to be closed)

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 24 03:05:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Jan 2009 02:05:59 +0000
Subject: [issue5037] unicode(x) for weakref.proxy objects invokes __str__
	instead of __unicode__
In-Reply-To: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>
Message-ID: <1232762759.47.0.794638939102.issue5037@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This was broken by r64791. The problem is that PyObject_Unicode now uses
_PyType_Lookup instead of PyObject_GetItem, so that the proxy's custom
__getattr__ implementation is bypassed.

----------
nosy: +benjamin.peterson, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5037>
_______________________________________

From report at bugs.python.org  Sat Jan 24 03:09:35 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 24 Jan 2009 02:09:35 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1232762975.49.0.286144040813.issue3677@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

The path variable should be PyMem_Free'd (in both trunk and py3k)
(also, I don't see any specific test - is there any?)

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Sat Jan 24 03:10:50 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 24 Jan 2009 02:10:50 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232763050.43.0.0818754065908.issue4999@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Sat Jan 24 05:10:28 2009
From: report at bugs.python.org (Takeshi Matsuyama)
Date: Sat, 24 Jan 2009 04:10:28 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232770228.0.0.825540906862.issue5036@psf.upfronthosting.co.za>


Takeshi Matsuyama <tksmashiw at gmail.com> added the comment:

Thanks for reply!

>If the xml file is small enough, could you attach it to the issue? Or 
>provide a download location?
Sorry, I found here.
http://webcvs.freedesktop.org/icon-theme/icon-naming-utils/legacy-icon-mapping.xml?revision=1.75&content-type=text%2Fplain&pathrev=1.75

>(Note that Python 2.5 only gets security fixes now, so unless this 
>still fails with 2.6 or later, this issue is likely to be closed)
I roughly confirmed the same problem on python-3.0 on MS Windows 2 weeks
ago, but need to verify more strictly...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 24 06:18:00 2009
From: report at bugs.python.org (Laszlo (Laca) Peter)
Date: Sat, 24 Jan 2009 05:18:00 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1232774280.8.0.170652587402.issue4111@psf.upfronthosting.co.za>


Laszlo (Laca) Peter <laca at sun.com> added the comment:

Please see here for discussion about the -G flag on OS X:
http://markmail.org/message/4nheqnexjr2o6mcx

If I read it correctly, on OS X, you will need to use -h
instead of -G and it won't emit an object file (dtrace.o)
so you will not need to link it.

Unfortunately, this means that the makefile will have to
be different on Solaris and OS X :(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Sat Jan 24 07:56:05 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 24 Jan 2009 06:56:05 +0000
Subject: [issue4965] Can doc index of html version be separately scrollable?
In-Reply-To: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za>
Message-ID: <20090124065551.GB7737@goofy>


Senthil <orsenthil at gmail.com> added the comment:

Terry, I think you mean the Sidebar content, right? 
Yes, I agree with you. It would be desirable to have the Sidebar
Fixed, while we scroll the document (Like this:
http://www.w3.org/Style/CSS/) 

This has to be worked out in the Sphnix CSS.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4965>
_______________________________________

From report at bugs.python.org  Sat Jan 24 09:48:19 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Sat, 24 Jan 2009 08:48:19 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232786899.55.0.558774543905.issue5036@psf.upfronthosting.co.za>


HiroakiKawai <kawai at apache.org> added the comment:

The sample code has bug. expat is OK.

Method char_data must append the incoming characters because the 
character sequence is an buffered input.
  def char_data(self, data):
    self.data += data

You should reset it by self.data = '' at end_element().

----------
nosy: +kawai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 24 10:20:10 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 24 Jan 2009 09:20:10 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1232788810.78.0.681212260312.issue4908@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Well since Python 2.4 doesn't have the egg-info feature, that is another
story.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Sat Jan 24 11:19:54 2009
From: report at bugs.python.org (Wayne Huang)
Date: Sat, 24 Jan 2009 10:19:54 +0000
Subject: [issue5040] Bug of CGIXMLRPCRequestHandler
In-Reply-To: <1232792394.35.0.81811153867.issue5040@psf.upfronthosting.co.za>
Message-ID: <1232792394.35.0.81811153867.issue5040@psf.upfronthosting.co.za>


New submission from Wayne Huang <WayneHuang.public at gmail.com>:

I met a bug of CGIXMLRPCRequestHandler in Python3.0. Because of the bug,
I couldn't use RPC in Apache CGI.

The version of my Python 3.0 is "Python 3.0 (r30:67507, Dec  3 2008,
20:14:27) [MSC v.1500 32 bit (Intel)] win32".

The code of my client is follow.

s = xmlrpc.client.ServerProxy('http://localhost/cgi-bin/rpc.py')
print(s.system.listMethods())

The code of my server in Apache's cgi-bin is follow

#!C:/Python30/python.exe

from xmlrpc.server import *

handler=CGIXMLRPCRequestHandler()
handler.register_introspection_functions()
handler.handle_request()

When I run the client code,some error of parser raise.

I found it is the matter of 'Content-Length' in the HTTP Response of
CGIXMLRPCRequestHandler,it is a wrong number.

----------
components: Library (Lib)
messages: 80440
nosy: WayneHuang
severity: normal
status: open
title: Bug of CGIXMLRPCRequestHandler
type: performance
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5040>
_______________________________________

From report at bugs.python.org  Sat Jan 24 11:29:16 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 24 Jan 2009 10:29:16 +0000
Subject: [issue4672] Distutils SWIG support blocks use of SWIG -outdir option
In-Reply-To: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za>
Message-ID: <1232792956.9.0.627291483784.issue4672@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Good suggestion, I'll add the quotes in the spawn call

Which does a simple log.info(string.join(cmd, ' ')) at the moment

----------
assignee:  -> tarek
nosy: +tarek
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4672>
_______________________________________

From report at bugs.python.org  Sat Jan 24 11:33:49 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 24 Jan 2009 10:33:49 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1232793229.91.0.0930867299425.issue3677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

added the mem release in r68882.
I'll try to add test cases too.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Sat Jan 24 11:52:48 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 24 Jan 2009 10:52:48 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1232794368.32.0.52258922754.issue3677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Added tests for UNC path imports in r68883 and r68884

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Sat Jan 24 12:07:42 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 24 Jan 2009 11:07:42 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1232795262.6.0.782112139757.issue3677@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>The path variable should be PyMem_Free'd

Sorry if I'm missing something, but is this really needed?
Other PyArg_ParseTuple(args, "s... doesn't seem to have
corresponding PyMem_Free.

static PyObject *
imp_new_module(PyObject *self, PyObject *args)
{
	char *name;
	if (!PyArg_ParseTuple(args, "s:new_module", &name))
		return NULL;
	return PyModule_New(name);
}

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Sat Jan 24 13:31:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 12:31:35 +0000
Subject: [issue5025] test_kqueue failure on OS X
In-Reply-To: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>
Message-ID: <1232800295.54.0.93373606649.issue5025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I just saw this same test_kqueue failure pop up on the OS X 3.x buildbot,
so it's evidently not just a peculiarity of my machine.

Unless there are any objections, I'll go ahead and check this in:  I think 
it's a sufficiently trivial fix that it's not worth wasting Christian's 
time with. :)

----------
assignee: christian.heimes -> marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5025>
_______________________________________

From report at bugs.python.org  Sat Jan 24 13:33:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 12:33:12 +0000
Subject: [issue5025] test_kqueue failure on OS X
In-Reply-To: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>
Message-ID: <1232800392.38.0.134455978451.issue5025@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5025>
_______________________________________

From report at bugs.python.org  Sat Jan 24 13:42:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 12:42:28 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1232795262.6.0.782112139757.issue3677@psf.upfronthosting.co.za>
Message-ID: <497B0CB1.3040403@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Sorry if I'm missing something, but is this really needed?

Yes, the "es" converter allocates memory.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Sat Jan 24 14:46:44 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 24 Jan 2009 13:46:44 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1232774280.8.0.170652587402.issue4111@psf.upfronthosting.co.za>
Message-ID: <18811.7100.983638.249613@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Laca> Please see here for discussion about the -G flag on OS X:
    Laca> http://markmail.org/message/4nheqnexjr2o6mcx

    Laca> If I read it correctly, on OS X, you will need to use -h instead
    Laca> of -G and it won't emit an object file (dtrace.o) so you will not
    Laca> need to link it.

    Laca> Unfortunately, this means that the makefile will have to be
    Laca> different on Solaris and OS X :(

We can worm around that using configure.  Thanks for the reference.  That
will go a long way toward getting the Sun dtrace probes working on Mac OSX.
For reference by others, here's Lee Packham's dtrace patch for PostgreSQL on
Mac OSX: http://blog.leenux.org.uk/wp-content/uploads/2008/10/postgresql-825-fixosxdtracediff.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Sat Jan 24 14:57:45 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 24 Jan 2009 13:57:45 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1232805465.51.0.16085682913.issue3677@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Ah, "es" is used in py3k, thanks. And sorry about my merge which had 
memory leak.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Sat Jan 24 15:10:17 2009
From: report at bugs.python.org (Takeshi Matsuyama)
Date: Sat, 24 Jan 2009 14:10:17 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232806217.49.0.460888835481.issue5036@psf.upfronthosting.co.za>


Takeshi Matsuyama <tksmashiw at gmail.com> added the comment:

Hi kawai.
I got correct output by modifying the code like you say, but I still
cannot understand why this happens.
Could you tell me more briefly, or point any documents about it?
I can't find any notes which say don't pass strings but append it for
CharacterDataHandler in official documents.
Does everyone know/understand it already? Only I am so stupid? (;;)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 24 15:18:42 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 14:18:42 +0000
Subject: [issue4710] [PATCH] zipfile.ZipFile does not extract directories
	properly
In-Reply-To: <1229865011.11.0.739181352345.issue4710@psf.upfronthosting.co.za>
Message-ID: <1232806722.67.0.161027949104.issue4710@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Committed as r68885, r68886, r68887, and r68888

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4710>
_______________________________________

From report at bugs.python.org  Sat Jan 24 15:25:27 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Sat, 24 Jan 2009 14:25:27 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232807127.37.0.74126899666.issue5036@psf.upfronthosting.co.za>


HiroakiKawai <kawai at apache.org> added the comment:

That's the spec of XML SAX interface.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 24 15:31:52 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 24 Jan 2009 14:31:52 +0000
Subject: [issue5041] Memory leak in imp.find_module
In-Reply-To: <1232807512.09.0.43179112168.issue5041@psf.upfronthosting.co.za>
Message-ID: <1232807512.09.0.43179112168.issue5041@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I found memory leak related to "es" on PyArg_ParseTuple.

----------
components: Extension Modules
files: py3k_memory_leak.patch
keywords: easy, needs review, patch
messages: 80452
nosy: ocean-city
severity: normal
status: open
title: Memory leak in imp.find_module
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file12844/py3k_memory_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5041>
_______________________________________

From report at bugs.python.org  Sat Jan 24 15:54:31 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Sat, 24 Jan 2009 14:54:31 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232808871.01.0.892034055559.issue5036@psf.upfronthosting.co.za>


HiroakiKawai <kawai at apache.org> added the comment:

Please read "The ContentHandler.characters() callback is missing data!" 
http://www.saxproject.org/faq.html

and close this issue :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 24 16:21:19 2009
From: report at bugs.python.org (Takeshi Matsuyama)
Date: Sat, 24 Jan 2009 15:21:19 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232810479.5.0.00642096488781.issue5036@psf.upfronthosting.co.za>


Takeshi Matsuyama <tksmashiw at gmail.com> added the comment:

a mistake of my former message, briefly -> in detail

>Please read "The ContentHandler.characters() callback is missing data!" 
>http://www.saxproject.org/faq.html
I was just reading above site. it is now very clear for me.
Thanks kawai and I'm sorry to take up your time, gagenellina.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 24 16:34:21 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Jan 2009 15:34:21 +0000
Subject: [issue5037] unicode(x) for weakref.proxy objects invokes __str__
	instead of __unicode__
In-Reply-To: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>
Message-ID: <1232811261.76.0.984356089848.issue5037@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

weakref.proxy needs to be fixed to delegate the unicode slot correctly.

>>> from weakref import proxy
>>> "__unicode__" in dir(type(proxy(Exception)))
False

That predicate must return true in order for the delegation to do the
right thing (this is actually the case for all of the slots and
pseudo-slots that can bypass __getattribute__ on the instance object -
it's just that most of them are already handled correctly).

This need to explicitly delegate all supported slots is the reason why
weakref proxy instances add so many magic method stubs when compared to
the actual interface of the underlying class:

>>> len(set(dir(type(proxy(Exception)))) - set(dir(Exception)))
53

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5037>
_______________________________________

From report at bugs.python.org  Sat Jan 24 17:01:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 16:01:57 +0000
Subject: [issue4393] Portability fixes in longobject.c
In-Reply-To: <1227443306.12.0.492255652415.issue4393@psf.upfronthosting.co.za>
Message-ID: <1232812917.83.0.540743426603.issue4393@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r68890, r68891, r68895 and r68896

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4393>
_______________________________________

From report at bugs.python.org  Sat Jan 24 17:04:19 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 24 Jan 2009 16:04:19 +0000
Subject: [issue5042] Structure sub-subclass does not initialize with base
	class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

When trying to create a sub-subclass of a ctypes.Structure, the behavior
is not as expected.

An executable example that describes the problem in detail and
demonstrates the issue is available at
http://paste.turbogears.org/paste/29555 and also attached.

The failing behavior is near the beginning, following the description.

Three unsuccessful workarounds follow.

The expected behavior is found at the end, where a final workaround has
been implemented.

Can this behavior be improved in subsequent releases of ctypes?  If not,
can ctypes at least support the workaround natively (perhaps by
providing a method in the Structure class that performs the workaround
and can be called by a sub-subclass during __init__)?

----------
assignee: theller
components: ctypes
files: ctypes subclassing issues.py
messages: 80457
nosy: jaraco, theller
severity: normal
status: open
title: Structure sub-subclass does not initialize with base class positional arguments
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file12845/ctypes subclassing issues.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5042>
_______________________________________

From report at bugs.python.org  Sat Jan 24 17:18:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 16:18:43 +0000
Subject: [issue5025] test_kqueue failure on OS X
In-Reply-To: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>
Message-ID: <1232813923.14.0.901751621308.issue5025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in the trunk in r68897.  Will merge to 2.6, 3.0 and 3.1.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5025>
_______________________________________

From report at bugs.python.org  Sat Jan 24 17:27:08 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 16:27:08 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1232814428.49.0.842371050771.issue3881@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Committed as r68893, r68894, r68898, r68901.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Sat Jan 24 17:35:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 16:35:26 +0000
Subject: [issue3105] Python 2.5.2 Windows Source Distribution missing Visual
	Studio 2005 ssl build files
In-Reply-To: <1213378847.48.0.141429051265.issue3105@psf.upfronthosting.co.za>
Message-ID: <1232814926.93.0.214391959146.issue3105@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This patch is out of date; VS 2005 is no longer of interest.

----------
nosy: +loewis
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3105>
_______________________________________

From report at bugs.python.org  Sat Jan 24 17:38:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 16:38:05 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1232815085.1.0.485307959102.issue2271@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Fixed in r66305.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Sat Jan 24 17:47:57 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 16:47:57 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1232815677.89.0.920927490352.issue4566@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Mark, the patch is fine, please apply. Great work!

----------
assignee:  -> mhammond
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Sat Jan 24 17:49:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 16:49:34 +0000
Subject: [issue4982] Running python 3 as Non-admin User requests the Runtime
	to terminate in an unusual way.
In-Reply-To: <1232242976.03.0.32299361581.issue4982@psf.upfronthosting.co.za>
Message-ID: <1232815774.0.0.237281221981.issue4982@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Do you have PYTHONPATH set, by any chance? Python 3.0 shouldn't pick up
c:\python25.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4982>
_______________________________________

From report at bugs.python.org  Sat Jan 24 18:00:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 17:00:27 +0000
Subject: [issue1672332] cPickle cannot unpickle subnormal floats on some
	machines
Message-ID: <1232816427.82.0.29132854811.issue1672332@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in the trunk in r68903.  If the buildbots are happy with the new 
tests, I'll port to 2.6, 3.0 and 3.1.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Sat Jan 24 18:05:47 2009
From: report at bugs.python.org (Ray)
Date: Sat, 24 Jan 2009 17:05:47 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1232788810.78.0.681212260312.issue4908@psf.upfronthosting.co.za>
Message-ID: <557a21f40901240905g5a321d81g59a624522cf232ff@mail.gmail.com>


Ray <rayjohnterrill at gmail.com> added the comment:

There wouldn't be an easy way to read the distutils setup.py info at
all in 2.4?  i suppose i could write something specific for our
environment.

On 1/24/09, Tarek Ziad? <report at bugs.python.org> wrote:
>
>  Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
>
>  Well since Python 2.4 doesn't have the egg-info feature, that is another
>  story.
>
>
>  _______________________________________
>  Python tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue4908>
>  _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Sat Jan 24 18:50:50 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 24 Jan 2009 17:50:50 +0000
Subject: [issue5043] get_msvcr() returns None rather than []
In-Reply-To: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>
Message-ID: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

def get_msvcr():
    """Include the appropriate MSVC runtime library if Python was built
    with MSVC 7.0 or later.
    """
    msc_pos = sys.version.find('MSC v.')
    if msc_pos != -1:
        msc_ver = sys.version[msc_pos+6:msc_pos+10]
        if msc_ver == '1300':
            # MSVC 7.0
            return ['msvcr70']
        elif msc_ver == '1310':
            # MSVC 7.1
            return ['msvcr71']
        elif msc_ver == '1400':
            # VS2005 / MSVC 8.0
            return ['msvcr80']
        elif msc_ver == '1500':
            # VS2008 / MSVC 9.0
            return ['msvcr90']
        else:
            raise ValueError("Unknown MS Compiler version %i " % msc_Ver)

    return [] <<<<<<<<-----

----------
components: Build
messages: 80466
nosy: lkcl
severity: normal
status: open
title: get_msvcr() returns None rather than []
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5043>
_______________________________________

From report at bugs.python.org  Sat Jan 24 19:41:10 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 24 Jan 2009 18:41:10 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232822470.88.0.610111472107.issue5031@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file12843/issue5031.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 19:41:23 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 24 Jan 2009 18:41:23 +0000
Subject: [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232822483.2.0.391756658983.issue5031@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Then the patch I wrote before "correcting it" was more purist ;) I 
preferred the `daemon` = ``False`` wording as well. Here's a corrected 
patch.

Added file: http://bugs.python.org/file12846/issue5031.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5031>
_______________________________________

From report at bugs.python.org  Sat Jan 24 19:43:11 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Jan 2009 18:43:11 +0000
Subject: [issue5037] unicode(x) for weakref.proxy objects invokes __str__
	instead of __unicode__
In-Reply-To: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>
Message-ID: <1232822591.64.0.652336707329.issue5037@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here's a patch.

----------
keywords: +needs review, patch
priority:  -> high
Added file: http://bugs.python.org/file12847/weakref_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5037>
_______________________________________

From report at bugs.python.org  Sat Jan 24 19:49:07 2009
From: report at bugs.python.org (Frank Henigman)
Date: Sat, 24 Jan 2009 18:49:07 +0000
Subject: [issue5044] name not found in generator in eval()
In-Reply-To: <1232822947.1.0.133791034087.issue5044@psf.upfronthosting.co.za>
Message-ID: <1232822947.1.0.133791034087.issue5044@psf.upfronthosting.co.za>


New submission from Frank Henigman <fjhenigman at cgl.uwaterloo.ca>:

# works
>>> eval( "sum( [ a[0]=='a' for j in 'a' ] )", {}, dict(a='a'))
# take out the square brackets
>>> eval( "sum(   a[0]=='a' for j in 'a'   )", {}, dict(a='a'))
NameError: global name 'a' is not defined

----------
components: Interpreter Core
messages: 80469
nosy: fjhpy
severity: normal
status: open
title: name not found in generator in eval()
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5044>
_______________________________________

From report at bugs.python.org  Sat Jan 24 20:04:41 2009
From: report at bugs.python.org (Weeble)
Date: Sat, 24 Jan 2009 19:04:41 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1232823881.71.0.494129385182.issue1529142@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

I installed Ubuntu on a laptop at the beginning of January and have
applied the patch I submitted above to IDLE. I've been using it
regularly for the last few weeks and have had no problems with it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_______________________________________

From report at bugs.python.org  Sat Jan 24 20:04:54 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 24 Jan 2009 19:04:54 +0000
Subject: [issue5043] get_msvcr() returns None rather than []
In-Reply-To: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>
Message-ID: <1232823894.04.0.229123315403.issue5043@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

My comment on this part of code is( from issue3871): 
+    # FIXME: next code is from issue870382
+    # MS C-runtime libraries never support backward compatibility.
+    # Linking to a different library without to specify correct runtime
+    # version for the headers will link renamed functions to msvcrt.
+    # See issue3308: this piece of code is python problem even
+    # with correct w32api headers.
+    # Issue: for MSVC compiler we can get the version and from version
+    # to determine mcvcrt as code below. But what about if python is
+    # build with GCC compiler?
+    # Output of sys.version is information for python build on first
+    # line, on the next line is information for the compiler and the
+    # output lack information for the C-runtime.

My vote is to remove function get_msvcr() from cygwinccompiler.py.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5043>
_______________________________________

From report at bugs.python.org  Sat Jan 24 20:07:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 19:07:02 +0000
Subject: [issue1672332] cPickle cannot unpickle subnormal floats on some
	machines
Message-ID: <1232824022.99.0.823898608415.issue1672332@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  After checking in this patch, the gentoo x86 trunk buildbot
has a new failure in test_pickletools, with the following output:

test_pickletools
**********************************************************************
File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/pickletools.py", line ?, in 
pickletools.__test__.disassembler_test
Failed example:
    dis(pickle.dumps(random.random, 0))
Expected:
        0: c    GLOBAL     'random random'
       15: p    PUT        0
       18: .    STOP
    highest protocol among opcodes = 0
Got:
        0: c    GLOBAL     'bsddb.test.test_thread random'
       31: p    PUT        0
       34: .    STOP
    highest protocol among opcodes = 0
**********************************************************************
1 items had failures:
   1 of  25 in pickletools.__test__.disassembler_test
***Test Failed*** 1 failures.
test test_pickletools failed -- 1 of 95 doctests failed

I'm having some difficulty figuring out how this could be
related to the checkin of this patch.

Anyone have any ideas where this might be coming from?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Sat Jan 24 20:17:11 2009
From: report at bugs.python.org (Weeble)
Date: Sat, 24 Jan 2009 19:17:11 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1232824631.07.0.389476612563.issue4676@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

I have experienced similar problems in Python 2.6.1 on Windows, and
found them to be due to Tk 8.5. I posted my findings here:

http://mail.python.org/pipermail/idle-dev/2009-January/002738.html

In summary, Tk 8.5 changed the name of the "anchor" mark to be unique to
each Text widget. The code to make the home key toggle between column 0
and the start of the text tries to make use of the "anchor" mark and
gets confused.

In the email I proposed a simple fix which I'm testing out right now.
Should I attach it as a patch?

----------
nosy: +weeble

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Sat Jan 24 20:36:09 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 24 Jan 2009 19:36:09 +0000
Subject: [issue5016] FileIO.seekable() can return False
In-Reply-To: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>
Message-ID: <1232825769.29.0.0822353605362.issue5016@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12821/fileio_append.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5016>
_______________________________________

From report at bugs.python.org  Sat Jan 24 20:37:37 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 24 Jan 2009 19:37:37 +0000
Subject: [issue5016] FileIO.seekable() can return False
In-Reply-To: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>
Message-ID: <1232825857.79.0.974098385675.issue5016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Woops, I attached the wrong patch!

Added file: http://bugs.python.org/file12848/fileio_seekable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5016>
_______________________________________

From report at bugs.python.org  Sat Jan 24 20:54:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Jan 2009 19:54:19 +0000
Subject: [issue1672332] cPickle cannot unpickle subnormal floats on some
	machines
Message-ID: <1232826859.77.0.0900534392966.issue1672332@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is not a new failure but an erratic one, and caused by a weakness
in pickle's handling of functions. See #3657.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Sat Jan 24 20:59:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 19:59:07 +0000
Subject: [issue1672332] cPickle cannot unpickle subnormal floats on some
	machines
Message-ID: <1232827147.69.0.912694921499.issue1672332@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Antoine!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Sat Jan 24 21:00:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 20:00:19 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1232827219.87.0.490827480108.issue3657@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Sat Jan 24 21:12:13 2009
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 24 Jan 2009 20:12:13 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1232827933.57.0.0105204285654.issue2527@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

This note is simply a reminder that Antoine's 'from __main__ import *' 
solution fails in python3.  Also, resolution of this issue probably 
could incorporate Issue1397474.


>>> import timeit
>>> timeit.timeit('None','from __main__ import *')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/timeit.py", line 227, in timeit
    return Timer(stmt, setup, timer).timeit(number)
  File "/usr/local/lib/python3.0/timeit.py", line 135, in __init__
    code = compile(src, dummy_src_name, "exec")
  File "<timeit-src>", line 2
SyntaxError: import * only allowed at module level

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2527>
_______________________________________

From report at bugs.python.org  Sat Jan 24 21:17:33 2009
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 24 Jan 2009 20:17:33 +0000
Subject: [issue5044] name not found in generator in eval()
In-Reply-To: <1232822947.1.0.133791034087.issue5044@psf.upfronthosting.co.za>
Message-ID: <1232828253.71.0.409302618993.issue5044@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5044>
_______________________________________

From report at bugs.python.org  Sat Jan 24 21:49:28 2009
From: report at bugs.python.org (Weeble)
Date: Sat, 24 Jan 2009 20:49:28 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1232830168.46.0.835920101162.issue4676@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

Another complication. On Windows, this line doesn't do what it claims:

if (event.state & 12) != 0 and event.keysym == "Home":
    # state&1==shift, state&4==control, state&8==alt
    return # <Modifier-Home>; fall back to class binding

The comment says state&8==alt, but this is wrong. state&8==mod1, and on
Windows Tk defines mod1 to be num-lock. So if you have num-lock on,
home_callback will always fall back to the standard binding.

See the Tk source:
xlib/X11/X.h   defines Mod1Mask
win/tkWinX.c   maps VK_NUMLOCK to Mod1Mask

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Sat Jan 24 22:13:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 21:13:23 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1232831603.26.0.385409680597.issue3657@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I just committed Tim's suggested change in r68906.  This seemed a no-
brainer, regardless of what should be done about pickle.whichmodule.  One 
fewer sporadic buildbot failure sounds like a good thing to me.

(I hadn't noticed the pickletools failures until just after I committed a 
pickle module change, so I was rather thrown until Antoine directed me 
here...)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Sat Jan 24 22:17:41 2009
From: report at bugs.python.org (Branden Moore)
Date: Sat, 24 Jan 2009 21:17:41 +0000
Subject: [issue5045] imaplib should remove length of literal strings
In-Reply-To: <1232831861.1.0.505003833235.issue5045@psf.upfronthosting.co.za>
Message-ID: <1232831861.1.0.505003833235.issue5045@psf.upfronthosting.co.za>


New submission from Branden Moore <bmoore-python at forkit.org>:

IMAP Literals are a tricky subject.  Currently, if IMAP returns:

* text text text {5}\r\n
12345more text

imaplib will return 2 data items:
[("text text text {5}", '12345'), "more text"]

This forces users of imaplib to then parse out and remove the '{5}' from
the first part of the tuple before appending the literal string.  It
would be nice to have imaplib strip the '{size}' portion of the string
in the first part of the tuple, so that the return value would be:
[("text text text ", '12345'), "more text"]

Though, because this entire response from the IMAP server should be
interpreted as a single line, it would be even better to return a
response such that 'data' is:
[(("text text text ", '12345'), "more text")]

a.k.a., a single 'data' item (only one IMAP response per data item) that
contains either a string or a tuple.  The tuple will contain either more
tuples and/or more strings.  Each sub-tuple here would contain two
strings, text, and the IMAP Literal String.

This would make parsing the responses from imaplib much more simple.  It
demarks obviously where IMAP Literal Strings are, and doesn't require
additional string parsing on the side of the imaplib user.

Thanks!

----------
components: Library (Lib)
messages: 80480
nosy: bmoore
severity: normal
status: open
title: imaplib should remove length of literal strings
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5045>
_______________________________________

From report at bugs.python.org  Sat Jan 24 22:37:51 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 24 Jan 2009 21:37:51 +0000
Subject: [issue5046] native win32 and wine mingw+msys build of python2.7
In-Reply-To: <1232833071.31.0.670571476989.issue5046@psf.upfronthosting.co.za>
Message-ID: <1232833071.31.0.670571476989.issue5046@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

this is an update of the mingw+msys port for native win32,
with the aim of being both compiled and used under both
wine-win32 and native-win32.

it is not a cross-compile patch.  it does not require -lwine.
it does not require a unix system.  it does not require cygwin.
(repeat the previous four sentences for both build _and_ use
of the resultant python.exe).  this information is specifically
given and stated [so blandly] because several people have been
extremely confused by what this patch achieves, due to the
tools being utilised to achieve it [wine].

the patch is against svn trunk r68884.

as of 2 hours ago, the following tests failed:
22 tests failed:
    test_cmath test_cmd_line_script test_compiler test_ctypes
    test_decimal test_distutils test_file test_logging test_mailbox
    test_math test_ntpath test_os test_parser test_posixpath test_pwd
    test_smtplib test_startfile test_tempfile test_transformer
    test_winsound test_zipfile test_zipimport_support

since then, several have been corrected.  test_pwd should not be
being tested.  several of the tests (test_tempfile) are fails due
to use of native wine msvcrt (it gets better when win32 msvcrt
is used).

this is work-in-progress for those people interested.

builds with --enable-msvcr9build are possible.

incorporation of roumen's cross-compile work is ongoing.

----------
components: Build
files: python-2.7a0-r68884-mingw-msys.patch
keywords: patch
messages: 80481
nosy: lkcl
severity: normal
status: open
title: native win32 and wine mingw+msys build of python2.7
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file12849/python-2.7a0-r68884-mingw-msys.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5046>
_______________________________________

From report at bugs.python.org  Sat Jan 24 22:40:47 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 24 Jan 2009 21:40:47 +0000
Subject: [issue5047] Remove Monterey support from configure.in
In-Reply-To: <20090124214044.37BA7D56A89@montanaro.dyndns.org>
Message-ID: <20090124214044.37BA7D56A89@montanaro.dyndns.org>


New submission from Skip Montanaro <skip at pobox.com>:

The attached patch removes vestiges of Monterey compiler support from
configure.in.  Apparently Monterey was some ill-conceived 64-bit SCO/IBM
operating system which died in 2000.  Can't see why we need to support it.

Skip

===File ~/src/python/trunk/configure.in.diff================
Index: configure.in
===================================================================
--- configure.in        (revision 68905)
+++ configure.in        (working copy)
@@ -216,7 +216,7 @@
 if test -z "$MACHDEP"
 then
        ac_sys_system=`uname -s`
-       if test "$ac_sys_system" = "AIX" -o "$ac_sys_system" = "Monterey64" \
+       if test "$ac_sys_system" = "AIX" \
        -o "$ac_sys_system" = "UnixWare" -o "$ac_sys_system" = "OpenUNIX"; then
                ac_sys_release=`uname -v`
        else
@@ -438,9 +438,6 @@
                AR="\$(srcdir)/Modules/ar_beos"
                RANLIB=:
                ;;
-    Monterey*)
-        RANLIB=:
-        without_gcc=;;
        *)      without_gcc=no;;
        esac])
 AC_MSG_RESULT($without_gcc)
@@ -562,10 +559,6 @@
     case $CC in
     cc|*/cc) CC="$CC -Ae";;
     esac;;
-Monterey*)
-    case $CC in
-    cc) CC="$CC -Wl,-Bexport";;
-    esac;;
 SunOS*)
     # Some functions have a prototype only with that define, e.g. confstr
     AC_DEFINE(__EXTENSIONS__, 1, [Defined on Solaris to see additional function prototypes.])
@@ -626,8 +619,6 @@
               exp_extra="."
           fi
           LINKCC="\$(srcdir)/Modules/makexp_aix Modules/python.exp $exp_extra \$(LIBRARY); $LINKCC";;
-       Monterey64*)
-          LINKCC="$LINKCC -L/usr/lib/ia64l64";;
        QNX*)
           # qcc must be used because the other compilers do not
           # support -N.
@@ -855,15 +846,6 @@
        OPT="-O"
        ;;
     esac
-
-    # The current (beta) Monterey compiler dies with optimizations
-    # XXX what is Monterey? Does it still die w/ -O? Can we get rid of this?
-    case $ac_sys_system in
-       Monterey*)
-           OPT=""
-           ;;
-    esac
-
 fi

 AC_SUBST(BASECFLAGS)
@@ -1709,7 +1691,6 @@
                else LDSHARED='$(CC) -G'
                fi;;
        SCO_SV*) LDSHARED='$(CC) -Wl,-G,-Bexport';;
-       Monterey*) LDSHARED="cc -G -dy -Bdynamic -Bexport -L/usr/lib/ia64l64";;
        CYGWIN*) LDSHARED="gcc -shared -Wl,--enable-auto-image-base";;
        atheos*) LDSHARED="gcc -shared";;
        *)      LDSHARED="ld";;
@@ -1746,7 +1727,6 @@
                then CCSHARED="-fPIC"
                else CCSHARED="-Kpic -belf"
                fi;;
-       Monterey*) CCSHARED="-G";;
        IRIX*/6*)  case $CC in
                   *gcc*) CCSHARED="-shared";;
                   *) CCSHARED="";;
============================================================

----------
messages: 80482
nosy: skip.montanaro
severity: normal
status: open
title: Remove Monterey support from configure.in

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5047>
_______________________________________

From report at bugs.python.org  Sat Jan 24 22:42:05 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 24 Jan 2009 21:42:05 +0000
Subject: [issue5034] itertools.fixlen
In-Reply-To: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>
Message-ID: <1232833325.91.0.931094332928.issue5034@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am still leaning towards rejecting this one based on:
* paucity of use cases
* non-atomicity (it can be built-out of existing tools)
* minimizing the number of tools in the toolkit
* not convinced that padded tuple unpacking is desirable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5034>
_______________________________________

From report at bugs.python.org  Sat Jan 24 22:49:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Jan 2009 21:49:48 +0000
Subject: [issue1672332] cPickle cannot unpickle subnormal floats on some
	machines
Message-ID: <1232833788.92.0.723824483543.issue1672332@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fix merged in r68907 (2.6), r68908 (3.1) and r68909 (3.0).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1672332>
_______________________________________

From report at bugs.python.org  Sat Jan 24 22:59:06 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 24 Jan 2009 21:59:06 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1232834346.63.0.588945637168.issue4111@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Sat Jan 24 23:26:05 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 24 Jan 2009 22:26:05 +0000
Subject: [issue5026] [reopening] native build of python win32 using msys under
	both wine and native win32
In-Reply-To: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>
Message-ID: <1232835965.4.0.570178700908.issue5026@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

#5046 supercedes this patch, for python2.7.  still relevant
for python2.5 though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5026>
_______________________________________

From report at bugs.python.org  Sun Jan 25 00:15:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 23:15:06 +0000
Subject: [issue5046] native win32 and wine mingw+msys build of python2.7
In-Reply-To: <1232833071.31.0.670571476989.issue5046@psf.upfronthosting.co.za>
Message-ID: <1232838906.05.0.743579005262.issue5046@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please don't post work in progress to this bugtracker.

----------
nosy: +loewis
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5046>
_______________________________________

From report at bugs.python.org  Sun Jan 25 00:38:25 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 24 Jan 2009 23:38:25 +0000
Subject: [issue5047] Remove Monterey support from configure.in
In-Reply-To: <20090124214044.37BA7D56A89@montanaro.dyndns.org>
Message-ID: <1232840305.28.0.0684422711504.issue5047@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You might want to take a look at r16962. It changed a few other things
as well.

Please do put patches into attachments, rather than including them in
the message.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5047>
_______________________________________

From report at bugs.python.org  Sun Jan 25 00:44:12 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 24 Jan 2009 23:44:12 +0000
Subject: [issue5047] Remove Monterey support from configure.in
In-Reply-To: <1232840305.28.0.0684422711504.issue5047@psf.upfronthosting.co.za>
Message-ID: <18811.42952.629394.736369@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Martin> You might want to take a look at r16962. It changed a few other
    Martin> things as well.

Will do.

    Martin> Please do put patches into attachments, rather than including
    Martin> them in the message.

Yeah, that's new mail program version suckage.  You would think an Emacs
command called "mail-attach-file" would actually attach the damn file
instead of simply embedding it into the mail message.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5047>
_______________________________________

From report at bugs.python.org  Sun Jan 25 01:15:11 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 25 Jan 2009 00:15:11 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1232842511.86.0.284448112424.issue4753@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

In the comment, you might mention both -fno-crossjumping and -fno-gcse.
-fno-crossjumping's description looks like it ought to prevent combining
computed gotos, but
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html says
-fno-gcse actually does it, and in my brief tests, the manual is
actually correct (compiling with just -fno-crossjumping combined gotos
anyway).

Otherwise, threadedceval6.patch looks good to submit to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan 25 01:32:27 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 25 Jan 2009 00:32:27 +0000
Subject: [issue5047] Remove Monterey support from configure.in
In-Reply-To: <20090124214044.37BA7D56A89@montanaro.dyndns.org>
Message-ID: <1232843547.93.0.648844746544.issue5047@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Here's the original patch as an attachment.

----------
keywords: +patch
Added file: http://bugs.python.org/file12850/configure.in.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5047>
_______________________________________

From report at bugs.python.org  Sun Jan 25 01:33:40 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 25 Jan 2009 00:33:40 +0000
Subject: [issue5047] Remove Monterey support from configure.in
In-Reply-To: <20090124214044.37BA7D56A89@montanaro.dyndns.org>
Message-ID: <1232843620.94.0.955326864348.issue5047@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

And a diff for README.  The other changes in r16962 seem to be bug fixes 
which, while exposed by the Monterey port, don't appear to be platform-
dependent.

Added file: http://bugs.python.org/file12851/README.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5047>
_______________________________________

From report at bugs.python.org  Sun Jan 25 03:05:04 2009
From: report at bugs.python.org (Konrad)
Date: Sun, 25 Jan 2009 02:05:04 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>


New submission from Konrad <konryd at gmail.com>:

The function itertools.combinations might benefit from making
the 'r' (length of the combinations) argument optionally a sequence.

With that change one could call combinations(sequence, [2, 3]) in
order to get all combinations of length 2 and 3.
In particular, one could call combinations(sequence,
range(len(sequence)) in order to get *all* combinations of given
sequence.

The change would be backwards compatible as it would check for
sequential arguments.

----------
components: Library (Lib)
messages: 80492
nosy: konryd, rhettinger
severity: normal
status: open
title: Extending itertools.combinations
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 03:52:28 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 25 Jan 2009 02:52:28 +0000
Subject: [issue5049] ctypes unwilling to allow pickling wide character array
In-Reply-To: <1232851948.05.0.0363189700044.issue5049@psf.upfronthosting.co.za>
Message-ID: <1232851948.05.0.0363189700044.issue5049@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Using Python 2.6.1, I'm unable to pickle a simple object with an array
of wide characters.

import ctypes, pickle

class MyStruct(ctypes.Structure):
  _fields_ = [('name', ctypes.c_wchar*2)]

s = MyStruct('DC')

pickle.dumps(s) # raises ValueError.

Replace ctypes.c_wchar with ctypes.c_char and the pickling works fine.

----------
assignee: theller
components: ctypes
messages: 80493
nosy: jaraco, theller
severity: normal
status: open
title: ctypes unwilling to allow pickling wide character array
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5049>
_______________________________________

From report at bugs.python.org  Sun Jan 25 03:56:06 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 25 Jan 2009 02:56:06 +0000
Subject: [issue5049] ctypes unwilling to allow pickling wide character
In-Reply-To: <1232851948.05.0.0363189700044.issue5049@psf.upfronthosting.co.za>
Message-ID: <1232852166.4.0.540428806768.issue5049@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I just discovered that trying to pickle a structure with even just a
c_wchar (not an array) also fails.

----------
title: ctypes unwilling to allow pickling wide character array -> ctypes unwilling to allow pickling wide character

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5049>
_______________________________________

From report at bugs.python.org  Sun Jan 25 04:21:50 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 25 Jan 2009 03:21:50 +0000
Subject: [issue5049] ctypes unwilling to allow pickling wide character
In-Reply-To: <1232851948.05.0.0363189700044.issue5049@psf.upfronthosting.co.za>
Message-ID: <1232853710.23.0.0697673736183.issue5049@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5049>
_______________________________________

From report at bugs.python.org  Sun Jan 25 04:23:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Jan 2009 03:23:00 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232853780.51.0.640723212423.issue5048@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Do you have compelling use cases?

Is it worth what it takes to preserve the relation with permuations()
and product() and the lexicographic orderings?

Do we care the length of the output is no longer predictable by a simple
n! / r! / (n-r)!  ?

Do we care that the variable length output prevents uses in for-loops
with tuple unpacking:

   for a, b, c in combinations('ABCDEF', [2,3]):
        . . .

----------
assignee:  -> rhettinger
components: +Extension Modules -Library (Lib)
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 06:40:41 2009
From: report at bugs.python.org (Yu-Jie Lin)
Date: Sun, 25 Jan 2009 05:40:41 +0000
Subject: [issue5050] unicode(C) invokes C.__unicode__ when __unicode__ is
	defined
In-Reply-To: <1232862040.08.0.372338675263.issue5050@psf.upfronthosting.co.za>
Message-ID: <1232862040.08.0.372338675263.issue5050@psf.upfronthosting.co.za>


New submission from Yu-Jie Lin <livibetter at gmail.com>:

Run the following code

class A:
  def __str__(self):
    return "__str__"
  def __unicode__(self):
    return "__unicode__"

a = A()

print str(a), unicode(a)
print str(A), unicode(A)

----

Results on Python 2.5.4 (r254:67916):
__str__ __unicode__
__main__.A
Traceback (most recent call last):
  File "/home/livibetter/tmp/unicode_classobj.py", line 14, in <module>
    print str(A), unicode(A)
TypeError: unbound method __unicode__() must be called with A instance
as first argument (got nothing instead)

Results on Python 2.6.1 (r261:67515):
__str__ __unicode__
__main__.A __main__.A

----

I was expecting the same result as on 2.6.1. By my observation,
unicode(C) tries to invoke C.__unicode__ if __unicode__ is defined in C,
where C is a class object.

I believe this behavior is incorrect.

----------
messages: 80496
nosy: livibetter
severity: normal
status: open
title: unicode(C) invokes C.__unicode__ when __unicode__ is defined
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5050>
_______________________________________

From report at bugs.python.org  Sun Jan 25 07:52:38 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 25 Jan 2009 06:52:38 +0000
Subject: [issue5050] unicode(C) invokes C.__unicode__ when __unicode__ is
	defined
In-Reply-To: <1232862040.08.0.372338675263.issue5050@psf.upfronthosting.co.za>
Message-ID: <1232866358.04.0.534870697714.issue5050@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No further bugs will be fixed in Python 2.5, unless they are security
bugs (which this is not). So closing it as "won't fix".

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5050>
_______________________________________

From report at bugs.python.org  Sun Jan 25 08:10:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Jan 2009 07:10:21 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232867421.3.0.38091989471.issue5048@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It would also be nice to have a __len__ method on both permutations and
combinations.

len(permutations(sequence)) could return the number of permutations
using the formulas (e.g. n! for permutations) without generating all the
possible permutations (as opposed to something like
len(list(permutations(sequence)))).

Also, is there a way to calculate combinations with repetitions[1]?
Maybe we could add an optional argument repetitions=True/False.

[1]:
http://en.wikipedia.org/wiki/Combinations#Number_of_combinations_with_repetition

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 08:30:57 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Jan 2009 07:30:57 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232868657.2.0.405510640551.issue5048@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido disallowed returning a len method on iterators.  He expected
bool(it) to be False.

The recipes section of the itertools docs has code for
combinations_with_replacement().  It was not included originally because
it was unclear whether there was actually a need to generate them. 
Possibly, people are mainly interested in knowing how many there are but
having no need to actually enumerate them.  That being said, if I get
more requests or if some real world use cases arise, I would be happy to
C the recipe and add it in Py2.7.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 10:43:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Jan 2009 09:43:12 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232876592.35.0.585397485617.issue5048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've seen requests for combinations with replacement come up on c.l.p. a 
few times in the past, though it's never been clear whether there was a 
real need or whether the interest was driven by homework or curiosity.

-1 for sequences in the second argument of combinations();  it doesn't 
feel like a useful enough generalization to be worth adding code for.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 11:57:40 2009
From: report at bugs.python.org (Konrad)
Date: Sun, 25 Jan 2009 10:57:40 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232881060.65.0.315176775336.issue5048@psf.upfronthosting.co.za>


Konrad <konryd at gmail.com> added the comment:

I'm afraid I don't have any real-world use cases. Originally, I assumed 
that dropping the length argument will make the function iterate over 
*all* combinations, which would enable me to write somehow twisted, one-
liner for _inefficiently_ solving knapsack problem.

max((comb for comb in all_combinations(zip(weights, values))
       if sum(map(itemgetter(0), comb)) < LIM), 
     key=lambda comb: sum(map(itemgetter(1), comb)))

But unfortunately, this is far from being 'compelling'.

Regarding other issues you raised: I think it would be pretty clear for 
the user, that the length of every combination might vary - that's what 
he asked for. And the length might be computed by summing the lengths 
counted using given formula, which is (for me at last) still explicit 
enough.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 12:39:18 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 25 Jan 2009 11:39:18 +0000
Subject: [issue5051] test_update2 in test_os.py invalid due to
	os.environ.clear() followed by reliance on environ COMSPEC
In-Reply-To: <1232883558.71.0.175097990327.issue5051@psf.upfronthosting.co.za>
Message-ID: <1232883558.71.0.175097990327.issue5051@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

class EnvironTests(mapping_tests.BasicTestMappingProtocol):
    """check that os.environ object conform to mapping protocol"""
    type2test = None
    def _reference(self):
        return {"KEY1":"VALUE1", "KEY2":"VALUE2", "KEY3":"VALUE3"}
    def _empty_mapping(self):
                   vvvvvv
        os.environ.clear() <<<<<---------- *******
                   ^^^^^^
        return os.environ
    def setUp(self):
        self.__save = dict(os.environ)
        os.environ.clear()
    def tearDown(self):
        os.environ.clear()
        os.environ.update(self.__save)

    # Bug 1110478
    def test_update2(self):
        if os.path.exists("/bin/sh"):
            os.environ.update(HELLO="World")
                       vvvvv
            value = os.popen("/bin/sh -c 'echo $HELLO'").read().strip()
                       ^^^^^ finds os.environ['COMSPEC'] to be empty! 
            self.assertEquals(value, "World")


this test will obviously fail, see _PyPopenCreateProcess in
posixmodule.c.

    if (i = GetEnvironmentVariable("COMSPEC",NULL,0)) {
        char *comshell;

    }
    /* Could be an else here to try cmd.exe / command.com in the path
       Now we'll just error out.. */
    else {
        PyErr_SetString(PyExc_RuntimeError,
            "Cannot locate a COMSPEC environment variable to "
            "use as the shell");
        return FALSE;
    }


the environment variables having been destroyed, there _is_ no
COMSPEC to obtain a working cmd.exe or command.com in order to
execute the /bin/sh (or /bin/sh.exe in the case of having installed
msys and created a symlink from c:/msys/bin to c:/bin).

----------
components: Tests
messages: 80502
nosy: lkcl
severity: normal
status: open
title: test_update2 in test_os.py invalid due to os.environ.clear() followed by reliance on environ COMSPEC
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5051>
_______________________________________

From report at bugs.python.org  Sun Jan 25 13:14:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Jan 2009 12:14:36 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1232885676.44.0.5709689016.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm wondering how to move forward with this issue.  Might it make sense to 
break the current monster patch into a series of more-easily reviewed 
patches?  I was thinking of something like:

 - patch 1 (Python code): remove all uses of cmp from std. lib. and tests
 - patch 2 (C code): remove all uses of tp_compare from Modules and 
Objects
 - patch 3 : rename tp_compare to tp_reserved in all Modules and Objects 
(should be a very simple patch, but touches a lot of files)
 - patch 4 : fix docs, and look for any other loose ends that need
   cleaning up.

Here's patch 1: remove uses of cmp from library and tests (and also from 
Tools/unicode/makeunicodedata.py).  It involves essentially no user-
visible changes.  (At least, assuming that users aren't trying to access 
e.g., UserString.__cmp__ directly.)

The patch is against py3k.  All tests pass on my machine with this patch 
applied.

Anyone interested in reviewing this?

Added file: http://bugs.python.org/file12852/1717_stage1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Sun Jan 25 13:38:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 12:38:04 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1232887084.06.0.897519243364.issue1717@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Quick comments on your patch:
- two files have unwanted modifications on non-ASCII characters
(Lib/heapq.py and Lib/sqlite3/test/hooks.py)
- you haven't renamed "__cmp__" to "_cmp" in Lib/xmlrpc/client.py:
deliberate?
- in Lib/heapq.py, there's a "_cmp__" which should be "_cmp"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Sun Jan 25 14:00:11 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Jan 2009 13:00:11 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1232888411.3.0.0591591526512.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Antoine.  Here's a new patch.

> - two files have unwanted modifications on non-ASCII characters
> (Lib/heapq.py and Lib/sqlite3/test/hooks.py)

Fixed, I think.  Could you double check?

> - you haven't renamed "__cmp__" to "_cmp" in Lib/xmlrpc/client.py:
> deliberate?

Not deliberate!  This __cmp__ should simply be removed, I think---the rich 
comparison methods are already present.

> - in Lib/heapq.py, there's a "_cmp__" which should be "_cmp"

Replaced "_cmp__" (which was in a comment) with "comparison".

Added file: http://bugs.python.org/file12853/1717_stage1_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Sun Jan 25 14:08:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Jan 2009 13:08:37 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232888917.62.0.521655481338.issue5048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> that dropping the length argument will make the function iterate over 
> *all* combinations,

Now *this* sounds more useful to me:  an itertool that generates *all* subsets of a list.  It's 
quite easy to do with existing itertools, though, either by looping over the second argument to 
combinations, or (for a different ordering) using product:

def subsets(iterable):
    l = list(iterable)
    for selector in itertools.product([False, True], repeat=len(l)):
        yield [element for indicator, element in zip(selector, l) if indicator]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 14:18:38 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 25 Jan 2009 13:18:38 +0000
Subject: [issue5052] "This module should be kept compatible with Python 2.1."
	in distutils code
In-Reply-To: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>
Message-ID: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

In distutils package, there are many files that saying
"This module should be kept compatible with Python 2.1."

According to Tarek Ziad?, this is not valid statement anymore.

----------
components: Distutils
messages: 80507
nosy: akitada
severity: normal
status: open
title: "This module should be kept compatible with Python 2.1." in distutils code
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5052>
_______________________________________

From report at bugs.python.org  Sun Jan 25 14:28:05 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 25 Jan 2009 13:28:05 +0000
Subject: [issue5052] "This module should be kept compatible with Python 2.1."
	in distutils code
In-Reply-To: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>
Message-ID: <1232890085.5.0.757054780726.issue5052@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

If PEP 291 is still valid, distutils needs "only remain compatible with
the version of Python it is distributed with."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5052>
_______________________________________

From report at bugs.python.org  Sun Jan 25 14:29:46 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 25 Jan 2009 13:29:46 +0000
Subject: [issue5052] "This module should be kept compatible with Python 2.1."
	in distutils code
In-Reply-To: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>
Message-ID: <1232890186.52.0.824772290697.issue5052@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek
nosy: +tarek
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5052>
_______________________________________

From report at bugs.python.org  Sun Jan 25 16:24:33 2009
From: report at bugs.python.org (Mike Watkins)
Date: Sun, 25 Jan 2009 15:24:33 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders()
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>


New submission from Mike Watkins <python at mikewatkins.ca>:

HTTPMessage.getallmatchingheaders() stopped working sometime after 
Python 3.0 release. In a recent (1 day ago) svn update the 
implementation says the method was copied from rfc822.message; the 
Python 3.x implementation is broken (iterates through self.keys instead 
of header values). I've not looked back to see where the change was 
introduced but I do know that it broke post 3.0 release.

But more importantly than the flaw in this method, the functionality is 
duplicated elsewhere in Python 3.x.

I propose either deprecating getallmatchingheaders() or if it is to be 
kept for compatibility, the fix can be simply replacing the method body 
with:

self.get_all(name)

The docstring for get_all (defined in email.message) affirms that its 
output is indeed compatible with that which was intended for 
getallmatchingheaders().

get_all(self, name, failobj=None) method of client.HTTPMessage instance
    Return a list of all the values for the named field.
    
    These will be sorted in the order they appeared in the original
    message, and may contain duplicates.  Any fields deleted and
    re-inserted are always appended to the header list.
    
    If no such fields exist, failobj is returned (defaults to None).

I've tested the use of get_all against one web server (QP) which runs on 
both Python 2.x and 3.x.

As a result of the broken getallmatchingheaders() the QP web server now 
uses for the same purpose as getallmatchingheaders() instead: 
get_all(name) (defined in email.message.Message in Py3k and 
getheaders(name) (defined in rfc822.Message).

See also issues on documentation and changed API in #4773, #3428

----------
components: Library (Lib)
messages: 80509
nosy: mwatkins
severity: normal
status: open
title: http.client.HTTPMessage.getallmatchingheaders()
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Sun Jan 25 16:30:03 2009
From: report at bugs.python.org (Mike Watkins)
Date: Sun, 25 Jan 2009 15:30:03 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
	parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>


New submission from Mike Watkins <python at mikewatkins.ca>:

There appears to have been a bug in how HTTP_ACCEPT is parsed living in 
run_cgi() for eons, perhaps from the time it was written. Perhaps not 
many are using this code (I'm not either) but recent (post 3.0 Release) 
Python 3.x appear to have broken something in getallmatchingheaders() 
(which originates in Message) and I happened to stumble upon this 
condition while searching through the stdlib code.

>From Line 980 of http.server

        accept = []
        for line in self.headers.getallmatchingheaders('accept'):
            if line[:1] in "\t\n\r ":
                accept.append(line.strip())
            else:
                accept = accept + line[7:].split(',')
        env['HTTP_ACCEPT'] = ','.join(accept)


line[:1] in '\t\n\r' clearly was meant to to be line[-1].

However that doesn't fix completely this chunk of code as it makes some 
assumptions about what getallmatchingheaders() delivers which aren't 
accurate. The following behaves as expected and feels safer:

        accept = []
        for line in self.headers.getallmatchingheaders('accept'):
            if line.lower().startswith("accept:"):
                line = line[7:]
            for part in line.split(','):
                part = part.strip()
                if part:
                    accept.append(part)
        env['HTTP_ACCEPT'] = ','.join(accept)


Note that post Python 3.0 release, 
http.client.HTTPMessage.getallmatchingheaders() was broken. I've 
reported this just now and proposed a fix in #5053.

----------
components: Library (Lib)
messages: 80510
nosy: mwatkins
severity: normal
status: open
title: CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5054>
_______________________________________

From report at bugs.python.org  Sun Jan 25 16:48:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 15:48:57 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1232888411.3.0.0591591526512.issue1717@psf.upfronthosting.co.za>
Message-ID: <1232898565.6616.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Fixed, I think.  Could you double check?

It's ok!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Sun Jan 25 16:51:33 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 25 Jan 2009 15:51:33 +0000
Subject: [issue5055] Distutils-SIG page needs to be updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Distutils-SIG page [1] and links there are considerably outdated.
They need to be updated to reflect current situation.

[1] http://www.python.org/community/sigs/current/distutils-sig/

----------
assignee: georg.brandl
components: Distutils, Documentation
messages: 80512
nosy: akitada, georg.brandl
severity: normal
status: open
title: Distutils-SIG page needs to be updated

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5055>
_______________________________________

From report at bugs.python.org  Sun Jan 25 16:52:14 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 25 Jan 2009 15:52:14 +0000
Subject: [issue5055] Distutils-SIG page needs to be updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232898734.76.0.946326935757.issue5055@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5055>
_______________________________________

From report at bugs.python.org  Sun Jan 25 17:08:14 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 25 Jan 2009 16:08:14 +0000
Subject: [issue5056] PyAPI assumes OS can access shared data in loadable
	modules (windows can't)
In-Reply-To: <1232899694.31.0.93225965153.issue5056@psf.upfronthosting.co.za>
Message-ID: <1232899694.31.0.93225965153.issue5056@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

an assumption has been made in the python core api that all operating
systems "dynamic module loading" can access data segments.  windows
_cannot_ do this.

the "workaround" has been to statically link absolutely _everything_
into a single whopping great dll.

the proper solution is to provide "accesser" functions:

PyAPI_FUNC(PyObject *)
PyErr_GetPyExc_OSError(void)
{
    return (PyObject*)PyExc_OSError;
}

PyAPI_FUNC(char*) _PyStructSequence_Get_UnnamedField(void)
{   
    return PyStructSequence_UnnamedField;
}

... actually the _best_ solution is to have everything that's needed in
a vector-table [discussed on python-dev mailing list]

----------
components: Build
messages: 80513
nosy: lkcl
severity: normal
status: open
title: PyAPI assumes OS can access shared data in loadable modules (windows can't)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5056>
_______________________________________

From report at bugs.python.org  Sun Jan 25 17:16:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 16:16:12 +0000
Subject: [issue5057] Unicode-width dependent optimization leads to
	non-portable pyc file
In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>
Message-ID: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The peephole optimizer can optimize indexed access to an unicode
constant which does not give the same result in UCS-2 and UCS-4 builds.
As a result, the pyc file is not portable across those builds.

This is something I witnessed when recompiling in UCS-2 rather than
UCS-4 mode, and having a strange failure in test_multibytecodec. Erasing
test_multibytecodec.pyc suppressed the failure.

Here is a small demonstration of the problem:

>>> def f():
...  return '\U00012345'[0]
... 
>>> import dis
>>> dis.dis(f)
  2           0 LOAD_CONST               3 ('\ud808') 
              3 RETURN_VALUE         


For reference, here is the error I had in test_multibytecodec:

======================================================================
FAIL: test_gb18030 (test.test_multibytecodec.Test_StreamWriter)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_multibytecodec.py",
line 185, in test_gb18030
    self.assertEqual(s.getvalue(), b'123\x907\x959')
AssertionError: b'123\x907\x959\x907\x959' != b'123\x907\x959'

----------------------------------------------------------------------

----------
components: Interpreter Core
messages: 80514
nosy: pitrou, rhettinger
severity: normal
status: open
title: Unicode-width dependent optimization leads to non-portable pyc file
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Sun Jan 25 17:21:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 16:21:33 +0000
Subject: [issue5057] Unicode-width dependent optimization leads to
	non-portable pyc file
In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>
Message-ID: <1232900493.29.0.322582099394.issue5057@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Sun Jan 25 17:42:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 16:42:17 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1232901737.19.0.191965288039.issue4753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in py3k in r68924.
I won't backport it to trunk myself but it should be easy enough,
provided people are interested.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending
versions:  -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sun Jan 25 18:04:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 25 Jan 2009 17:04:29 +0000
Subject: [issue5055] Distutils-SIG page needs to be updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232903069.36.0.266679870342.issue5055@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not my issue.

----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5055>
_______________________________________

From report at bugs.python.org  Sun Jan 25 19:15:01 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 25 Jan 2009 18:15:01 +0000
Subject: [issue5058] stop pgen.exe from generating CRLF-ended files and
	causing mayhem with win32-based patch submissions
In-Reply-To: <1232907301.06.0.0381974721982.issue5058@psf.upfronthosting.co.za>
Message-ID: <1232907301.06.0.0381974721982.issue5058@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

diff --git a/Parser/pgenmain.c b/Parser/pgenmain.c
index fc27a2c..a4d4911 100644
--- a/Parser/pgenmain.c
+++ b/Parser/pgenmain.c
@@ -49,7 +49,7 @@ main(int argc, char **argv)
        graminit_h = argv[2];
        graminit_c = argv[3];
        g = getgrammar(filename);
-       fp = fopen(graminit_c, "w");
+       fp = fopen(graminit_c, "wb");
        if (fp == NULL) {
                perror(graminit_c);
                Py_Exit(1);
@@ -58,7 +58,7 @@ main(int argc, char **argv)
                printf("Writing %s ...\n", graminit_c);
        printgrammar(g, fp);
        fclose(fp);
-       fp = fopen(graminit_h, "w");
+       fp = fopen(graminit_h, "wb");
        if (fp == NULL) {
                perror(graminit_h);
                Py_Exit(1);
@@ -79,7 +79,7 @@ getgrammar(char *filename)
        grammar *g0, *g;
        perrdetail err;
        
-       fp = fopen(filename, "r");
+       fp = fopen(filename, "rb");
        if (fp == NULL) {
                perror(filename);
                Py_Exit(1);

----------
components: Build
messages: 80517
nosy: lkcl
severity: normal
status: open
title: stop pgen.exe from generating CRLF-ended files and causing mayhem with win32-based patch submissions
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5058>
_______________________________________

From report at bugs.python.org  Sun Jan 25 19:16:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 25 Jan 2009 18:16:40 +0000
Subject: [issue5051] test_update2 in test_os.py invalid due to
	os.environ.clear() followed by reliance on environ COMSPEC
In-Reply-To: <1232883558.71.0.175097990327.issue5051@psf.upfronthosting.co.za>
Message-ID: <1232907400.58.0.959512238712.issue5051@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The test actually doesn't rely on COMSPEC. On systems that have /bin/sh,
COMSPEC should have no relevance.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5051>
_______________________________________

From report at bugs.python.org  Sun Jan 25 19:30:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 25 Jan 2009 18:30:58 +0000
Subject: =?utf-8?q?[issue4863]_deprecate/delete=09distutils.mwerkscompiler...?=
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <1232908258.11.0.640480087325.issue4863@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r68929 and r68931

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4863>
_______________________________________

From report at bugs.python.org  Sun Jan 25 19:34:50 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 25 Jan 2009 18:34:50 +0000
Subject: [issue3350] multiprocessing adds built-in types to the global
	copyreg.dispatch_table
In-Reply-To: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za>
Message-ID: <1232908490.31.0.393502518187.issue3350@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Alexandre, this behavior no longer occurs in trunk, and a custom 
ForkingPickler was added as part of issue 3125

I am going to close this as fixed, but please reopen if there is continued 
undesired behavior.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3350>
_______________________________________

From report at bugs.python.org  Sun Jan 25 19:37:15 2009
From: report at bugs.python.org (Ross Light)
Date: Sun, 25 Jan 2009 18:37:15 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1232908635.49.0.416293336728.issue4285@psf.upfronthosting.co.za>


Ross Light <rlight2 at gmail.com> added the comment:

Hello, my name is Ross Light.  I've written a patch for this, but this
is my first patch, so someone please review.

This does pass all regression tests, but I did have to modify the
test_sys case to not check for sys.version_info being a tuple.

----------
keywords: +patch
nosy: +ross.light
Added file: http://bugs.python.org/file12854/patch-4285a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Jan 25 19:45:18 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 25 Jan 2009 18:45:18 +0000
Subject: [issue5055] Distutils-SIG page needs to be updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232909118.64.0.513846163911.issue5055@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

I think this is a duplicate of issue4137.
Please close this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5055>
_______________________________________

From report at bugs.python.org  Sun Jan 25 19:45:50 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 25 Jan 2009 18:45:50 +0000
Subject: [issue4137] update SIG web pages
In-Reply-To: <1224230964.55.0.983457546691.issue4137@psf.upfronthosting.co.za>
Message-ID: <1232909150.35.0.0114385209643.issue4137@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +akitada, georg.brandl, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4137>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:03:07 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 25 Jan 2009 19:03:07 +0000
Subject: [issue5056] PyAPI assumes OS can access shared data in loadable
	modules (windows can't)
In-Reply-To: <1232899694.31.0.93225965153.issue5056@psf.upfronthosting.co.za>
Message-ID: <1232910187.46.0.123196953399.issue5056@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

apologies - case of mistaken identity!

patch attached - beginnings of moving data over to accessor-functions.
attached here because it is relevant for "vector-table" future work.

please close this bug.

----------
keywords: +patch
Added file: http://bugs.python.org/file12855/data_into_fns.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5056>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:08:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 25 Jan 2009 19:08:26 +0000
Subject: [issue5055] Distutils-SIG page needs to be updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232910506.43.0.546988257942.issue5055@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

akitada, can you propose wording (or, more specifically, a patch)?

Notice that this is really the Python bug tracker, so issues with
python.org are not normally tracked here.

In any case, if you want to work on this: the sources live in

https://svn.python.org/www/trunk/beta.python.org/build/data/community/sigs/current/distutils-sig/

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5055>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:09:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 25 Jan 2009 19:09:26 +0000
Subject: [issue5055] Distutils-SIG page needs to be updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232910566.99.0.92077936091.issue5055@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> update SIG web pages

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5055>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:13:09 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 25 Jan 2009 19:13:09 +0000
Subject: =?utf-8?q?[issue4863]_deprecate/delete=09distutils.mwerkscompiler...?=
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <1232910789.67.0.139975962604.issue4863@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Probably this patch is needed. :-)

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file12856/remaining.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4863>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:18:15 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 25 Jan 2009 19:18:15 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1232911095.28.0.792643669507.issue4285@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

You also need to add unit tests for the new behavior you've implemented.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:25:22 2009
From: report at bugs.python.org (Ross Light)
Date: Sun, 25 Jan 2009 19:25:22 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1232911522.02.0.127878980443.issue4285@psf.upfronthosting.co.za>


Ross Light <rlight2 at gmail.com> added the comment:

Oh yes, you're right.  Sorry!

Added file: http://bugs.python.org/file12857/patch-4285b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:25:46 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 25 Jan 2009 19:25:46 +0000
Subject: =?utf-8?q?[issue4863]_deprecate/delete=09distutils.mwerkscompiler...?=
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <1232911546.45.0.239967075195.issue4863@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

right, applying it now. sorry about that

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4863>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:29:22 2009
From: report at bugs.python.org (Mike Watkins)
Date: Sun, 25 Jan 2009 19:29:22 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders()
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1232911762.64.0.900080745187.issue5053@psf.upfronthosting.co.za>


Mike Watkins <python at mikewatkins.ca> added the comment:

Trivial patch for http.client attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file12858/http.client.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:29:44 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Jan 2009 19:29:44 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1232911784.85.0.302484689318.issue4285@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 on this idea

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:32:44 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 25 Jan 2009 19:32:44 +0000
Subject: =?utf-8?q?[issue4863]_deprecate/delete=09distutils.mwerkscompiler...?=
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <1232911964.91.0.348043963069.issue4863@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r68933 and r68935, thank you for noticing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4863>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:33:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 25 Jan 2009 19:33:34 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1232912014.63.0.764490659986.issue4285@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file12854/patch-4285a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:35:19 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Jan 2009 19:35:19 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232912119.16.0.620064379235.issue5048@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

There is already a powerset() recipe in the docs.  It was contributed by
Eric Raymond.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:40:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Jan 2009 19:40:05 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232912405.85.0.670606426402.issue5048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So there is.  Apologies---I'll try to read more carefully next time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:40:49 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 25 Jan 2009 19:40:49 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1232912449.27.0.388171558583.issue4285@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

A couple of further comments:
- please use tabs for indentation consistently.
- please change Doc/library/sys.rst, including adding a versionchanged
indication
- I find the naming of the macros *Flag confusing; to me, a "flag" says
"boolean" - but I'm not a native speaker (of English). Common names are
"item", "field", "element".

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:42:39 2009
From: report at bugs.python.org (Weeble)
Date: Sun, 25 Jan 2009 19:42:39 +0000
Subject: [issue3068] IDLE - Add an extension configuration dialog
In-Reply-To: <1213035033.21.0.781726477097.issue3068@psf.upfronthosting.co.za>
Message-ID: <1232912559.78.0.139348813084.issue3068@psf.upfronthosting.co.za>


Changes by Weeble <clockworksaint at gmail.com>:


----------
nosy: +weeble

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3068>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:45:56 2009
From: report at bugs.python.org (Attila Babo)
Date: Sun, 25 Jan 2009 19:45:56 +0000
Subject: [issue5059] Policy.DomainStrict in cookielib example code
In-Reply-To: <1232912756.19.0.0105064644084.issue5059@psf.upfronthosting.co.za>
Message-ID: <1232912756.19.0.0105064644084.issue5059@psf.upfronthosting.co.za>


New submission from Attila Babo <attila.babo at gmail.com>:

Example code at the bottom of cookielib documentation has an error:
policy = DefaultCookiePolicy(
    rfc2965=True, strict_ns_domain=Policy.DomainStrict,
    blocked_domains=["ads.net", ".ads.net"])

The corrected version is
policy = DefaultCookiePolicy(
    rfc2965=True, strict_ns_domain= DefaultCookiePolicy.DomainStrict,
    blocked_domains=["ads.net", ".ads.net"])

----------
assignee: georg.brandl
components: Documentation
messages: 80535
nosy: babo, georg.brandl
severity: normal
status: open
title: Policy.DomainStrict in cookielib example code
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5059>
_______________________________________

From report at bugs.python.org  Sun Jan 25 20:47:55 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Jan 2009 19:47:55 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232912875.37.0.833215840805.issue5048@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am rejecting the OP's request for the reasons cited.

Also rejecting the request for a __len__ method on permutations.

Ezio or Mark, please open another feature request for
combinations_with_replacement() and assign to me.  Will likely accept
this one and put it in when I get a chance.

Thank you to all the posters on this one.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Sun Jan 25 21:17:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 20:17:59 +0000
Subject: [issue5056] PyAPI assumes OS can access shared data in loadable
	modules (windows can't)
In-Reply-To: <1232899694.31.0.93225965153.issue5056@psf.upfronthosting.co.za>
Message-ID: <1232914679.98.0.129300477095.issue5056@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5056>
_______________________________________

From report at bugs.python.org  Sun Jan 25 21:18:38 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 25 Jan 2009 20:18:38 +0000
Subject: [issue5060] gcc profile guided optimization
In-Reply-To: <1232914718.3.0.0101941779254.issue5060@psf.upfronthosting.co.za>
Message-ID: <1232914718.3.0.0101941779254.issue5060@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

The make target "run_profile_task" fail as executable cannot load shared
library. Patch attached.

----------
files: py-issue-profile.patch
keywords: patch
messages: 80537
nosy: rpetrov
severity: normal
status: open
title: gcc profile guided optimization
Added file: http://bugs.python.org/file12859/py-issue-profile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5060>
_______________________________________

From report at bugs.python.org  Sun Jan 25 21:18:59 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 25 Jan 2009 20:18:59 +0000
Subject: [issue5060] gcc profile guided optimization
In-Reply-To: <1232914718.3.0.0101941779254.issue5060@psf.upfronthosting.co.za>
Message-ID: <1232914739.13.0.852927726556.issue5060@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5060>
_______________________________________

From report at bugs.python.org  Sun Jan 25 21:19:17 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 25 Jan 2009 20:19:17 +0000
Subject: [issue5060] gcc profile guided optimization
In-Reply-To: <1232914718.3.0.0101941779254.issue5060@psf.upfronthosting.co.za>
Message-ID: <1232914757.01.0.517295539125.issue5060@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
components: +Build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5060>
_______________________________________

From report at bugs.python.org  Sun Jan 25 21:19:34 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 25 Jan 2009 20:19:34 +0000
Subject: [issue5060] gcc profile guided optimization
In-Reply-To: <1232914718.3.0.0101941779254.issue5060@psf.upfronthosting.co.za>
Message-ID: <1232914774.38.0.476209773812.issue5060@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5060>
_______________________________________

From report at bugs.python.org  Sun Jan 25 21:22:49 2009
From: report at bugs.python.org (Ross Light)
Date: Sun, 25 Jan 2009 20:22:49 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1232914969.19.0.408175882958.issue4285@psf.upfronthosting.co.za>


Ross Light <rlight2 at gmail.com> added the comment:

Okay, here's a patch with the requested changes.  You're right in saying
that flag is usually boolean, I was just going along with several other
files where there's float and int flags (i.e. floatobject.c).

Added file: http://bugs.python.org/file12860/patch-4285c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Sun Jan 25 22:25:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Jan 2009 21:25:20 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232918720.11.0.510188828628.issue4705@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> since I don't see how the behaviour can differ for a read-only
> non-seekable stream.

Unless I'm misunderstanding you (quite likely), I think one *can* get 
different results with buffered and unbuffered stdin.
For example, on my machine, if I create the following script:

#!/usr/bin/python -u
import sys
print sys.stdin.readline()

and name it test.py, I get the following result in an OS X Terminal 
running bash:

dickinsm$ ls python_source/trunk/Objects/ | (./test.py; ./test.py)
abstract.c

boolobject.c

Whereas if I remove the '-u' from the shebang line I just get:

dickinsm$ ls python_source/trunk/Objects/ | (./test.py; ./test.py)
abstract.c


I'm not 100% sure that I understand exactly what's going on here, but it's 
something like the following:  in the first (unbuffered) case, the 
stdin.readline call of the first ./test.py only reads one line from stdin, 
leaving the rest intact;  so the second ./test.py also gets to output a 
line.  In the second case some larger amount of stdin (1024 bytes?) is 
immediately slurped into the stdin buffer for the first Python process, so 
the second ./test.py doesn't get anything.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Sun Jan 25 22:33:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 21:33:40 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1232918720.11.0.510188828628.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232919248.6616.15.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

[...]

I hadn't thought of such situations :-/

So the question is whether it is really useful to enforce unbuffered
stdin with the '-u' option (or your example is simply too borderline).
If so, the patch will have to be replaced with another one implementing
read1() in the FileIO class.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Sun Jan 25 22:36:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 21:36:57 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1232919248.6616.15.camel@localhost>
Message-ID: <1232919445.6616.18.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thinking about it, TextIOWrapper has its own input buffering (the
`decoded_chars` attribute), so your use case would probably not be
satisfied.

(and disabling TextIOWrapper's internal buffering would be a bad idea
since it would make it horribly slow)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Sun Jan 25 23:00:14 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 25 Jan 2009 22:00:14 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1232920814.99.0.846885162975.issue4111@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Here's a patch against the current trunk (2.7) which compiles on my Mac.  It
adds a --with-dtrace configure option.  The code checks to see if the -G
option is understood by the dtrace command.  If so, dtrace support is added
Sun-style.  If not we do things Apple's way.

The existing test cases pass on Apple except for one case in test_sys which
tries to confirm the size of a frame object.  I added an #ifdef WITH_DTRACE
around the extra slot but there is no way of telling from Python code that
this extra slot is there.  That would have to somehow be exposed to the
Python programmer so the test can be adjusted.  All tests pass when
--with-dtrace is omitted.  I have not yet tried this on Solaris.  I will try
to get to it this week if someone doesn't beat me to it.

There are as yet no new dtrace test cases so I can't confirm that the added
dtrace support actually works.  There are also no documentation updates.
Unlike most compile options this adds a significant new feature to the
runtime environment so some documentation changes are probably called for.

Added file: http://bugs.python.org/file12861/dtrace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Sun Jan 25 23:00:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Jan 2009 22:00:38 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232920838.76.0.6394216998.issue4705@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> So the question is whether it is really useful to enforce unbuffered
> stdin with the '-u' option (or your example is simply too borderline).

Hard to say.  It seems at least possible that there are Python users for 
whom stdin being unbuffered (with -u) matters, so if there's any 
reasonable way of avoiding changing this it should probably be considered.

Though I have to admit that I'm not one of those users (I don't think I've 
*ever* used the -u option outside of testing...).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Sun Jan 25 23:10:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 22:10:09 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1232920838.76.0.6394216998.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232921430.6616.27.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hard to say.  It seems at least possible that there are Python users for 
> whom stdin being unbuffered (with -u) matters, so if there's any 
> reasonable way of avoiding changing this it should probably be considered.

It's not about changing it, stdin has always been buffered in py3k. My
original commit actually attempted to change it, and it failed (I hadn't
noticed it at first due to mis-testing on my part). The new patch is
about putting it back in buffered mode even with '-u'.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Sun Jan 25 23:12:43 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 25 Jan 2009 22:12:43 +0000
Subject: [issue5052] "This module should be kept compatible with Python 2.1."
	in distutils code
In-Reply-To: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>
Message-ID: <1232921563.14.0.812609846538.issue5052@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r68943

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5052>
_______________________________________

From report at bugs.python.org  Sun Jan 25 23:23:48 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 25 Jan 2009 22:23:48 +0000
Subject: [issue5052] "This module should be kept compatible with Python 2.1."
	in distutils code
In-Reply-To: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>
Message-ID: <1232922228.38.0.384646042005.issue5052@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Note that distutils was removed from PEP 291 in r1982 "After some
discussion at the distutils sprint at PyCon 2005". 

This was not discussed on the distutils mailing list at the time which I
regard as not in line with the way Python or distutils is developed.

While we likely don't need Python 2.1 compatibility anymore, Python 2.3
is still in active use, so keeping distutils Python 2.3 compatible would
allow package authors to use a single distutils version (the Python 2.6
one) to cover the Python releases 2.3 - 2.6.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5052>
_______________________________________

From report at bugs.python.org  Sun Jan 25 23:34:18 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 25 Jan 2009 22:34:18 +0000
Subject: [issue5052] Mark distutils to stay compatible with 2.3
In-Reply-To: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>
Message-ID: <1232922858.37.0.413675429076.issue5052@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok, I will rewrite the top README file to explain this (and PEP 291 as
well) and keep the Python 2.3 compatibility in the whole package.

----------
status: closed -> open
title: "This module should be kept compatible with Python 2.1." in distutils code -> Mark distutils to stay compatible with 2.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5052>
_______________________________________

From report at bugs.python.org  Mon Jan 26 00:35:36 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 25 Jan 2009 23:35:36 +0000
Subject: [issue1885] [distutils] - error when processing the "--formats=tar"
	option
In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za>
Message-ID: <1232926536.16.0.0174000064518.issue1885@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

fixed in r68951 in trunk. 

I will propagate the change into 2.6/3.0/3.1 tomorrow.

----------
versions: +Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1885>
_______________________________________

From report at bugs.python.org  Mon Jan 26 00:41:43 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 25 Jan 2009 23:41:43 +0000
Subject: [issue5061] Inadequate documentation of the built-in function open
In-Reply-To: <1232926902.91.0.899964022103.issue5061@psf.upfronthosting.co.za>
Message-ID: <1232926902.91.0.899964022103.issue5061@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Documentation of the mode parameter of the built-in function open is 
insufficient with respect to what values are acceptable.

(1) Right after the mode table, it states "For binary random access, the 
mode 'w+b' opens and truncates the file to 0 bytes, while 'r+b' opens 
the file without truncation." This is true of text random access too -- 
w+ or r+. Furthermore, the possibility of a+, while meaningful, is not 
mentioned.

(2) The documentation does not, but should, say that while w/r/a with or 
without the plus can appear without a 'b' or 't', a plain 'b' as the 
mode valuable raises an error that r/w/a wasn't specified.

(3) The documentation does not, but should, say that + cannot stand on 
its own -- the mode must also include an r, w, or a. The table listing 
the meanings of each value just says + means "open a disk file for 
updating (reading and writing)". Suggested rewording is to put the 
phrase "in conjunction with 'r', 'w', or 'a', open a disk file...". 
Alternatively, add a note to that table entry and explain below that the 
plus must accompany a r/w/a.

----------
assignee: georg.brandl
components: Documentation
messages: 80549
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Inadequate documentation of the built-in function open
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5061>
_______________________________________

From report at bugs.python.org  Mon Jan 26 00:47:40 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 25 Jan 2009 23:47:40 +0000
Subject: [issue5061] Inadequate documentation of the built-in function open
In-Reply-To: <1232926902.91.0.899964022103.issue5061@psf.upfronthosting.co.za>
Message-ID: <1232927260.55.0.868134954483.issue5061@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

In point (2) I should have written "a plain 'b' or 't'" and "value" not 
"valuable". Neither 't' nor 'b' can appear without a r/w/a.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5061>
_______________________________________

From report at bugs.python.org  Mon Jan 26 01:28:46 2009
From: report at bugs.python.org (Akira Kitada)
Date: Mon, 26 Jan 2009 00:28:46 +0000
Subject: [issue5052] Mark distutils to stay compatible with 2.3
In-Reply-To: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>
Message-ID: <1232929726.0.0.641041992504.issue5052@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Is there any PEP describing we have to keep compatibility with 2.3 
release? I'm not against the idea but just curious.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5052>
_______________________________________

From report at bugs.python.org  Mon Jan 26 01:34:21 2009
From: report at bugs.python.org (Akira Kitada)
Date: Mon, 26 Jan 2009 00:34:21 +0000
Subject: [issue5055] Distutils-SIG page needs to be updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232930061.42.0.0656553189805.issue5055@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Could you tell me where the right place to ask this kind of problems?
I could not find any other trackers...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5055>
_______________________________________

From report at bugs.python.org  Mon Jan 26 01:36:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 26 Jan 2009 00:36:11 +0000
Subject: [issue5055] Distutils-SIG page needs to be updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232930171.09.0.0767225445673.issue5055@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Unfortunately, there is no tracker for the web pages. Questions about
the SIG pages can also be asked on the SIG mailing lists. However, there
might be nobody responsible for editing the web pages (as is the case
with these pages).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5055>
_______________________________________

From report at bugs.python.org  Mon Jan 26 01:49:38 2009
From: report at bugs.python.org (Zach Hirsch)
Date: Mon, 26 Jan 2009 00:49:38 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1232930978.47.0.150875137359.issue2889@psf.upfronthosting.co.za>


Zach Hirsch <zhirsch at umich.edu> added the comment:

Here's a patch against the head of trunk that adds vcproj files for
_curses and _curses_panel, modifies (slightly) the test suite and
_cursesmodule.c (again, slightly) to get Python to work with pdcurses on
windows. I also added a blurb to PCbuild\readme.txt.

With this, test_curses.py passes and I'm able to run all the curses
demos that come with Python's source.

----------
keywords: +patch
nosy: +zhirsch
Added file: http://bugs.python.org/file12862/python-pdcurses.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Mon Jan 26 02:15:26 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 26 Jan 2009 01:15:26 +0000
Subject: [issue5061] Inadequate documentation of the built-in function open
In-Reply-To: <1232926902.91.0.899964022103.issue5061@psf.upfronthosting.co.za>
Message-ID: <1232932525.99.0.463969832549.issue5061@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

I disagree.  You propose to examine the trees but ignore the forest.  
The perspective programmer needs to understand what is a file.

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5061>
_______________________________________

From report at bugs.python.org  Mon Jan 26 02:28:58 2009
From: report at bugs.python.org (Carl Johnson)
Date: Mon, 26 Jan 2009 01:28:58 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>


New submission from Carl Johnson <carl at carlsensei.com>:

The documentation at http://docs.python.org/library/rlcompleter.html
claims that

Completer.complete(text, state)?

   Return the state*th completion for *text.

   If called for text that doesn?t include a period character ('.'), it
will complete from names currently defined in __main__, __builtin__ and
keywords (as defined by the keyword module).

   If called for a dotted name, it will try to evaluate anything without
obvious side-effects (functions will not be evaluated, but it can
generate calls to __getattr__()) up to the last part, and find matches
for the rest via the dir() function. Any exception raised during the
evaluation of the expression is caught, silenced and None is returned.

In other words, it claims to use dir(obj) as part of the tab completion
process. This is not true (using Python 2.6.1 on OS X):

>>> class B(object):
...  def __dir__(self): return dir(u"") #Makes B objects look like strings
...
>>> b = B()
>>> dir(b)
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__',
'__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__',
'__le__', '__len__', '__lt__', '__mod__', '__mul__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__',
'__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__',
'_formatter_field_name_split', '_formatter_parser', 'capitalize',
'center', 'count', 'decode', 'encode', 'endswith', 'expandtabs', 'find',
'format', 'index', 'isalnum', 'isalpha', 'isdecimal', 'isdigit',
'islower', 'isnumeric', 'isspace', 'istitle', 'isupper', 'join',
'ljust', 'lower', 'lstrip', 'partition', 'replace', 'rfind', 'rindex',
'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines',
'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']
>>> c = rlcompleter.Completer()
>>> c.complete("b.", 0) #Notice that it does NOT return __add__
u'b.__class__('
>>> c.matches #Notice that this list is completely different from the
list given by dir(b)
[u'b.__class__(', u'b.__delattr__(', u'b.__doc__', u'b.__format__(',
u'b.__getattribute__(', u'b.__hash__(', u'b.__init__(', u'b.__new__(',
u'b.__reduce__(', u'b.__reduce_ex__(', u'b.__repr__(',
u'b.__setattr__(', u'b.__sizeof__(', u'b.__str__(',
u'b.__subclasshook__(', u'b.__class__(', u'b.__class__(',
u'b.__delattr__(', u'b.__dict__', u'b.__dir__(', u'b.__doc__',
u'b.__format__(', u'b.__getattribute__(', u'b.__hash__(',
u'b.__init__(', u'b.__module__', u'b.__new__(', u'b.__reduce__(',
u'b.__reduce_ex__(', u'b.__repr__(', u'b.__setattr__(',
u'b.__sizeof__(', u'b.__str__(', u'b.__subclasshook__(',
u'b.__weakref__', u'b.__class__(', u'b.__delattr__(', u'b.__doc__',
u'b.__format__(', u'b.__getattribute__(', u'b.__hash__(',
u'b.__init__(', u'b.__new__(', u'b.__reduce__(', u'b.__reduce_ex__(',
u'b.__repr__(', u'b.__setattr__(', u'b.__sizeof__(', u'b.__str__(',
u'b.__subclasshook__(']

Suggested course of action: 

* Change the documentation for Python 2.6/3.0.
* Update Completer to use __dir__ in Pythons 2.7/3.1 and revert the
documentation.

See
http://mail.python.org/pipermail/python-dev/2009-January/thread.html#85471

----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 80556
nosy: carlj, georg.brandl
severity: normal
status: open
title: Rlcompleter.Completer does not use __dir__ magic method
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Mon Jan 26 02:42:27 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Jan 2009 01:42:27 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1232934147.44.0.908530354037.issue4285@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Rather than deleting the isinstance() check from the tests completely, I
suggest changing it to be:

self.assert_(isinstance(vi[:], tuple))

Also, comparing directly with a tuple is also a fairly common use of
version_info so it would be worth adding a test to explicitly guarantee
that comparison:

self.assert_(vi > (1,0,0))

Patch applied and built cleanly for me, but I haven't checked the doc
build yet.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Mon Jan 26 04:07:31 2009
From: report at bugs.python.org (Patrick Toal)
Date: Mon, 26 Jan 2009 03:07:31 +0000
Subject: [issue5063] python-2.6.spec doesn't build properly
In-Reply-To: <1232939250.95.0.104379121936.issue5063@psf.upfronthosting.co.za>
Message-ID: <1232939250.95.0.104379121936.issue5063@psf.upfronthosting.co.za>


New submission from Patrick Toal <ptoal at takeflight.ca>:

Attempting to build an RPM with the python-2.6.spec contained in the 
python-2.6.1 distribution tar fails.  The following diff's enabled me to 
cleanly build the rpm's on a standard CentOS 5.1 installation.

----------
components: Build
files: python-2.6.1.spec.diff
keywords: patch
messages: 80558
nosy: ptoal
severity: normal
status: open
title: python-2.6.spec doesn't build properly
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file12863/python-2.6.1.spec.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5063>
_______________________________________

From report at bugs.python.org  Mon Jan 26 04:25:44 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Jan 2009 03:25:44 +0000
Subject: [issue5064] compiler.parse raises SyntaxErrors without line number
	information
In-Reply-To: <1232940344.37.0.615917855536.issue5064@psf.upfronthosting.co.za>
Message-ID: <1232940344.37.0.615917855536.issue5064@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Sometimes a syntax error in source passed to `compiler.parse? causes a
`SyntaxError? with lots of nice information to be raised:

>>> from compiler import parse
>>> try:
...     parse("def f(")
... except SyntaxError, e:
...     pass
...
>>> e
SyntaxError('unexpected EOF while parsing', (None, 1, 6, 'def f('))

But for other syntax errors, only a string message is provided, no
location information:

>>> try:
...     parse("def f(x=10, y): pass")
... except SyntaxError, f:
...     pass
...
>>> f
SyntaxError('non-default argument follows default argument',)
>>> try:
...     parse("f(x=10, y)")
... except SyntaxError, g:
...     pass
...
>>> g
SyntaxError('non-keyword arg after keyword arg',)
>>> 

On the other hand, the built in compiler produces exceptions which do
have this information in these cases.

The absence of the information makes the job of tools trying to operate
on Python source code more difficult (naively written, they'll simply
fail when they encounter one of these less informative exceptions).

----------
components: Library (Lib)
messages: 80559
nosy: exarkun
severity: normal
status: open
title: compiler.parse raises SyntaxErrors without line number information
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5064>
_______________________________________

From report at bugs.python.org  Mon Jan 26 04:47:08 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Jan 2009 03:47:08 +0000
Subject: [issue5065] IDLE improve Subprocess Startup Error message
In-Reply-To: <1232941628.82.0.541445606335.issue5065@psf.upfronthosting.co.za>
Message-ID: <1232941628.82.0.541445606335.issue5065@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

When launching IDLE, it reports:

"IDLE's subprocess didn't make connection. Either IDLE can't start a 
subprocess or personal firewall software is blocking the connection."

This should report what needs to be opened on the firewall to allow 
the connection, e.g. "Allow UDP/TCP connections to 127.0.0.1 on ports 
FOO and BAR and try again".

----------
components: IDLE
messages: 80560
nosy: stevenjd
severity: normal
status: open
title: IDLE improve Subprocess Startup Error message
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5065>
_______________________________________

From report at bugs.python.org  Mon Jan 26 04:51:38 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 26 Jan 2009 03:51:38 +0000
Subject: [issue5064] compiler.parse raises SyntaxErrors without line number
	information
In-Reply-To: <1232940344.37.0.615917855536.issue5064@psf.upfronthosting.co.za>
Message-ID: <1232941898.16.0.777994742781.issue5064@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Patches are welcome! The compiler package is deprecated in favor of
builtin AST.

----------
nosy: +benjamin.peterson
priority:  -> low
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5064>
_______________________________________

From report at bugs.python.org  Mon Jan 26 04:56:58 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Jan 2009 03:56:58 +0000
Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

Documentation for IDLE states:

    Starting IDLE on UNIX 
    On Unix, just type "idle" at a command prompt. This should bring
    up a Window similar to the one above. (If it doesn't, look for
    the "idle" script in the Tools/idle directory in the Python source
    distribution.)

http://www.python.org/idle/doc/idlemain.html

I believe that is obsolete, I cannot see a Tools/idle directory in 
either 2.5 or 2.6. Perhaps better instructions might be:

    (If it doesn't, run "python LOC/idlelib/idle.py" where LOC 
    is the location of your Python source distribution, usually 
    /usr/lib/python*.)

or similar.

----------
assignee: georg.brandl
components: Documentation, IDLE
messages: 80562
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: IDLE documentation for Unix obsolete/incorrect

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5066>
_______________________________________

From report at bugs.python.org  Mon Jan 26 05:35:06 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 26 Jan 2009 04:35:06 +0000
Subject: [issue5061] Inadequate documentation of the built-in function open
In-Reply-To: <1232932525.99.0.463969832549.issue5061@psf.upfronthosting.co.za>
Message-ID: <p06240804c5a2eae07af0@[10.0.1.222]>


Mitchell Model <mlm at acm.org> added the comment:

>David W. Lambert <lambertdw at corning.com> added the comment:
>
>I disagree.  You propose to examine the trees but ignore the forest.
>The perspective programmer needs to understand what is a file.
>

Could you be more specific about what parts of my comments you 
disagree with? The current documentation leaves open the possibility 
of someone thinking that random access doesn't apply to text files, 
getting errors when entering the apparently legal, but in reality 
not, 'b', and that '+', 't+', and 'b+' are legal whereas they require 
a r, w, or a.

I know this bit of documentation has been stable for years, but in 
doing some writing I got tripped up by trying to write an example 
using just '+', despite being very knowledgeable about Python. At 
that pointI experimented with the various combinations and compared 
the reality against the documentation. What I ended up doing is 
splitting the table in two and listing the + combinations explicitly:
Text or Binary:
t	text
b	binary

Read, Write, or Append:
r	beginning, read
w	beginning, write
a	end, write
r+	beginning, read/write
w+	beginning, read/write
a+	end, read/write

-- 

         --- Mitchell

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5061>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090126/3e6a6441/attachment-0001.txt>

From report at bugs.python.org  Mon Jan 26 07:24:33 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Jan 2009 06:24:33 +0000
Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful
In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za>
Message-ID: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

Using the wrong sort of quotes in json gives unhelpful error messages:

>>> json.loads("{'test':'test'}")
Traceback (most recent call last):
  ...
ValueError: Expecting property name: line 1 column 1 (char 1)

Unless you know that strings in JSON must be delimited with 
double-quotes and not single (a very surprising fact to those used to 
Python) this error message is perplexing. I suggest something like:

Single-quoted strings are invalid property names: line 1 column 1 
(char 1)

or 

Parse error, invalid char: line 1, column 1 (char 1)

----------
messages: 80564
nosy: stevenjd
severity: normal
status: open
title: Error msg from using wrong quotes in JSON is unhelpful
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5067>
_______________________________________

From report at bugs.python.org  Mon Jan 26 11:25:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Jan 2009 10:25:06 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1232965506.59.0.592237677537.issue4707@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Clearer title.

----------
title: round() shows undocumented behaviour -> round(25, 1) should return an integer, not a float

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Mon Jan 26 12:08:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Jan 2009 11:08:22 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1232968102.19.0.0474385705269.issue4707@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some minor modifications to the last patch:

 - fix round docstring:  it now reads "round(number[, ndigits]) -> number"
   instead of "round(number[, ndigits]) -> floating-point number"
 - add Misc/NEWS entry
 - add extra tests for round(x, n) with n huge and positive

----------
stage:  -> commit review
versions: +Python 3.1
Added file: http://bugs.python.org/file12865/round_int_int5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Mon Jan 26 12:08:31 2009
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Mon, 26 Jan 2009 11:08:31 +0000
Subject: [issue5068] tarfile loops forever on broken input
In-Reply-To: <1232968111.2.0.128325452145.issue5068@psf.upfronthosting.co.za>
Message-ID: <1232968111.2.0.128325452145.issue5068@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

I have troubles actually finding such a file, but I encountered it at
least once (file is gone by now though). The lines in question are for
bz2 compression:

in _BZ2Proxy.read:

            try:
                raw = self.fileobj.read(self.blocksize)
                data = self.bz2obj.decompress(raw)
                b.append(data)
            except EOFError:
                break

if it ever goes here (after finishing reading header) and data is
truncated, fileobj.read() will return 0 and data will be '' and
so on forever.

----------
components: Library (Lib)
messages: 80567
nosy: fijal
severity: normal
status: open
title: tarfile loops forever on broken input
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5068>
_______________________________________

From report at bugs.python.org  Mon Jan 26 12:17:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Jan 2009 11:17:53 +0000
Subject: [issue5057] Unicode-width dependent optimization leads to
	non-portable pyc file
In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>
Message-ID: <1232968673.44.0.0362361099247.issue5057@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Mon Jan 26 12:29:31 2009
From: report at bugs.python.org (Weeble)
Date: Mon, 26 Jan 2009 11:29:31 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1232969371.85.0.0611589213215.issue4676@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

Just got a chance to test this on a Windows desktop with a proper 
keyboard. (My laptop does weird things with num-lock and scroll-lock.) I 
got it to crash once, but I have no idea what was special about that 
time. Otherwise I can reproduce the exception traceback printed to the 
console, with the following steps:

1) Start IDLE from the console, e.g.:
    python c:\python26\Lib\idlelib\idle.py
2) Make sure num-lock is turned OFF.
3) Enter a few characters, e.g:
    rhubarb
4) Press shift+left to create a selection of at least one character.
5) Press shift+home. The stack trace appears in the console:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
    return self.func(*args)
  File "C:\Python26\lib\idlelib\MultiCall.py", line 150, in handler
    r = l[i](event)
  File "C:\Python26\lib\idlelib\EditorWindow.py", line 333, in 
home_callback
    if self.text.compare(first,">",last):
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 2858, in compare
    self._w, 'compare', index1, op, index2))
TclError: expected boolean value but got ""

This is consistent with my understanding that Tk 8.5 does not use a mark 
named "anchor" to indicate the selection anchor. I have written a patch 
that directly calls "tk::TextKeySelect" instead of trying to duplicate 
its behaviour using the "anchor" mark. I'm not terribly confident with 
using diff and patch, so please let me know if I've done it wrong. I did 
use -u.

Added file: http://bugs.python.org/file12866/IDLE_fix_shift_home.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Mon Jan 26 12:51:27 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 26 Jan 2009 11:51:27 +0000
Subject: [issue5068] tarfile loops forever on broken input
In-Reply-To: <1232968111.2.0.128325452145.issue5068@psf.upfronthosting.co.za>
Message-ID: <1232970687.65.0.625221681077.issue5068@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5068>
_______________________________________

From report at bugs.python.org  Mon Jan 26 12:53:14 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Mon, 26 Jan 2009 11:53:14 +0000
Subject: [issue4941] Tell GCC Py_DECREF is unlikely to call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1232970794.47.0.309004539944.issue4941@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

>Probably #if the definitions of Py_LIKELY and Py_UNLIKELY instead of
__builtin_expect so new compilers can easily add their own definitions.

This was done in the first version, but with the currently supported
compilers it's simpler to do like that, because both GCC and ICC support
the same __builtin_expect syntax, so you get less code this way.

Anyway, the code was "inspired" from the Linux kernel which only
supports those two compilers, so anybody more knowledgeable is welcome
to suggest how to express this with other compilers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4941>
_______________________________________

From report at bugs.python.org  Mon Jan 26 13:45:00 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Jan 2009 12:45:00 +0000
Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful
In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za>
Message-ID: <1232973900.49.0.29879166866.issue5067@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve at pearwood.info>:


----------
components: +Library (Lib)
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5067>
_______________________________________

From report at bugs.python.org  Mon Jan 26 14:50:49 2009
From: report at bugs.python.org (Qiangning Hong)
Date: Mon, 26 Jan 2009 13:50:49 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1232977849.69.0.59749278899.issue1722344@psf.upfronthosting.co.za>


Changes by Qiangning Hong <hongqn at gmail.com>:


----------
nosy: +hongqn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Mon Jan 26 14:51:32 2009
From: report at bugs.python.org (Mike Watkins)
Date: Mon, 26 Jan 2009 13:51:32 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1232977892.45.0.781661312662.issue5053@psf.upfronthosting.co.za>


Changes by Mike Watkins <python at mikewatkins.ca>:


----------
title: http.client.HTTPMessage.getallmatchingheaders() -> http.client.HTTPMessage.getallmatchingheaders() always returns []

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Mon Jan 26 15:18:13 2009
From: report at bugs.python.org (=?utf-8?q?=CE=A7=CF=81=CE=AE=CF=83=CF=84=CE=BF=CF=82_=CE=93=CE=B5=CF=89=CF=81=CE=B3=CE=AF=CE=BF=CF=85_(Christos_Georgiou)?=)
Date: Mon, 26 Jan 2009 14:18:13 +0000
Subject: [issue5069] Use sets instead of list in posixpath._resolve_link
In-Reply-To: <1232979493.22.0.551586556821.issue5069@psf.upfronthosting.co.za>
Message-ID: <1232979493.22.0.551586556821.issue5069@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:

The paths_seen object is a list; a set is more appropriate, since its
main use is a lookup as in "path in paths_seen"

----------
components: Library (Lib)
files: posixpath.diff
keywords: patch
messages: 80570
nosy: tzot
severity: normal
status: open
title: Use sets instead of list in posixpath._resolve_link
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12867/posixpath.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5069>
_______________________________________

From report at bugs.python.org  Mon Jan 26 16:28:35 2009
From: report at bugs.python.org (Paolo 'Blaisorblade' Giarrusso)
Date: Mon, 26 Jan 2009 15:28:35 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1232983715.55.0.906589769122.issue4753@psf.upfronthosting.co.za>


Paolo 'Blaisorblade' Giarrusso <p.giarrusso at gmail.com> added the comment:

-fno-gcse is controversial.
Even if it might avoid jumps sharing, the impact of that option has to
be measured, since common subexpression elimination allows omitting some
recalculations, so disabling global CSE might have a negative impact on
other code.

It would be maybe better to disable GCSE only for the interpreter loop,
but that would make some intra-file inlining impossible.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Mon Jan 26 16:54:26 2009
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 26 Jan 2009 15:54:26 +0000
Subject: [issue4672] Distutils SWIG support blocks use of SWIG -outdir option
In-Reply-To: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za>
Message-ID: <1232985266.83.0.838185071277.issue4672@psf.upfronthosting.co.za>


Andy Buckley <andy at insectnation.org> added the comment:

Dumb question, but why is distutils wrapping the command args in quotes
anyway? I'm not even sure why lists are being used (rather than a
string) for the options, except that lists are a bit more "Pythony" and
can be used to semantically divide the options from each other. If you
end up having to use separate list elements for the option flag and the
value it takes, doesn't that indicate that the list isn't being used
properly?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4672>
_______________________________________

From report at bugs.python.org  Mon Jan 26 16:56:40 2009
From: report at bugs.python.org (Kevin Watters)
Date: Mon, 26 Jan 2009 15:56:40 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1232985400.32.0.860057404861.issue4753@psf.upfronthosting.co.za>


Changes by Kevin Watters <kevinwatters at gmail.com>:


----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Mon Jan 26 17:01:06 2009
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 26 Jan 2009 16:01:06 +0000
Subject: [issue5070] Distutils should create install dir if needed
In-Reply-To: <1232985666.7.0.224838813352.issue5070@psf.upfronthosting.co.za>
Message-ID: <1232985666.7.0.224838813352.issue5070@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

If you attempt to call "python setup.py install --prefix=/foo", and
/foo/lib/pythonX.Y/site-packages does not exist, the installation will
fail, requiring that the directory be made by hand.

Since there is no easy way to know in advance (other than by running
Python to build the version number string) exactly where the install
will go, this can be troublesome for automated build scripts. For this
reason, and also to be more consistent with existing build/install
systems like autotools, I suggest that distutils builds the necessary
portions of the lib directory tree (provided /foo exists). This should
certainly happen (IMHO) if the --force option is given.

----------
components: Distutils
messages: 80573
nosy: andybuckley
severity: normal
status: open
title: Distutils should create install dir if needed
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5070>
_______________________________________

From report at bugs.python.org  Mon Jan 26 17:03:37 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Jan 2009 16:03:37 +0000
Subject: [issue5070] Distutils should create install dir if needed
In-Reply-To: <1232985666.7.0.224838813352.issue5070@psf.upfronthosting.co.za>
Message-ID: <1232985817.8.0.299508026023.issue5070@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This isn't accurate.  distutils *will* create the directory if it does
not exist.  Perhaps you have setuptools installed?  setuptools disables
this behavior of distutils and forces you to create the directory manually.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5070>
_______________________________________

From report at bugs.python.org  Mon Jan 26 17:05:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Jan 2009 16:05:08 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1232985908.12.0.827908622665.issue4705@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It's not about changing it, stdin has always been buffered in py3k.

Sorry:  I should have been clearer.  It's the change from 2.x to 3.x that 
interests me.

So 'python3.0 -u' has buffered stdin, while 'python2.6 -u' does not;  I'm 
wondering: was this an intentional design change?  Or was it just an 
accident/by-product of the rewritten io?

Anyway, the patch looks good to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Mon Jan 26 17:10:21 2009
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 26 Jan 2009 16:10:21 +0000
Subject: [issue5071] Distutils should not fail if install dir is not in
	PYTHONPATH
In-Reply-To: <1232986221.07.0.343484520205.issue5071@psf.upfronthosting.co.za>
Message-ID: <1232986221.07.0.343484520205.issue5071@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

At present, distutils exits with an error return code if the directory
that modules are being installed into is not in PYTHONPATH. Since the
install path is not easily obtained (it at least requires running Python
to work out the version string, plus some guesswork about "lib" vs.
"lib64", etc. etc.), it would be nice if this was not a blocking
problem... at least when the --force flag is passed to setup.py

(PS. It would be nice if there *is* a way to get the installation path
from distutils before installing, for the reasons mentioned: that way
automatic install scripts like the one I'm managing could work out the
path, make it and add it to the PYTHONPATH, without worrying about
getting it wrong. Am I just missing something that already exists?)

----------
components: Distutils
messages: 80576
nosy: andybuckley
severity: normal
status: open
title: Distutils should not fail if install dir is not in PYTHONPATH
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5071>
_______________________________________

From report at bugs.python.org  Mon Jan 26 17:11:50 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Jan 2009 16:11:50 +0000
Subject: [issue5071] Distutils should not fail if install dir is not in
	PYTHONPATH
In-Reply-To: <1232986221.07.0.343484520205.issue5071@psf.upfronthosting.co.za>
Message-ID: <1232986310.3.0.47628544214.issue5071@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

See my comment on issue5070.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5071>
_______________________________________

From report at bugs.python.org  Mon Jan 26 17:56:59 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Jan 2009 16:56:59 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1232989019.52.0.74079377924.issue4474@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@marketdickinson, @lemburg: ping! I updated the patch, does it look 
better?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Mon Jan 26 18:00:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Jan 2009 17:00:42 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1232989242.69.0.482749785342.issue4626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ping! Can anyone review my patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Mon Jan 26 18:03:52 2009
From: report at bugs.python.org (Akira Kitada)
Date: Mon, 26 Jan 2009 17:03:52 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1232989432.53.0.0165794058293.issue4010@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Attached patch changes distutils to pass CPPFLAGS to compiler.

----------
nosy: +tarek
Added file: http://bugs.python.org/file12868/issue4010.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Mon Jan 26 18:08:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Jan 2009 17:08:30 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1232989710.36.0.99977987378.issue4010@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Mon Jan 26 18:26:03 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Jan 2009 17:26:03 +0000
Subject: [issue1885] [distutils] - error when processing the "--formats=tar"
	option
In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za>
Message-ID: <1232990763.17.0.660718816434.issue1885@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done (in r68969 for py3k branch)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1885>
_______________________________________

From report at bugs.python.org  Mon Jan 26 18:27:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Jan 2009 17:27:04 +0000
Subject: [issue5070] Distutils should create install dir if needed
In-Reply-To: <1232985666.7.0.224838813352.issue5070@psf.upfronthosting.co.za>
Message-ID: <1232990824.12.0.450788598439.issue5070@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5070>
_______________________________________

From report at bugs.python.org  Mon Jan 26 18:27:19 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 26 Jan 2009 17:27:19 +0000
Subject: [issue5071] Distutils should not fail if install dir is not in
	PYTHONPATH
In-Reply-To: <1232986221.07.0.343484520205.issue5071@psf.upfronthosting.co.za>
Message-ID: <1232990839.34.0.852532289253.issue5071@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5071>
_______________________________________

From report at bugs.python.org  Mon Jan 26 18:44:47 2009
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 26 Jan 2009 17:44:47 +0000
Subject: [issue5070] Distutils should create install dir if needed
In-Reply-To: <1232985666.7.0.224838813352.issue5070@psf.upfronthosting.co.za>
Message-ID: <1232991887.53.0.859607928953.issue5070@psf.upfronthosting.co.za>


Andy Buckley <andy at insectnation.org> added the comment:

Thanks for the rapid feedback: yes, I am using setuptools and didn't
realise it would be responsible for this override. Is setuptools
feedback done completely independently from this tracker?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5070>
_______________________________________

From report at bugs.python.org  Mon Jan 26 18:46:17 2009
From: report at bugs.python.org (Weeble)
Date: Mon, 26 Jan 2009 17:46:17 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1232991977.35.0.288576780239.issue1529142@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

A thought occurs to me: would this patch make it harder to cope with 
awkward firewalls that block the connection? Are they more or less 
likely to intervene when passing a port of 0 and letting it pick a port 
automatically? And if they do intervene, would users be able to create 
an exception if there is no small list of ports that might be used?

Apart from that, what do I need to do to move this forward? Go hunt for 
more testers willing to try out the patch? Find an expert to review it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_______________________________________

From report at bugs.python.org  Mon Jan 26 19:05:52 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Jan 2009 18:05:52 +0000
Subject: [issue5070] Distutils should create install dir if needed
In-Reply-To: <1232985666.7.0.224838813352.issue5070@psf.upfronthosting.co.za>
Message-ID: <1232993152.15.0.72569738261.issue5070@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Yea.  setuptools is often discussed on distutils-sig:

  http://www.python.org/community/sigs/current/distutils-sig/

And has an issue tracker of its own:

  http://bugs.python.org/setuptools/

http://bugs.python.org/setuptools/issue54 sounds like this issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5070>
_______________________________________

From report at bugs.python.org  Mon Jan 26 19:53:50 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 26 Jan 2009 18:53:50 +0000
Subject: [issue5061] Inadequate documentation of the built-in function open
In-Reply-To: <1232926902.91.0.899964022103.issue5061@psf.upfronthosting.co.za>
Message-ID: <1232996030.58.0.957719324278.issue5061@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

(prospective, not perspective programmer)

Spelling out the possibilities as suggested in Message80563 makes better
sense to me than writing in words the logic handling the mode argument
of the io.open function.  (Perhaps there is a clearer implementation
using a dictionary with frozenset keys, but the io module for py3k is
being recast in c, per my understanding.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5061>
_______________________________________

From report at bugs.python.org  Mon Jan 26 19:59:00 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 26 Jan 2009 18:59:00 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1232996340.2.0.938804230255.issue2459@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Mon Jan 26 20:22:54 2009
From: report at bugs.python.org (Olemis Lang)
Date: Mon, 26 Jan 2009 19:22:54 +0000
Subject: [issue5072] urllib.open sends full URL after GET command instead of
	local path
In-Reply-To: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>
Message-ID: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>


New submission from Olemis Lang <olemis at gmail.com>:

Hello ... 

The first thing I have to say is that I searched the open issues and I 
found nothing similar to what I am going to report hereinafter. If this 
ticket is duplicate , I apologize ...

Yesterday I was testing how to access the wiki pages in a 
Trac [1]_ site and I realized that something wrong was happening 
(a bug? ...)

Initially the behavior was as follows :

{{{
#!python
>>> u = urllib.urlopen('http://localhost:8000/trac-dev')
>>> u.read()
'Environment not found'
>>> u.close()
}}}

And tracd reported a line like this 

{{{
127.0.0.1 - - [25/Jan/2009 17:32:08] "GET http://localhost:8000/trac-
dev HTTP/1.0" 404 -
}}}

Which means that a 'Not found' error code was sent back to urllib 
client.

I tried to access the same page from my browser and tracd reported

{{{
127.0.0.1 - - [25/Jan/2009 18:05:44] "GET /trac-dev HTTP/1.0" 200 -
}}}

The problem is obvious ... urllib was sending the full URL after GET
and it should send only the string after the network location.

I applied the following patch to urllib (yours will be better, I am 
sure about that ;)

{{{
#!diff

--- /usr/lib/python2.5/urllib.py        2008-07-31 13:40:40.000000000 
-0500
+++ /media/urllib_unix.py     2009-01-26 09:48:54.000000000 -0500
@@ -270,6 +270,7 @@
     def open_http(self, url, data=None):
         """Use HTTP protocol."""
         import httplib
+        from urlparse import urlparse
         user_passwd = None
         proxy_passwd= None
         if isinstance(url, str):
@@ -312,12 +313,17 @@
         else:
             auth = None
         h = httplib.HTTP(host)
+        target = ''.join(sep + part for sep, part in \
+                                zip(['', ';', '?', '#'], \
+                                    urlparse(selector)[2:]) \
+                                if part)
+        print target
         if data is not None:
-            h.putrequest('POST', selector)
+            h.putrequest('POST', target)
             h.putheader('Content-Type', 'application/x-www-form-
urlencoded')
             h.putheader('Content-Length', '%d' % len(data))
         else:
-            h.putrequest('GET', selector)
+            h.putrequest('GET', target)
         if proxy_auth: h.putheader('Proxy-Authorization', 'Basic %s' % 
proxy_auth)
         if auth: h.putheader('Authorization', 'Basic %s' % auth)
         if realhost: h.putheader('Host', realhost)


}}}

And everithing was ?back? to normal ...

{{{
#!python
>>> u = urllib.urlopen('http://localhost:8000/trac-dev')
>>> u.read()
    ... # Lots of beautiful HTML code ;)
>>> u.close()
}}}

... tracd outputted ...

{{{
127.0.0.1 - - [25/Jan/2009 18:05:44] "GET /trac-dev HTTP/1.0" 200 -
}}}

The same picture is shown when using both Python 2.5.1 and 2.5.2 ...
I have not installed Python 2.6.x so I am not sure about whether this
issue has propagated onto newer versions of Python ... and I don't 
know euther if this issue is also present in urllib2 or not ...

... so further research is needed, but IMO this is a serious bug :(

PD: If this is a bug ... how could it be hidden so far ? Is there any 
    test case written to assert this kind of things ? I checked out 
    `test.test_urllib` and `test.test_urllibnet` modules and I saw
    nothing at all ... 

.. [1] Trac
       (http://trac.edgewall.org)

----------
components: Library (Lib)
messages: 80586
nosy: olemis
severity: normal
status: open
title: urllib.open sends full URL after GET command instead of local path
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5072>
_______________________________________

From report at bugs.python.org  Mon Jan 26 20:25:51 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 26 Jan 2009 19:25:51 +0000
Subject: [issue5068] tarfile loops forever on broken input
In-Reply-To: <1232968111.2.0.128325452145.issue5068@psf.upfronthosting.co.za>
Message-ID: <1232997951.1.0.133541626565.issue5068@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Thanks for the report. The problem is in fact easy to reproduce.
_BZ2Proxy hangs if it is passed a file object with either no data or
with a partial bzipped file. For example try:

tarfile.open(mode="r:bz2", fileobj=StringIO.StringIO())

I will create a decent fix for that problem, but not before next week. I
am too busy doing other important stuff ATM.

----------
versions: +Python 3.0, Python 3.1 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5068>
_______________________________________

From report at bugs.python.org  Mon Jan 26 20:28:45 2009
From: report at bugs.python.org (Olemis Lang)
Date: Mon, 26 Jan 2009 19:28:45 +0000
Subject: [issue5072] urllib.open sends full URL after GET command instead of
	local path
In-Reply-To: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>
Message-ID: <1232998125.38.0.202815798287.issue5072@psf.upfronthosting.co.za>


Olemis Lang <olemis at gmail.com> added the comment:

Ooops ... sorry, remove the print statement. The patch is as follows :

{{{
#!diff

--- /usr/lib/python2.5/urllib.py        2008-07-31 13:40:40.000000000 
-0500
+++ /media/urllib_unix.py     2009-01-26 09:48:54.000000000 -0500
@@ -270,6 +270,7 @@
     def open_http(self, url, data=None):
         """Use HTTP protocol."""
         import httplib
+        from urlparse import urlparse
         user_passwd = None
         proxy_passwd= None
         if isinstance(url, str):
@@ -312,12 +313,17 @@
         else:
             auth = None
         h = httplib.HTTP(host)
+        target = ''.join(sep + part for sep, part in \
+                                zip(['', ';', '?', '#'], \
+                                    urlparse(selector)[2:]) \
+                                if part)
         if data is not None:
-            h.putrequest('POST', selector)
+            h.putrequest('POST', target)
             h.putheader('Content-Type', 'application/x-www-form-
urlencoded')
             h.putheader('Content-Length', '%d' % len(data))
         else:
-            h.putrequest('GET', selector)
+            h.putrequest('GET', target)
         if proxy_auth: h.putheader('Proxy-Authorization', 'Basic %s' % 
proxy_auth)
         if auth: h.putheader('Authorization', 'Basic %s' % auth)
         if realhost: h.putheader('Host', realhost)


}}}

I apologize once again ...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5072>
_______________________________________

From report at bugs.python.org  Mon Jan 26 21:20:17 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 26 Jan 2009 20:20:17 +0000
Subject: [issue5073] bsddb/test/test_lock.py sometimes fails due to floating
	point error
In-Reply-To: <1233001217.88.0.560168543661.issue5073@psf.upfronthosting.co.za>
Message-ID: <1233001217.88.0.560168543661.issue5073@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

time.time() returns floating point, so sometimes folloing assertion in 
LockingTestCase#test03_lock_timeout fails due to floating point 
calculation error.

>self.assertTrue((end_time-start_time) >= 0.1

end_time-start_time becomes 0.0999999046326 for instance. I ran 
test_lock.py 100 times after applied the attached patch, I saw no error.

----------
components: Tests
files: test_lock.patch
keywords: patch
messages: 80589
nosy: ocean-city
severity: normal
status: open
title: bsddb/test/test_lock.py sometimes fails due to floating point error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12869/test_lock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5073>
_______________________________________

From report at bugs.python.org  Mon Jan 26 21:49:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 20:49:20 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1232985908.12.0.827908622665.issue4705@psf.upfronthosting.co.za>
Message-ID: <1233002986.7526.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So 'python3.0 -u' has buffered stdin, while 'python2.6 -u' does not;
> I'm wondering: was this an intentional design change?  Or was it just
> an accident/by-product of the rewritten io?

I'm not sure (I didn't write the new io in the first place) but I'd say
it was simply overlooked. Otherwise 'python3.0 -u' would have had at
least unbuffered stdout/stderr, which it didn't have.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Mon Jan 26 22:09:23 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Jan 2009 21:09:23 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233004163.3.0.258996301072.issue2459@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Reminder, make sure we can still break out of a "while 1: pass".

----------
nosy: +rhettinger
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Mon Jan 26 22:17:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Jan 2009 21:17:51 +0000
Subject: [issue5073] bsddb/test/test_lock.py sometimes fails due to floating
	point error
In-Reply-To: <1233001217.88.0.560168543661.issue5073@psf.upfronthosting.co.za>
Message-ID: <1233004671.42.0.576505030167.issue5073@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks good to me!  If it were me I'd probably just code the test directly 
as 

self.assertTrue((end_time-start_time) >= 0.0999)

to avoid having to look for epsilon when reading.

Do you want to commit it or shall I?

----------
nosy: +marketdickinson
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5073>
_______________________________________

From report at bugs.python.org  Mon Jan 26 22:18:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 21:18:41 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1233004163.3.0.258996301072.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233004750.7526.17.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Reminder, make sure we can still break out of a "while 1: pass".

Yes, the patch takes care of that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Mon Jan 26 22:19:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 21:19:24 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1233004764.97.0.712509611428.issue4705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Mon Jan 26 22:40:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 26 Jan 2009 21:40:57 +0000
Subject: [issue5073] bsddb/test/test_lock.py sometimes fails due to floating
	point error
In-Reply-To: <1233001217.88.0.560168543661.issue5073@psf.upfronthosting.co.za>
Message-ID: <1233006057.47.0.962711272319.issue5073@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Could you commit please? :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5073>
_______________________________________

From report at bugs.python.org  Mon Jan 26 22:41:16 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Jan 2009 21:41:16 +0000
Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1233006076.88.0.256331624078.issue5066@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

LOL. That doc was apparently last revised in 2000 for the IDLE released
with 1.5.2 (see screenshot).  Other needed updates I see are: 'Shell'
and 'Options' have been added to the menu line; we now have unicode
text; screenshots look different (and nicer) on newer Tk on WinXP and
could/should be redone.

If it were decided to update this and add it to the doc package, I would
help in some way.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5066>
_______________________________________

From report at bugs.python.org  Mon Jan 26 23:03:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Jan 2009 22:03:13 +0000
Subject: [issue5073] bsddb/test/test_lock.py sometimes fails due to floating
	point error
In-Reply-To: <1233001217.88.0.560168543661.issue5073@psf.upfronthosting.co.za>
Message-ID: <1233007393.26.0.0862115870716.issue5073@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r68978 (trunk) and r68979 (2.6).  bsddb is no longer part of the 
standard Python distribution for 3.x, so the patch doesn't apply there.

Thank you!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5073>
_______________________________________

From report at bugs.python.org  Mon Jan 26 23:09:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 22:09:42 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1233007782.45.0.45433827222.issue4705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed and applied a small fix to the test so that it passes in debug
mode (r68977, r68981, r68982). Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Tue Jan 27 00:08:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 23:08:38 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233011318.54.0.964056849735.issue2459@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patches don't apply cleanly anymore, I'll regenerate a new one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Tue Jan 27 00:08:44 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 23:08:44 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233011324.95.0.935472746288.issue2459@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file10147/loops8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Tue Jan 27 00:08:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 23:08:48 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233011328.76.0.0424536518223.issue2459@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9871/loops7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Tue Jan 27 00:08:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 23:08:52 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233011332.29.0.349114617381.issue2459@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9870/loops6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Tue Jan 27 00:08:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 23:08:55 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233011335.78.0.745544448168.issue2459@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9863/loops5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Tue Jan 27 00:08:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 23:08:59 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233011339.63.0.546164034767.issue2459@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9832/loops4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Tue Jan 27 00:09:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Jan 2009 23:09:02 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1233011342.99.0.743704908538.issue2459@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9829/loops3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
_______________________________________

From report at bugs.python.org  Tue Jan 27 00:13:33 2009
From: report at bugs.python.org (Ross Light)
Date: Mon, 26 Jan 2009 23:13:33 +0000
Subject: [issue4285] Use a named tuple for sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1233011613.01.0.571160248006.issue4285@psf.upfronthosting.co.za>


Ross Light <rlight2 at gmail.com> added the comment:

Tests added and new patch uploaded.  Anything else, anyone?

Added file: http://bugs.python.org/file12870/patch-4285d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________

From report at bugs.python.org  Tue Jan 27 01:09:18 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 00:09:18 +0000
Subject: [issue5072] urllib.open sends full URL after GET command instead of
	local path
In-Reply-To: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>
Message-ID: <1233014958.69.0.719101732889.issue5072@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I could not reproduce this issue neither with Python 2.6 nor 2.5.2
If I print host and selector near line 313, I get 'localhost:8000' and 
'/trac-dev', the expected results.
Do you have an HTTP proxy? running at the *same* port? (!)

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5072>
_______________________________________

From report at bugs.python.org  Tue Jan 27 01:24:40 2009
From: report at bugs.python.org (philobyte)
Date: Tue, 27 Jan 2009 00:24:40 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1233015880.77.0.970678191617.issue4673@psf.upfronthosting.co.za>


philobyte <Peter.A.Silva at gmail.com> added the comment:

python setup.py uninstall 
should do all the same processing as 'install' but whenever it gets to
the point of copying a file to a system destination, it should instead
unlink the destination.

besides the obvious use, here is another one:
   when upgrading a package, and the new version no longer includes
certain files, just installing the new version will leave leftovers
of the previous version installed.  using uninstall beforehand will
clean out the cruft.

----------
nosy: +philobyte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4673>
_______________________________________

From report at bugs.python.org  Tue Jan 27 01:32:29 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 00:32:29 +0000
Subject: [issue5069] Use sets instead of list in posixpath._resolve_link
In-Reply-To: <1232979493.22.0.551586556821.issue5069@psf.upfronthosting.co.za>
Message-ID: <1233016349.62.0.583249579176.issue5069@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Simple and correct.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5069>
_______________________________________

From report at bugs.python.org  Tue Jan 27 01:36:54 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 00:36:54 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1233016614.06.0.869868343913.issue5053@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I think unified diffs are preferred.
Isn't there an existing test for this method?

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Tue Jan 27 02:05:51 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 01:05:51 +0000
Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful
In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za>
Message-ID: <1233018351.52.0.794716492238.issue5067@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This patch provides a better error message for this case::

  json.loads("""{'test': "test"}""")

but still doesn't help in this one::

  json.loads("""{"test": 'test'}""")

'test' looks like garbage to JSON (it *is* garbage!), exactly the same 
as::

  json.loads("""{"test": @?&%%}""")

so it's hard to provide a better message when the parser expects a 
generic object.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5067>
_______________________________________

From report at bugs.python.org  Tue Jan 27 02:06:13 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 01:06:13 +0000
Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful
In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za>
Message-ID: <1233018373.31.0.9418088867.issue5067@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12871/json-messages.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5067>
_______________________________________

From report at bugs.python.org  Tue Jan 27 02:42:19 2009
From: report at bugs.python.org (steve21)
Date: Tue, 27 Jan 2009 01:42:19 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1233020539.44.0.269039576151.issue5032@psf.upfronthosting.co.za>


steve21 <steve872929-bv at yahoo.com.au> added the comment:

Here's a couple of functions I use with count and step:

def cf_e():
    '''return: (iterator) the infinite continued fraction for e
    e=[2; 1, 2, 1, 1, 4, 1, 1, 6, 1 , ... , 1, 2k, 1, ...]
    '''
    yield 2
    for k in itertools.count(2, 2):
        yield 1
        yield k
        yield 1


def prime_factors(n):
    '''n: (int > 1)
    return: (list) the sorted list of tuples (p,e) of prime factors of n
            p is a prime factor, e is the number of times the factor is used
    '''
    ret = []
    if n <= 1:
        return ret

    # factors: use known (small) primes, then possible primes (odd numbers)
    for factor in itertools.chain([2,3,5,7,11], itertools.count(13, 2)):
        if factor*factor > n:
            if n != 1:
                ret += [(n, 1)]
            break
        for e in itertools.count(0):
            div, mod = divmod(n, factor)
            if mod != 0:
                break
            n = div
        if e >= 1:
            ret += [(factor, e)]
    return ret

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Tue Jan 27 02:53:57 2009
From: report at bugs.python.org (Mike Watkins)
Date: Tue, 27 Jan 2009 01:53:57 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1233021237.34.0.255505648164.issue5053@psf.upfronthosting.co.za>


Mike Watkins <python at mikewatkins.ca> added the comment:

Re diffs, noted for the future. 
Re tests:

# py3k-devel/Lib/test % grep -r getallmatchingheaders *

... Returns nothing, so not only does the email package need a test for 
this but so does http.client. 

Incidentally test_mailbox.py has a test for the proposed alternative - 
get_all(), which I noted above. That's another good reason for ridding 
the world of getallmatchingheaders() or at least simply calling 
get_all() from within getallmatchingheaders() if compatibility is a 
legitimate concern.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Tue Jan 27 03:14:55 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 02:14:55 +0000
Subject: [issue5058] stop pgen.exe from generating CRLF-ended files and
	causing mayhem with win32-based patch submissions
In-Reply-To: <1232907301.06.0.0381974721982.issue5058@psf.upfronthosting.co.za>
Message-ID: <1233022495.08.0.726296391116.issue5058@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I don't understand the issue. Those files *are* text files, and have 
CRLF on Windows as expected, like all other text files.

I think you should fix your build process, or your environment, or your 
diff utility, or whatever is causing you a problem -- but not pgen.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5058>
_______________________________________

From report at bugs.python.org  Tue Jan 27 03:47:19 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 02:47:19 +0000
Subject: [issue5065] IDLE improve Subprocess Startup Error message
In-Reply-To: <1232941628.82.0.541445606335.issue5065@psf.upfronthosting.co.za>
Message-ID: <1233024439.86.0.697703472197.issue5065@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

#1529142 would fix this issue also, if it were accepted.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5065>
_______________________________________

From report at bugs.python.org  Tue Jan 27 03:48:03 2009
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 27 Jan 2009 02:48:03 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1233024483.62.0.503081369687.issue5032@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

Nice.  Now I know that $e$ is a least transcendental number.  But I 
can't figure out why inserting this code into your file (and removing 
some "itertools.") is difficult or unreadable.  I maintain a personal 
library of modules that I don't actually expect Guido to include in the 
python standard library.


import itertools

def count(offset=0,stride=1):
    for i in itertools.count():
        yield offset+i*stride


# this version probably performs faster
def count(offset=0,stride=1):
    while True:
        yield offset
        offset += stride

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Tue Jan 27 03:48:30 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 02:48:30 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1233024510.96.0.747367900513.issue1529142@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

If this patch were accepted, #5065 would be a non-issue then.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_______________________________________

From report at bugs.python.org  Tue Jan 27 03:59:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 02:59:37 +0000
Subject: [issue5065] IDLE improve Subprocess Startup Error message
In-Reply-To: <1232941628.82.0.541445606335.issue5065@psf.upfronthosting.co.za>
Message-ID: <1233025177.29.0.827975204789.issue5065@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5065>
_______________________________________

From report at bugs.python.org  Tue Jan 27 04:00:49 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 03:00:49 +0000
Subject: [issue1498370] Improve itertools.starmap
Message-ID: <1233025249.15.0.180152477004.issue1498370@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: anthonybaxter -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1498370>
_______________________________________

From report at bugs.python.org  Tue Jan 27 04:02:25 2009
From: report at bugs.python.org (Poor Yorick)
Date: Tue, 27 Jan 2009 03:02:25 +0000
Subject: [issue5074] python3 and ctypes, script causes crash
In-Reply-To: <1233025345.07.0.118465005013.issue5074@psf.upfronthosting.co.za>
Message-ID: <1233025345.07.0.118465005013.issue5074@psf.upfronthosting.co.za>


New submission from Poor Yorick <pooryorick at users.sourceforge.net>:

the following script causes python3 to crash on my Windows XP Pro  Machine:

import ctypes

b = ctypes.windll.Kernel32
var1 = 'TEMP'
out = ctypes.create_string_buffer(40) 
c = b.GetEnvironmentVariableW(var1,out,40)
print('ones', c, out, out.raw)
print('two: ', dir(out))

----------
assignee: theller
components: ctypes
messages: 80611
nosy: pooryorick, theller
severity: normal
status: open
title: python3 and ctypes, script causes crash
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5074>
_______________________________________

From report at bugs.python.org  Tue Jan 27 04:08:29 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Jan 2009 03:08:29 +0000
Subject: [issue5069] Use sets instead of list in posixpath._resolve_link
In-Reply-To: <1232979493.22.0.551586556821.issue5069@psf.upfronthosting.co.za>
Message-ID: <1233025709.88.0.88534994363.issue5069@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Applied in r69003.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5069>
_______________________________________

From report at bugs.python.org  Tue Jan 27 04:32:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Jan 2009 03:32:54 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1233027174.65.0.0556371817649.issue4626@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't like the change of API to PyTokenizer_FromString. I would prefer
another function like PyTokenizer_IgnoreCodingCookie() blows up when
parsing has already started.

The (char *) cast in PyTokenizer_FromString is unneeded.

You need to indent the "else" clause after you test for ignore_cookie.

I'd like to see a test that shows that byte strings still have their
cookies examined.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Tue Jan 27 04:57:01 2009
From: report at bugs.python.org (steve21)
Date: Tue, 27 Jan 2009 03:57:01 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1233028621.62.0.725226010085.issue5032@psf.upfronthosting.co.za>


steve21 <steve872929-bv at yahoo.com.au> added the comment:

I already use the second version of the count function you give (without
default arguments which I am not a big fan of). I'm not saying its
difficult or unreadable to bypass itertools.count and write your own
enhanced count function. But if I use a custom count function, you use a
custom count function, and possibly many others too, then there could be
a common requirement for a step argument and it might be a good idea too
make it more widely available. 

Haskell has a powerful and concise list notation, some of which Python
has already borrowed from:
multiple3 = [3,6..]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Tue Jan 27 04:58:51 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 03:58:51 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1233028731.63.0.700534025847.issue5062@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This is not a bug in rlcompleter; __dir__ is returning bogus items, and 
rlcompleter checks whether there exist actually an attribute with such 
name.

Defining __getattr__ (or __getattribute__) and a matching __dir__ works 
fine:

>>> class B(object):
...   def __dir__(self):
...     return dir(object) + ["xa","xb","xc"]
...   def __getattr__(self, name):
...     if name in ["xa","xb","xc"]:
...       return None
...     raise AttributeError, name
...
>>> b = B()
>>> import rlcompleter
>>> c = rlcompleter.Completer()
>>> c.complete("b.", 0)
'b.__class__('
>>> c.matches
['b.__class__(', 'b.__delattr__(', 'b.__doc__', 'b.__format__(', 
'b.__getattribute__(', 
...
'b.xa', 'b.xb', 'b.xc', 'b.__class__(', 'b.__class__(', 
...]
>>> c.complete("b.x", 0)
'b.xa'
>>> c.matches
['b.xa', 'b.xb', 'b.xc']

Now, looking at this I saw there *is* a bug in rlcompleter, as it may 
return many duplicate items:

>>> c.complete("b.__c", 0)
'b.__class__('
>>> c.matches
['b.__class__(', 'b.__class__(', 'b.__class__(', 'b.__class__(']

The attached patch fixes that.

----------
keywords: +patch
nosy: +gagenellina
Added file: http://bugs.python.org/file12872/rlcompleter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Tue Jan 27 05:09:19 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 04:09:19 +0000
Subject: [issue5051] test_update2 in test_os.py invalid due to
	os.environ.clear() followed by reliance on environ COMSPEC
In-Reply-To: <1232883558.71.0.175097990327.issue5051@psf.upfronthosting.co.za>
Message-ID: <1233029359.11.0.884672607846.issue5051@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I *did* have /bin/sh in a Windows box some time ago.
Probably the test should check sys.platform in addition to /bin/sh 
existence.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5051>
_______________________________________

From report at bugs.python.org  Tue Jan 27 05:37:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 04:37:32 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1233031052.82.0.1874225992.issue5048@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I added combinations_with_replacement() in r69001 and r69004 .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Tue Jan 27 05:37:54 2009
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 27 Jan 2009 04:37:54 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1233028621.62.0.725226010085.issue5032@psf.upfronthosting.co.za>
Message-ID: <84B204FFB016BA4984227335D8257FBA849B9A@CVCV0XI05.na.corning.com>


David W. Lambert <lambertdw at corning.com> added the comment:

Probably a better prime factor algorithm uses Sieve of E. to generate
primes through int(1+sqrt(n)) and test these.

The other algorithm uses a custom generator anyway.  Oh well, good luck,
I'll shut up.
You do have use cases that I couldn't think of.

Dave.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Tue Jan 27 05:39:42 2009
From: report at bugs.python.org (Carl Johnson)
Date: Tue, 27 Jan 2009 04:39:42 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1233031182.0.0.777565522668.issue5062@psf.upfronthosting.co.za>


Carl Johnson <carl at carlsensei.com> added the comment:

It seems to me that it isn't tab completion's place to out think the
__dir__ method. A) Because the documentation doesn't tell you that it
does (although you are warned that it may call some stuff) and B)
because if someone set up a __dir__ method, they probably are listing
the things that they want listed for a particular reason. I think that
it would be less confusing for rlcompleter to follow the __dir__ method
when it exists and only do its own poking and prodding when it does not.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Tue Jan 27 06:00:33 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 05:00:33 +0000
Subject: [issue5075] bdist_wininst should not depend on the vc runtime?
In-Reply-To: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>
Message-ID: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

After consideration of issue 4120 and issue 4566, it seems to me that
executables created by bdist_wininst will have a manifest referencing
the MSVC9 assembly, and thus will be in a similar position to the .pyd
files in issue 4120 - that unless the assembly is installed globally or
next to the executable itself, the executable will not start.  Note that
I have not verified this, but have verified the final installer
executable references the CRT assembly, and given those other bugs,
expect it to be true.

It seems to me a reasonable solution would be to have the bdist_wininst
stub use a static copy of the C runtime library.  While this means 2
copies of the CRT will eventually be loaded and would otherwise be
considered evil, the way the stub dynamically loads Python and the few
API functions it uses means it might be reasonable in this case.  Would
the trivial patch which achieves this be desired?

----------
assignee: mhammond
components: Distutils
messages: 80620
nosy: mhammond
severity: normal
status: open
title: bdist_wininst should not depend on the vc runtime?
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5075>
_______________________________________

From report at bugs.python.org  Tue Jan 27 06:14:59 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 05:14:59 +0000
Subject: [issue1498370] Improve itertools.starmap
Message-ID: <1233033299.72.0.498355649018.issue1498370@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This was fixed in r60013.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1498370>
_______________________________________

From report at bugs.python.org  Tue Jan 27 06:15:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 05:15:45 +0000
Subject: [issue5034] itertools.fixlen
In-Reply-To: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>
Message-ID: <1233033345.51.0.546345937419.issue5034@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5034>
_______________________________________

From report at bugs.python.org  Tue Jan 27 06:17:21 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 05:17:21 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1233033441.08.0.509707133444.issue2527@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2527>
_______________________________________

From report at bugs.python.org  Tue Jan 27 06:18:58 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 05:18:58 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1233033538.55.0.25526423345.issue1242657@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Tue Jan 27 06:19:25 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 05:19:25 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1233033565.62.0.0703056175316.issue4920@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Tue Jan 27 06:20:09 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 05:20:09 +0000
Subject: [issue5021] doctest.testfile should set __name__, can't use namedtuple
In-Reply-To: <1232540587.99.0.985129988543.issue5021@psf.upfronthosting.co.za>
Message-ID: <1233033609.18.0.475483451572.issue5021@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5021>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:03:19 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 06:03:19 +0000
Subject: [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>
Message-ID: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

bdist_wininst installers created by py3k fail due to PySys_SetArgv and
Py_SetProgramName both being passed 'char *' strings instead of wide
strings.

The patch is against the svn trunk as currently Python 2.x and 3.x share
the same bdist_wininst stub.  The patch doesn't change the behaviour on
Python 2.x, and continues to allow the same executable stub to be
shared, as the appropriate signature is determined at runtime based on
the Python version.

The patch does not include the 2 new stub executables required
(wininst-9.0.exe and wininst-9.0-amd64.exe), but the patch *and* the new
stub executables should be merged into whatever py3k branches are
appropriate.  I've tested (pywin32) installers based on the new stub on
python 2.6 32bit, and python 3.0 32 and 64bit.

----------
assignee: mhammond
components: Distutils
files: wininst_py3k.patch
keywords: needs review, patch, patch
messages: 80622
nosy: mhammond
priority: high
severity: normal
stage: commit review
status: open
title: bdist_wininst fails on py3k
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12873/wininst_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5076>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:09:06 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 06:09:06 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1233036546.35.0.0462714578337.issue5062@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This is what rlcompleter does; it uses dir() to find out what names to 
return.
Or do you mean that it should not iterate along __bases__ because this 
has already been done by dir()?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:13:38 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 27 Jan 2009 06:13:38 +0000
Subject: [issue5077] 2to3 fixers for the removal of operator functions
In-Reply-To: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>
Message-ID: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

This is a 2to3 fixer for the removal of obsolete functions in r68962.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_operator.py
messages: 80624
nosy: alexandre.vassalotti
severity: normal
stage: patch review
status: open
title: 2to3 fixers for the removal of operator functions
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12874/fix_operator.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5077>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:15:39 2009
From: report at bugs.python.org (Carl Johnson)
Date: Tue, 27 Jan 2009 06:15:39 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1233036939.45.0.639195415593.issue5062@psf.upfronthosting.co.za>


Carl Johnson <carl at carlsensei.com> added the comment:

I think that checking to see which things really exist with
getattr/hasattr made sense back in the days before the __dir__, since in
those days the real API for an object could diverge wildly from what was
reported by dir(object), but nowadays, if someone goes to the trouble of
defining the __dir__ method, then we should just trust that as being
"the API" and not do any other checking.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:19:54 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 27 Jan 2009 06:19:54 +0000
Subject: [issue5077] 2to3 fixers for the removal of operator functions
In-Reply-To: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>
Message-ID: <1233037194.76.0.216875238173.issue5077@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file12875/fix_operator.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5077>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:20:05 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 27 Jan 2009 06:20:05 +0000
Subject: [issue5077] 2to3 fixers for the removal of operator functions
In-Reply-To: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>
Message-ID: <1233037205.03.0.941128100137.issue5077@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Removed file: http://bugs.python.org/file12874/fix_operator.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5077>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:23:22 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 27 Jan 2009 06:23:22 +0000
Subject: [issue5077] 2to3 fixer for the removal of operator functions
In-Reply-To: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>
Message-ID: <1233037402.11.0.765800278162.issue5077@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
title: 2to3 fixers for the removal of operator functions -> 2to3 fixer for the removal of operator functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5077>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:43:43 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 06:43:43 +0000
Subject: [issue1397474] timeit execution enviroment
Message-ID: <1233038623.39.0.817862603593.issue1397474@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: fdrake -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397474>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:46:15 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 06:46:15 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1233038775.47.0.0735184878791.issue5062@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

The check is made to decide whether the attribute is a method or not 
(because methods get a "(" appended) -- for names that fail to exist, 
one could just omit the "(" and include the name anyway.

rlcompleter does nothing special with __dir__, it always uses dir() 
only.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Tue Jan 27 07:53:45 2009
From: report at bugs.python.org (Carl Johnson)
Date: Tue, 27 Jan 2009 06:53:45 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1233039225.19.0.757131616583.issue5062@psf.upfronthosting.co.za>


Carl Johnson <carl at carlsensei.com> added the comment:

Ah, I see. It does a dir(obj) then tests things to see which are
callable and while it is at that, it removes the names that don't really
exist according to getattr.

Actually, can we go back to the Python 2.5 behavior? I really hate those
auto-added parentheses. For one thing, it screws it up when you do
"help(name<TAB>". Am I missing some really obvious switch that would
turn the behavior back to the old style of ignoring the
callable/non-callable thing?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Tue Jan 27 08:01:50 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 07:01:50 +0000
Subject: [issue5074] python3 and ctypes, script causes crash
In-Reply-To: <1233025345.07.0.118465005013.issue5074@psf.upfronthosting.co.za>
Message-ID: <1233039710.46.0.0531601680799.issue5074@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

3rd argument to GetEnvironmentVariableW is the buffer size in 
*characters*, not bytes. Your buffer has room for 20 characters only, 
not 40. You should use create_unicode_buffer instead.

Probably the names create_unicode_buffer/create_string_buffer should be 
revised in 3.x

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5074>
_______________________________________

From report at bugs.python.org  Tue Jan 27 08:19:55 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 27 Jan 2009 07:19:55 +0000
Subject: [issue5074] python3 and ctypes, script causes crash
In-Reply-To: <1233025345.07.0.118465005013.issue5074@psf.upfronthosting.co.za>
Message-ID: <1233040795.82.0.0879476296552.issue5074@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you think this is a bug in ctypes? *Of course* it is possible to
crash Python by using ctypes incorrectly.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5074>
_______________________________________

From report at bugs.python.org  Tue Jan 27 08:20:46 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 07:20:46 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1233040846.31.0.231552641232.issue5062@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

The current behaviour is actually a requested feature: see #449227

I see your point, it may be annoying sometimes -- but calling a method 
is far more common than just getting a reference to it, so I think the 
current behaviour is fine (I'm talking about the added "(", not the 
repeated entries, nor the unneeded __bases__ recursion, nor the deleted 
entries)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Tue Jan 27 08:24:00 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 27 Jan 2009 07:24:00 +0000
Subject: [issue5075] bdist_wininst should not depend on the vc runtime?
In-Reply-To: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>
Message-ID: <1233041040.19.0.412268609372.issue5075@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think it would be even better if it didn't link with the CRT at all,
but until somebody provides a patch for that, linking statically sounds
fine to me.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5075>
_______________________________________

From report at bugs.python.org  Tue Jan 27 08:27:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 27 Jan 2009 07:27:35 +0000
Subject: [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>
Message-ID: <1233041255.26.0.541521177543.issue5076@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Is it really useful to be have the same stub for 2.x and 3.x? I think it
would be better if they mutually ignore each other, and be different.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5076>
_______________________________________

From report at bugs.python.org  Tue Jan 27 08:53:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 27 Jan 2009 07:53:24 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1233042804.68.0.356054786669.issue4673@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

philobyte, this means you have to keep the source somewhere to be able
to run setup.py uninstall. This is not handy imho.

What about a uninstall registery in Python that keeps track of the files
installed for each package ? this would let us have an uninstall command
that could run on its own.

"uninstall packagename"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4673>
_______________________________________

From report at bugs.python.org  Tue Jan 27 08:58:02 2009
From: report at bugs.python.org (Mike Watkins)
Date: Tue, 27 Jan 2009 07:58:02 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1233043082.67.0.983182248702.issue5053@psf.upfronthosting.co.za>


Mike Watkins <python at mikewatkins.ca> added the comment:

Further investigation ( grep -r getallmatchingheaders Lib/* ) reveals 
that in addition to having no tests, and being implemented incorrectly 
in http.client, getallmatchingheaders() is called only once, in 
http.server; that code is also broken (I reported this yesterday in  
#5053).

Maybe Python 3 is where getallmatchingheaders can make a graceful 
goodbye (and a 2to3 conversion added?).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Tue Jan 27 09:16:54 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 27 Jan 2009 08:16:54 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1233044214.56.0.234379648271.issue4626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Note that PyTokenizer_FromString is not an API function: it's not marked
with PyAPI_FUNC, and not exported from the windows DLL.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Tue Jan 27 09:49:11 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 27 Jan 2009 08:49:11 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1232989019.52.0.74079377924.issue4474@psf.upfronthosting.co.za>
Message-ID: <497ECA83.2050800@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2009-01-26 17:56, STINNER Victor wrote:
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> @marketdickinson, @lemburg: ping! I updated the patch, does it look 
> better?

Yes, but there are a few things that still need fixing:

 * SIZEOF_WCHAR_T is not defined for Windows builds, so needs
   to be added to PC/pyconfig.h (OTOH wchar_t is 2 bytes on Windows)
 * USE_WCHAR_SURROGATE should be #defined just before the
   function and #undef'ed right after it; I'd also use a more
   accurate name
 * please use pre-processor indents, e.g.
   #ifdef ...
   # define ...
   #endif

I'd write

#if (Py_UNICODE_SIZE == 2) && defined((SIZEOF_WCHAR_T) && (SIZEOF_WCHAR_T > 2)
# define CONVERT_WCHAR_TO_SURROGATES
#endif

...

#undef CONVERT_WCHAR_TO_SURROGATES

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Tue Jan 27 10:57:37 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 09:57:37 +0000
Subject: [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>
Message-ID: <1233050257.64.0.716100380567.issue5076@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

> Is it really useful to be have the same stub for 2.x and 3.x? 
> I think it would be better if they mutually ignore each 
> other, and be different.

Good question!  I'm not really aware of the complexities involved in
merging between the various branches, but given the fairly trivial
nature of the patch I figured there were potential advantages in both
identical source and stubs.  I'm happy to work the patch into either
#ifdef based (ie, identical source, different stubs), or "unconditional"
(both source and stubs different) if you prefer - and if so, which of
those 2 do you prefer?

On a related note, its obviously true that the same final installer will
not be able to be shared between 2.x and 3.x, as is currently possible
between pure-python installers between the 2.x series.  However, this
could be addressed in .py code at a later time while still allowing the
same stub to be shared if that is desirable.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5076>
_______________________________________

From report at bugs.python.org  Tue Jan 27 10:57:59 2009
From: report at bugs.python.org (Takeshi Matsuyama)
Date: Tue, 27 Jan 2009 09:57:59 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1233050279.36.0.555570547754.issue5036@psf.upfronthosting.co.za>


Takeshi Matsuyama <tksmashiw at gmail.com> added the comment:

>From msg80438
>You should reset it by self.data = '' at end_element().

It seems that we should reset it at start_element() like this,
============================
def start_element(self, name, attrs):
  ...abbr...
  if name == 'link':
    self.data = ''
=============================
or unwanted \s, \t, and \n mix in "self.data".
That's all, thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Tue Jan 27 11:06:46 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 10:06:46 +0000
Subject: [issue5021] doctest.testfile should set __name__, can't use namedtuple
In-Reply-To: <1232540587.99.0.985129988543.issue5021@psf.upfronthosting.co.za>
Message-ID: <1233050806.6.0.146335689171.issue5021@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

r69014 and r69015.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5021>
_______________________________________

From report at bugs.python.org  Tue Jan 27 11:14:58 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 10:14:58 +0000
Subject: [issue5075] bdist_wininst should not depend on the vc runtime?
In-Reply-To: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>
Message-ID: <1233051298.16.0.507192531319.issue5075@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Ironically I just received personal mail:

"""I have downloaded pywin32_212 [2.6] three times today. the download
completes successfully. but on running the pywin installer i repeatedly
get an error."""

Attached is a screen-shot of the error dialog
"pywin32-212-win32-py2.6.exe...has failed to start because the
application configuration is incorrect..."""

My apologies for not being more on top of this, but I couldn't find the
answer in the developer FAQ.  This question applies to issue 4566 and
will partially apply to issue 5076.  The patches are against the trunk -
after checking in, what action should I take to ensure it is merged to
2.6 and 3.x?  I'm happy to manually merge and checkin to those branches
if appropriate; if so, should I check it into branches/release30-maint
as well as branches/py3k?

Thanks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5075>
_______________________________________

From report at bugs.python.org  Tue Jan 27 11:33:34 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 27 Jan 2009 10:33:34 +0000
Subject: [issue5078] Avoid redundant call to FormatError()
In-Reply-To: <1233052414.48.0.581929509045.issue5078@psf.upfronthosting.co.za>
Message-ID: <1233052414.48.0.581929509045.issue5078@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

For a background, see the developers' mailing list from 2009-01-26,
subject "FormatError() in callproc.c under win32". The attached patch
removes the redundant call to FormatError(). It also makes
SetException() a static function, since it is only used locally.

----------
assignee: theller
components: ctypes
files: Python-redundant-FormatError-call.0.patch
keywords: patch
messages: 80641
nosy: eckhardt, theller
severity: normal
status: open
title: Avoid redundant call to FormatError()
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file12876/Python-redundant-FormatError-call.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5078>
_______________________________________

From report at bugs.python.org  Tue Jan 27 11:47:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 10:47:41 +0000
Subject: [issue5021] doctest.testfile should set __name__, can't use namedtuple
In-Reply-To: <1232540587.99.0.985129988543.issue5021@psf.upfronthosting.co.za>
Message-ID: <1233053261.82.0.277024037646.issue5021@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Also r69016 and r69017.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5021>
_______________________________________

From report at bugs.python.org  Tue Jan 27 11:48:12 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 10:48:12 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1233053292.39.0.294051359398.issue1242657@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Tue Jan 27 11:55:50 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 10:55:50 +0000
Subject: [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1233053750.66.0.563506167047.issue5032@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I've looked again at what it would take to update the C code and think
that the optimizations there make it difficult to add this feature
without adding a lot of code complexity and without slowing-down the
common case.  Also, I value the simplicity of the current API.

Suggest you use "range(start, sys.maxsize, step)" or just roll your own
generator (like Lambert's second version).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5032>
_______________________________________

From report at bugs.python.org  Tue Jan 27 12:09:38 2009
From: report at bugs.python.org (Tom Lynn)
Date: Tue, 27 Jan 2009 11:09:38 +0000
Subject: [issue5079] time.ctime docs refer to "time tuple" for default
In-Reply-To: <1233054577.95.0.996547748761.issue5079@psf.upfronthosting.co.za>
Message-ID: <1233054577.95.0.996547748761.issue5079@psf.upfronthosting.co.za>


New submission from Tom Lynn <tlynn at users.sourceforge.net>:

The docs for time.ctime() (quoted below) seem to have been copied from 
time.asctime(). They refer to a time tuple and localtime(), where they 
should refer to seconds and time().

Current docs::

    ctime(seconds) -> string
    
    Convert a time in seconds since the Epoch to a string in local time.
    This is equivalent to asctime(localtime(seconds)). When the time 
    tuple is not present, current time as returned by localtime() is 
    used.

----------
messages: 80644
nosy: tlynn
severity: normal
status: open
title: time.ctime docs refer to "time tuple" for default

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5079>
_______________________________________

From report at bugs.python.org  Tue Jan 27 12:10:38 2009
From: report at bugs.python.org (Tom Lynn)
Date: Tue, 27 Jan 2009 11:10:38 +0000
Subject: [issue5079] time.ctime docs refer to "time tuple" for default
In-Reply-To: <1233054577.95.0.996547748761.issue5079@psf.upfronthosting.co.za>
Message-ID: <1233054638.85.0.77087356739.issue5079@psf.upfronthosting.co.za>


Changes by Tom Lynn <tlynn at users.sourceforge.net>:


----------
components: +Library (Lib)
type:  -> feature request
versions: +Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5079>
_______________________________________

From report at bugs.python.org  Tue Jan 27 12:14:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Jan 2009 11:14:22 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1233054862.05.0.920860121665.issue5048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

combinations_with_replacement addition looks good.  Thank you.

I wonder whether the second argument should be constrained to be an
integer? I find the following a little surprising:

>>> list(combinations_with_replacement(range(5), -0.3))
[()]

(same behaviour with combinations and permutations).  Should I open a
separate issue for this, or is it just not worth changing?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Tue Jan 27 12:19:29 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 11:19:29 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1233055169.35.0.969258645175.issue5048@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Glad you like it.

Will meditate for a bit on the floating point input.  My first thought
is that it isn't worth going through the __index__ dance to preclude
inputs that look odd.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Tue Jan 27 12:25:13 2009
From: report at bugs.python.org (Andy Buckley)
Date: Tue, 27 Jan 2009 11:25:13 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1233055513.29.0.451871835334.issue4673@psf.upfronthosting.co.za>


Andy Buckley <andy at insectnation.org> added the comment:

If an uninstall registry is feasible, the it could be neat. The
suggested behaviour of unlinking known files based on the source
directory is not all that inconvenient: it's by no means perfect, but it
has its uses and is familiar to many, since it is how GNU autotools behaves.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4673>
_______________________________________

From report at bugs.python.org  Tue Jan 27 12:31:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Jan 2009 11:31:46 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1233055906.62.0.547330960224.issue5048@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I only just noticed the DeprecationWarning that's already happening for
float inputs in 2.7.  (And float inputs already raise TypeError in 3.1.)
So I agree that it's probably not worth it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Tue Jan 27 13:23:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Jan 2009 12:23:57 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Since Python 2.3, PyArg_ParseTuple and friends give a DeprecationWarning
for floating-point arguments where integers are expected.  From
http://www.python.org/download/releases/2.3/NEWS.txt:

- The PyArg_Parse functions now issue a DeprecationWarning if a float
  argument is provided when an integer is specified (this affects the 'b',
  'B', 'h', 'H', 'i', and 'l' codes).  Future versions of Python will
  raise a TypeError.

Can we turn that DeprecationWarning into a TypeError for 2.7?  (It's
already a TypeError in 3.x.) I'd like to see things like 'range(-0.3)'
and 'itertools.combinations(range(3), 5.1)' raise TypeError.

N.B. The relevant format codes in 2.7 include 'I' and 'n' in addition to
the six codes listed above.

----------
messages: 80649
nosy: marketdickinson
severity: normal
status: open
title: PyArg_Parse* should raise TypeError for float parsed with integer format
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Tue Jan 27 13:52:00 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 27 Jan 2009 12:52:00 +0000
Subject: [issue5081] Unable to print Unicode characters in Python 3 on Windows
In-Reply-To: <1233060719.46.0.922217803692.issue5081@psf.upfronthosting.co.za>
Message-ID: <1233060719.46.0.922217803692.issue5081@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

While trying to port pyftpdlib to Python 3.x I noticed that Python 3.0
has a serious issue since unable to print certain unicode characters on
stdout:

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> print('\u20ac')  # euro sign
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python30\lib\io.py", line 1491, in write
    b = encoder.encode(s)
  File "C:\python30\lib\encodings\cp850.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u20ac' in
position
0: character maps to <undefined>
>>>


Note that the same thing works on Python 2.6

Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print unicode('\u20ac')
\u20ac

This same thing is also discussed on python ml:
http://groups.google.it/group/comp.lang.python/browse_thread/thread/fb42765fe7476fc9/f560b4eaf2b0e3f4?hl=it&pli=1

----------
components: None
messages: 80650
nosy: giampaolo.rodola
severity: normal
status: open
title: Unable to print Unicode characters in Python 3 on Windows
type: crash
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5081>
_______________________________________

From report at bugs.python.org  Tue Jan 27 15:02:46 2009
From: report at bugs.python.org (Olemis Lang)
Date: Tue, 27 Jan 2009 14:02:46 +0000
Subject: [issue5072] urllib.open sends full URL after GET command instead of
	local path
In-Reply-To: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>
Message-ID: <1233064966.64.0.838082272244.issue5072@psf.upfronthosting.co.za>


Olemis Lang <olemis at gmail.com> added the comment:

Actually I am using a proxy hosted in some other machine (i.e. not my 
PC ... sorry, I didnt mention :S ...) I ?debugged? urllib and, when 
branching at this point (see below ;) in URLopener.open_http :

{{{
#!python

# urllib,py

    def open_http(self, url, data=None):
        """Use HTTP protocol."""
        import httplib
        user_passwd = None
        proxy_passwd= None
        if isinstance(url, str):             # Branching here !!!!!!!!!!
            host, selector = splithost(url)
            if host:
                user_passwd, host = splituser(host)
                host = unquote(host)
            realhost = host
        else:
            host, selector = url


}}}

url variable is bound to the following binary tuple 

{{{
#!python

('172.18.2.7:3128', 'http://localhost:8000/trac-dev')
}}}

My IP is 172.18.2.99 ... so the `else` branch is the one being executed 

If you need further details ... dont hesitate and ask anything you 
want ;)

PD: What d'u mean when you said?

> Do you have an HTTP proxy? running at the *same* port? (!)

I dont understand this since *I already said* that *I accessed* my Trac 
environment using my web browser (Opera 9.63, I dont know whether this 
is relevant at all ... ), *I sent you* the lines outputted by tracd to 
stdout (or stderr ... I am not very sure right now ... ;) and *I told 
you* that, once I applied the path *I submitted*, everything was *back 
to normal* ...

I dont understand how could all this be possible if I were running 
tracd and an HTTP proxy in the *same* port, or even in case 
`http_proxy` envvar be set to the hostname + port where my Trac 
instance is listening for incoming connections ... 

Anyway ... CMIIW ...

I also checked that immediately before executing the following 
statements ...

{{{
#!python

# urllib,py

        h = httplib.HTTP(host)
        if data is not None:
            h.putrequest('POST', selector)
            h.putheader('Content-Type', 'application/x-www-form-
urlencoded')
            h.putheader('Content-Length', '%d' % len(data))
        else:
            h.putrequest('GET', selector)

}}}

... `selector` is bound to 'http://localhost:8000/trac-dev' ... BTW the 
`else` clause *is the one executed* in this case, and this is 
consistent with tracd reports *I sent before* and is logical since 
`data` arg *is missing* in the code snippet I sent before.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5072>
_______________________________________

From report at bugs.python.org  Tue Jan 27 15:07:27 2009
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Tue, 27 Jan 2009 14:07:27 +0000
Subject: [issue1293741] doctest runner cannot handle non-ascii characters
Message-ID: <1233065247.98.0.289508330218.issue1293741@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1293741>
_______________________________________

From report at bugs.python.org  Tue Jan 27 15:30:25 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 27 Jan 2009 14:30:25 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1233066625.0.0.0692990190192.issue3892@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've investigated more. I think this is timeout problem. According to 
following site,

http://www.oracle.com/technology/documentation/berkeley-
db/db/api_c/rep_timeout.html

timeout should be specified in microseconds. This means

self.dbenvMaster.rep_set_timeout(db.DB_REP_CONNECTION_RETRY,100123)

only waits 10msec. This is too small comparing to default timeout. 
Probably 10sec is appropriate here.

After I applied an attached patch "fix_timeout.py", I ran test several 
times and found no error.

# I changed time.time()+10 to time.time()+30 because my machine is too 
slow, so 10sec was not enough. :-[

----------
keywords: +patch
Added file: http://bugs.python.org/file12877/fix_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Tue Jan 27 15:37:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Jan 2009 14:37:58 +0000
Subject: [issue5072] urllib.open sends full URL after GET command instead of
	local path
In-Reply-To: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>
Message-ID: <1233067078.24.0.645518792208.issue5072@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I suppose 172.18.2.7:3128 is the address:port of the your proxy, right?
In which case, urllib seems to do the right thing. When talking to an
HTTP proxy, requests are of the form "GET http://site.com/path", rather
than "GET /path". It's up to the proxy to strip the host part of the URL
when forwarding the request to the target server.

(but I suppose tracd could also be more permissive and allow the "GET
http://site.com/path" variant. It seems Apache does)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5072>
_______________________________________

From report at bugs.python.org  Tue Jan 27 15:38:07 2009
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 27 Jan 2009 14:38:07 +0000
Subject: [issue1397474] timeit execution enviroment
Message-ID: <1233067087.63.0.336634087757.issue1397474@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397474>
_______________________________________

From report at bugs.python.org  Tue Jan 27 16:11:53 2009
From: report at bugs.python.org (Olemis Lang)
Date: Tue, 27 Jan 2009 15:11:53 +0000
Subject: [issue5072] urllib.open sends full URL after GET command instead of
	local path
In-Reply-To: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>
Message-ID: <1233069113.37.0.61102954689.issue5072@psf.upfronthosting.co.za>


Olemis Lang <olemis at gmail.com> added the comment:

> Quoting Antoine Pitrou ...

> I suppose 172.18.2.7:3128 is the address:port of the your proxy, 
right?

Yes ...

> In which case, urllib seems to do the right thing. When talking to an
HTTP proxy, requests are of the form "GET http://site.com/path", rather
than "GET /path". It's up to the proxy to strip the host part of the URL
when forwarding the request to the target server.

This being said ... 

> (but I suppose tracd could also be more permissive and allow the "GET
http://site.com/path" variant. It seems Apache does)

... It works with Apache (I am talking about trac once again ...) 
therefore I will report this issue to Trac devs instead ...

Thnx a lot ! Sorry if I caused you any trouble ...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5072>
_______________________________________

From report at bugs.python.org  Tue Jan 27 17:31:37 2009
From: report at bugs.python.org (Akira Kitada)
Date: Tue, 27 Jan 2009 16:31:37 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1233073897.33.0.205786302845.issue1180@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Any update?
Is this patch going to be included in 2.6.x/3.0.x in near future?

----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
_______________________________________

From report at bugs.python.org  Tue Jan 27 17:38:08 2009
From: report at bugs.python.org (Andrea Corbellini)
Date: Tue, 27 Jan 2009 16:38:08 +0000
Subject: [issue5082] Let frameworks to register attributes as builtins
In-Reply-To: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>
Message-ID: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>


New submission from Andrea Corbellini <andrea.corbellini at beeseek.org>:

Most of the Python frameworks have some functions and classes that are
widely used. For example a 'log.debug' function will be used in almost
all modules. It is inconvenient to write 'import log' every time.

It would be useful to have a special place (a dict or a special module)
where you can declare attributes that can be used everywhere without
importing anything. Currently, the only way to do this is:

>>> import __builtin__
>>> __builtin__.debug = log.debug

However, I think that this shouldn't be the better solution. Using
something like '__framework__' would be really better, in my opinion.

----------
components: Interpreter Core
messages: 80656
nosy: andrea-bs
severity: normal
status: open
title: Let frameworks to register attributes as builtins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5082>
_______________________________________

From report at bugs.python.org  Tue Jan 27 17:38:25 2009
From: report at bugs.python.org (Andrea Corbellini)
Date: Tue, 27 Jan 2009 16:38:25 +0000
Subject: [issue5082] Let frameworks to register attributes as builtins
In-Reply-To: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>
Message-ID: <1233074305.15.0.967637986176.issue5082@psf.upfronthosting.co.za>


Changes by Andrea Corbellini <andrea.corbellini at beeseek.org>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5082>
_______________________________________

From report at bugs.python.org  Tue Jan 27 17:50:41 2009
From: report at bugs.python.org (John Levon)
Date: Tue, 27 Jan 2009 16:50:41 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1233075041.74.0.790174287484.issue4111@psf.upfronthosting.co.za>


Changes by John Levon <movement at users.sourceforge.net>:


----------
nosy: +movement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Jan 27 17:55:40 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Jan 2009 16:55:40 +0000
Subject: [issue5082] Let frameworks to register attributes as builtins
In-Reply-To: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>
Message-ID: <1233075340.36.0.383795339968.issue5082@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Please, don't do that! Why not using "from framework import debug"? 
Working example: "from logging import debug". I hate namespace 
polution and all global symbols.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5082>
_______________________________________

From report at bugs.python.org  Tue Jan 27 18:09:05 2009
From: report at bugs.python.org (Andrea Corbellini)
Date: Tue, 27 Jan 2009 17:09:05 +0000
Subject: [issue5082] Let frameworks to register attributes as builtins
In-Reply-To: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>
Message-ID: <1233076145.3.0.690038078811.issue5082@psf.upfronthosting.co.za>


Andrea Corbellini <andrea.corbellini at beeseek.org> added the comment:

Well, writing every time 'from X import Y' looks to me uncomfortable.
But of course what I'm asking is not essential :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5082>
_______________________________________

From report at bugs.python.org  Tue Jan 27 18:10:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 27 Jan 2009 17:10:38 +0000
Subject: [issue5082] Let frameworks to register attributes as builtins
In-Reply-To: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>
Message-ID: <1233076238.99.0.877555871629.issue5082@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Not being able to figure out where a name came from easily is worse than
having to type out the import statement.  This feature would negatively
impact readability of Python source significantly.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5082>
_______________________________________

From report at bugs.python.org  Tue Jan 27 18:35:39 2009
From: report at bugs.python.org (James Cooper)
Date: Tue, 27 Jan 2009 17:35:39 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1233077739.37.0.380059664237.issue2047@psf.upfronthosting.co.za>


James Cooper <james.cooper at solidodesign.com> added the comment:

Our company recently rediscovered this bug in 2.5.2.  After a couple
hours of debugging, we realized the error message was incorrect and
found the bug in the destinsrc function.

This may not be a show-stopping bug, but it's non-obvious, annoying,
unnecessary, and very easy to fix.  Any chance of getting this into a
release?

----------
nosy: +jamescooper

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Tue Jan 27 18:39:46 2009
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 27 Jan 2009 17:39:46 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1233077739.37.0.380059664237.issue2047@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0901270939t6d605b15j320bb16e2396396a@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Tue, Jan 27, 2009 at 12:35 PM, James Cooper <report at bugs.python.org> wrote:
> This may not be a show-stopping bug, but it's non-obvious, annoying,
> unnecessary, and very easy to fix.  Any chance of getting this into a
> release?

Considering that the issue is idle for such a long time, I am not sure
if any one will check this in. Your best bet may be to bring this up
on python-dev. As you say, the problem is obvious and the fix is
simple.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Tue Jan 27 18:47:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 27 Jan 2009 17:47:02 +0000
Subject: [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233050257.64.0.716100380567.issue5076@psf.upfronthosting.co.za>
Message-ID: <497F4893.5000909@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Good question!  I'm not really aware of the complexities involved in
> merging between the various branches, but given the fairly trivial
> nature of the patch I figured there were potential advantages in both
> identical source and stubs.  I'm happy to work the patch into either
> #ifdef based (ie, identical source, different stubs), or "unconditional"
> (both source and stubs different) if you prefer - and if so, which of
> those 2 do you prefer?

It's still possible to merge changes reasonably even if the "target"
(i.e. py3k) differs slightly from the source. Therefore, I think the 3k
version should unconditionally only support python3x.dlls. IOW, let
the sources diverge (for sake of simplicity of each individual source).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5076>
_______________________________________

From report at bugs.python.org  Tue Jan 27 18:53:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 27 Jan 2009 17:53:06 +0000
Subject: [issue5075] bdist_wininst should not depend on the vc runtime?
In-Reply-To: <1233051298.16.0.507192531319.issue5075@psf.upfronthosting.co.za>
Message-ID: <497F49FD.8060306@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> My apologies for not being more on top of this, but I couldn't find the
> answer in the developer FAQ.  This question applies to issue 4566 and
> will partially apply to issue 5076.  The patches are against the trunk -
> after checking in, what action should I take to ensure it is merged to
> 2.6 and 3.x?  I'm happy to manually merge and checkin to those branches
> if appropriate; if so, should I check it into branches/release30-maint
> as well as branches/py3k?

If you want to backport the changes yourself, you should run
svnmerge.py; not sure how well this works on Windows, though (it invokes
an svn binary). The merge flow would be

  trunk -> release26-maint
       \-> py3k -> release30-maint

It's important to use svnmerge only, so that the merge tracking
properties are right.

In 2.6, do "svnmerge.py merge -r<rev>", then "svn commit -F
svnmerge-<tab>". In 3k, do the same, although you might have
to recompile the stubs in-between in case there are merge
conflicts on the binary files. In 3.0, do the same, but you
need to "svn revert .", because there will be merge conflicts
on ".".

If you don't want to perform all these operations, let me know,
and I'll do them.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5075>
_______________________________________

From report at bugs.python.org  Tue Jan 27 19:03:29 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 27 Jan 2009 18:03:29 +0000
Subject: [issue1754] WindowsError messages are not properly encoded
In-Reply-To: <1199705072.7.0.841408898872.issue1754@psf.upfronthosting.co.za>
Message-ID: <1233079409.19.0.662555892122.issue1754@psf.upfronthosting.co.za>


Changes by Ulrich Eckhardt <eckhardt at satorlaser.com>:


----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754>
_______________________________________

From report at bugs.python.org  Tue Jan 27 19:08:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 18:08:16 +0000
Subject: [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1233079696.47.0.283847509225.issue5048@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Correction to earlier statement.  It should have read:

Guido disallowed returning a len method on iterators.  He expected
bool(it) to be always be True.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5048>
_______________________________________

From report at bugs.python.org  Tue Jan 27 19:13:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 27 Jan 2009 18:13:02 +0000
Subject: [issue5081] Unable to print Unicode characters in Python 3 on Windows
In-Reply-To: <1233060719.46.0.922217803692.issue5081@psf.upfronthosting.co.za>
Message-ID: <1233079982.02.0.258320875432.issue5081@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Your 2.6 example is incorrect. Try

py> print u'\u20ac'

If you want the 3.0 equivalent of your 2.6 code: it is

py> print(r'\u20ac')
\u20ac

Closing this as "works for me".

----------
nosy: +loewis
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5081>
_______________________________________

From report at bugs.python.org  Tue Jan 27 19:25:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 27 Jan 2009 18:25:07 +0000
Subject: [issue5082] Let frameworks to register attributes as builtins
In-Reply-To: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>
Message-ID: <1233080707.91.0.119134080189.issue5082@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I agree that this shouldn't be added to Python. At a minimum, it is
clear that there is too much opposition to such a feature that the bug
tracker is an inappropriate medium to discuss it.

If you want to pursue this idea, discuss it on python-ideas, and, if
this shows sufficient interest in the feature, write a PEP.

----------
nosy: +loewis
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5082>
_______________________________________

From report at bugs.python.org  Tue Jan 27 19:31:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Jan 2009 18:31:44 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233081104.51.0.35975929784.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stage 1 committed in r69025 (py3k) and r69026 (release30-maint).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Tue Jan 27 19:39:19 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Tue, 27 Jan 2009 18:39:19 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1233081559.92.0.878453594434.issue874900@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Tue Jan 27 21:30:21 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 27 Jan 2009 20:30:21 +0000
Subject: [issue5083] New resource ('gui') for regrtest
In-Reply-To: <1233088221.56.0.688581339016.issue5083@psf.upfronthosting.co.za>
Message-ID: <1233088221.56.0.688581339016.issue5083@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

I would like to add a 'gui' resource in regrtest, this would be nice for
the ttk module that I'm planning to do add very soon (after I solve
another issue about tests).

----------
components: Tests
files: regrtest_gui_resource.diff
keywords: patch
messages: 80668
nosy: gpolo
severity: normal
status: open
title: New resource ('gui') for regrtest
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12878/regrtest_gui_resource.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5083>
_______________________________________

From report at bugs.python.org  Tue Jan 27 21:56:02 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Jan 2009 20:56:02 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233089762.46.0.927246014342.issue4707@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12407/round_int_int.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Tue Jan 27 21:56:06 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Jan 2009 20:56:06 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233089766.49.0.16709201215.issue4707@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12412/round_int_int2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Tue Jan 27 21:56:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Jan 2009 20:56:10 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233089770.3.0.698320995845.issue4707@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12414/round_int_int3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Tue Jan 27 21:56:13 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Jan 2009 20:56:13 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233089773.86.0.208426643515.issue4707@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12415/round_int_int4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Tue Jan 27 22:16:17 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Jan 2009 21:16:17 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1233090977.45.0.0202967362871.issue3997@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11841/zip-64k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Tue Jan 27 22:16:24 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Jan 2009 21:16:24 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1233090984.19.0.0435305110553.issue3997@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11850/zip-64k-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Tue Jan 27 22:40:52 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 27 Jan 2009 21:40:52 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233092452.39.0.102355317587.issue4753@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I'll take on the two remaining tasks for this:

* add configure magic to detect when the compiler supports this so
  that it can default to --with-computed-gotos on modern systems.
* commit the back port to 2.7 trunk.

----------
assignee:  -> gregory.p.smith
status: pending -> open
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Tue Jan 27 22:52:20 2009
From: report at bugs.python.org (Jake McGuire)
Date: Tue, 27 Jan 2009 21:52:20 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>


New submission from Jake McGuire <jake at youtube.com>:

Instance attribute names are normally interned - this is done in 
PyObject_SetAttr (among other places).  Unpickling (in pickle and 
cPickle) directly updates __dict__ on the instance object.  This 
bypasses the interning so you end up with many copies of the strings 
representing your attribute names, which wastes a lot of space, both in 
RAM and in pickles of sequences of objects created from pickles.  Note 
that the native python memcached client uses pickle to serialize 
objects.

>>> import pickle
>>> class C(object):
...   def __init__(self, x):
...     self.long_attribute_name = x
...
>>> len(pickle.dumps([pickle.loads(pickle.dumps(C(None), 
pickle.HIGHEST_PROTOCOL)) for i in range(100)], 
pickle.HIGHEST_PROTOCOL))
3658
>>> len(pickle.dumps([C(None) for i in range(100)], 
pickle.HIGHEST_PROTOCOL))
1441
>>>

Interning the strings on unpickling makes the pickles smaller, and at 
least for cPickle actually makes unpickling sequences of many objects 
slightly faster.  I have included proposed patches to cPickle.c and 
pickle.py, and would appreciate any feedback.

----------
components: Library (Lib)
files: cPickle.c.diff
keywords: patch
messages: 80670
nosy: jakemcguire
severity: normal
status: open
title: unpickling does not intern attribute names
type: resource usage
Added file: http://bugs.python.org/file12879/cPickle.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Tue Jan 27 22:52:58 2009
From: report at bugs.python.org (Jake McGuire)
Date: Tue, 27 Jan 2009 21:52:58 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233093178.33.0.941263356353.issue5084@psf.upfronthosting.co.za>


Changes by Jake McGuire <jake at youtube.com>:


Added file: http://bugs.python.org/file12880/pickle.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:05:27 2009
From: report at bugs.python.org (Ted Leung)
Date: Tue, 27 Jan 2009 22:05:27 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1232920814.99.0.846885162975.issue4111@psf.upfronthosting.co.za>
Message-ID: <FB45C73D-4CAF-4062-A118-BB302CECAC8E@sauria.com>


Ted Leung <twl at sauria.com> added the comment:

I tried building this on my Mac and got this;

ar cr libpython2.7.a Python/_warnings.o Python/Python-ast.o Python/ 
asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/ 
compile.o Python/codecs.o Python/errors.o Python/frozen.o Python/ 
frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o  
Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/ 
graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/ 
modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o  
Python/pyarena.o Python/pyfpe.o Python/pymath.o Python/pystate.o  
Python/pythonrun.o Python/structmember.o Python/symtable.o Python/ 
sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o  
Python/pystrtod.o Python/formatter_unicode.o Python/formatter_string.o  
Python/dynload_shlib.o @DTRACEOBJS@  Python/mactoolboxglue.o Python/ 
thread.o
ar: @DTRACEOBJS@: No such file or directory
make: *** [libpython2.7.a] Error 1

my configure line was:

./configure --enable-framework --enable-toolbox-glue --with-threads -- 
enable-dtrace

On Jan 25, 2009, at 2:00 PM, Skip Montanaro wrote:

>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> Here's a patch against the current trunk (2.7) which compiles on my  
> Mac.  It
> adds a --with-dtrace configure option.  The code checks to see if  
> the -G
> option is understood by the dtrace command.  If so, dtrace support  
> is added
> Sun-style.  If not we do things Apple's way.
>
> The existing test cases pass on Apple except for one case in  
> test_sys which
> tries to confirm the size of a frame object.  I added an #ifdef  
> WITH_DTRACE
> around the extra slot but there is no way of telling from Python  
> code that
> this extra slot is there.  That would have to somehow be exposed to  
> the
> Python programmer so the test can be adjusted.  All tests pass when
> --with-dtrace is omitted.  I have not yet tried this on Solaris.  I  
> will try
> to get to it this week if someone doesn't beat me to it.
>
> There are as yet no new dtrace test cases so I can't confirm that  
> the added
> dtrace support actually works.  There are also no documentation  
> updates.
> Unlike most compile options this adds a significant new feature to the
> runtime environment so some documentation changes are probably  
> called for.
>
> Added file: http://bugs.python.org/file12861/dtrace.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4111>
> _______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:27:55 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 27 Jan 2009 22:27:55 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1233095275.43.0.347890442156.issue3997@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Amaury, did the buildbots verify this worked and thus this bug can be
closed?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:31:53 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Jan 2009 22:31:53 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233095513.24.0.816786205929.issue4707@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Someone ought to ping Guido on this.  He may have some strong thoughts
on the signature (having it sometimes return ints and sometimes floats).
 But in this case, accuracy may be the more important consideration.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:33:35 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 27 Jan 2009 22:33:35 +0000
Subject: [issue5085] distutils/test_sdist failure on windows
In-Reply-To: <1233095615.15.0.606843588925.issue5085@psf.upfronthosting.co.za>
Message-ID: <1233095615.15.0.606843588925.issue5085@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

test_sdist fails on windows with following message.

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%
20trunk/builds/1823/step-test/0

======================================================================
ERROR: test_make_distribution (distutils.tests.test_sdist.sdistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\distutils\tests\test_sdist.py", line 119, in 
test_make_distribution
    spawn('tar --help')
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\distutils\spawn.py", line 37, in spawn
    _spawn_nt(cmd, search_path, dry_run=dry_run)
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\distutils\spawn.py", line 70, in _spawn_nt
    cmd = _nt_quote_args(cmd)
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\distutils\spawn.py", line 61, in _nt_quote_args
    args[i] = '"%s"' % args[i]
TypeError: 'str' object does not support item assignment

////////////////////////////////////

This can be fixed if replace
  spawn('tar --help')
in Lib/distutils/tests/test_sdist.py with
  spawn(['tar', '--help'])
but, "tar --help" outputs very long message, it is not beautiful.

So I'll push attached patch. (This also checks gzip
which requres to run test)

----------
components: Tests
files: test_sdist_on_win32.patch
keywords: patch
messages: 80674
nosy: ocean-city
severity: normal
status: open
title: distutils/test_sdist failure on windows
versions: Python 2.7
Added file: http://bugs.python.org/file12881/test_sdist_on_win32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5085>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:37:18 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 22:37:18 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1233095838.2.0.571672600199.issue4566@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:39:38 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 22:39:38 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1233095978.94.0.793910421281.issue4566@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

ack - I mis-clicked and accidentally removed message78811 and can't see
how to reinstate it.  The message isn't critical, but I'm sorry about that!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:42:53 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Jan 2009 22:42:53 +0000
Subject: [issue5077] 2to3 fixer for the removal of operator functions
In-Reply-To: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>
Message-ID: <1233096173.37.0.678606241147.issue5077@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Review:

The mappings should become static to the class or module.

The repeat2mul case doesn't handle prefixes.

----------
nosy: +benjamin.peterson
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5077>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:46:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 27 Jan 2009 22:46:34 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1230908781.42.0.375234888778.issue4566@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I haven't been able to try this patch myself yet, but I see a potential
problem:  the "cookie" variable is declared as a DWORD, while
ActivateActCtx expects a ULONG_PTR. DWORD and ULONG_PTR are only the
same thing in 32-bit Windows.

Also, where are you seeing that these SxS functions are "Vista or
later"?  My XP kernel32.dll has all of them.  MSDN says they're XP or Vista.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Tue Jan 27 23:58:45 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 22:58:45 +0000
Subject: [issue5079] time.ctime docs refer to "time tuple" for default
In-Reply-To: <1233054577.95.0.996547748761.issue5079@psf.upfronthosting.co.za>
Message-ID: <1233097125.66.0.963765775081.issue5079@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

It's already fixed in 2.6, 2.7 and 3.0
I'm unsure of 2.5 status regarding documentation updates.

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +gagenellina, georg.brandl
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5079>
_______________________________________

From report at bugs.python.org  Wed Jan 28 00:30:07 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 27 Jan 2009 23:30:07 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233099007.52.0.419220036756.issue5084@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Either my browser got crazy, or you uploaded the same patch (.py) twice.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Wed Jan 28 00:38:47 2009
From: report at bugs.python.org (Jake McGuire)
Date: Tue, 27 Jan 2009 23:38:47 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233099527.01.0.775254409243.issue5084@psf.upfronthosting.co.za>


Changes by Jake McGuire <jake at youtube.com>:


Removed file: http://bugs.python.org/file12879/cPickle.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Wed Jan 28 00:39:02 2009
From: report at bugs.python.org (Jake McGuire)
Date: Tue, 27 Jan 2009 23:39:02 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233099542.46.0.0005593235355.issue5084@psf.upfronthosting.co.za>


Changes by Jake McGuire <jake at youtube.com>:


Added file: http://bugs.python.org/file12882/cPickle.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Wed Jan 28 00:39:53 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 27 Jan 2009 23:39:53 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <FB45C73D-4CAF-4062-A118-BB302CECAC8E@sauria.com>
Message-ID: <18815.36772.289014.489189@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Ted> I tried building this on my Mac and got this;

Forgive me if I'm preaching to the choir here.

Did you run autoconf or autoreconf after applying the patch?  If not,
@DTRACEOBJS@ would not be a substitutable string.  It's fairly common (at
least in the Python community) to omit modified configure scripts from these
sorts of patches because the changes to generated configure scripts between
different versions of autoconf are so massive that they dwarf the actual
functional changes in the patch, often by a couple orders of magnitude.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Jan 28 00:52:47 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 23:52:47 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1233100367.2.0.85344940126.issue4566@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Checked in to the trunk as as r69038 and svnmerge'd:
* release26-maint as 69040
* py3k as 69041
* release30-maint as 69043

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Wed Jan 28 01:03:18 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 28 Jan 2009 00:03:18 +0000
Subject: [issue4706] try to build a C module,
	but don't worry if it doesn't work
In-Reply-To: <1229782192.75.0.491587462854.issue4706@psf.upfronthosting.co.za>
Message-ID: <1233100998.57.0.28577423806.issue4706@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Tarek:

Yes, failure to build an extension module for any reason should
definitely cause "build" to fail by default.  However, many Python
packages seem to come with optional extension modules, typically for a
performance speed-up.  simplejson, zope.interface, and twisted all do
this (these are three packages that allmydata-tahoe depends on).  My own
pyutil package used to do this, but I eventually just removed the
optional C extension module in order to avoid this problem.  So, for
those it would be good if the package setup.py could specify that an
extension module is optional and that failure to build it for any reason
does not mean failure of the "build".

Note that twisted's setup.py already attempts to do this for certain of
its extension modules, and if I understand correctly it is able to
detect and handle failure to build if gcc fails, but not if gcc is absent.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4706>
_______________________________________

From report at bugs.python.org  Wed Jan 28 01:25:08 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 28 Jan 2009 00:25:08 +0000
Subject: [issue4706] try to build a C module,
	but don't worry if it doesn't work
In-Reply-To: <1229782192.75.0.491587462854.issue4706@psf.upfronthosting.co.za>
Message-ID: <1233102308.03.0.997289510116.issue4706@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

As far as Twisted is concerned, the two cases Tarek mentioned aren't
really relevant.  In order for Zooko's use case to be handled ("install
Twisted on an OLPC"), what would be ideal is if there were a way to tell
distutils about an extension which is optional.  It doesn't matter if it
can be built or not.  Any failure is irrelevant.

This doesn't necessarily have to mean that errors pass silently.  The
build failure can still be reported.  The build could even fail by
default and distutils could gain a new option for switching the behavior
to succeeding if only optional extensions fail to build.  Or it could be
the other way around, with an option to make the build fail if any
optional extensions cannot be built (this approach favors people who
don't really know what a "build" is and just want something installed,
leaving the more advanced option to people who are able to figure out
that there are options that control build behavior).

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4706>
_______________________________________

From report at bugs.python.org  Wed Jan 28 01:38:42 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 28 Jan 2009 00:38:42 +0000
Subject: [issue5072] urllib.open sends full URL after GET command instead of
	local path
In-Reply-To: <1233064966.64.0.838082272244.issue5072@psf.upfronthosting.co.za>
Message-ID: <364081.18241.qm@web32806.mail.mud.yahoo.com>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

> > Do you have an HTTP proxy? running at the *same* port?
> (!)
> 
> I dont understand this since *I already said* that *I
> accessed* my Trac 
> environment using my web browser (Opera 9.63, I dont know
> whether this 
> is relevant at all ... ), *I sent you* the lines outputted
> by tracd to 
> stdout (or stderr ... I am not very sure right now ... ;)
> and *I told 
> you* that, once I applied the path *I submitted*,
> everything was *back 
> to normal* ...

If you had configured a proxy at localhost:8000, and *also* a Trac instance at that port, and Trac had "won the race" for the port, then you would observe exactly the symthoms you describe. That is, urllib talking to 8000 as it were a proxy, and the Trac instance actually there getting confused.

Your patch, as you surely understand now, is not correct; in fact, the code is OK as it is. urllib builds the request in that specific way *because* he thinks there is a proxy. If the proxy is buggy, misconfigured, or inexistent, it's not the library's fault :)

-- 
Gabriel Genellina
> 
> I dont understand how could all this be possible if I were
> running 
> tracd and an HTTP proxy in the *same* port, or even in case
> 
> `http_proxy` envvar be set to the hostname + port where my
> Trac 
> instance is listening for incoming connections ... 
> 
> Anyway ... CMIIW ...
> 
> I also checked that immediately before executing the
> following 
> statements ...
> 
> {{{
> #!python
> 
> # urllib,py
> 
>         h = httplib.HTTP(host)
>         if data is not None:
>             h.putrequest('POST', selector)
>             h.putheader('Content-Type',
> 'application/x-www-form-
> urlencoded')
>             h.putheader('Content-Length',
> '%d' % len(data))
>         else:
>             h.putrequest('GET', selector)
> 
> }}}
> 
> ... `selector` is bound to
> 'http://localhost:8000/trac-dev' ... BTW the 
> `else` clause *is the one executed* in this case, and this
> is 
> consistent with tracd reports *I sent before* and is
> logical since 
> `data` arg *is missing* in the code snippet I sent before.
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5072>
> _______________________________________

      Yahoo! Cocina
Recetas pr?cticas y comida saludable
http://ar.mujer.yahoo.com/cocina/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5072>
_______________________________________

From report at bugs.python.org  Wed Jan 28 01:52:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Jan 2009 00:52:02 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233103922.76.0.478238606648.issue4707@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido, do you have any thoughts on this?

Basically, it's a choice between giving round() a weird signature
(sometimes returning floats and sometimes int/longs) versus having
accurate roundings of integers (which become unrepresentable when
divided by powers of 10.0).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 02:24:57 2009
From: report at bugs.python.org (Michael Newman)
Date: Wed, 28 Jan 2009 01:24:57 +0000
Subject: [issue5086] set_daemon does not exist in Thread
In-Reply-To: <1233105897.35.0.794946960861.issue5086@psf.upfronthosting.co.za>
Message-ID: <1233105897.35.0.794946960861.issue5086@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

This is related to:
http://bugs.python.org/issue3628
http://bugs.python.org/issue4808

I found in the example at the bottom of:
http://docs.python.org/3.0/library/queue.html
"t.set_daemon(True)"
won't work.

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from threading import Thread
>>> t = Thread()
>>> dir(t)
['_Thread__exc_info', '_Thread__initialized', '__class__',
'__delattr__', '__dic
t__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__gt__',
 '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
'__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
'__str__
', '__subclasshook__', '__weakref__', '_args', '_block', '_bootstrap',
'_bootstr
ap_inner', '_daemonic', '_delete', '_ident', '_initialized', '_kwargs',
'_name',
 '_note', '_set_daemon', '_started', '_stderr', '_stop', '_stopped',
'_target',
'_verbose', 'daemon', 'getName', 'ident', 'isAlive', 'isDaemon',
'is_alive', 'jo
in', 'name', 'run', 'setDaemon', 'setName', 'start']
>>> t.set_daemon(True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Thread' object has no attribute 'set_daemon'
>>> t.daemon
False
# This appears to be the proper method, unless "set_daemon" gets added
in (or setDaemon is used, but that appears to be depreciated syntax):
>>> t.daemon = True
>>> t.daemon
True

Please see the attached "queue_join.py" for my own working example. It
would be helpful to include the line:
>>> from threading import Thread
in the official example.

----------
assignee: georg.brandl
components: Documentation
files: queue_join.py
messages: 80685
nosy: georg.brandl, mnewman
severity: normal
status: open
title: set_daemon does not exist in Thread
versions: Python 3.0
Added file: http://bugs.python.org/file12883/queue_join.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5086>
_______________________________________

From report at bugs.python.org  Wed Jan 28 02:25:30 2009
From: report at bugs.python.org (Michael Newman)
Date: Wed, 28 Jan 2009 01:25:30 +0000
Subject: [issue5087] set_daemon does not exist in Thread
In-Reply-To: <1233105930.75.0.986865589873.issue5087@psf.upfronthosting.co.za>
Message-ID: <1233105930.75.0.986865589873.issue5087@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

This is related to:
http://bugs.python.org/issue3628
http://bugs.python.org/issue4808

I found in the example at the bottom of:
http://docs.python.org/3.0/library/queue.html
"t.set_daemon(True)"
won't work.

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from threading import Thread
>>> t = Thread()
>>> dir(t)
['_Thread__exc_info', '_Thread__initialized', '__class__',
'__delattr__', '__dic
t__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__gt__',
 '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
'__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
'__str__
', '__subclasshook__', '__weakref__', '_args', '_block', '_bootstrap',
'_bootstr
ap_inner', '_daemonic', '_delete', '_ident', '_initialized', '_kwargs',
'_name',
 '_note', '_set_daemon', '_started', '_stderr', '_stop', '_stopped',
'_target',
'_verbose', 'daemon', 'getName', 'ident', 'isAlive', 'isDaemon',
'is_alive', 'jo
in', 'name', 'run', 'setDaemon', 'setName', 'start']
>>> t.set_daemon(True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Thread' object has no attribute 'set_daemon'
>>> t.daemon
False
# This appears to be the proper method, unless "set_daemon" gets added
in (or setDaemon is used, but that appears to be depreciated syntax):
>>> t.daemon = True
>>> t.daemon
True

Please see the attached "queue_join.py" for my own working example. It
would be helpful to include the line:
>>> from threading import Thread
in the official example.

----------
assignee: georg.brandl
components: Documentation
files: queue_join.py
messages: 80686
nosy: georg.brandl, mnewman
severity: normal
status: open
title: set_daemon does not exist in Thread
versions: Python 3.0
Added file: http://bugs.python.org/file12884/queue_join.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5087>
_______________________________________

From report at bugs.python.org  Wed Jan 28 03:17:49 2009
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 28 Jan 2009 02:17:49 +0000
Subject: [issue5075] bdist_wininst should not depend on the vc runtime?
In-Reply-To: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>
Message-ID: <1233109069.05.0.874307272319.issue5075@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Thanks for the merging advice!

The patch to the build system is indeed trivial - unfortunately it also
failed to work correctly due to install.c using freopen, a CRT function,
to redirect the output.  Interestingly, this probably means that if
someone attempted to use python 2.6 to create a pure-python .exe
installer, they would fail to see any output when installed to earlier
Python versions (and vice-versa...)

I've worked up a patch for install.c which uses the win32 API to achieve
the same result using SetStdHandle() etc.  This technique requires the
handles to be redirected before the Python DLL is loaded, so I took the
opportunity to refactor things a little - we now have 2 locations that
perform the redirection instead of 3 but I didn't see huge benefit in
trying to knock that down to 1.

The patch is against the trunk but should also be applied to 2.6 and the
3.x branches.  I've tested the new code-paths using a 32bit trunk build
only but it should work the same everywhere.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file12885/bug-5075.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5075>
_______________________________________

From report at bugs.python.org  Wed Jan 28 03:54:54 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 28 Jan 2009 02:54:54 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233111294.82.0.529841196863.issue5084@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The patch for cPickle doesn't do the same thing as the pickle one. In
the cPickle one, you are only interning slot attributes, which, I
believe, is not what you intended. :-)

----------
assignee:  -> alexandre.vassalotti
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Wed Jan 28 04:00:03 2009
From: report at bugs.python.org (Jake McGuire)
Date: Wed, 28 Jan 2009 03:00:03 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233111294.82.0.529841196863.issue5084@psf.upfronthosting.co.za>
Message-ID: <47161827-5844-427F-BFCE-1CD5BF742164@youtube.com>


Jake McGuire <jake at youtube.com> added the comment:

Are you sure?  I may not have enough context in my diff, which I  
should have done against an anonymous svn checkout, but it looks like  
the slot attributes get set several lines after my diff.  "while  
(PyDict_Next(slotstate, ...))" as opposed to the "while  
(PyDict_Next(state, ...))" in my change...

-jake

On Jan 27, 2009, at 6:54 PM, Alexandre Vassalotti wrote:

>
> Alexandre Vassalotti <alexandre at peadrop.com> added the comment:
>
> The patch for cPickle doesn't do the same thing as the pickle one. In
> the cPickle one, you are only interning slot attributes, which, I
> believe, is not what you intended. :-)
>
> ----------
> assignee:  -> alexandre.vassalotti
> nosy: +alexandre.vassalotti
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5084>
> _______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Wed Jan 28 04:03:11 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 28 Jan 2009 03:03:11 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233111791.24.0.00716258804502.issue5084@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Oh, you are right. I was looking at py3k's version of pickle, which uses
PyDict_Update instead of a while loop; that is why I got confused.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Wed Jan 28 04:06:40 2009
From: report at bugs.python.org (Ted Leung)
Date: Wed, 28 Jan 2009 03:06:40 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <18815.36772.289014.489189@montanaro.dyndns.org>
Message-ID: <7F9F5F12-24D1-4545-A72D-5E177EE5B7DB@sauria.com>


Ted Leung <twl at sauria.com> added the comment:

I didn't run auto(re)conf.  After I did that, all was well.  However,  
the ustack provider doesn't appear to be working correctly.   I tried  
running the py_profile.d from the DTrace toolkit, and it doesn't show  
any stack traces, and when the script starts up it says

cc1: warning: /dev/fd/5 is shorter than expected

The basic function entry/exit probes appear to be working.

John +nosy'ed himself, so perhaps he'll have some insight?

On Jan 27, 2009, at 3:39 PM, Skip Montanaro wrote:

>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> Ted> I tried building this on my Mac and got this;
>
> Forgive me if I'm preaching to the choir here.
>
> Did you run autoconf or autoreconf after applying the patch?  If not,
> @DTRACEOBJS@ would not be a substitutable string.  It's fairly  
> common (at
> least in the Python community) to omit modified configure scripts  
> from these
> sorts of patches because the changes to generated configure scripts  
> between
> different versions of autoconf are so massive that they dwarf the  
> actual
> functional changes in the patch, often by a couple orders of  
> magnitude.
>
> Skip
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4111>
> _______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Jan 28 04:31:59 2009
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 28 Jan 2009 03:31:59 +0000
Subject: [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>
Message-ID: <1233113519.87.0.0592630975006.issue5076@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Attaching an updated patch against the py3k branch which makes no
attempt to work on py2k.

Added file: http://bugs.python.org/file12886/wininst_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5076>
_______________________________________

From report at bugs.python.org  Wed Jan 28 04:39:29 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Jan 2009 03:39:29 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233113969.24.0.0366088752743.issue4707@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think it's fine if it returns an int iff the first arg is an int.  In
other languages this would be overloaded as follows:

round(int)int
round(float)float
round(int, int)int
round(float, int)float

----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 04:45:25 2009
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 28 Jan 2009 03:45:25 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233114325.2.0.0422156047594.issue4707@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

I'd prefer round(x,positive_integer) return float.  Returning int is a 
bit of a lie, except that the decimal module is available to avoid this 
sort of lie.

For non-positive integer roundings I'd like an integer return.

In my opinion, we'd benefit from this definition of round:


import numbers

def round(a,p=0,base=10):
    '''
        >>> round(147,-1,5)
        145.0
        >>> round(143,-1,5)
        145.0
        >>> round(142,-1,5)
        140.0
        >>> round(12.345,1,2)
        12.5
        >>> round(12.345,2,2)
        12.25
        >>> round(12.345,-2,2)
        12
        >>> round(12.345,-3,2)
        16
    '''
    # consider using sign transfer for negative a

    if base < 1:
        raise ValueError('base too confusing')

    require_integral_output = (
        (p < 1) and
        isinstance(base, numbers.Integral) and
        isinstance(p, numbers.Integral))

    b = base**p
    result = int(a*b+0.5)/b
    if require_integral_output:
        result = int(0.5+result)
    return result

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 04:56:15 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Jan 2009 03:56:15 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233114975.86.0.872865778403.issue4707@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Well, that would leave a function whose return *type* depends on the
*value* of one of the arguments, which I find very ugly.

I don't know why you think rounding an int to X (X>0) digits after the
decimal point should return a float -- it's not like the int has any
digits behind the point, so nothing is gained. Why would it be a lie?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 05:15:21 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Jan 2009 04:15:21 +0000
Subject: [issue5086] set_daemon does not exist in Thread
In-Reply-To: <1233105897.35.0.794946960861.issue5086@psf.upfronthosting.co.za>
Message-ID: <1233116121.6.0.381487814358.issue5086@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> set_daemon does not exist in Thread

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5086>
_______________________________________

From report at bugs.python.org  Wed Jan 28 05:19:53 2009
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 28 Jan 2009 04:19:53 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233116393.77.0.557647144894.issue4707@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

The value of one of the arguments controls how many digits there are.

Certainly if you rounded $10 to the nearest cents you'd expect $10.00.
Thus round(10,2) should be 10.00.  Without using decimal module, the 
best we can do is produce  10.0.

I'd apply a similar argument to convince you that the return value 
should be integral for negative "number of digits".

Hark!  This is python.  We can take this correct and beautiful approach.  
We are not constrainded by function signatures of c++ or FORTRAN90.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 05:26:24 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Jan 2009 04:26:24 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233116784.19.0.880187786226.issue4707@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm sorry, but I don't see a significant difference between $10 and
$10.00.  If you want to display a certain number of digits, use "%.2f" %
x.  And trust me, I'm not doing this for Fortran's sake.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 08:29:52 2009
From: report at bugs.python.org (Neal Norwitz)
Date: Wed, 28 Jan 2009 07:29:52 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1233127792.11.0.598145006753.issue5023@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Can you debug this problem any further?  What is the C call stack?  Does
the problem occur if you build in debug mode (./configure
--with-pydebug)?  Does the problem occur with a different compiler (if
you have access to another one on the same box)?

----------
nosy: +nnorwitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5023>
_______________________________________

From report at bugs.python.org  Wed Jan 28 09:53:17 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Jan 2009 08:53:17 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233132797.09.0.424038984918.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Can anyone who uses tkinter give me some advice?  Does PyTclObject in 
_tkinter.c need to have its tp_richcompare method implemented?  And if so, 
how do I go about testing the implementation?  It seems that PyTclObjects 
aren't directly exposed to Python under 'import tkinter'.

I'll hold off on any more checkins until the 3.0.1 thread on python-dev 
has resolved itself.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Wed Jan 28 10:26:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Jan 2009 09:26:34 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233134794.48.0.501568443722.issue4707@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For myself, I strongly prefer that round(int, int) return an integer in 
Python 3.x.  Here ar\
e three reasons:

(1) Interoperability with Decimal (and, to a lesser extent, Fraction): 
the decimal module is\
 carefully designed so that Decimals interact well with integers.  If 
round(int, int) return\
s an integer then someone working with Decimals can use round freely, 
without worrying about\
 whether his or her numbers are actually integers or Decimals.  If 
round(int, int) returns a\
 float then that someone is likely to get a nasty shock doing 
round(Decimal, int) when it tu\
rns out that the Decimal was actually just a plain integer.

(2) Accuracy:  currently, for example, we have

>>> round(10**16+1, 0)
10000000000000000.0

If the return type is changed to int, there's no need for this loss of 
accuracy.

(3) Consistency:  in 3.x, round(my_decimal, n) returns a Decimal;  
round(my_fraction, n) ret\
urns a Fraction.  That is, for all Python's numeric types other than 
int, the value returned\
 from two-argument round has the same type as the first argument.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 10:35:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Jan 2009 09:35:47 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233135347.76.0.623056739692.issue4707@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

marketdickinson> (2) Accuracy

I see int/float like bytes/characters: it's not a good idea to mix 
them. If you use float, you know that you loose precision (digits) 
after some operations. Whereas I suppose the operations on int are 
always exact.

I like round(int,int)->int (same input/output types). To get a float, 
use round(float(int), int)->float.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 10:40:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Jan 2009 09:40:20 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233135620.89.0.721414195636.issue4707@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Apologies for the poor formatting in the last comment.  Bad
cut-and-paste job.

One more reason:

(4) "In the face of ambiguity, refuse the temptation to guess."
Why should round(int, int) be float, rather than Decimal, or Fraction?
This was the one argument against the integer division change that I 
found somewhat compelling.  But of course there's a big difference:  1/2 
had to have *some* type, and it couldn't be an integer.  In contrast, 
given that round(34, n) is always integral, there's an obvious choice 
for the return type. 

I'll shut up now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 10:56:10 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Jan 2009 09:56:10 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233136570.73.0.925404772839.issue4707@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It's settled then.  Input type dictates output type.  No dependency on
the actual values.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 10:56:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Jan 2009 09:56:24 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233136584.16.0.813219586872.issue4707@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 11:58:27 2009
From: report at bugs.python.org (Fons Dijkstra)
Date: Wed, 28 Jan 2009 10:58:27 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>


New submission from Fons Dijkstra <fdij at xs4all.nl>:

Although it is possible to specify a default value for an append action,  
either directly or through the set_default() function, it is not handled 
correctly when this default is overruled by the user. Take for example 
the following code:

  import optparse
  parser = optparse.OptionParser()
  parser.add_option("-o", "--option", action = "append")
  parser.set_defaults(option = ["a"])
  options, args = parser.parse_args()
  print options

When this is called without arguments the following is printed:
  {'option': ['a']} # as expected

But when it is called with for example with -ob the following is 
printed:
  {'option': ['a', 'b']} # expected {'option': ['b']}

So the default option is also appended, even if the option is explicitly defined by the user.

----------
components: Library (Lib)
messages: 80704
nosy: pycurry
severity: normal
status: open
title: optparse: inconsistent default value for append actions
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5088>
_______________________________________

From report at bugs.python.org  Wed Jan 28 13:52:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Jan 2009 12:52:50 +0000
Subject: [issue5089] Error in atexit._run_exitfuncs [...] Exception expected
	for value, tuple found
In-Reply-To: <1233147170.33.0.0367863608551.issue5089@psf.upfronthosting.co.za>
Message-ID: <1233147170.33.0.0367863608551.issue5089@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

When running the test-suite (using "make test") for a 32-bit debug build 
of py3k on OS X 10.5/Core 2 Duo, I occasionally (perhaps 1 time in 10) get 
the following output at the end of a (successful) test_run:

...
test_zipimport_support
test_zlib
301 tests OK.
22 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
    test_epoll test_largefile test_nis test_normalization
    test_ossaudiodev test_pep277 test_socketserver test_startfile
    test_timeout test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
Those skips are all expected on darwin.
Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, tuple found
[1264638 refs]


I assume that there's a genuine exception here that we're not seeing;  
i.e., that there's a shallow error (tuple instead of exception) that's 
masking output of information from a deeper error.

----------
components: Tests
messages: 80705
nosy: marketdickinson
severity: normal
status: open
title: Error in atexit._run_exitfuncs [...] Exception expected for value, tuple found
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5089>
_______________________________________

From report at bugs.python.org  Wed Jan 28 13:53:13 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 28 Jan 2009 12:53:13 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233147193.8.0.22196492409.issue1717@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Mark,

I'm not a very huge user of tkinter, but I can tell you it would be
tricky to try getting a PyTclObject. It needs to be exposed if you want
to test it without relying on Tcl, but, to me they are just a
"temporary" object that serves to indicate the caller that it needs to
be converted to something else since _tkinter itself wasn't able to do
it. For this reason I would actually prefer to them not be comparable.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Wed Jan 28 14:10:13 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 28 Jan 2009 13:10:13 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1233148213.63.0.370972584932.issue2983@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Added in python-trunk now: r69050

I will be merging it into py3k now, and my bad for taking so long to do
this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Wed Jan 28 14:35:46 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 28 Jan 2009 13:35:46 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1233149746.82.0.369121582486.issue3997@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, the correction went in r68678, r68700, r68734 and r68735

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Wed Jan 28 14:37:11 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Jan 2009 13:37:11 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233149831.95.0.268459222587.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Guilherme.

> For this reason I would actually prefer to them not be comparable.

That's fine with me, so long as we can be sure that there's no existing 
code that depends on them being comparable.  I can't figure out whether 
there's any legitimate way that the tp_compare slot (which is currently 
implemented) of a PyTclObject could ever be called.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Wed Jan 28 15:05:25 2009
From: report at bugs.python.org (wang)
Date: Wed, 28 Jan 2009 14:05:25 +0000
Subject: [issue5090] import tkinter library Visual C++ Concepts:C Run-Time
	Error R6034 when embeded python in c++
In-Reply-To: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>
Message-ID: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>


New submission from wang <zevboy at gmail.com>:

import tkinter library Visual C++ Concepts:C Run-Time Error R6034 when 
embeded python in c++

----------
components: Tkinter
messages: 80710
nosy: guxianminer
severity: normal
status: open
title: import tkinter library Visual C++ Concepts:C Run-Time Error R6034 when embeded python in c++
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5090>
_______________________________________

From report at bugs.python.org  Wed Jan 28 15:21:07 2009
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 28 Jan 2009 14:21:07 +0000
Subject: [issue5091] Segfault in PyObject_Malloc(), address out of bounds
In-Reply-To: <1233152467.68.0.872773053534.issue5091@psf.upfronthosting.co.za>
Message-ID: <1233152467.68.0.872773053534.issue5091@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

One of our application recently started to segfault in
PyObject_Malloc(). The cause of the problem could be tracked down to an
overflowing internal cache.

However I was astonished that Python was segfaulting instead of raising
a memory exception. I did some post mortem debugging with gdb and found
an address out of bounds problem. I think the issue is caused by the
limited heap of a 32bit Python process.

(gdb) bt
...
#7  <signal handler called>
#8  PyObject_Malloc (nbytes=40) at Objects/obmalloc.c:747
#9  0xb7edfba5 in _PyObject_GC_Malloc (basicsize=28) at
Modules/gcmodule.c:1322
#10 0xb7e79867 in PyType_GenericAlloc (type=0xb7606d40, nitems=0) at
Objects/typeobject.c:454
...

(gdb) up 8
#8  PyObject_Malloc (nbytes=40) at Objects/obmalloc.c:747
747                             if ((pool->freeblock = *(block **)bp) !=
NULL) {
(gdb) print pool
$1 = (poolp) 0x17ecc000
(gdb) print pool->freeblock
$2 = (block *) 0xecc778b7 <Address 0xecc778b7 out of bounds>
(gdb) print bp
$3 = (block *) 0xecc778b7 <Address 0xecc778b7 out of bounds>

Python: 2.5.2 (32bit)
OS: SuSE Linux 2.6.16.60-0.33-bigsmp

----------
components: Interpreter Core
messages: 80711
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: Segfault in PyObject_Malloc(), address out of bounds
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5091>
_______________________________________

From report at bugs.python.org  Wed Jan 28 15:43:33 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 28 Jan 2009 14:43:33 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1233153813.6.0.0683400991098.issue2983@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

r69051 in py3k

Now only samples are missing, I will be doing these later today I think.
And there is an issue regarding regrtest (gui resource), see issue5083.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Wed Jan 28 15:44:53 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 28 Jan 2009 14:44:53 +0000
Subject: [issue5083] New resource ('gui') for regrtest
In-Reply-To: <1233088221.56.0.688581339016.issue5083@psf.upfronthosting.co.za>
Message-ID: <1233153893.33.0.691982828706.issue5083@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Uhm, maybe this 'gui' resource is too special to live in use_resources ?
Maybe a new option in regrtest would be better ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5083>
_______________________________________

From report at bugs.python.org  Wed Jan 28 16:47:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Jan 2009 15:47:26 +0000
Subject: [issue5083] New resource ('gui') for regrtest
In-Reply-To: <1233088221.56.0.688581339016.issue5083@psf.upfronthosting.co.za>
Message-ID: <1233157646.09.0.00708227010234.issue5083@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Do the tests require human interaction? If so, it should definitely be
another option.

Otherwise, I'm don't know if we'll be wreaking havok with the buildbots
by including it in -uall even if it is automatic.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5083>
_______________________________________

From report at bugs.python.org  Wed Jan 28 16:52:38 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 28 Jan 2009 15:52:38 +0000
Subject: [issue5083] New resource ('gui') for regrtest
In-Reply-To: <1233157646.09.0.00708227010234.issue5083@psf.upfronthosting.co.za>
Message-ID: <ac2200130901280752o7fce9fa7h59ccb9d22daf6924@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Do the tests require human interaction? If so, it should definitely be
> another option.
>

No interaction is needed for the current ones.

> Otherwise, I'm don't know if we'll be wreaking havok with the buildbots
> by including it in -uall even if it is automatic.
>

I'm worried that those buildbots systems are not really supposed to
have all the libraries required installed, the only exception would be
the ones running under Windows.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5083>
_______________________________________

From report at bugs.python.org  Wed Jan 28 17:16:42 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 28 Jan 2009 16:16:42 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1233159402.05.0.980326594225.issue2983@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

samples: r69053 and r69055

Closing the issue now, thanks.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Wed Jan 28 17:42:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Jan 2009 16:42:31 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233160951.9.0.553856748578.issue4753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, I've compiled py3k on an embarassingly fast Core2-based
server (Xeon E5410), and the computed gotos option gives a 16% speedup
on pybench and pystone.

(with gcc 4.3.2 in 64-bit mode)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Wed Jan 28 18:39:35 2009
From: report at bugs.python.org (Darrell)
Date: Wed, 28 Jan 2009 17:39:35 +0000
Subject: [issue2995] Idle, some Linuxes, cannot position Cursor by mouseclick
In-Reply-To: <1211995180.72.0.174580651078.issue2995@psf.upfronthosting.co.za>
Message-ID: <1233164375.85.0.273211939566.issue2995@psf.upfronthosting.co.za>


Darrell <dustbin at barabashtx.us> added the comment:

I'm using Mandriva 2009.0 and can confirm this problem. RMeyers
suggested testing further by loading and running idlelibs/IOBinding.py.

On my Linux system I find that the mouse clicks and selection works fine
when running IOBinding.py. Being that this module appears to be built
upon Tkinter, it would seem that the bug is at a higher level?

----------
nosy: +dbarabash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2995>
_______________________________________

From report at bugs.python.org  Wed Jan 28 18:46:15 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 28 Jan 2009 17:46:15 +0000
Subject: [issue5057] Unicode-width dependent optimization leads to
	non-portable pyc file
In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>
Message-ID: <1233164775.98.0.177605362124.issue5057@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is this related to issue3297 ?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Wed Jan 28 19:33:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Jan 2009 18:33:21 +0000
Subject: [issue5057] Unicode-width dependent optimization leads to
	non-portable pyc file
In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>
Message-ID: <1233167601.8.0.0237986111032.issue5057@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think so. Issue 3297 seems related to the way unicode objects
are marshalled/unmarshalled, even if the build settings don't change.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5057>
_______________________________________

From report at bugs.python.org  Wed Jan 28 19:35:25 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Jan 2009 18:35:25 +0000
Subject: [issue5083] New resource ('gui') for regrtest
In-Reply-To: <1233088221.56.0.688581339016.issue5083@psf.upfronthosting.co.za>
Message-ID: <1233167725.54.0.446260805885.issue5083@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, if the libraries for Ttk are not included then the tests should
get skipped when the import fails.

A key reason to leaving something out of 'all' is if it takes a REALLY
long time like the zipfile64 tests.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5083>
_______________________________________

From report at bugs.python.org  Wed Jan 28 19:57:18 2009
From: report at bugs.python.org (=?utf-8?q?Te-j=C3=A9_Rodgers?=)
Date: Wed, 28 Jan 2009 18:57:18 +0000
Subject: [issue4631] urlopen returns extra, spurious bytes
In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za>
Message-ID: <1233169038.6.0.0412645964543.issue4631@psf.upfronthosting.co.za>


Changes by Te-j? Rodgers <contact at tejerodgers.com>:


----------
nosy: +trodgers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4631>
_______________________________________

From report at bugs.python.org  Wed Jan 28 20:19:09 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 28 Jan 2009 19:19:09 +0000
Subject: [issue4631] urlopen returns extra, spurious bytes
In-Reply-To: <1228994582.88.0.234313374656.issue4631@psf.upfronthosting.co.za>
Message-ID: <1233170349.45.0.770366826419.issue4631@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


----------
nosy:  -exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4631>
_______________________________________

From report at bugs.python.org  Wed Jan 28 20:21:36 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 28 Jan 2009 19:21:36 +0000
Subject: [issue5090] import tkinter library Visual C++ Concepts:C Run-Time
	Error R6034 when embeded python in c++
In-Reply-To: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>
Message-ID: <1233170496.06.0.135364933448.issue5090@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Please be more specific. What did you try exactly?
If you embed python in a C++ application, which compiler did you use?

A sample that reproduce the problem would be most useful.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5090>
_______________________________________

From report at bugs.python.org  Wed Jan 28 20:30:34 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 28 Jan 2009 19:30:34 +0000
Subject: [issue5083] New resource ('gui') for regrtest
In-Reply-To: <1233167725.54.0.446260805885.issue5083@psf.upfronthosting.co.za>
Message-ID: <ac2200130901281130q1b754830t52ce0d5cfdb2b7c0@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Well, if the libraries for Ttk are not included then the tests should
> get skipped when the import fails.
>

Ah yes, good you said that because I wasn't doing it.

> A key reason to leaving something out of 'all' is if it takes a REALLY
> long time like the zipfile64 tests.

I will add a 'gui' resource on regrtest then.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5083>
_______________________________________

From report at bugs.python.org  Wed Jan 28 20:52:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 28 Jan 2009 19:52:07 +0000
Subject: [issue5075] bdist_wininst should not depend on the vc runtime?
In-Reply-To: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>
Message-ID: <1233172327.68.0.0559254117752.issue5075@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looks fine to me, please apply.

As all the IO is done with Win32 directly, you might as well call
DeleteFile instead of remove (unless I miss something).

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5075>
_______________________________________

From report at bugs.python.org  Wed Jan 28 21:06:54 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 28 Jan 2009 20:06:54 +0000
Subject: [issue5083] New resource ('gui') for regrtest
In-Reply-To: <1233088221.56.0.688581339016.issue5083@psf.upfronthosting.co.za>
Message-ID: <1233173214.3.0.351385005743.issue5083@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Added in r69063

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5083>
_______________________________________

From report at bugs.python.org  Wed Jan 28 21:08:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 28 Jan 2009 20:08:28 +0000
Subject: [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>
Message-ID: <1233173308.75.0.487342803965.issue5076@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This patch is fine, please apply.

I wish it wouldn't be necessary to widen char*, but start off with
wchar_t from the beginning. AFAICT, this would work fine for argv[1]
(there are only two arguments, anyway), but might get complicated for
argv[0].

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5076>
_______________________________________

From report at bugs.python.org  Wed Jan 28 22:47:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Jan 2009 21:47:29 +0000
Subject: [issue4707] round(25, 1) should return an integer, not a float
In-Reply-To: <1229791357.03.0.0672690211922.issue4707@psf.upfronthosting.co.za>
Message-ID: <1233179249.29.0.157541357986.issue4707@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed in r69068 (py3k), r69069 (release30-maint).

The original bug with round(float, n) (loss of accuracy arising from 
intermediate floating-point rounding errors) is still present;  I think 
further discussion for that can go into issue 1869 (which should probably 
have its priority upgraded).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________

From report at bugs.python.org  Wed Jan 28 22:48:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Jan 2009 21:48:10 +0000
Subject: [issue1869] Builtin round function is sometimes inaccurate for floats
In-Reply-To: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za>
Message-ID: <1233179290.33.0.709412420779.issue1869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue 4707.

----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1869>
_______________________________________

From report at bugs.python.org  Wed Jan 28 23:13:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Jan 2009 22:13:12 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1233180792.24.0.971968168829.issue2047@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Adding a test as well would be nice.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Wed Jan 28 23:21:52 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 28 Jan 2009 22:21:52 +0000
Subject: [issue5058] stop pgen.exe from generating CRLF-ended files and
	causing mayhem with win32-based patch submissions
In-Reply-To: <1232907301.06.0.0381974721982.issue5058@psf.upfronthosting.co.za>
Message-ID: <1233181312.45.0.400187337459.issue5058@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5058>
_______________________________________

From report at bugs.python.org  Thu Jan 29 00:15:58 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Jan 2009 23:15:58 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1233184558.31.0.0886980194924.issue4920@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r69070 and r69071.

Thanks for the bug report and patch!

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Thu Jan 29 01:11:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 29 Jan 2009 00:11:02 +0000
Subject: [issue4920] Inconsistent usage of next/__next__ in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1233187862.71.0.812662984705.issue4920@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4920>
_______________________________________

From report at bugs.python.org  Thu Jan 29 01:13:41 2009
From: report at bugs.python.org (Jerzy)
Date: Thu, 29 Jan 2009 00:13:41 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <1233188020.97.0.306560555097.issue5092@psf.upfronthosting.co.za>
Message-ID: <1233188020.97.0.306560555097.issue5092@psf.upfronthosting.co.za>


New submission from Jerzy <jerzyo at genesilico.pl>:

Hi

I am using the multiprocessing mudule and I found a very weird thing.
It seems that that the result of one fragment of the code depends on the
fragment of the code that is after it, which should not happen. 

My script looks like this

import time
import multiprocessing
import sys

def f():
  sys.stderr.write(str(len(l))+"\n")
  print len(l)
  #del l
  while(True):
    time.sleep(1)
l=[]
for i in range(2*1000*1000):
  l.append(str(i))
process = multiprocessing.Process(target=f)
process.start()

while(True):
  time.sleep(1)

And its output is as expected:
2000000
2000000
but when I uncoment the 'del l' line I get:

  File
"/home/jerzyo/programs/python2.6/Python-2.6.1/Lib/multiprocessing/process.py",
line 231, in _bootstrap
    self.run()
  File
"/home/jerzyo/programs/python2.6/Python-2.6.1/Lib/multiprocessing/process.py",
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "bin/momory.py", line 6, in f
    sys.stderr.write(str(len(l))+"\n")
UnboundLocalError: local variable 'l' referenced before assignment


How is that? The line that deletes l is after the printing line. How
python interpreter knows that l will be deleted. This is a very anomalus
behaviour and should never happen.

By the way. Is there any way to free some parts of memory in child
process. Suppose I wand to create 100 child processes that do not use
the l list. How can I avoid making 100 copies of l in child processes.

That is my firs post and won't come here very often, so please answer
also to my email (if it is not automaic). I am running python 2.6.1 on
ubuntu 8.04 32bit.

jerzy

----------
messages: 80731
nosy: Orlowski
severity: normal
status: open
title: weird memory usage in multiprocessing module
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Thu Jan 29 01:14:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 29 Jan 2009 00:14:41 +0000
Subject: [issue4948] Make heapq work with all mutable sequences
In-Reply-To: <1231951228.13.0.336987683355.issue4948@psf.upfronthosting.co.za>
Message-ID: <1233188081.33.0.346182831231.issue4948@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

With no compelling use cases, it's not worth slowing down the module. 
Am sticking with the original design decision.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4948>
_______________________________________

From report at bugs.python.org  Thu Jan 29 01:29:58 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 00:29:58 +0000
Subject: [issue5093] 2to3 with a pipe on non-ASCII script
In-Reply-To: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>
Message-ID: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If Python output is redirected to a pipe, sys.stdout encoding is 
ASCII. So "2to3 script.py|cat" will write the patch in ASCII. If the 
script contains a non-ASCII character, 2to3 fails with:
  ...
  File ".../lib2to3/refactor.py", line 238, in refactor_file
    self.processed_file(str(tree)[:-1], filename, write=write)
  File ".../lib2to3/refactor.py", line 342, in processed_file
    self.print_output(diff_texts(old_text, new_text, filename))
  File ".../main.py", line 48, in print_output
    print(line)
UnicodeEncodeError: 'ascii' codec can't encode character '\xfb' in 
position 11: ordinal not in range(128)

Should we consider the input file and stdout as binary files? 
Workaround: modify the files in place (-w option) but don't write the 
patch to stdout (no such option yet).

A project may contain scripts in ASCII, Latin-1 and UTF-8 (eg. Python 
source code ;-)).

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 80733
nosy: haypo
severity: normal
status: open
title: 2to3 with a pipe on non-ASCII script

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5093>
_______________________________________

From report at bugs.python.org  Thu Jan 29 01:37:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 00:37:47 +0000
Subject: [issue5093] 2to3 with a pipe on non-ASCII script
In-Reply-To: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>
Message-ID: <1233189467.82.0.745440677909.issue5093@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Example of workaround: don't write the patch if the option -w is used. 
I don't need the patch if I choosed to modify the files in place.

----------
keywords: +patch
Added file: http://bugs.python.org/file12887/2to3_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5093>
_______________________________________

From report at bugs.python.org  Thu Jan 29 01:52:43 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Jan 2009 00:52:43 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

When you call datetime.datetime.utcnow() you get back a naive datetime
object. But why? You asked for UTC as the timezone based on what method
call you made. And UTC is a very concrete timezone that never changes.

It would be nice to have a concrete UTC tzinfo class that utcnow() uses
so that at least those datetime instances are non-naive.

If people have no issues with making this happen I will write the code
for the concrete UTC tzinfo instance and make the appropriate changes to
utcnow().

----------
components: Extension Modules
messages: 80735
nosy: brett.cannon
severity: normal
status: open
title: datetime lacks concrete tzinfo impl. for UTC
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Thu Jan 29 02:05:57 2009
From: report at bugs.python.org (engelbert gruber)
Date: Thu, 29 Jan 2009 01:05:57 +0000
Subject: [issue2263] struct.pack() + numpy int raises SystemError
In-Reply-To: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za>
Message-ID: <1233191157.87.0.777338835919.issue2263@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

on ubuntu 8.04, Python 2.7a0 (trunk:69044) and numpy 1.2.1
("." is OK, "e" means SystemError)

* signed always works, longlong also.
* unsigned native works half of the time
* unsigned little/big endian never works
* the numpy type does seam to have any effect.

signed char          b   'int16'   .  <.  >.  'uint32'   .  <.  >. 
sys:1: DeprecationWarning: struct integer overflow masking is deprecated
unsigned char        B   'int16'   .  <e  >e  'uint32'   .  <e  >e 
signed short         h   'int16'   .  <.  >.  'uint32'   .  <.  >. 
unsigned short       H   'int16'   .  <e  >e  'uint32'   .  <e  >e 
signed int           i   'int16'   .  <.  >.  'uint32'   .  <.  >. 
unsigned int         I   'int16'   e  <e  >e  'uint32'   e  <e  >e 
signed long          l   'int16'   .  <.  >.  'uint32'   .  <.  >. 
unsigned long        L   'int16'   e  <e  >e  'uint32'   e  <e  >e 
signed long long     q   'int16'   .  <.  >.  'uint32'   .  <.  >. 
unsigned long long   Q   'int16'   .  <.  >.  'uint32'   .  <.  >.

----------
nosy: +grubert
versions: +Python 2.7
Added file: http://bugs.python.org/file12888/issue2263-numpy.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2263>
_______________________________________

From report at bugs.python.org  Thu Jan 29 02:24:15 2009
From: report at bugs.python.org (johansen)
Date: Thu, 29 Jan 2009 01:24:15 +0000
Subject: [issue2159] dbmmodule inquiry function is performance prohibitive
In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>
Message-ID: <1233192255.84.0.660493233973.issue2159@psf.upfronthosting.co.za>


johansen <johansen at sun.com> added the comment:

I haven't been able to find any of the patches listed in the comments,
but it does look like providing a nb_nonzero method in the module would
solve our issue.  PyObject_IsTrue checks the tp_as_number methods before
the sequence and mapping methods.  I'm not sure if it's safe to count on
this behavior as always being true, but for 2.4 and the dbmmodule, it
would work.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2159>
_______________________________________

From report at bugs.python.org  Thu Jan 29 02:43:29 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 29 Jan 2009 01:43:29 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <1233188020.97.0.306560555097.issue5092@psf.upfronthosting.co.za>
Message-ID: <1233193409.77.0.813951829875.issue5092@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

The del statement makes the variable local, as alluded to by

http://docs.python.org/dev/3.0/reference/simple_stmts.html#the-del-
statement

The manual is clearer about assignments, which are local unless declared 
global or nonlocal.


For other question, me thinks you need to write slightly cleverer code 
that passes only required data.  I have experience with 
multiprocessing.Pool().map which lets me control the arguments I pass to 
functions.

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Thu Jan 29 02:50:41 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 29 Jan 2009 01:50:41 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <1233188020.97.0.306560555097.issue5092@psf.upfronthosting.co.za>
Message-ID: <1233193841.4.0.544454697714.issue5092@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

My second answer is irrelevant.  Function receives the global data as 
well as the arguments.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Thu Jan 29 03:02:27 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 29 Jan 2009 02:02:27 +0000
Subject: [issue2159] dbmmodule inquiry function is performance prohibitive
In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>
Message-ID: <1233194547.12.0.333723335971.issue2159@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2159>
_______________________________________

From report at bugs.python.org  Thu Jan 29 03:17:08 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 29 Jan 2009 02:17:08 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1233195428.53.0.785067265706.issue5094@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Brett,
It might be worth to update tzinfo-examples.py to use your concrete UTC
then: 

http://svn.python.org/view/python/trunk/Doc/includes/tzinfo-examples.py?rev=62214&view=markup

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Thu Jan 29 03:29:17 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 29 Jan 2009 02:29:17 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <1233188020.97.0.306560555097.issue5092@psf.upfronthosting.co.za>
Message-ID: <1233196157.85.0.99936146684.issue5092@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As David says, this is not a bug. del l indicates that there is a local
variable to be deleled, but when the del statement is executed, there is
no local variable. The error message is confusing in this case: there
actually is no later assignment to l (in the function at all).
Typically, when you have an unbound local, it is because of a later
assignment, such as

def foo():
  a = l + 1
  l = 2

In this specific example, there is no later assignment - yet it is still
an unbound local.

So that you get the exception is not a bug.

I was going to suggest that the error message could be better, but I
can't think of any other error message that is better and still correct,
hence closing it as won't fix.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Thu Jan 29 03:55:33 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 29 Jan 2009 02:55:33 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1232824631.07.0.389476612563.issue4676@psf.upfronthosting.co.za>
Message-ID: <ac2200130901281855s7affe4a4k1376da0a701260ea@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Weeble added the comment:
>
> In summary, Tk 8.5 changed the name of the "anchor" mark to be unique to
> each Text widget. The code to make the home key toggle between column 0
> and the start of the text tries to make use of the "anchor" mark and
> gets confused.
>
> In the email I proposed a simple fix which I'm testing out right now.
> Should I attach it as a patch?
>

I see your simple fix depends on a unsupported proc provided by tk,
how good is to depend on it ?
And I don't think that is backwards compatible till tk 8.2, is it ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Thu Jan 29 04:05:50 2009
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 29 Jan 2009 03:05:50 +0000
Subject: [issue5095] msi missing from "bdist --help-formats"
In-Reply-To: <1233198350.56.0.182108150047.issue5095@psf.upfronthosting.co.za>
Message-ID: <1233198350.56.0.182108150047.issue5095@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

The bdist_msi command is documented in the distutils reference:

http://docs.python.org/distutils/apiref.html#module-distutils.command.bdist_msi

But it does not show up with "bdist --help-formats"

$ python setup.py bdist --help-formats
List of available distribution formats:
  --formats=rpm      RPM distribution
  --formats=gztar    gzip'ed tar file
  --formats=bztar    bzip2'ed tar file
  --formats=ztar     compressed tar file
  --formats=tar      tar file
  --formats=wininst  Windows executable installer
  --formats=zip      ZIP file

This probably exists in 3.0 too, but I haven't checked.

----------
components: Distutils
messages: 80743
nosy: bethard
severity: normal
stage: needs patch
status: open
title: msi missing from "bdist --help-formats"
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5095>
_______________________________________

From report at bugs.python.org  Thu Jan 29 04:07:33 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Jan 2009 03:07:33 +0000
Subject: [issue5095] msi missing from "bdist --help-formats"
In-Reply-To: <1233198350.56.0.182108150047.issue5095@psf.upfronthosting.co.za>
Message-ID: <1233198453.89.0.720780319342.issue5095@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> tarek
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5095>
_______________________________________

From report at bugs.python.org  Thu Jan 29 04:38:05 2009
From: report at bugs.python.org (wang)
Date: Thu, 29 Jan 2009 03:38:05 +0000
Subject: [issue5090] import tkinter library Visual C++ Concepts:C Run-Time
	Error R6034 when embeded python in c++
In-Reply-To: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>
Message-ID: <1233200285.35.0.0178617093253.issue5090@psf.upfronthosting.co.za>


wang <zevboy at gmail.com> added the comment:

my compile is gcc 4.2.1
system is windows xp

some other library can be import.
such as:sys os

c++ code line:
    Py_Initialize();
    Py_SetProgramName(L"MyProgram");
    module=PyImport_ImportModule("__main__");
    moduledict=PyModule_GetDict(dodule);
    PySys_SetArgv(1,wxargv);
    PyRun_StringFlags("\
import tkinter\n\
",Py_file_input,moduledict,moduledict,NULL);
Py_finalize();

the urllib.request also can not import.

----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5090>
_______________________________________

From report at bugs.python.org  Thu Jan 29 04:52:46 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Jan 2009 03:52:46 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233195428.53.0.785067265706.issue5094@psf.upfronthosting.co.za>
Message-ID: <bbaeab100901281952x11236252n2eeea0c90612659b@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Jan 28, 2009 at 18:17, Daniel Diniz <report at bugs.python.org> wrote:
>
> Daniel Diniz <ajaksu at gmail.com> added the comment:
>
> Brett,
> It might be worth to update tzinfo-examples.py to use your concrete UTC
> then:

I will if people are generally okay with the idea of adding this class.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Thu Jan 29 06:05:35 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 29 Jan 2009 05:05:35 +0000
Subject: [issue5090] import tkinter library Visual C++ Concepts:C Run-Time
	Error R6034 when embeded python in c++
In-Reply-To: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>
Message-ID: <1233205535.44.0.852641649398.issue5090@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

os and sys are builtin modules. See if you can import any other pure 
Python module.
Also, see #4566

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5090>
_______________________________________

From report at bugs.python.org  Thu Jan 29 06:14:25 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 29 Jan 2009 05:14:25 +0000
Subject: [issue5090] import tkinter library Visual C++ Concepts:C Run-Time
	Error R6034 when embeded python in c++
In-Reply-To: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>
Message-ID: <1233206065.29.0.699803884043.issue5090@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

(In case the fix in #4566 works for you, please let us know)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5090>
_______________________________________

From report at bugs.python.org  Thu Jan 29 08:48:34 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 29 Jan 2009 07:48:34 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1233215314.92.0.198505780544.issue2578@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

FYI - As a side note to this issue of removing the clutter of alternate
names - I intend to gather up the worthy non-clutter additional unittest
assertFoo APIs that we have at Google to contribute towards 3.1/2.7, my
goal is to do this before PyCon this year.

This thread from last spring summarizes the types of things I'd like
include already.

 http://mail.python.org/pipermail/python-dev/2008-April/078716.html

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
_______________________________________

From report at bugs.python.org  Thu Jan 29 08:56:12 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 29 Jan 2009 07:56:12 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1233215772.8.0.314116036381.issue2578@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee: purcell -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
_______________________________________

From report at bugs.python.org  Thu Jan 29 08:56:28 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 29 Jan 2009 07:56:28 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1233215788.67.0.497650344672.issue2578@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
_______________________________________

From report at bugs.python.org  Thu Jan 29 09:47:23 2009
From: report at bugs.python.org (Weeble)
Date: Thu, 29 Jan 2009 08:47:23 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1233218843.72.0.775627706078.issue4676@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

Well, the status quo depends on an unsupported field - "anchor". As far
as I can tell, the only other option that allows any customisation of
cursor behaviour is to re-implement the entire selection system from the
ground up. Would it be acceptable to detect the Tk version and change
strategy accordingly?

I don't know how far back this would work: I've tested it with Tk 8.5
and 8.4.

I'll ask on comp.lang.tcl and see what they recommend fpr customising
the behaviour of a text widget.

Thanks for looking over this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Thu Jan 29 09:59:59 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Thu, 29 Jan 2009 08:59:59 +0000
Subject: [issue5056] PyAPI assumes OS can access shared data in loadable
	modules (windows can't)
In-Reply-To: <1232899694.31.0.93225965153.issue5056@psf.upfronthosting.co.za>
Message-ID: <1233219599.79.0.308077334407.issue5056@psf.upfronthosting.co.za>


Changes by Ulrich Eckhardt <eckhardt at satorlaser.com>:


----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5056>
_______________________________________

From report at bugs.python.org  Thu Jan 29 10:06:34 2009
From: report at bugs.python.org (Weeble)
Date: Thu, 29 Jan 2009 09:06:34 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1233219994.44.0.497788432776.issue4676@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

I posted a question on comp.lang.tcl here:

http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/aab17806f6fa837f#

By the way, which versions of Tk must Python support? Where do I find
out things like that?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Thu Jan 29 10:22:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Jan 2009 09:22:20 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233220940.95.0.0288954244377.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not going to get more time to work on this before
the weekend, so if anyone else wants to take over please
feel free.

Still to do for stage 2:  cell objects and slot
wrapper objects need to have tp_richcompare
implemented, to replace the tp_compare slots that
are being removed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jan 29 10:38:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 29 Jan 2009 09:38:41 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233221921.41.0.980678600845.issue1717@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

For 3.0, are you going to keep tp_compare slot in existence and just
assert that it is NULL?  Then in 3.1, remove the slot entirely?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jan 29 10:45:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Jan 2009 09:45:24 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233222324.2.0.295224338617.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

If I understand Christian's plan correctly, it was to:

(1) raise TypeError for non-NULL tp_compare, and
(2) rename tp_compare to tp_reserved (with type void *).

and both of these would happen with 3.0.1, so no difference between
3.0.1 and 3.1.0.

It seems to me that if tp_compare is actually going to be removed then
that should be done in 3.0.1;  else third-party stuff that works with
3.0.x will fail with 3.1, due to the various tp_* fields being out of sync.

It would be nice not to have tp_reserved hanging around for the duration
of 3.x.  (Similarly for nb_reserved.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jan 29 10:53:03 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 29 Jan 2009 09:53:03 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233222783.28.0.757625627541.issue1717@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Instead of tp_reserved, the name should be tp_deprecated_compare.

There should be a python-dev discussion around when to actually remove
the slot:

  3.0.1 -- binary incompatibility between minor releases (BAD)
  3.1.0 -- uncomfortable for writers who have to add #ifdefs
  4.0.0 -- no pain, just wasted space
  3.1.5 -- just plain mean :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jan 29 10:56:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 29 Jan 2009 09:56:47 +0000
Subject: [issue5090] import tkinter library Visual C++ Concepts:C Run-Time
	Error R6034 when embeded python in c++
In-Reply-To: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>
Message-ID: <1233223007.31.0.0303979734609.issue5090@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, issue4566 describes exactly the same problem.

----------
resolution:  -> duplicate
status: open -> pending
superseder:  -> 2.6.1 breaks many applications that embed Python on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5090>
_______________________________________

From report at bugs.python.org  Thu Jan 29 11:53:47 2009
From: report at bugs.python.org (Jerzy)
Date: Thu, 29 Jan 2009 10:53:47 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <1233196157.85.0.99936146684.issue5092@psf.upfronthosting.co.za>
Message-ID: <498181FA.9070004@genesilico.pl>


Jerzy <jerzyo at genesilico.pl> added the comment:

I still do not understand what is going on when python executed thic 
code. I have a local variable l in my parent process. When I create a 
child process, program makes first makes a copy of memory. Than what?

I am sure that l still exists in child process because
1. It can be printed
2. It has still a lot of memory allocated for it

You say that l does not exist as a local variable in child process. Is 
it global? How can I dealocate it in child process?

Jerzy

Martin v. L?wis pisze:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> As David says, this is not a bug. del l indicates that there is a local
> variable to be deleled, but when the del statement is executed, there is
> no local variable. The error message is confusing in this case: there
> actually is no later assignment to l (in the function at all).
> Typically, when you have an unbound local, it is because of a later
> assignment, such as
> 
> def foo():
>   a = l + 1
>   l = 2
> 
> In this specific example, there is no later assignment - yet it is still
> an unbound local.
> 
> So that you get the exception is not a bug.
> 
> I was going to suggest that the error message could be better, but I
> can't think of any other error message that is better and still correct,
> hence closing it as won't fix.
> 
> ----------
> nosy: +loewis
> resolution:  -> wont fix
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5092>
> _______________________________________
> 
> 
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Thu Jan 29 11:56:14 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 29 Jan 2009 10:56:14 +0000
Subject: [issue5084] unpickling does not intern attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233226574.97.0.630787137754.issue5084@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5084>
_______________________________________

From report at bugs.python.org  Thu Jan 29 12:27:44 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 29 Jan 2009 11:27:44 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1233228464.09.0.0201556195103.issue4821@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Thu Jan 29 12:28:36 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 29 Jan 2009 11:28:36 +0000
Subject: [issue4818] Patch for thread-support in md5module.c
In-Reply-To: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>
Message-ID: <1233228516.27.0.80628048622.issue4818@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4818>
_______________________________________

From report at bugs.python.org  Thu Jan 29 12:41:40 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 29 Jan 2009 11:41:40 +0000
Subject: [issue4701] range objects becomes hashable after attribute access
In-Reply-To: <1229700071.49.0.411961185177.issue4701@psf.upfronthosting.co.za>
Message-ID: <1233229300.64.0.737735648336.issue4701@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4701>
_______________________________________

From report at bugs.python.org  Thu Jan 29 12:42:55 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Thu, 29 Jan 2009 11:42:55 +0000
Subject: [issue5096] strange thing after call PyObject_CallMethod
In-Reply-To: <1233229375.88.0.463699429869.issue5096@psf.upfronthosting.co.za>
Message-ID: <1233229375.88.0.463699429869.issue5096@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

When unhandled in python code exception occurs in PyObject_CallMethod 
frame_dealloc() (Objects/frameobject.c:422) 
not called. Even if I call PyErr_Print(). 

But if I call PyErr_Clear() then all okay. Documentation says that both 
this functions doing same work(http://docs.python.org/3.0/c-api/
exceptions.html). As we see thats not true or not all nuances documented.

Examples and more on this mailing list:
http://groups.google.com/group/comp.lang.python/browse_thread/
thread/19316b3effa37d2d

----------
components: Interpreter Core
messages: 80757
nosy: exe
severity: normal
status: open
title: strange thing after call PyObject_CallMethod
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5096>
_______________________________________

From report at bugs.python.org  Thu Jan 29 12:50:39 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 29 Jan 2009 11:50:39 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1233218843.72.0.775627706078.issue4676@psf.upfronthosting.co.za>
Message-ID: <ac2200130901290350o7c0b6dc9p4d8152a29f6a385@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Weeble  added the comment:
>
> Well, the status quo depends on an unsupported field - "anchor".

Better not repeat the mistake then ?

> As far
> as I can tell, the only other option that allows any customisation of
> cursor behaviour is to re-implement the entire selection system from the
> ground up. Would it be acceptable to detect the Tk version and change
> strategy accordingly?
>

IDLE already reimplements several things, which were useful back then
when it wasn't reimplementing -- just adding functionality. If the
only correct solution is really to reimplement the selection, then it
would be better to do it anyway, but I don't think it is.

I'm interested in knowing how many interactive shells implement this
same behaviour, or if there are that many I would like at least some
examples. I'm unsure about the usefulness of the current functionality
(supposing it was working as intended).

> I don't know how far back this would work: I've tested it with Tk 8.5
> and 8.4.
>

All versions of 8.4 ? I've seen complaints about early releases of tk
8.4 and the use of the unsupported function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Thu Jan 29 13:06:33 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 29 Jan 2009 12:06:33 +0000
Subject: [issue5096] strange thing after call PyObject_CallMethod
In-Reply-To: <1233229375.88.0.463699429869.issue5096@psf.upfronthosting.co.za>
Message-ID: <1233230793.03.0.302257723482.issue5096@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think I have an explanation:
When a python exception is raised, the current call stack is stored in
the exception state (tstate->curexc_traceback). This includes all the
living frame objects, with all their local variables.
This explains why frame_dealloc is not called at this time, and why the
"self" object has its refcount increased.

PyErr_Clear() releases everything.
PyErr_Print() does clear tstate->curexc_traceback, but only to copy the
value into sys.last_traceback; So the frame object is still alive.

I suggest you to use PyErr_PrintEx(0), which will print and clear the
error, but not store the exception info into the sys.last_* variables.
[PyErr_Print() simply calls PyErr_PrintEx(1); No, it's not yet documented]

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5096>
_______________________________________

From report at bugs.python.org  Thu Jan 29 13:42:32 2009
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 29 Jan 2009 12:42:32 +0000
Subject: [issue5075] bdist_wininst should not depend on the vc runtime?
In-Reply-To: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>
Message-ID: <1233232952.78.0.327136355725.issue5075@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Checked into trunk as r69094; merged to release26-maint as r69095, py3k
as r69096 and release30-maint as r69097.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5075>
_______________________________________

From report at bugs.python.org  Thu Jan 29 13:50:55 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Thu, 29 Jan 2009 12:50:55 +0000
Subject: [issue5096] strange thing after call PyObject_CallMethod
In-Reply-To: <1233229375.88.0.463699429869.issue5096@psf.upfronthosting.co.za>
Message-ID: <1233233455.31.0.914698370589.issue5096@psf.upfronthosting.co.za>


Kandalintsev Alexandre <bug_hunter at messir.net> added the comment:

Thank you for your activity. This feature drank alot of my blood. Please 
document this or change behavior.

PS Older python versions may be also affected so changing behavior may 
brake existing code :(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5096>
_______________________________________

From report at bugs.python.org  Thu Jan 29 13:57:20 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 29 Jan 2009 12:57:20 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1233233840.89.0.66479740946.issue4174@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

From report at bugs.python.org  Thu Jan 29 14:13:16 2009
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 29 Jan 2009 13:13:16 +0000
Subject: [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>
Message-ID: <1233234796.85.0.747291335849.issue5076@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Checked into py3k as r6998; merged to release30-maint as 69099.  I hope
I got that right!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5076>
_______________________________________

From report at bugs.python.org  Thu Jan 29 14:16:23 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 29 Jan 2009 13:16:23 +0000
Subject: [issue5096] strange thing after call PyObject_CallMethod
In-Reply-To: <1233229375.88.0.463699429869.issue5096@psf.upfronthosting.co.za>
Message-ID: <1233234983.8.0.533505063805.issue5096@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> georg.brandl
components: +Documentation -Interpreter Core
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5096>
_______________________________________

From report at bugs.python.org  Thu Jan 29 14:20:35 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Thu, 29 Jan 2009 13:20:35 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

asyncore.dispatcher_with_send undocumented in all python versions

----------
assignee: georg.brandl
components: Documentation
messages: 80763
nosy: exe, georg.brandl
severity: normal
status: open
title: asyncore.dispatcher_with_send undocumented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5097>
_______________________________________

From report at bugs.python.org  Thu Jan 29 14:56:26 2009
From: report at bugs.python.org (Weeble)
Date: Thu, 29 Jan 2009 13:56:26 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1233237386.21.0.117112550085.issue4676@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

You're right: we should find a solution that's safe and supported.

I *think* the primary reason for overriding the home key behaviour was 
not for the interactive shell, but to make it easier to edit code. Most 
programmer's editors that do automatic indentation also let you use home 
to move to the beginning of the text on a line, rather than the absolute 
beginning of the line. I couldn't say for sure though: I'm new here.

I've proposed some changes to the ctrl-left, ctrl-right behaviour on 
idle-dev that would also require custom handling of selection behaviour. 
If it were to be decided that reimplementing the selection-handling was 
worthwhile I would be willing to work on such a patch to redo the 
selection-handling using only supported Tk features, but I get the 
impression I'd need lots of help to get it tested with every possible 
version of Tcl/Tk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Thu Jan 29 15:42:00 2009
From: report at bugs.python.org (Stuart Axon)
Date: Thu, 29 Jan 2009 14:42:00 +0000
Subject: [issue5098] Environ doesn't escape spaces properly
In-Reply-To: <1233240119.96.0.34005552843.issue5098@psf.upfronthosting.co.za>
Message-ID: <1233240119.96.0.34005552843.issue5098@psf.upfronthosting.co.za>


New submission from Stuart Axon <stu.axon at gmail.com>:

os.environ doesn't escape spaces, but does backslashes and others

In the windows python interpreter I echo'd the variable 'ProgramFiles',
then in the commandprompt.

>>> from os import environ
>>> environ['ProgramFiles']
'C:\\Program Files'
>>> ^Z

[C:\]echo %ProgramFiles%
C:\Program Files

This 'half' escapping seems odd, and is annoying when building file
paths for instance, probably the space should also be escaped.

----------
components: None
messages: 80765
nosy: stuaxo
severity: normal
status: open
title: Environ doesn't escape spaces properly
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5098>
_______________________________________

From report at bugs.python.org  Thu Jan 29 15:49:33 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 29 Jan 2009 14:49:33 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1233237386.21.0.117112550085.issue4676@psf.upfronthosting.co.za>
Message-ID: <ac2200130901290649j5c322514xd7a51506ace966c9@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Weeble added the comment:
>
> I *think* the primary reason for overriding the home key behaviour was
> not for the interactive shell, but to make it easier to edit code. Most
> programmer's editors that do automatic indentation also let you use home
> to move to the beginning of the text on a line, rather than the absolute
> beginning of the line.
>

Yes, but IDLE goes beyond that and adds some weird behaviour.
Suppose you have this line in IDLE:

>>> xxxx

Why would you want to go at the absolute beginning there ? That is
what happens when you press home twice.
Then there is the other case, the reason for the current home code:

   y, ...

Pressing home twice while on the second line toggles between the
absolute start of that line and one position before y, this is the
behaviour that I haven't seen used anywhere else (but it is not like I
have used many GUI shells). If it is used everywhere else I haven't
looked at then this might be good because people are accustomed to,
otherwise it is just a feature that IDLE has for no reason.

> I've proposed some changes to the ctrl-left, ctrl-right behaviour on
> idle-dev that would also require custom handling of selection behaviour.

I'm subscribed to idle-dev but I assume I don't read it at all.

> If it were to be decided that reimplementing the selection-handling was
> worthwhile I would be willing to work on such a patch to redo the
> selection-handling using only supported Tk features, but I get the
> impression I'd need lots of help to get it tested with every possible
> version of Tcl/Tk.
>

Before start writing new code I suggest to check how many IDLE forks
exist, and check if any of them has this fixed. It would be good to
start writing tests for idlelib too.
Testing with every possible version of Tcl/Tk is not going to work,
the minimal possible is 8.2 as it is what _tkinter supports. But I
suspect most people are using tk 8.4 (and then there are a lot of
minor releases), some tk 8.5 and very few using other versions.
The externally maintained tk versions are 8.4.12, 8.4.16, 8.4.18.1 and
8.5.2.0 so we could target these versions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Thu Jan 29 15:51:27 2009
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 29 Jan 2009 14:51:27 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1233240687.87.0.896254917517.issue3823@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Thu Jan 29 15:58:18 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 29 Jan 2009 14:58:18 +0000
Subject: [issue5098] Environ doesn't escape spaces properly
In-Reply-To: <1233240119.96.0.34005552843.issue5098@psf.upfronthosting.co.za>
Message-ID: <1233241098.68.0.319593994652.issue5098@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

The backslash escaping has nothing to do with os.environ.  It's the way
any string with a backslash in it is displayed in the interactive
interpreter (it's the way str.__repr__ works).  Performing any escaping
on a string to make it usable in a command line is a task which is
inappropriate as a feature of os.environ.  The contents of os.environ
are just strings.  If you want to use them in a command line, you need
to escape them appropriately.  Notice that in addition to escaping the
space, you may also sometimes need to escape a backslash (not in this
case on Windows, though, since a single \ is allowed here).  The
escaping of the \ in this example is *only* in the *display* of the
variable - there is only one \ in the string itself.

I recommend closing this ticket as invalid.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5098>
_______________________________________

From report at bugs.python.org  Thu Jan 29 16:01:17 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 29 Jan 2009 15:01:17 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1233241277.79.0.192844822846.issue3823@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


----------
nosy:  -exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Thu Jan 29 16:01:48 2009
From: report at bugs.python.org (Weeble)
Date: Thu, 29 Jan 2009 15:01:48 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1233241308.2.0.281837419574.issue4676@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

I can't see any useful reason to go to the absolute start of the line in 
the interactive shell. However, it does make sense in the source editor, 
and it is consistent with, for example, Visual Studio. The first use-
case off the top of my head is when you want to copy a block of code and 
not lose the relative indentation of the first line. You press home-
twice to go to the absolute start of line and select from there. It's 
also the only quick way in IDLE to be sure that the text widget is 
scrolled all the way to the left, since there's no horizontal scrollbar. 
(Any idea why that is? I assumed it's to discourage long lines, but I 
don't know.)

The proposal I refer to in IDLE-dev is this:
    http://mail.python.org/pipermail/idle-dev/2009-January/002742.html

I only mention it because it demonstrates another reason why we might 
want to override the default selection/navigation mechanics.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Thu Jan 29 16:21:15 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 29 Jan 2009 15:21:15 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1233241308.2.0.281837419574.issue4676@psf.upfronthosting.co.za>
Message-ID: <ac2200130901290721u130f1f92i6af22c736b243d2d@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> It's
> also the only quick way in IDLE to be sure that the text widget is
> scrolled all the way to the left, since there's no horizontal scrollbar.
> (Any idea why that is? I assumed it's to discourage long lines, but I
> don't know.)

The shell is configured to wrap lines if they get too long, but you
will notice that pressing 'end' doesn't really get you to the end of
line.
It should be easier to not wrap there too and add a horizontal
scrollbar (if needed) to all text widgets used by idle.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4676>
_______________________________________

From report at bugs.python.org  Thu Jan 29 16:30:07 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Jan 2009 15:30:07 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233243007.39.0.294266016776.issue1717@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Actually, I would like to repurpose tp_compare as tp_bytes for the
__bytes__ method.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jan 29 16:57:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Jan 2009 15:57:12 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1233244632.67.0.277032801356.issue5097@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: georg.brandl -> josiahcarlson
nosy: +josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5097>
_______________________________________

From report at bugs.python.org  Thu Jan 29 17:00:08 2009
From: report at bugs.python.org (Mary Stern)
Date: Thu, 29 Jan 2009 16:00:08 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttribuetError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>


New submission from Mary Stern <marystern at yahoo.com>:

I was getting this error (while running my unit tests):

Exception exceptions.AttributeError: "'NoneType' object has no attribute
'error'" in <bound method Popen.__del__ of <subprocess.Popen object at
0x8a2596c>> ignored

which I tracked down to the os module being set to None (yes really!) in
POpen._internal_poll() when called from Popen.__del__, so this line:

                    except os.error:

was generating the error.

I guess that the module is getting unloaded earlier somehow (maybe a
race condition)?

----------
components: Extension Modules
messages: 80771
nosy: marystern
severity: normal
status: open
title: subprocess.POpen.__del__() AttribuetError (os module == None!)
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Thu Jan 29 17:00:46 2009
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Thu, 29 Jan 2009 16:00:46 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1233180792.24.0.971968168829.issue2047@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0901290800w89daf7ajf3eaf03cec77731e@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Wed, Jan 28, 2009 at 5:13 PM, Antoine Pitrou <report at bugs.python.org> wrote:

shutil_destinsrc.patch has both the code chage and two test cases.
Actually test cases are much longer than the code itself :-).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Thu Jan 29 17:01:24 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 29 Jan 2009 16:01:24 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1233244884.75.0.226964445573.issue2578@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

As an side-side-note, I find much more important to add some kind of
test discovery since it is being duplicated in several packages in Lib/
and will continue being duplicated.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
_______________________________________

From report at bugs.python.org  Thu Jan 29 17:01:33 2009
From: report at bugs.python.org (Mary Stern)
Date: Thu, 29 Jan 2009 16:01:33 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1233244893.8.0.0329726447783.issue5099@psf.upfronthosting.co.za>


Changes by Mary Stern <marystern at yahoo.com>:


----------
title: subprocess.POpen.__del__() AttribuetError (os module == None!) -> subprocess.POpen.__del__() AttributeError (os module == None!)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Thu Jan 29 17:31:53 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 29 Jan 2009 16:31:53 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1233246713.29.0.0827889032083.issue5099@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Thu Jan 29 18:33:41 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 29 Jan 2009 17:33:41 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1233250421.28.0.0909359154659.issue4174@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

From report at bugs.python.org  Thu Jan 29 18:34:22 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 29 Jan 2009 17:34:22 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1233250462.71.0.0145073581295.issue4174@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

From report at bugs.python.org  Thu Jan 29 19:16:11 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 29 Jan 2009 18:16:11 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1233252971.19.0.426552535404.issue2578@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

@gpsmith: Way to go!

@gpolo: Alas, test discovery is now a much harder problem because it
depends on using conventions for test naming.  Unless all existing
implementations use the same conventions, it's hard to see how to
replace them.  Please bring that up on python-ideas at python.org.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
_______________________________________

From report at bugs.python.org  Thu Jan 29 19:32:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Jan 2009 18:32:17 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1233253937.42.0.896928245643.issue2047@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, I had only given a quick look at Benjamin's patch, not yours.
Actually Benjamin's patch does not seem to address anything, which makes
things more confusing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Thu Jan 29 19:45:50 2009
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Thu, 29 Jan 2009 18:45:50 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1233253937.42.0.896928245643.issue2047@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0901291045mf9208cfie6fd244f9771e740@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Thu, Jan 29, 2009 at 1:32 PM, Antoine Pitrou <report at bugs.python.org> wrote:
> Sorry, I had only given a quick look at Benjamin's patch, not yours.
> Actually Benjamin's patch does not seem to address anything, which makes
> things more confusing.

True. It is all a bit unfortunate for such a small change to get
bogged down like this. I specifically asked about the patch proposed
by Christian and implemented by Benjamin (in msg63168) but no one
bothered to reply. Please look at my patch and see if you can apply
it. In fact, I even submitted it when Guido asked for some patches to
test codereview tool initially. It is at
http://codereview.appspot.com/841/show.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Thu Jan 29 20:18:39 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 29 Jan 2009 19:18:39 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <498181FA.9070004@genesilico.pl>
Message-ID: <4982010B.5000503@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I still do not understand what is going on when python executed thic 
> code. I have a local variable l in my parent process. 

No, you don't. It's a global variable, not a local one.

> When I create a 
> child process, program makes first makes a copy of memory. Than what?

It doesn't have to do anything with the multiprocessing at all.
For comparison, just run the Python script

def f():
  del l
l = []
f()

It produces the same error, with no multiprocessing involved.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Thu Jan 29 20:20:09 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 29 Jan 2009 19:20:09 +0000
Subject: [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233234796.85.0.747291335849.issue5076@psf.upfronthosting.co.za>
Message-ID: <49820165.9060804@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Checked into py3k as r6998; merged to release30-maint as 69099.  I hope
> I got that right!

If you ask whether checking into py3k was the right thing: yes, it was.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5076>
_______________________________________

From report at bugs.python.org  Thu Jan 29 20:22:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 29 Jan 2009 19:22:40 +0000
Subject: [issue5098] Environ doesn't escape spaces properly
In-Reply-To: <1233240119.96.0.34005552843.issue5098@psf.upfronthosting.co.za>
Message-ID: <1233256960.76.0.717198161772.issue5098@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As Jean-Paul explains, you are misinterpreting what you are seeing.
Closing as invalid.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5098>
_______________________________________

From report at bugs.python.org  Thu Jan 29 20:39:21 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Jan 2009 19:39:21 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1233243007.39.0.294266016776.issue1717@psf.upfronthosting.co.za>
Message-ID: <bbaeab100901291139l3797147fhcd2176f69ca0705a@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Thu, Jan 29, 2009 at 07:30, Benjamin Peterson <report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> Actually, I would like to repurpose tp_compare as tp_bytes for the
> __bytes__ method.

Repurposing would be extremely bad as that would mean it is possible
for people to actually compile code with a busted __bytes__
implementation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jan 29 20:40:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Jan 2009 19:40:26 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <bbaeab100901291139l3797147fhcd2176f69ca0705a@mail.gmail.com>
Message-ID: <1afaf6160901291140v60d8d691obf34791cced93241@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Thu, Jan 29, 2009 at 2:39 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> Brett Cannon <brett at python.org> added the comment:
>
> On Thu, Jan 29, 2009 at 07:30, Benjamin Peterson <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <benjamin at python.org> added the comment:
>>
>> Actually, I would like to repurpose tp_compare as tp_bytes for the
>> __bytes__ method.
>
> Repurposing would be extremely bad as that would mean it is possible
> for people to actually compile code with a busted __bytes__
> implementation.

Wasn't there another case of an old slot being reused?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jan 29 20:54:19 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Jan 2009 19:54:19 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1afaf6160901291140v60d8d691obf34791cced93241@mail.gmail.com>
Message-ID: <bbaeab100901291154t47adaf09sb9864052db14d80d@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

>> On Thu, Jan 29, 2009 at 07:30, Benjamin Peterson <report at bugs.python.org> wrote:
>>>
>>> Benjamin Peterson <benjamin at python.org> added the comment:
>>>
>>> Actually, I would like to repurpose tp_compare as tp_bytes for the
>>> __bytes__ method.
>>
>> Repurposing would be extremely bad as that would mean it is possible
>> for people to actually compile code with a busted __bytes__
>> implementation.
>
> Wasn't there another case of an old slot being reused?

Not that I can remember, but I'm sure someone will correct me if I'm wrong.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jan 29 21:05:22 2009
From: report at bugs.python.org (Jeroen Dirks)
Date: Thu, 29 Jan 2009 20:05:22 +0000
Subject: [issue5100] ElementTree.iterparse and Element.tail confusion
In-Reply-To: <1233259522.5.0.311608999465.issue5100@psf.upfronthosting.co.za>
Message-ID: <1233259522.5.0.311608999465.issue5100@psf.upfronthosting.co.za>


New submission from Jeroen Dirks <jeroen.dirks at oracle.com>:

I am using cElementTree.iterparse in order to parse through a huge XML
document and filter out sections of interest.

The usage pattern is that I wait for an "end" event for a element of
interest and then if it matches a some criterium I write it out using
cElementTree.tostring().

My code had bug in it because the cElementTree.tostring methods prints
the element including its tail. The element retreived from the iterparse
iterator sometimes contains the tail by the time it emits the end event
but sometimes it does not.

In my document the tail just consisted of the newline '\n' character and
about 98% of the time it was attached to the element during its end event.

This is rather confusing behavior. 

Could ElementTree/cElementTree.iterparse be changed so that if you
respond to the end event for an element its tail is never set?

----------
components: XML
messages: 80783
nosy: jeroen.dirks
severity: normal
status: open
title: ElementTree.iterparse and Element.tail confusion
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5100>
_______________________________________

From report at bugs.python.org  Thu Jan 29 21:20:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Jan 2009 20:20:46 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1233260446.77.0.355593696543.issue2047@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> accepted
versions: +Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Thu Jan 29 21:38:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Jan 2009 20:38:10 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1233261490.4.0.552203866778.issue2047@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed, thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Thu Jan 29 21:38:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Jan 2009 20:38:19 +0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1233261499.78.0.509941926503.issue2047@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
_______________________________________

From report at bugs.python.org  Thu Jan 29 22:04:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Jan 2009 21:04:18 +0000
Subject: [issue5101] test_funcattrs truncated during unittest conversion
In-Reply-To: <1233263058.35.0.644658374842.issue5101@psf.upfronthosting.co.za>
Message-ID: <1233263058.35.0.644658374842.issue5101@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

It looks as though a few of the tests in test_funcattrs disappeared in the 
conversion to unittest, committed in r60522.  (The first one I noticed was 
test_empty_cell, but there are others missing too.)

Question for Georg (who did the checkin): do you know whether these tests 
were removed deliberately?  Or should they be reintroduced if possible?

----------
components: Tests
messages: 80785
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: test_funcattrs truncated during unittest conversion

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5101>
_______________________________________

From report at bugs.python.org  Thu Jan 29 23:30:33 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 22:30:33 +0000
Subject: [issue3311] block operation on closed socket/pipe for multiprocessing
In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
Message-ID: <1233268233.85.0.517790241179.issue3311@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is not critical anymore because jesse.noller fixed the 
crash in r68768.

Python 2.7a0 (trunk:68873M, Jan 23 2009, 08:46:25)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _multiprocessing
>>> obj = _multiprocessing.Connection(755)
>>> obj.close()
>>> obj.poll()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: handle out of range in select()

I would prefer a message "I/O operation on closed socket", but you can 
close this issue.

Note: I proposed a similar patch to improve the error message ("I/O 
operation on closed socket") for the socket module in issue #4853.

----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3311>
_______________________________________

From report at bugs.python.org  Thu Jan 29 23:35:01 2009
From: report at bugs.python.org (Jacques Grove)
Date: Thu, 29 Jan 2009 22:35:01 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>


New submission from Jacques Grove <jacques at tripitinc.com>:

When doing a urllib2 fetch of a url that results in a redirect, the
connection to the redirect does not pass along the timeout of the
original url opener.  The result is that the redirected url fetch (which
is a new request) will get the default socket timeout, instead of the
timeout that the user requested originally.  This is obviously a bug.

So we have in urllib2.py in 2.6.1:

def http_error_302(self, req, fp, code, msg, headers):
.....
    return self.parent.open(new)

this should be:
    return self.parent.open(new, timeout=req.timeout)

or something in that vein.


Of course, to be 100% correct, you should probably keep track of how
much time has elapsed since the original url fetch went out, and reduce
the timeout based on this, but I'm not asking for miracles :-)


Jacques

----------
components: Library (Lib)
messages: 80787
nosy: jacques
severity: normal
status: open
title: urllib2.py timeouts do not propagate across redirects for 2.6.1 (and 3.x?)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Thu Jan 29 23:38:46 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 22:38:46 +0000
Subject: [issue4233] open(0, closefd=False) prints 3 warnings
In-Reply-To: <1225325281.06.0.202625450166.issue4233@psf.upfronthosting.co.za>
Message-ID: <1233268726.95.0.709889918538.issue4233@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue has been fixed in py3k, release30-maint and trunk. I think 
that 2.6.x doesn't need this API change, so I prefer to close this 
issue. Reopen the issue if I'm wrong.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4233>
_______________________________________

From report at bugs.python.org  Thu Jan 29 23:43:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 22:43:38 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1233269018.64.0.0920211311237.issue3618@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The test (io_deadlock.patch) pass on the io-c branch \o/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Thu Jan 29 23:44:27 2009
From: report at bugs.python.org (Jacques Grove)
Date: Thu, 29 Jan 2009 22:44:27 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>


New submission from Jacques Grove <jacques at tripitinc.com>:

In ssl.py of Python 2.6.1 we have this code in  SSLSocket.__init__():

            if do_handshake_on_connect:
                timeout = self.gettimeout()
                try:
                    self.settimeout(None)
                    self.do_handshake()
                finally:
                    self.settimeout(timeout)

The problem is, what happens if the remote end (server) is hanging when
do_handshake() is called?  The result is that the user-requested timeout
will be ignored, and the connection will hang until the TCP socket
timeout expires.

This is easily reproducable with this test code:


import urllib2
urllib2.urlopen("https://localhost:9000/", timeout=2.0)


and running netcat on port 9000, i.e.:

nc -l -p 9000 localhost

If you use "http" instead of "https", the timeout works as expected
(after 2 seconds in this case).

----------
components: Library (Lib)
messages: 80790
nosy: jacques
severity: normal
status: open
title: ssl.SSLSocket timeout not working correctly when remote end is hanging
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:13:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 23:13:38 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1233270818.59.0.883381370647.issue4626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I don't like the change of API to PyTokenizer_FromString. 
> I would prefer another function like 
PyTokenizer_IgnoreCodingCookie()

Ok, I created a new function PyTokenizer_FromUnicode(). I 
choosed "FromUnicode" because the string is encoded in unicode (as 
UTF-8, even if it's not the wchar_t* type).

> The (char *) cast in PyTokenizer_FromString is unneeded.

The cast on the decode_str() result? It was already present in the 
original code. I removed it in my new patch.

> You need to indent the "else" clause after you test for 
ignore_cookie.

Ooops, I always have problems to generate a diff because my editor 
removes trailing spaces and then I have to ignore space changes to 
create  the diff.

> I'd like to see a test that shows that byte strings still have their
cookies examined.

test_pep263 has already two tests using a "#coding:" header.

Added file: http://bugs.python.org/file12889/tokenizer_ignore_cookie-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:13:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 23:13:48 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1228976357.63.0.133847904092.issue4626@psf.upfronthosting.co.za>
Message-ID: <1233270828.82.0.552864117236.issue4626@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12771/tokenizer_ignore_cookie-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:15:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 23:15:27 +0000
Subject: [issue3610] Fix gdbinit for Python 3.0
In-Reply-To: <1219194498.13.0.487280154525.issue3610@psf.upfronthosting.co.za>
Message-ID: <1233270927.12.0.111823862186.issue3610@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch is now outdated.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3610>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:21:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 23:21:48 +0000
Subject: [issue3880] _tkinter._flatten() doesn't check PySequence_Size() error
	code
In-Reply-To: <1221572716.31.0.755070088085.issue3880@psf.upfronthosting.co.za>
Message-ID: <1233271308.45.0.955995313288.issue3880@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The bug is still here in py3k:

$ cat bla.py
import _tkinter, gc
_tkinter._flatten(True)
gc.collect()

$ ./python bla.py
Exception TypeError: "object of type 'bool' has no len()" in 'garbage 
collection' ignored
Fatal Python error: unexpected exception during garbage collection
Abandon (core dumped)

Can anyone apply my patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3880>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:23:57 2009
From: report at bugs.python.org (Roman Zeyde)
Date: Thu, 29 Jan 2009 23:23:57 +0000
Subject: [issue5104] getsockaddrarg() casts port number from int to short
	without any warning
In-Reply-To: <1233271436.92.0.964920785544.issue5104@psf.upfronthosting.co.za>
Message-ID: <1233271436.92.0.964920785544.issue5104@psf.upfronthosting.co.za>


New submission from Roman Zeyde <roman.zeyde at gmail.com>:

The following code shouldn't fail without any warning at all:

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('localhost', 70000))
>>> print(s.getsockname())
('127.0.0.1', 4464)

After looking through socketmodule.c (rev. 68450), it seems that AF_INET
case casts an "int port" into a "short addr->sin_port", and does not
checks for overflows:

	case AF_INET:
	{
		struct sockaddr_in* addr;
		char *host;
		int port, result;
		if (!PyTuple_Check(args)) {
			PyErr_Format(
				PyExc_TypeError,
				"getsockaddrarg: "
				"AF_INET address must be tuple, not %.500s",
				Py_TYPE(args)->tp_name);
			return 0;
		}
		if (!PyArg_ParseTuple(args, "eti:getsockaddrarg",
				      "idna", &host, &port))
			return 0;
		addr=(struct sockaddr_in*)addr_ret;
                result = setipaddr(host, (struct sockaddr *)addr,
                                   sizeof(*addr),  AF_INET);
                PyMem_Free(host);
                if (result < 0)
			return 0;
		addr->sin_family = AF_INET;
		addr->sin_port = htons((short)port);
		*len_ret = sizeof *addr;
		return 1;
	}

----------
components: None
messages: 80794
nosy: roman.zeyde
severity: normal
status: open
title: getsockaddrarg() casts port number from int to short without any warning
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5104>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:24:23 2009
From: report at bugs.python.org (Roman Zeyde)
Date: Thu, 29 Jan 2009 23:24:23 +0000
Subject: [issue5104] getsockaddrarg() casts port number from int to short
	without any warning
In-Reply-To: <1233271436.92.0.964920785544.issue5104@psf.upfronthosting.co.za>
Message-ID: <1233271463.37.0.498647573655.issue5104@psf.upfronthosting.co.za>


Changes by Roman Zeyde <roman.zeyde at gmail.com>:


----------
components: +Extension Modules -None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5104>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:25:45 2009
From: report at bugs.python.org (Roman Zeyde)
Date: Thu, 29 Jan 2009 23:25:45 +0000
Subject: [issue5104] getsockaddrarg() casts port number from int to short
	without any warning
In-Reply-To: <1233271436.92.0.964920785544.issue5104@psf.upfronthosting.co.za>
Message-ID: <1233271545.05.0.0767386328089.issue5104@psf.upfronthosting.co.za>


Changes by Roman Zeyde <roman.zeyde at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5104>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:36:20 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 23:36:20 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1233272180.53.0.386448904211.issue4474@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

For lemburg, updated patch:
 - Move USE_WCHAR_SURROGATE define outside PyUnicode_FromWideChar() 
(and indent the defines, sorry)
 - Add "#define SIZEOF_WCHAR_T 2" to PC/pyconfig.h

Added file: http://bugs.python.org/file12890/unicode_fromwidechar_surrogate-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:36:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 23:36:25 +0000
Subject: [issue4474] PyUnicode_FromWideChar incorrect for characters outside
	the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1233272185.02.0.572273335883.issue4474@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12822/unicode_fromwidechar_surrogate-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:37:26 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 23:37:26 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1233272246.59.0.821530498821.issue4487@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4487>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:39:02 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 29 Jan 2009 23:39:02 +0000
Subject: [issue5104] getsockaddrarg() casts port number from int to short
	without any warning
In-Reply-To: <1233271436.92.0.964920785544.issue5104@psf.upfronthosting.co.za>
Message-ID: <1233272342.52.0.264480776314.issue5104@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

heh yes, not a big deal but this should raise an overflow error in that 
case.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5104>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:48:39 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 23:48:39 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1233272919.67.0.876686193801.issue1726687@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> But negative time_t are still not allowed by the Microsoft CRT, 
> the tests fail.
> (...)
> is this a bug or a feature request?

Linux mktime() supports any timestamp from 1901..2038. Should we limit 
the timestamp to 1970 just because of Microsoft? Test tm_wday fixes a 
bug on Linux and doesn't change the behaviour on Windows. So the 
problem is just the unit test: the test should be different on Windows 
(make sure that -1 raises an error).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Fri Jan 30 00:53:31 2009
From: report at bugs.python.org (Brandon Adams)
Date: Thu, 29 Jan 2009 23:53:31 +0000
Subject: [issue5105] sqlite3.Row class,
	handling duplicate column names resulting from a SQL join
In-Reply-To: <1233273211.24.0.156313751238.issue5105@psf.upfronthosting.co.za>
Message-ID: <1233273211.24.0.156313751238.issue5105@psf.upfronthosting.co.za>


New submission from Brandon Adams <sockonafish at gmail.com>:

When using sqlite3.Row as the row_factory for a sqlite3 connection and 
performing a SQL join that returns rows from two or more tables with 
identical column names, the returned sqlite3.Row object contains 
duplicate keys.  Subsequently, when trying to access values by key, only 
the value contained in the lowest numbered index matching the key is 
returned.  Additionally, attempting to use the keys returned to create a 
new table in the database fails due to a duplicate column name error.

A better behavior would be for the sqlite3.Row object's indices to be 
prefixed with table names for cases in which a query produces results 
from two or more tables.

----------
components: Library (Lib)
messages: 80798
nosy: sockonafish
severity: normal
status: open
title: sqlite3.Row class, handling duplicate column names resulting from a SQL join
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5105>
_______________________________________

From report at bugs.python.org  Fri Jan 30 01:05:29 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jan 2009 00:05:29 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1233273929.89.0.125629712649.issue1726687@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My test included in mktime_fix_and_tests.patch has a problem: the 
timezone is constant and it's mine (GMT+1). I don't know how to write 
a generic test working on any time zone. I can't use 
datetime.fromtimestamp() because datetime.fromtimestamp() uses 
time.mktime() :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Fri Jan 30 01:32:28 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Jan 2009 00:32:28 +0000
Subject: [issue5085] distutils/test_sdist failure on windows
In-Reply-To: <1233095615.15.0.606843588925.issue5085@psf.upfronthosting.co.za>
Message-ID: <1233275548.07.0.537518421882.issue5085@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Just saw that issue, thanks, the bug was fixed some minutes ago.

I came up with about the same fix, see r69106

----------
assignee:  -> tarek
nosy: +tarek
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5085>
_______________________________________

From report at bugs.python.org  Fri Jan 30 01:40:07 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 30 Jan 2009 00:40:07 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1233276007.95.0.154271722672.issue4673@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I will continue to discuss this in distutils-SIG:

Marc-Andr? Lemburg proposed me to introduce the uninstall command from
mxSetup.py (from mxBase, http://www.egenix.com/products/python/mxBase/)

So I need to ask for opinions first

----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4673>
_______________________________________

From report at bugs.python.org  Fri Jan 30 02:18:34 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Jan 2009 01:18:34 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1233278314.19.0.831527834142.issue3783@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am also working on a patch for this and would like to coordinate.  My
first draft is attached:

Added file: http://bugs.python.org/file12891/tmp_dev_shelver.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Jan 30 02:37:35 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 30 Jan 2009 01:37:35 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1233279455.99.0.780871147893.issue3783@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Some comments on tmp_dev_shelver.py...

Regarding SQLhash.__init__, it would be better to avoid relying on the
"sqlite_master" table by using the CREATE TABLE IF NOT EXISTS form of
table creation.

Setting the isolation_level in __init__ will have essentially no effect
on this code because there is currently no transaction management in the
code.  However, the rest of the code also has almost no effect, because
there are no commits anywhere in SQLhash.  All the data is always lost
when the connection is closed.

Regarding the XXX in SQLhash.__len__, there is no faster way using
"sqlite_master".  There is basically just one way to make COUNT(*) fast.
 Keep track of the count in the database (update it on inserts and
deletes).  Then, use that instead of using COUNT(*).

Once there is some use of transactions, it will indeed be important, in
DBhash.__setitem__, to make sure the delete and the insert are in the
same transaction.  Actually, a different approach would be better,
though.  INSERT OR REPLACE INTO will let you replace a row's value with
one statement.  It's also faster, since the row only has to be found once.

Additionally, an index on the key column will assist performance
substantially for large data sets.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Jan 30 03:00:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Jan 2009 02:00:54 +0000
Subject: [issue4626] compile() doesn't ignore the source encoding when a
	string is passed in
In-Reply-To: <1233270818.59.0.883381370647.issue4626@psf.upfronthosting.co.za>
Message-ID: <1afaf6160901291800y2b6330dcp12282ebc5e2969eb@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Thu, Jan 29, 2009 at 5:13 PM, STINNER Victor <report at bugs.python.org> wrote:
> Ok, I created a new function PyTokenizer_FromUnicode(). I
> choosed "FromUnicode" because the string is encoded in unicode (as
> UTF-8, even if it's not the wchar_t* type).

How about PyTokenizer_FromUTF8() then?

>
>> The (char *) cast in PyTokenizer_FromString is unneeded.
>
> The cast on the decode_str() result? It was already present in the
> original code. I removed it in my new patch.

No, I was referring to this line:

tok->encoding = (char *)PyMem_MALLOC

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4626>
_______________________________________

From report at bugs.python.org  Fri Jan 30 03:25:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Jan 2009 02:25:26 +0000
Subject: [issue3880] _tkinter._flatten() doesn't check PySequence_Size() error
	code
In-Reply-To: <1221572716.31.0.755070088085.issue3880@psf.upfronthosting.co.za>
Message-ID: <1233282326.75.0.510567871451.issue3880@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r69113.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3880>
_______________________________________

From report at bugs.python.org  Fri Jan 30 03:30:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Jan 2009 02:30:00 +0000
Subject: [issue5087] set_daemon does not exist in Thread
In-Reply-To: <1233105930.75.0.986865589873.issue5087@psf.upfronthosting.co.za>
Message-ID: <1233282600.1.0.650260112601.issue5087@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r69114.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5087>
_______________________________________

From report at bugs.python.org  Fri Jan 30 04:01:00 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Fri, 30 Jan 2009 03:01:00 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1233284460.95.0.494273295488.issue5094@psf.upfronthosting.co.za>


HiroakiKawai <kawai at apache.org> added the comment:

I want UTC tzinfo. too.

----------
nosy: +kawai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri Jan 30 04:06:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Jan 2009 03:06:32 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1233284792.05.0.554763040701.issue3783@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for looking at this.  I'll do an update in the next few days.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Jan 30 04:15:47 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 30 Jan 2009 03:15:47 +0000
Subject: [issue5041] Memory leak in imp.find_module
In-Reply-To: <1232807512.09.0.43179112168.issue5041@psf.upfronthosting.co.za>
Message-ID: <1233285347.25.0.340724561092.issue5041@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Fixed in r69117(py3k).

----------
keywords:  -needs review
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5041>
_______________________________________

From report at bugs.python.org  Fri Jan 30 04:50:24 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Jan 2009 03:50:24 +0000
Subject: [issue5106] Update Naming & Binding statement for 3.0
In-Reply-To: <1233287424.89.0.100401288129.issue5106@psf.upfronthosting.co.za>
Message-ID: <1233287424.89.0.100401288129.issue5106@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Language / Execution Model / Naming & Binding 
just before example that does not work, 

class A:
    a = 42
    b = list(a + i for i in range(10))

says :
"The scope of names defined in a class block is limited to the class
block; it does not extend to the code blocks of methods ? this includes
generator expressions since they are implemented using a function scope."

As pointed out by Alan Isaacs (clp), in 3.0,
"this includes comprehensions and generator expressions"
would be more complete and not possibly imply that g.e.s are special in
this regard.  In 2.x, 
    c = [a + i for i in range(10)]
works but it fails with same 
"NameError: global name 'a' is not defined"
in 3.0.  In fact, I think 'comprehensions and ' should be added just
because this is a change which people could trip over.

----------
assignee: georg.brandl
components: Documentation
messages: 80810
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Update Naming & Binding statement for 3.0
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5106>
_______________________________________

From report at bugs.python.org  Fri Jan 30 06:00:28 2009
From: report at bugs.python.org (John Machin)
Date: Fri, 30 Jan 2009 05:00:28 +0000
Subject: [issue5107] built-in open(..., encoding=vague_default)
In-Reply-To: <1233291628.48.0.339738109946.issue5107@psf.upfronthosting.co.za>
Message-ID: <1233291628.48.0.339738109946.issue5107@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

Docs say """The default encoding is platform dependent""" but don't say
how to find out what that is, or how it is determined. On my Windows XP
SP3 setup, the default is cp1252, but the best/only guess at finding out
without actually opening a file involved sys.defaultencoding() which
produces 'utf-8'. I was pointed at locale.getpreferredencoding(), which
returns 'cp1252' on my machine.

Please add a sentence along these lines: The default encoding is
(obtained by calling|the same as) locale.getpreferredencoding(), not
sys.getdefaultencoding() -- corrected/amplified as necessary.

----------
assignee: georg.brandl
components: Documentation
messages: 80811
nosy: georg.brandl, sjmachin
severity: normal
status: open
title: built-in open(..., encoding=vague_default)
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5107>
_______________________________________

From report at bugs.python.org  Fri Jan 30 11:53:04 2009
From: report at bugs.python.org (Jerzy)
Date: Fri, 30 Jan 2009 10:53:04 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <4982010B.5000503@v.loewis.de>
Message-ID: <4982DBF3.4060602@genesilico.pl>


Jerzy <jerzyo at genesilico.pl> added the comment:

OK, I see and if don't want l to exist in f() I have to:

def f():
   pass

def a():
   l=[]
   f()

a()

????

Jurek

Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> I still do not understand what is going on when python executed thic 
>> code. I have a local variable l in my parent process. 
> 
> No, you don't. It's a global variable, not a local one.
> 
>> When I create a 
>> child process, program makes first makes a copy of memory. Than what?
> 
> It doesn't have to do anything with the multiprocessing at all.
> For comparison, just run the Python script
> 
> def f():
>   del l
> l = []
> f()
> 
> It produces the same error, with no multiprocessing involved.
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5092>
> _______________________________________
> 
> 
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Fri Jan 30 12:01:16 2009
From: report at bugs.python.org (Jerzy)
Date: Fri, 30 Jan 2009 11:01:16 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <4982010B.5000503@v.loewis.de>
Message-ID: <4982DDE3.7050007@genesilico.pl>


Jerzy <jerzyo at genesilico.pl> added the comment:

And anyway, for me it's not OK if something in a code of a function like 
'del' affect how variables are affected in whole function.

It is really illogical. There code is in lines and line are one below 
another. The logical way is that a line of code affects the program ONLY 
when it is executed and ONLY from the time it is executed. A statement 
that is not executed (python never reach the place) should not affect 
the program in ANY way.

You may think what you think, but for me it is a big bug in the heart of 
python

Jerzy

Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> I still do not understand what is going on when python executed thic 
>> code. I have a local variable l in my parent process. 
> 
> No, you don't. It's a global variable, not a local one.
> 
>> When I create a 
>> child process, program makes first makes a copy of memory. Than what?
> 
> It doesn't have to do anything with the multiprocessing at all.
> For comparison, just run the Python script
> 
> def f():
>   del l
> l = []
> f()
> 
> It produces the same error, with no multiprocessing involved.
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5092>
> _______________________________________
> 
> 
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Fri Jan 30 12:26:58 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jan 2009 11:26:58 +0000
Subject: [issue5108] Invalid UTF-8 ("%s") length in PyUnicode_FromFormatV()
In-Reply-To: <1233314818.25.0.50797871273.issue5108@psf.upfronthosting.co.za>
Message-ID: <1233314818.25.0.50797871273.issue5108@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_FromFormatV() doesn't count correctly the unicode length of 
an UTF-8 string. Commit r57837 "Change %s argument for 
PyUnicode_FromFormat to be UTF-8. Fixes #1070." introduced the bug. To 
compute the length, it uses a a complex code to compute the length of 
the UTF-8 string, whereas PyUnicode_DecodeUTF8(p, 
strlen(p), "replace") + Py_UNICODE_COPY() is used to copy the string. 
The problem may comes from the error handling ("replace").

Valgrind show that the error occurs at Py_UNICODE_COPY(): Invalid 
write of size 1. Since it's only one byte, Python does not always 
crash.

To reproduce the crash, use PyUnicode_FromFormatV() or function using 
it: PyUnicode_FromFormat(), PyErr_Format(), ...

Example 1:

    import grp
    
x=["\uDBE7\u8C99", "\u9C31\uF8DC\u3EC5\u1804\u629D\uE748\u68C8\uCF74\u9E63\uF647\uBF7A\uED63"]
    x=str(x)
    grp.getgrnam(x)

Example 2:

    import unicodedata
    x 
= "\\udbe7\u8c99', '\u9c31\\uf8dc\u3ec5\u1804\u629d\\ue748\u68c8\ucf74\u9e63\\uf647\ubf7a\\ued63"
    unicodedata.lookup(x)

I wrote a patch reusing PyUnicode_DecodeUTF8(p, strlen(p), "replace") 
+ PyUnicode_GET_SIZE() to get the real length of the converted UTF-8 
string.

A better patch should reuse code used to convert UTF-8 to Unicode with 
the "replace" error handling.

----------
components: Unicode
messages: 80814
nosy: haypo
severity: normal
status: open
title: Invalid UTF-8 ("%s") length in PyUnicode_FromFormatV()
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5108>
_______________________________________

From report at bugs.python.org  Fri Jan 30 12:27:05 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jan 2009 11:27:05 +0000
Subject: [issue5108] Invalid UTF-8 ("%s") length in PyUnicode_FromFormatV()
In-Reply-To: <1233314818.25.0.50797871273.issue5108@psf.upfronthosting.co.za>
Message-ID: <1233314825.45.0.472276218622.issue5108@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file12892/unicode_format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5108>
_______________________________________

From report at bugs.python.org  Fri Jan 30 13:33:27 2009
From: report at bugs.python.org (Malcolm Purvis)
Date: Fri, 30 Jan 2009 12:33:27 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>


New submission from Malcolm Purvis <malcolm at purvis.id.au>:

Copying an array.array object via the array constructor is some 100x
slower than using slicing or even converting the array to a string and
then passing that string to the array constructor.

Running the attached program on a 2.2GHz MacBook Pro (OSX 10.5.5, 4GB
RAM) produces this output:

$ python2.6 array_test.py
Constructor:  18.5617749691
Slice:  0.169251918793
String:  0.375015974045

>From a look at arraymodule.c it seems that array_new() does not have a
special case for the array type and therefore uses the generic sequence
copy code rather than using memcpy(), like it can for slicing.

----------
components: Library (Lib)
files: array_test.py
messages: 80815
nosy: malcolmp
severity: normal
status: open
title: array.array constructor very slow when passed an array object.
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file12893/array_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Fri Jan 30 14:18:46 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 30 Jan 2009 13:18:46 +0000
Subject: [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1233321526.77.0.917361245111.issue4908@psf.upfronthosting.co.za>


Changes by Floris Bruynooghe <floris.bruynooghe at gmail.com>:


----------
nosy: +flub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Fri Jan 30 14:27:39 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 30 Jan 2009 13:27:39 +0000
Subject: [issue3610] Fix gdbinit for Python 3.0
In-Reply-To: <1219194498.13.0.487280154525.issue3610@psf.upfronthosting.co.za>
Message-ID: <1233322059.57.0.260468845969.issue3610@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

The gdbinit file for Python 3 is still broken.  I've not been able to
figure out how to get a string encoded as utf-8 from a Unicode object
without needing a process around.  If you require a process then
gdbinit becomes much less useful since it won't work with core files.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3610>
_______________________________________

From report at bugs.python.org  Fri Jan 30 14:57:41 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 30 Jan 2009 13:57:41 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1233323861.07.0.309938896517.issue3783@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Unassigning myself.  I don't have time for this.  I've taken my sandbox
version about as far as I can, and the subject of this ticket has
gone a bit far afield from just adding a sqlite module to the dbm pkg.

----------
assignee: skip.montanaro -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Jan 30 15:40:25 2009
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 30 Jan 2009 14:40:25 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <1233188020.97.0.306560555097.issue5092@psf.upfronthosting.co.za>
Message-ID: <1233326425.97.0.690405797973.issue5092@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

The alternative is unreasonable.  I doubt you'd be happy with this:


a = 'Something'

def variable_both_global_and_local()->Exception('No good!'):
    del a    # delete a from global name space
    a = 'anotherthing'  # define a in local name space

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Fri Jan 30 16:00:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Jan 2009 15:00:42 +0000
Subject: [issue5107] built-in open(..., encoding=vague_default)
In-Reply-To: <1233291628.48.0.339738109946.issue5107@psf.upfronthosting.co.za>
Message-ID: <1233327642.56.0.470276864009.issue5107@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is more complicated than that. The algorithm is currently as follows
(copied from TextIOWrapper.__init__):

        if encoding is None:
            try:
                encoding = os.device_encoding(buffer.fileno())
            except (AttributeError, UnsupportedOperation):
                pass
            if encoding is None:
                try:
                    import locale
                except ImportError:
                    # Importing locale may fail if Python is being built
                    encoding = "ascii"
                else:
                    encoding = locale.getpreferredencoding()

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5107>
_______________________________________

From report at bugs.python.org  Fri Jan 30 16:26:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Jan 2009 15:26:49 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

In Py2.x
>>> u'\2620'
outputs u'\2620' whereas
>>> print u'\2620'
raises an error.

Instead, in Py3.x, both
>>> '\u2620'
and
>>> print('\u2620')
raise an error if the terminal doesn't use an encoding able to display
the character (e.g. the windows terminal used for these examples).

This is caused by the new string representation defined in the PEP3138[1].

Consider also the following example:
Py2:
>>> [u'\u2620']
[u'\u2620']
Py3:
>>> ['\u2620']
UnicodeEncodeError: 'charmap' codec can't encode character '\u2620' in
position 9: character maps to <undefined>

This means that there is no way to print lists (or other objects) that
contain characters that can't be encoded.
Two workarounds may be:
1) encode all the elements of the list, but it's not practical;
2) use ascii(), but it adds extra "" around the output and escape
backslashes and apostrophes (and it won't be possible to use _[0] in the
next line).
 
Also note that in Py3
>>> ['\ud800']
['\ud800']
>>> _[0]
'\ud800'
works, because U+D800 belongs to the category "Cs (Other, Surrogate)"
and it is escaped[2].

The best solution is probably to change the default error-handler of the
Python3 interactive interpreter to 'backslashreplace' in order to avoid
this behavior, but I don't know if it's possible only for ">>> foo" and
not for ">>> print(foo)" (print() should still raise an error as it does
in Py2).

This proposal has already been refused in the PEP3138[3] but there are
no links to the discussion that led to this decision.

I think this should be rediscussed and possibly changed, because, even
if can't see the "listOfJapaneseStrings"[4], I still prefer to see a
sequence of escaped chars than a UnicodeEncodeError.

[1]: http://www.python.org/dev/peps/pep-3138/
[2]: http://www.python.org/dev/peps/pep-3138/#specification
[3]: http://www.python.org/dev/peps/pep-3138/#rejected-proposals
[4]: http://www.python.org/dev/peps/pep-3138/#motivation

----------
components: Unicode
messages: 80820
nosy: ezio.melotti
severity: normal
status: open
title: Printing Unicode chars from the interpreter in a non-UTF8 terminal (Py3)
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Fri Jan 30 16:31:50 2009
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 30 Jan 2009 15:31:50 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1233329510.2.0.359232699863.issue5109@psf.upfronthosting.co.za>


David W. Lambert <lambertdw at corning.com> added the comment:

memcpy won't work if the data type changes.  (possibly signed <-> 
unsigned same-byte-count works).

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Fri Jan 30 16:43:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jan 2009 15:43:19 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233330199.81.0.327157172192.issue5110@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

To be clear, this issue only affects the interpreter.

> 2) use ascii(), but it adds extra "" around the output

It doesn't ass extra "" if you replace repr() by ascii() in the 
interpreter code (sys.displayhook)?

> The best solution is probably to change the default error-handler 
> of the Python3 interactive interpreter to 'backslashreplace' 
> in order to avoid this behavior, (...)

Hum, it implies that sys.stdout has a different behaviour in the 
interpreter and when running a script. We can expect many bugs ports 
from newbies "the example works in the terminal/IDLE, but not in my 
script, HELP!". So I prefer ascii().

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Fri Jan 30 16:46:51 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jan 2009 15:46:51 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233330411.92.0.907757406611.issue5110@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You change change the display hook with a site.py script (which have 
to be in sys.path) :
---------
import sys

def hook(message):
    print(ascii(message))

sys.displayhook = hook
---------

Example (run python in an empty environment to get ASCII charset):
---------
$ env -i PYTHONPATH=$PWD ./python
Python 3.1a0 (py3k:69105M, Jan 30 2009, 10:36:27)
>>> import sys
>>> sys.stdout.encoding
'ANSI_X3.4-1968'
>>> "\xe9"
'\xe9'
>>> print("\xe9")
Traceback (most recent call last):
  (...)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' (...)
---------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Fri Jan 30 16:55:33 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Jan 2009 15:55:33 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233330933.13.0.447224596063.issue5110@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This seems to solve the problem, but apparently the interactive "_"
doesn't work anymore.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Fri Jan 30 16:57:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jan 2009 15:57:27 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233331047.31.0.759914829027.issue5110@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh yeah, original sys.displayhook uses a special hack for the _ global 
variable:
---------
import sys
import builtins

def hook(message):
    if message is None:
        return
    builtins._ = message
    print(ascii(message))

sys.displayhook = hook
---------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Fri Jan 30 17:04:15 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jan 2009 16:04:15 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233331455.63.0.735254479903.issue5110@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch to use ascii() directly in sys_displayhook() (with an 
unit test!).

----------
keywords: +patch
Added file: http://bugs.python.org/file12894/display_hook_ascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Fri Jan 30 17:31:23 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Jan 2009 16:31:23 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1233333083.5.0.916670063317.issue3783@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Jan 30 17:48:59 2009
From: report at bugs.python.org (Guillaume Desmottes)
Date: Fri, 30 Jan 2009 16:48:59 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	loopback
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>


New submission from Guillaume Desmottes <gdesmott at gnome.org>:

To reproduce:
- Launch a HTTP server listening on an Inet6 socket on, say, port 5555
- Try to connect using the IPv6 loopback: 
http = httplib.HTTPConnection('[::1]:5555')
http.request('GET', '/foo')
r = http.getresponse()
print r.status
- You get 400 (bad-request) instead of 404

It seems that's because the HTTP request is wrong. Python sends this header:
Host: ::1:5555
but it should be:
Host: [::1]:5555

I'm using python 2.5.2-1ubuntu1 on Intrepid.

----------
components: Library (Lib)
messages: 80827
nosy: gdesmott
severity: normal
status: open
title: httplib: wrong Host header when connecting to IPv6 loopback
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Fri Jan 30 18:01:13 2009
From: report at bugs.python.org (Kevin Watters)
Date: Fri, 30 Jan 2009 17:01:13 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233334873.11.0.117390107156.issue4753@psf.upfronthosting.co.za>


Kevin Watters <kevinwatters at gmail.com> added the comment:

Does anyone know the equivalent ICC command line option for GCC's -fno-
gcse? (Or if it has one?) I can't find a related option in the docs.

It looks like ICC hits the same combining goto problem, as was 
mentioned: without changing any options, I applied pitrou_dispatch_2.7.patch to release-26maint and pybench reported 
literally no difference, +0.0%.

Even if stock Python is built with MSVC, devs like myself who ship 
Python would like to see the benefit.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan 30 18:06:45 2009
From: report at bugs.python.org (Guillaume Desmottes)
Date: Fri, 30 Jan 2009 17:06:45 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1233335205.01.0.0976836916516.issue5111@psf.upfronthosting.co.za>


Guillaume Desmottes <gdesmott at gnome.org> added the comment:

Actually, this bug is present when you try to connect to any URL
containing an IP6 and a port.

So, we have the same problem when using, for example:
http = httplib.HTTPConnection('[2a01:8790:16d:0:218:de87:164:8745]:5555')

but
http = httplib.HTTPConnection('[2001:4860:0:1001::68]:80')

does work. Probably because we use the default HTTP port.

----------
title: httplib: wrong Host header when connecting to IPv6 loopback -> httplib: wrong Host header when connecting to IPv6 litteral URL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Fri Jan 30 18:38:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 30 Jan 2009 17:38:50 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233337130.4.0.686120307796.issue1717@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's stage 2:  remove uses of tp_compare from Objects and Modules, and
replace uses of PyObject_Compare with PyObject_RichCompareBool.
PyObject_Compare, cmp and friends still haven't been removed at this
stage.

In detail:
  - for cell objects, method wrapper objects, PyTclObjects, and
    PyST_Objects (in the parser module), remove the defined tp_compare
    methods and implement tp_richcompare instead.
  - add tests for cell comparisons and PyST_Object comparisons;  
reenable
    tests for method wrapper comparisons.  There are no tests for the
    PyTclObject comparisons.
  - remove tp_compare method from sets (all it did was emit an error
    message about the nonsensicality of doing order comparisons on sets)
  - in Objects/rangeobject.c and ElementTree, replace uses of
    PyObject_Compare with PyObject_RichCompareBool

Added file: http://bugs.python.org/file12895/1717_stage2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Fri Jan 30 19:25:44 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Jan 2009 18:25:44 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1233339944.03.0.0796986569075.issue3783@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file12896/dbsqlite.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Jan 30 19:41:18 2009
From: report at bugs.python.org (Michael Welsh Duggan)
Date: Fri, 30 Jan 2009 18:41:18 +0000
Subject: [issue5112] Incorrect documentation for PyErr_BadInternalCall
In-Reply-To: <1233340878.84.0.440465699769.issue5112@psf.upfronthosting.co.za>
Message-ID: <1233340878.84.0.440465699769.issue5112@psf.upfronthosting.co.za>


New submission from Michael Welsh Duggan <mwd at sei.cmu.edu>:

Documentation says that this call is shorthand for
PyErr_SetString(PyExc_TypeError, message), but is instead shorthand for
PyErr_SetString(PyExc_SystemError, message).

----------
assignee: georg.brandl
components: Documentation
messages: 80831
nosy: georg.brandl, md5i
severity: normal
status: open
title: Incorrect documentation for PyErr_BadInternalCall
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5112>
_______________________________________

From report at bugs.python.org  Fri Jan 30 19:46:03 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 30 Jan 2009 18:46:03 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233341163.67.0.849891803017.issue5110@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Fri Jan 30 20:04:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 30 Jan 2009 19:04:30 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233342270.52.0.457682539909.issue4753@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The x86 gentoo buildbot is failing to compile, with error:

/Python/makeopcodetargets.py ./Python/opcode_targets.h
  File "./Python/makeopcodetargets.py", line 28
    f.write(",\n".join("\t&&%s" % s for s in targets))
                                      ^
SyntaxError: invalid syntax
make: *** [Python/opcode_targets.h] Error 1

I suspect that it's because the system Python on this buildbot is Python 
2.3, which doesn't understand generator expressions.  Are there any 
objections to me adding a couple of square brackets to this line to turn 
the argument of join into a list comprehension?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan 30 20:21:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 30 Jan 2009 19:21:02 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233343262.09.0.66206992509.issue4753@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One other thought:  it seems that as a result of this change, the py3k 
build process now depends on having some version of Python already 
installed;  before this, it didn't.  Is this true, or am I misinterpreting 
something?

Might it be worth adding the file Python/opcode_targets.h to the 
distribution to avoid this problem?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan 30 20:23:21 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 30 Jan 2009 19:23:21 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233343401.72.0.928597226295.issue4753@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry:  ignore that last.  Python/opcode_targets.h is already part of the 
distribution.  I don't know what I was doing wrong.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan 30 21:12:13 2009
From: report at bugs.python.org (Andreas Kupries)
Date: Fri, 30 Jan 2009 20:12:13 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>


New submission from Andreas Kupries <andreask at activestate.com>:

The 'test_posix' of Python's 2.5.4.3 testsuite fails on HPUX. This has
happened on parisc and ia64 systems. On the parisc system failure occurs
for both parisc1.1 and parisc2.0w builds. The HPUX versions are 11.00
(parisc) and 11.22 (ia64).

The attached file contains the output of executing

./apy/bin/python2.5 ./apy/lib/python2.5/test/regrtest.py -v test_posix

----------
components: Tests
files: bug-test_posix-hpux.log
messages: 80835
nosy: andreask
severity: normal
status: open
title: 2.5.4.3 / test_posix failing on HPUX systems
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12897/bug-test_posix-hpux.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Fri Jan 30 21:24:54 2009
From: report at bugs.python.org (Andreas Kupries)
Date: Fri, 30 Jan 2009 20:24:54 +0000
Subject: [issue5114] 2.5.4.3 / test_threading hangs
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>


New submission from Andreas Kupries <andreask at activestate.com>:

On two machines I have seen test_threading hang in ...
HPUX 11.22 ia64,
Solaris 5.8 sparc

The attached file contains the output of running

./apy/bin/python2.5 ./apy/lib/python2.5/test/regrtest.py -v test_threading

on the problematic machines.

It is necessary to kill one of the subprocesses to force forward
progress. A partial output of 'ps -ef' on the HPUX machine is

andreask 26601 26552  0 12:13:50 pts/1     0:00 ./apy/bin/python2.5
./apy/lib/python2.5/test/regrtest.py -v tes
andreask 26657 26601  0 12:14:26 pts/1     0:00
/home/andreask/tmp/autotest/apy/bin/python2.5 -c if 1:^J
andreask 26658 26657  0 12:14:26 pts/1     0:00
/home/andreask/tmp/autotest/apy/bin/python2.5 -c if 1:^J

And I usually kill the bottom most process.

----------
components: Tests
files: bug-test_threading-hpux-solaris.log
messages: 80836
nosy: andreask
severity: normal
status: open
title: 2.5.4.3 / test_threading hangs
versions: Python 2.5
Added file: http://bugs.python.org/file12898/bug-test_threading-hpux-solaris.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5114>
_______________________________________

From report at bugs.python.org  Fri Jan 30 21:38:37 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 30 Jan 2009 20:38:37 +0000
Subject: [issue4375] inspect.getsource doesn't work with PYTHONPATH and source
	compiled from a different dir
In-Reply-To: <1227261204.44.0.0137459794576.issue4375@psf.upfronthosting.co.za>
Message-ID: <1233347917.03.0.199266179828.issue4375@psf.upfronthosting.co.za>


Erick Tryzelaar <idadesub at users.sourceforge.net> added the comment:

I just checked, and the latest svn version of python has fixed this. Could 
someone close this bug for me?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4375>
_______________________________________

From report at bugs.python.org  Fri Jan 30 21:39:09 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 30 Jan 2009 20:39:09 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1233347949.21.0.943019848255.issue4673@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4673>
_______________________________________

From report at bugs.python.org  Fri Jan 30 21:40:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 30 Jan 2009 20:40:27 +0000
Subject: [issue1205239] Let shift operators take any integer value
Message-ID: <1233348027.76.0.804761555518.issue1205239@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1205239>
_______________________________________

From report at bugs.python.org  Fri Jan 30 21:54:37 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 30 Jan 2009 20:54:37 +0000
Subject: [issue5107] built-in open(..., encoding=vague_default)
In-Reply-To: <1233291628.48.0.339738109946.issue5107@psf.upfronthosting.co.za>
Message-ID: <1233348877.4.0.13556716397.issue5107@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5107>
_______________________________________

From report at bugs.python.org  Fri Jan 30 21:59:38 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 30 Jan 2009 20:59:38 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1233349178.25.0.750725669535.issue5103@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Fri Jan 30 22:38:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Jan 2009 21:38:52 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233351532.86.0.653431599097.issue4753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Mark:

"""Are there any objections to me adding a couple of square brackets to
this line to turn the argument of join into a list comprehension?"""

No problems for me. You might also add to the top comments of the file
that it is 2.3-compatible.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Fri Jan 30 23:22:20 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Jan 2009 22:22:20 +0000
Subject: [issue4124] Patch for adding "default" to itemgetter and attrgetter
In-Reply-To: <1224022053.76.0.0750871741065.issue4124@psf.upfronthosting.co.za>
Message-ID: <1233354140.76.0.560373406618.issue4124@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will take a look at it next week.

----------
assignee:  -> rhettinger
nosy: +rhettinger
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4124>
_______________________________________

From report at bugs.python.org  Fri Jan 30 23:50:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Jan 2009 22:50:37 +0000
Subject: [issue4124] Patch for adding "default" to itemgetter and attrgetter
In-Reply-To: <1224022053.76.0.0750871741065.issue4124@psf.upfronthosting.co.za>
Message-ID: <1233355837.74.0.246468430068.issue4124@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am curious about your use cases.  ISTM that in every case I've every
used either function, I've always known that the attribute or item is
going to be there.  For instance, the original motivating use cases were
to support the key= argument to
min/max/sorted/nlargest/nsmallest/groupby and to support iterator
algebra with itertools:

def powerset(iterable):
    '''Iterate over all subsets.

    >>> list(powerset('abc'))
    [set([]), set(['a']), set(['b']), set(['a', 'b'])]

    '''
    # Only 1 initial call to PyObject_Hash().  
    # No trips around the eval-loop.
    # Memory friendly.
    seq = map(set, list(iterable)[::-1])
    selector_stream = product([False, True], repeat=len(seq))
    newsets, ns1 = tee(starmap(set, repeat(())))
    components = imap(compress, repeat(seq), selector_stream)
    sets_and_components = imap(chain, izip(newsets), components)
    results = starmap(set.update, sets_and_components)
    return imap(itemgetter(0), izip(ns1, results))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4124>
_______________________________________

From report at bugs.python.org  Fri Jan 30 23:52:31 2009
From: report at bugs.python.org (Jerzy)
Date: Fri, 30 Jan 2009 22:52:31 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <1233326425.97.0.690405797973.issue5092@psf.upfronthosting.co.za>
Message-ID: <4983849F.4070800@genesilico.pl>


Jerzy <jerzyo at genesilico.pl> added the comment:

I am not an expert. But for me it is much better.
If you cannot delete the global variable in a function (del makes the 
variable local anyway). So trying to delete a global variable should 
raise an exception "Cannot delete a global variable" or something like 
that. In a function variable should be global till the place when you 
define a local one.

Example:

a='Something'

def f():
  print a   #prints the global variable a
  del a     #Make an exception that a is global so it cannot be deleted
  a='anotherthing' #make a local a
  print a  #print local a
  del a    #delete local a
  print a  #print global a

f()

Also, if there are two variable (global and local) with seme name, there 
should be a way to access either of them like 'print loc(a)' and 'print 
glob(a)'. This is just a suggestion

Another way of resolving the problem would be making it impossible to 
make a local variable when there is anothe one with the same name.

David W. Lambert pisze:
> David W. Lambert <lambertdw at corning.com> added the comment:
> 
> The alternative is unreasonable.  I doubt you'd be happy with this:
> 
> 
> a = 'Something'
> 
> def variable_both_global_and_local()->Exception('No good!'):
>     del a    # delete a from global name space
>     a = 'anotherthing'  # define a in local name space
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5092>
> _______________________________________
> 
> 
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Sat Jan 31 00:17:27 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 30 Jan 2009 23:17:27 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1233357447.59.0.195045504511.issue5097@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Feel like writing some documentation?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5097>
_______________________________________

From report at bugs.python.org  Sat Jan 31 01:31:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jan 2009 00:31:28 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1233361888.47.0.730346504532.issue1717@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I haven't stared very closely but it looks ok.
("spanish armada" might be replaced with "spanish inquisition", though)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Sat Jan 31 01:44:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jan 2009 00:44:59 +0000
Subject: [issue4704] Update pybench for python 3.0
In-Reply-To: <1229770440.73.0.84111592631.issue4704@psf.upfronthosting.co.za>
Message-ID: <1233362699.04.0.519146877896.issue4704@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Since cmp is slated for removal, this should also be done for 3.0.1.

----------
nosy: +pitrou
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4704>
_______________________________________

From report at bugs.python.org  Sat Jan 31 01:57:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 31 Jan 2009 00:57:32 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233363452.0.0.292344060049.issue5110@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Victor, I'm not sure whether you are proposing that
display_hook_ascii.patch is included into Python. IIUC, this patch
breaks PEP3138, so it clearly must be rejected.

Overall, I fail to see the bug in this report. Python 3.0 works as
designed as shown here.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Sat Jan 31 02:32:37 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 31 Jan 2009 01:32:37 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <4983849F.4070800@genesilico.pl>
Message-ID: <4983AA30.3040909@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Another way of resolving the problem would be making it impossible to 
> make a local variable when there is anothe one with the same name.

Please trust that there really is no problem. If you don't understand
how Python works, ask on a mailing list. If you want to propose a change
to Python, contact python-ideas. Don't be surprised when everybody tells
you that things are fine the way they are.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Sat Jan 31 02:34:53 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 31 Jan 2009 01:34:53 +0000
Subject: [issue5105] sqlite3.Row class,
	handling duplicate column names resulting from a SQL join
In-Reply-To: <1233273211.24.0.156313751238.issue5105@psf.upfronthosting.co.za>
Message-ID: <1233365693.33.0.820781191008.issue5105@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I think this is a sqlite issue, not a Python one.
cursor.description should return unique column names.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5105>
_______________________________________

From report at bugs.python.org  Sat Jan 31 02:52:27 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 31 Jan 2009 01:52:27 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1233366747.25.0.507309134282.issue5103@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> janssen
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Sat Jan 31 02:58:49 2009
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 31 Jan 2009 01:58:49 +0000
Subject: [issue5092] weird memory usage in multiprocessing module
In-Reply-To: <4983849F.4070800@genesilico.pl>
Message-ID: <84B204FFB016BA4984227335D8257FBA8C9490@CVCV0XI05.na.corning.com>


David W. Lambert <lambertdw at corning.com> added the comment:

#Ah!  Not a problem.  You need globals() and locals() dictionaries.
# as a python3 script, this message produces next couple lines output.

#method one
#yup, global a is gone
#method two
#{'gv': 'local here', 'name': 'gv'}
#yup, global gv is gone

print('method one')

a = ''

def Delete_a_global_variable():
    global a
    del a

Delete_a_global_variable()

try:
    a
    print('whoops!  this can never happen')
except NameError:
    print('yup, global a is gone')

print('method two')

gv = ''                                 # global variable

def delete_chosen_variable(name):
    del globals()[name]
    gv = 'local here'
    print(locals())

delete_chosen_variable('gv')

try:
    gv
    print('whoops!  this can never happen')
except NameError:
    print('yup, global gv is gone')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5092>
_______________________________________

From report at bugs.python.org  Sat Jan 31 03:22:13 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 31 Jan 2009 02:22:13 +0000
Subject: [issue5105] sqlite3.Row class,
	handling duplicate column names resulting from a SQL join
In-Reply-To: <1233273211.24.0.156313751238.issue5105@psf.upfronthosting.co.za>
Message-ID: <1233368533.19.0.525370982526.issue5105@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

See http://www.sqlite.org/cvstrac/tktview?tn=3221

Try upgrading to the latest sqlite release. Or set "pragma 
full_column_names=ON;"

import sqlite3
conn = sqlite3.connect(':memory:')
cursor = conn.cursor()
cursor.execute("create table T (a, b, c)")
cursor.execute("insert into T values (1, 2, 3)")
cursor.execute("insert into T values (2, 3, 4)")
conn.commit()
cursor.execute("pragma short_column_names=OFF;")
cursor.execute("pragma full_column_names=ON;")
cursor.execute("select * from T T1, T T2 where T1.a=T2.b")
print [d[0] for d in cursor.description]
# output: ['T1.a', 'T1.b', 'T1.c', 'T2.a', 'T2.b', 'T2.c']

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5105>
_______________________________________

From report at bugs.python.org  Sat Jan 31 03:51:00 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 31 Jan 2009 02:51:00 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

It would be really handy to add a way to portably kill process groups of 
a process spawned with subprocess.Popen. My project starts a process, 
which then starts other long running processes. Because of this process 
tree, there's no way for me to portably kill all of those processes. 
Would it be possible to extend subprocess with these features? I did 
find someone who's already implemented this [1], and it's working well 
in my project. There was some discussion about adding this, but it seems 
no one actually committed a patch to implement it.

Anyway, I've attached a patch against python3.0's svn branch that 
implements this. I don't have access to windows, so I'm not able to make 
sure that the TerminateJobObject is correct, and works.

[1]: http://benjamin.smedbergs.us/blog/2006-12-11/killableprocesspy/
[2]: http://mail.python.org/pipermail/python-list/2008-April/487588.html

----------
components: Library (Lib)
files: killpg.patch
keywords: patch
messages: 80850
nosy: erickt
severity: normal
status: open
title: Extend subprocess.kill to be able to kill process groups
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file12899/killpg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Sat Jan 31 03:56:05 2009
From: report at bugs.python.org (Takeshi Matsuyama)
Date: Sat, 31 Jan 2009 02:56:05 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1233370565.0.0.186657287433.issue5036@psf.upfronthosting.co.za>


Takeshi Matsuyama <tksmashiw at gmail.com> added the comment:

Could someone close this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 31 04:16:24 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 31 Jan 2009 03:16:24 +0000
Subject: [issue5036] xml.parsers.expat make a dictionary which keys are broken
	if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1233371784.94.0.706231269664.issue5036@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5036>
_______________________________________

From report at bugs.python.org  Sat Jan 31 04:35:39 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 31 Jan 2009 03:35:39 +0000
Subject: [issue5110] Printing Unicode chars from the interpreter in a non-UTF8
	terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233372939.78.0.388755298097.issue5110@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This seems to fix the problem:
------------------------------
import sys
import builtins

def hook(message):
    if message is None:
        return
    builtins._ = message
    try:
        print(repr(message))
    except UnicodeEncodeError:
        print(ascii(message))

sys.displayhook = hook
------------------------------
Just to clarify:
* The current Py3 behavior works fine in UTF8 terminals
* It doesn't work on non-UTF8 terminals if they can't encode the chars
(they raise an error)
* It only affects the interactive interpreter
* This new patch escapes the chars instead of raise an error only on
non-UTF8 terminal and only when printed as ">>> foo" (without print())
and leaves the other behaviors unchanged
* This is related to Py3 only

Apparently the patch provided by Victor always escapes the non-ascii
chars. This new hook function prints the Unicode chars if possible and
escapes them if not. On a UTF8 terminal the behavior is unchanged, on a
non-UTF8 terminal all the chars that can not be encoded will now be escaped.

This only changes the behavior of ">>> foo", so it can not lead to
confusion ("It works in the interpreter but not in the script"). In a
script one can't write "foo" alone but "print(foo)" and the behavior of
"print(foo)" is the same in both the interpreter and the scripts (with
the patch applied):

>>> ['\u2620']
['\u2620']
>>> print(['\u2620'])
UnicodeEncodeError: 'charmap' codec can't encode character '\u2620' in
position 2: character maps to <undefined>

I think that the PEP3138 didn't consider this issue. Its purpose is to
have a better output (Unicode chars instead of escaped chars), but it
only works with UTF8 terminals, on non-UTF8 terminals the output is
worse (UnicodeEncodeError instead of escaped chars).

This is an improvement and I can't see any negative side-effect.

Attached there's a txt with more example, on Py2 and Py3, on
Windows(non-UTF8 terminal) and Linux (UTF8 terminal), with and without
my patch.

Added file: http://bugs.python.org/file12900/issue5110.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________

From report at bugs.python.org  Sat Jan 31 04:51:03 2009
From: report at bugs.python.org (Brandon Adams)
Date: Sat, 31 Jan 2009 03:51:03 +0000
Subject: [issue5105] sqlite3.Row class,
	handling duplicate column names resulting from a SQL join
In-Reply-To: <1233273211.24.0.156313751238.issue5105@psf.upfronthosting.co.za>
Message-ID: <1233373863.83.0.851903757746.issue5105@psf.upfronthosting.co.za>


Brandon Adams <sockonafish at gmail.com> added the comment:

Ah, that's it.  Thanks for the tip, this issue can be closed now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5105>
_______________________________________

From report at bugs.python.org  Sat Jan 31 04:57:44 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 31 Jan 2009 03:57:44 +0000
Subject: [issue5106] Update Naming & Binding statement for 3.0
In-Reply-To: <1233287424.89.0.100401288129.issue5106@psf.upfronthosting.co.za>
Message-ID: <1233374264.9.0.0482821640287.issue5106@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r69132.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5106>
_______________________________________

From report at bugs.python.org  Sat Jan 31 04:58:25 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 31 Jan 2009 03:58:25 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1233374305.18.0.186691285987.issue5099@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

At interpreter shutdown, the module's global variables are set to None 
before the module itself is released. __del__ methods may be called in 
those precaries circumstances, and should not rely on any global state.

A temporary fix would be to make Popen._internal_poll and 
Popen._handle_exitstatus keep a reference to the os module (just add a 
default argument os=os, like sys=sys in __del__). But this is just a 
hack; the real fix would be to avoid defining __del__ at all.

A patch for subprocess.py is attached.

----------
components: +Library (Lib)
keywords: +patch
nosy: +gagenellina
Added file: http://bugs.python.org/file12901/subprocess.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sat Jan 31 05:14:56 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 31 Jan 2009 04:14:56 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1233375296.72.0.566092073495.issue5099@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Patch and test case against trunk

----------
versions: +Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12902/test_subprocess.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sat Jan 31 05:17:01 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 31 Jan 2009 04:17:01 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1233375421.89.0.705967204948.issue5102@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Sat Jan 31 05:19:42 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 31 Jan 2009 04:19:42 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1233375582.33.0.127962025359.issue5094@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Seems perfectly reasonable to me.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sat Jan 31 07:52:54 2009
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 31 Jan 2009 06:52:54 +0000
Subject: [issue5116] expose _CrtSetReportMode via the msvcrt module
In-Reply-To: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>
Message-ID: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

In bug 4804, there is some debate about how desirable it is for Python
to unconditionally disable all CRT assertions on Windows - however,
there is agreement that exposing the ability to enable and disable these
assertions via the msvcrt module is reasonable - so I'm attaching a
patch for exactly that.  I'd also like to nominate this for the 2.6 and
py3k branches.

----------
assignee: mhammond
files: msvcrt_crtsetreportmode.patch
keywords: needs review, patch, patch
messages: 80858
nosy: mhammond
priority: normal
severity: normal
status: open
title: expose _CrtSetReportMode via the msvcrt module
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12903/msvcrt_crtsetreportmode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5116>
_______________________________________

From report at bugs.python.org  Sat Jan 31 07:53:20 2009
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 31 Jan 2009 06:53:20 +0000
Subject: [issue5116] expose _CrtSetReportMode via the msvcrt module
In-Reply-To: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>
Message-ID: <1233384800.48.0.554945895143.issue5116@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5116>
_______________________________________

From report at bugs.python.org  Sat Jan 31 07:55:59 2009
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 31 Jan 2009 06:55:59 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1233384959.38.0.459150257579.issue4804@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I created bug 5116 with a patch to expose CrtSetDebugMode via the msvcrt
module.  I didn't attach it to this patch as it doesn't address the
fundamental point in this bug, just offers a workaround to reinstate the
default if desired.  If there *was* agreement to change Python so only
the test suite disabled the CRT reports, then such a change could
probably now be implemented in .py code using the patch in bug 5116.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Sat Jan 31 08:25:52 2009
From: report at bugs.python.org (eliben)
Date: Sat, 31 Jan 2009 07:25:52 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>


New submission from eliben <eliben at gmail.com>:

This is correct:

relpath(r'd:\abc\jho', r'd:\abc')
=> 'jho'

But this isn't:
relpath(r'd:\jho', r'd:\\')
=> '..\jho'

Neither is this:
relpath(r'd:\jho', r'd:')
=> '..\..\..\jho'

----------
components: Library (Lib)
messages: 80860
nosy: eliben
severity: normal
status: open
title: os.path.relpath problem with root drive directory on windows
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 09:35:01 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 08:35:01 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233390901.51.0.287818137731.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

About this,

>But this isn't:
>relpath(r'd:\jho', r'd:\\')
>=> '..\jho'

Same happens on posixpath.

from posixpath import relpath
print relpath(r'/abc', r'/') #=> ../abc

I'll look at the code.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 09:46:41 2009
From: report at bugs.python.org (eliben)
Date: Sat, 31 Jan 2009 08:46:41 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233391601.16.0.561315637099.issue5117@psf.upfronthosting.co.za>


eliben <eliben at gmail.com> added the comment:

The problem is with these lines:

    start_list = abspath(start).split(sep)
    path_list = abspath(path).split(sep)

In case of 'd:\', the split returns two elements, the second empty.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 10:20:21 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 09:20:21 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233393621.77.0.372799239383.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I hope attached patch will fix this bug.

----------
keywords: +patch
Added file: http://bugs.python.org/file12904/fix_relpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 11:02:13 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 10:02:13 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233396133.06.0.443952022018.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

If it is better _abspath_split("/") to return [""] instead of [] for
consistency, "fix_relpath_v2.patch" might be better. (There is no
difference for relpath behavior though)

Added file: http://bugs.python.org/file12905/fix_relpath_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 11:17:24 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 10:17:24 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233397044.93.0.559157469103.issue5117@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file12905/fix_relpath_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 11:17:41 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 10:17:41 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233397061.45.0.812140285606.issue5117@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file12906/fix_relpath_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 11:47:52 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 31 Jan 2009 10:47:52 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1233398872.56.0.188192310444.issue4804@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I think we ought to make sure that python doesn't crash, even if one 
passes a bogus fd to os.closerange().
My current patch catches all invalid arguments in software, except for 
the file descriptors sometimes allowed.
To that end, I suggest my current granular CrtSetDebugMode method, as 
currently implemented in the latest patch.

Martin has yet to comment on it.  Although he was right that a previous 
version was flawed, I think I've cracked it this time, WRT proper 
python threads.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Sat Jan 31 11:50:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jan 2009 10:50:07 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1233399007.44.0.627271661387.issue5094@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please do. The current situation where the doc tells you not to use
"naive" datetime objects but Python gives you no way to do so is awful.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sat Jan 31 13:28:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 12:28:00 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233404880.4.0.304989834432.issue4753@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Square brackets added in r69133.  The gentoo x86 3.x buildbot seems to be 
passing the compile stage now.  (Though not the test stage, of course:  
one can't have everything!)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 31 13:57:51 2009
From: report at bugs.python.org (Ultrasick)
Date: Sat, 31 Jan 2009 12:57:51 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>


New submission from Ultrasick <python at ontheserver.de>:

print '%.2f' % 2.544 // returns 2.54
print '%.2f' % 2.545 // returns 2.54 but should return 2.55
print '%.2f' % 2.546 // returns 2.55

----------
messages: 80868
nosy: Ultrasick
severity: normal
status: open
title: '%.2f' % 2.545 doesn't round correctly
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 15:12:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 14:12:39 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233411159.77.0.485887752138.issue5118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is not a bug;  it's a consequence of the finite accuracy of floating-
point arithmetic.  If you look at the actual value that's stored for 
'2.545', you'll see that it's actually slightly less than 2.545, so 
rounding it down is the correct thing to do.

>>> 2.545
2.5449999999999999

----------
nosy: +marketdickinson
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 15:13:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 14:13:07 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233411187.83.0.937269563457.issue5118@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 15:18:09 2009
From: report at bugs.python.org (Ultrasick)
Date: Sat, 31 Jan 2009 14:18:09 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233411489.05.0.585511999737.issue5118@psf.upfronthosting.co.za>


Ultrasick <python at ontheserver.de> added the comment:

print round(2.545, 2) // returns 2.55

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 16:14:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 15:14:09 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233414849.97.0.0570185009845.issue5118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> print round(2.545, 2) // returns 2.55

Aha!  Yes, that one *is* a bug (see issue #1869), though it's not one that 
I regard as terribly serious, and not one that can be easily solved in all 
cases.

Here's why I don't see it as particularly serious: you're rounding a value 
that's just on the boundary:  2.545+tiny_error should round up, while 
2.545-tiny_error should round down.  But tiny (or not-so-tiny) errors are 
an almost unavoidable part of working with binary floating-point 
arithmetic.  Additionally, whether the binary approximation stored for 
2.545 is less than or greater than the true value depends on many things 
(format of a C double, system C library function used for string-to-double 
conversion, etc.), so in a sense either 2.55 *or* 2.54 can be defended as 
a valid result, and a good numeric programmer won't write code that 
depends on getting one or the other.

Having said that, if you're interested in providing a patch for issue 
#1869 I'd certainly take a look.

If you care about *exact* representations of numbers with a finite number 
of places after the decimal point, you may be interested in Python's 
'decimal' module.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 16:14:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 15:14:19 +0000
Subject: [issue1869] Builtin round function is sometimes inaccurate for floats
In-Reply-To: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za>
Message-ID: <1233414859.72.0.844523772975.issue1869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue 5118.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1869>
_______________________________________

From report at bugs.python.org  Sat Jan 31 16:23:54 2009
From: report at bugs.python.org (Ultrasick)
Date: Sat, 31 Jan 2009 15:23:54 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233415434.14.0.701345685303.issue5118@psf.upfronthosting.co.za>


Ultrasick <python at ontheserver.de> added the comment:

I am sorry but I am not a C programmer. I cannot provide any patches.

As far as I understood this issue and issue #1869 have a common problem
but this issue wouldn't be solved if issue #1869 is solved. "print
'%.2f' % 2.545" doesn't seam to use the built in round() function.
Otherwise the result would be 2.55 already as the result of round(2.545,
2) is.

So you might want to reopen the bug. But either way I don't consider
this bug as really serious either.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 16:36:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 15:36:03 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233416163.3.0.884154866046.issue5118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> So you might want to reopen the bug. But either way I don't consider
> this bug as really serious either.

I don't understand.  As far as I can see '%.2f' % 2.545 is returning
the correct result: there is no bug here, so no need to reopen. '%.2f' 
should *not* return 2.55;  it should return 2.54, which is exactly what it 
does.  round(2.545, 2) should also return 2.54, but returns 2.55 instead;  
issue 1869 is already open for this.

You're correct that the float formatting doesn't use round:  it does 
whatever the platform C library's sprintf does.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 16:51:44 2009
From: report at bugs.python.org (Ultrasick)
Date: Sat, 31 Jan 2009 15:51:44 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233417104.85.0.361841669501.issue5118@psf.upfronthosting.co.za>


Ultrasick <python at ontheserver.de> added the comment:

Well that's not what I have learned how rounding works. I think that's
the more common way:

0.4 -> 0
0.5 -> 1
0.6 -> 1

I hope you don't try to spread the misbehavoir of pythons way of rounding

print '%.2f' % 2.545 // returns 2.54

to the built in round() function. So that round() would also return 2.54.

The result of rounding 2.545 is 2.55 no matter how python temporarly
stores "2.545" and independent of how python does the rounding. The
result is 2.55 and not 2.54. If python doesn't deliver "2.55" as the
result of it's rounding algorithm then it's doing it wrong. And if
python does stuff wrong then it has a bug.

in my opinion

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 17:05:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 16:05:48 +0000
Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233417948.1.0.884757342993.issue5118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> result is 2.55 and not 2.54. If python doesn't deliver "2.55" as the
> result of it's rounding algorithm then it's doing it wrong. And if

Sorry, but that's just not true.  I suggest that you (a) read the 
section on floating-point[1] in the Python tutorial, and/or (b) ask 
about this on comp.lang.python if you feel inclined---there are plenty 
of people there who would be glad to explain what's going on here.

[1] http://docs.python.org/tutorial/floatingpoint.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5118>
_______________________________________

From report at bugs.python.org  Sat Jan 31 17:21:55 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 16:21:55 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233418915.36.0.528737482805.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

It seems that there is still problem.

>>> ntpath.relpath("//whiterab-c2znlh/foo/", "//whiterab-c2znlh/bar/")
'..\\foo'

This should raise ValueError because "//whiterab-c2znlh/foo" is UNC root
prefix (like "e:" for normal path) not "//whiterab-c2znlh" AFAIK.

I'll look into more deeper...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 17:35:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 16:35:30 +0000
Subject: [issue789290] Minor FP bug in object.c
Message-ID: <1233419730.59.0.735634760998.issue789290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll take this.

I think there *is* a problem here: on a system with 64-bit long, 
_Py_HashDouble can end up trying to cast the float value 2.**63 to a C 
long.  Since 2.**63 doesn't fit in a long, we get undefined behaviour, 
according to the C standards.

In more detail: when computing the hash of the floating-point value x = 
2.**63 on a 64-bit system, we end up in _Py_HashDouble in 
Objects/object.c.  The intpart of x will be 2.**63, and fractpart is 0.0.  
The comparison:

  if (intpart > LONG_MAX || -intpart > LONG_MAX) {

*fails*, because LONG_MAX (== 2**63-1) is implicitly converted to the 
float value 2.**63 before the comparison.  So we end up at the line:

  x = (long)intpart;

which attempts to convert intpart(== 2.0**63) to a long.  Even if this 
conversion doesn't signal, it could return some random long number, so 
unless we're very lucky, hash(2**63) == hash(2.**63) will fail.

On my system (OS X 10.5.4/x86_64), I *am* lucky:  when 2.**63 is cast to 
long I get LONG_MIN (!).  And it just so happens that hash(LONG_MIN) == 
hash(2**63), so we're okay.

----------
assignee: nobody -> marketdickinson
nosy: +marketdickinson
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue789290>
_______________________________________

From report at bugs.python.org  Sat Jan 31 17:52:21 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 31 Jan 2009 16:52:21 +0000
Subject: [issue5112] Incorrect documentation for PyErr_BadInternalCall
In-Reply-To: <1233340878.84.0.440465699769.issue5112@psf.upfronthosting.co.za>
Message-ID: <1233420741.31.0.714282375054.issue5112@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r69140.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5112>
_______________________________________

From report at bugs.python.org  Sat Jan 31 18:16:25 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 17:16:25 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233422185.4.0.769801793214.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I hope this works.

Added file: http://bugs.python.org/file12907/fix_relpath_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 18:16:35 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 17:16:35 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233422195.58.0.807323300045.issue5117@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file12904/fix_relpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 18:16:47 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 17:16:47 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233422207.43.0.806109093315.issue5117@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file12906/fix_relpath_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 18:17:00 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 31 Jan 2009 17:17:00 +0000
Subject: [issue5117] os.path.relpath problem with root drive directory on
	windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233422220.36.0.270861075246.issue5117@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Sat Jan 31 18:17:58 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jan 2009 17:17:58 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1233404880.4.0.304989834432.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233422310.6442.0.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Square brackets added in r69133.  The gentoo x86 3.x buildbot seems to be 
> passing the compile stage now.  (Though not the test stage, of course:  
> one can't have everything!)

The test failure also happens on trunk, it may be related to the recent
tk changes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 31 20:36:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Jan 2009 19:36:10 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1233430570.7.0.53158226724.issue4753@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> The test failure also happens on trunk, it may be related to the recent
> tk changes.

Yes; sorry---I didn't mean to suggest that the test failures were in any 
way related to the opcode dispatch stuff.  Apart from the ttk teething 
difficulties, there's a weird 'Unknown signal 32' error that's been going 
on on the gentoo buildbot for many months now.  But that's a separate 
issue (issue #4970, to be precise).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Sat Jan 31 20:52:39 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 31 Jan 2009 19:52:39 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1233431559.35.0.76857856657.issue5097@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5097>
_______________________________________

From report at bugs.python.org  Sat Jan 31 20:54:15 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 31 Jan 2009 19:54:15 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1233431655.77.0.378096418128.issue5115@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Sat Jan 31 21:53:39 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 31 Jan 2009 20:53:39 +0000
Subject: [issue5119] inconsistent wide character parameter handling in 64-bit
	python
In-Reply-To: <1233435219.37.0.934884464449.issue5119@psf.upfronthosting.co.za>
Message-ID: <1233435219.37.0.934884464449.issue5119@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Using Python 2.5.4 and Python 2.6.1 on 32-bit python, when passing a
regular string to a function expecting pointer to a wide string
(wintypes.LPCWSTR), the function executes without problems.

When calling the same using Python 2.6.1 on 64-bit windows, the called
function appears not to recognize the parameter unless it is first
converted to unicode.

I discovered this when calling the WNetAddConnection2 function.

Assuming a properly-initialized NETRESOURCE, resource.

password = None
username = 'username at domain.com'
flags = 0

val = ctypes.windll.mpr.WNetAddConnection2W(
  ctypes.byref(resource),
  password,
  username,
  flags)

This method works fine on 32-bit python but fails on 64-bit python
unless username=unicode(username).  The error returned is "The specified
password is incorrect", indicating that the username is in fact
incorrect because the correct username does not require a password.

I wish I had a better test case; I'll try to track down one that doesn't
require such a complex underlying API.

I'm not sure what the correct fix is for this, but regardless, I would
expect the behavior to be consistent for the same Python version
independent of word size.

----------
assignee: theller
components: ctypes
messages: 80883
nosy: jaraco, theller
severity: normal
status: open
title: inconsistent wide character parameter handling in 64-bit python
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5119>
_______________________________________

From report at bugs.python.org  Sat Jan 31 22:25:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 31 Jan 2009 21:25:50 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

For some reason the recently added test_ttk_guionly is causing Tcl to
abort on Mac. I would prefer to disable the test for now, except if some
mac owner has the time to fix it.

I would like to know the tcl version being used on the noller-osx86
buildslave too, if possible.

----------
components: Tkinter
messages: 80884
nosy: gpolo
severity: normal
status: open
title: Disabling test_ttk_guionly on mac
type: crash
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5120>
_______________________________________

From report at bugs.python.org  Sat Jan 31 22:33:23 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 31 Jan 2009 21:33:23 +0000
Subject: [issue5119] inconsistent wide character parameter handling in 64-bit
	python
In-Reply-To: <1233435219.37.0.934884464449.issue5119@psf.upfronthosting.co.za>
Message-ID: <1233437603.32.0.991645388729.issue5119@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After putting together a more simple example without externalities, I'm
unable to continue to assert the discrepancy between 32 and 64-bit
Windows, although I do still see where narrow character strings are
treated as wide character buffers.

See the attached script that demonstrates the issue (on Python 2.5 and
Python 2.6 regardless of word size).

Now the inconsistency seems to only lie with the WNetAddConnection2W
function and not the MessageBoxW function, both of which take LPCTSTR
parameters (at least according to the documentation).

Perhaps this is a non-issue, but I'd be interested to know why the
WNetAddConnection2W example works in 32-bit but not 64-bit.  Could it be
the 32-bit WNetAddConnection2W actually attempts to handle the buffer as
both wide and narrow, but MessageBoxW takes it at face value?

Added file: http://bugs.python.org/file12908/ui.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5119>
_______________________________________

From report at bugs.python.org  Sat Jan 31 22:39:39 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 31 Jan 2009 21:39:39 +0000
Subject: [issue5119] inconsistent wide character parameter handling in 64-bit
	python
In-Reply-To: <1233435219.37.0.934884464449.issue5119@psf.upfronthosting.co.za>
Message-ID: <1233437979.08.0.347333637578.issue5119@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Or alternately, is it possible (and reasonable) for ctypes to inspect
the function signature and create wide character buffers when appropriate?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5119>
_______________________________________

From report at bugs.python.org  Sat Jan 31 22:45:33 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 31 Jan 2009 21:45:33 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <ac2200130901311345x13d7ae70j133c652ab82baa85@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> For some reason the recently added test_ttk_guionly is causing Tcl to
> abort on Mac. I would prefer to disable the test for now, except if some
> mac owner has the time to fix it.

Just saw it didn't cause an abort with the buildslave heller-x86-osx5, btw.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5120>
_______________________________________