R. David Murray writes:
> On Mon, 04 Oct 2010 12:32:26 -0400, Scott Dial
> wrote:
> > On 10/2/2010 7:00 PM, R. David Murray wrote:
> > > The clever hack (thanks ultimately to Martin) is to accept 8bit data
> > > by encoding it using the ASCII codec and the surrogateescape error
> > > handle
On Mon, 4 Oct 2010 16:01:17 -0400
Barry Warsaw wrote:
> >
> >Why would a distro want to provide all combinations of Python builds?
>
> Maybe not all, but definitely several. At least a normal build and a debug
> build, but a wide unicode build possibly also.
What is the point of shipping a diff
On Oct 04, 2010, at 09:10 PM, Antoine Pitrou wrote:
>On Mon, 4 Oct 2010 14:41:11 -0400
>Barry Warsaw wrote:
>>
>> For a distro, all those Python binaries have to go in /usr/bin. We
>> already symlink /usr/bin/python to pythonX.Y so I don't see the harm
>> in a few extra symlinks.
>
>Why would a
On 09/29/2010 08:50 PM, Raymond Hettinger wrote:
1. Liberalize setobject.c binary operator methods to accept anything
registered to the Set ABC and add a backwards incompatible restriction
to the Set ABC binary operator methods to only accept Set ABC
instances (they currently accept any iterab
Hi--sorry to be a little late to the discussion. I'm the putz who
backported capsules (and monkeyed with CObject) for 2.7.
On 09/27/2010 07:44 PM, Jesus Cea wrote:
http://bugs.python.org/issue9675
Long history sort: Python 2.7 backported Capsule support and
(incorrectly, in my opinion) ma
On Mon, 4 Oct 2010 14:41:11 -0400
Barry Warsaw wrote:
>
> For a distro, all those Python binaries have to go in /usr/bin. We already
> symlink /usr/bin/python to pythonX.Y so I don't see the harm in a few extra
> symlinks.
Why would a distro want to provide all combinations of Python builds?
O
On Oct 01, 2010, at 07:36 PM, Benjamin Peterson wrote:
>2010/10/1 Barry Warsaw :
>> I can think of a couple of ways out, none of which are totally
>> satisfying. Probably the easiest out is to change the PEP 3149
>> naming so that the files don't end in ".so". E.g. use this instead:
>>
>> foo.
On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote:
>Besides, mingling different installations together makes uninstalling
>much more difficult.
Not for a distro I think.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Pyt
On Oct 02, 2010, at 09:44 AM, Martin v. Löwis wrote:
With my branch, you'll end up with this in /tmp/python:
bin/python3.2m - the normal build binary
bin/python3.2dmu - the wide+pydebug build binary
bin/python3.2m-config
bin/python3.2dmu-config
>>>
>
On Oct 02, 2010, at 04:50 PM, Nick Coghlan wrote:
>On Sat, Oct 2, 2010 at 10:24 AM, Antoine Pitrou
>wrote:
>> On Fri, 1 Oct 2010 20:06:57 -0400
>> Barry Warsaw wrote:
>>>
>>> With my branch, you'll end up with this in /tmp/python:
>>>
>>> bin/python3.2m - the normal build binary
>>> bi
On Oct 02, 2010, at 10:36 AM, Georg Brandl wrote:
>Am 02.10.2010 00:06, schrieb Barry Warsaw:
>
>> The reason is that the import.c logic that uses the struct filedescr
>> tables built from _PyImport_DynLoadFiletab are just not smart enough
>> to handle this case. All it knows about are suffix, an
On Oct 02, 2010, at 07:00 PM, R. David Murray wrote:
>The advantage of this patch is that it means Python3.2 can have an
>email module that is capable of handling a significant proportion of
>the applications where the ability to process binary email data is
>required.
Like others, I'm concerned
On Mon, 04 Oct 2010 12:32:26 -0400, Scott Dial
wrote:
> On 10/2/2010 7:00 PM, R. David Murray wrote:
> > The clever hack (thanks ultimately to Martin) is to accept 8bit data
> > by encoding it using the ASCII codec and the surrogateescape error
> > handler.
>
> I've seen this idea pop up in a nu
On 10/2/2010 7:00 PM, R. David Murray wrote:
> The clever hack (thanks ultimately to Martin) is to accept 8bit data
> by encoding it using the ASCII codec and the surrogateescape error
> handler.
I've seen this idea pop up in a number of threads. I worry that you are
all inventing a new kind of du
On 2010-10-04, at 05:04 , Eviatar Bach wrote:
> Hello,
>
> I have a proposal of making the range() function inclusive; that is,
> range(3) would generate 0, 1, 2, and 3, as opposed to 0, 1, and 2. Not only
> is it more intuitive, it also seems to be used often, with coders often
> writing range(0,
15 matches
Mail list logo