> But distutils currently *doesn't* invoke it, AFAICT
Sure. In 3k, look at Lib/distutils/command/build.py:build_py_2to3.
That's how I ported Django to Py3k.
> 1) People are currently confused as to where they should be commit fixes.
Sure, but it only happens rarely.
> 2) Changes to the sandbox
On Wed, Jul 2, 2008 at 1:09 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Agreed. A lot of the pending bugs seem to be related to the version of
>> lib2to3 in the stdlib, rather than the stand-alone product. Neal
>> Norwitz and I have been working to turn parts of 2to3 into a more
>> general
On Wed, Jul 2, 2008 at 12:51 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Why was this test disabled, rather than fixed? That seems a rather
>> poor solution to the problem of it taking longer than desired to run.
>
> I disabled it because I didn't know how to fix it, and created bug
> repor
> Agreed. A lot of the pending bugs seem to be related to the version of
> lib2to3 in the stdlib, rather than the stand-alone product. Neal
> Norwitz and I have been working to turn parts of 2to3 into a more
> general refactoring library; once that's done (or even preferably
> before), lib2to3 shou
> Why was this test disabled, rather than fixed? That seems a rather
> poor solution to the problem of it taking longer than desired to run.
I disabled it because I didn't know how to fix it, and created bug
reports 2968 and 2969 in return. It is policy that tests that break
get disabled, rather t
On Wed, Jul 2, 2008 at 9:36 AM, Collin Winter <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 11:32 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> On Tue, Jul 1, 2008 at 8:36 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>> On Tue, Jul 1, 2008 at 7:38 PM, Benjamin Peterson
>>> <[EMAIL PROTECTED]
On Wed, Jul 2, 2008 at 9:30 AM, Collin Winter <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 7:38 PM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
>> On Tue, Jul 1, 2008 at 9:04 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>> I just committed r64651 which is my attempt to add support to
>>>
On Wed, Jul 2, 2008 at 11:35 AM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> -On [20080702 20:27], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>>I disagree. Instead, I would say that such code needs to be aware of
>>surrogates.
>
> Just to make sure I u
-On [20080702 20:27], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>I disagree. Instead, I would say that such code needs to be aware of
>surrogates.
Just to make sure I understood you:
Python's code needs to be made aware of surrogates?
If so, do you want me to log issues for
On Wed, Jul 2, 2008 at 11:22 AM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> -On [20080702 19:42], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>>Yes. At least in the sense that \U gets translated to a
>>surrogate pair, and that the UTF-8 codec suppor
-On [20080702 19:42], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>Yes. At least in the sense that \U gets translated to a
>surrogate pair, and that the UTF-8 codec supports surrogate pairs in
>both directions. It's been like this for a long time. What else would
>you e
Followup: Neal Norwitz <[EMAIL PROTECTED]> will coordinate this, send
mail to him if you're interested, not to me. :-)
On Wed, Jul 2, 2008 at 10:13 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I've got an offer from Klocwork (a static source code analysis
> company, www.klocwork.com) to give
On Wed, Jul 2, 2008 at 10:19 AM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> -On [20080702 19:08], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>>I think we should continue to leave this up to the distribution. AFAIK
>>many Linux distros already use UCS4
-On [20080702 19:08], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>I think we should continue to leave this up to the distribution. AFAIK
>many Linux distros already use UCS4 for everything anyway.
FreeBSD's ports makes it a configure option.
>For that reason I think it's a
I've got an offer from Klocwork (a static source code analysis
company, www.klocwork.com) to give some developers free access to
their findings from running their bug-finding software over Python
source code. I don't have the bandwidth to deal with this myself, but
I think it would be valuable if w
I think we should continue to leave this up to the distribution. AFAIK
many Linux distros already use UCS4 for everything anyway.
The alternative (no matter what the configure flag is called) is
UTF-16, not UCS-2 though: there is support for surrogate pairs in
various places, including the \U esca
On Tue, Jul 1, 2008 at 11:32 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 8:36 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> On Tue, Jul 1, 2008 at 7:38 PM, Benjamin Peterson
>> <[EMAIL PROTECTED]> wrote:
>>> On Tue, Jul 1, 2008 at 9:04 PM, Brett Cannon <[EMAIL PROTECTED]>
On Wed, Jul 2, 2008 at 11:30 AM, Collin Winter <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 7:38 PM, Benjamin Peterson
>> Well for starters, you know the test for fix_imports is disabled, right?
>
> Why was this test disabled, rather than fixed? That seems a rather
> poor solution to the pro
On Tue, Jul 1, 2008 at 7:38 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 9:04 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> I just committed r64651 which is my attempt to add support to
>> fix_imports so that modules that have been split up in 3.0 can be
>> properly fi
Guido van Rossum wrote:
On Wed, Jul 2, 2008 at 5:31 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
I've posted a possible fix for the __hash__ backwards incompatibilities
described in issue 2235 [1].
The patch uses a model similar to that used in Py3k (using None is indicate
"don't inherit __hash_
On Wed, Jul 2, 2008 at 5:31 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I've posted a possible fix for the __hash__ backwards incompatibilities
> described in issue 2235 [1].
>
> The patch uses a model similar to that used in Py3k (using None is indicate
> "don't inherit __hash__"), but extends i
Guido (and others of course),
back in 2001 you pointed out that you wanted to move to UCS4 completely as
the ideal situation
(http://mail.python.org/pipermail/i18n-sig/2001-June/001107.html) over the
current default UCS2.
Given 3.0 will use Unicode strings as the default, would it also not make
s
I've posted a possible fix for the __hash__ backwards incompatibilities
described in issue 2235 [1].
The patch uses a model similar to that used in Py3k (using None is
indicate "don't inherit __hash__"), but extends it to allowing Py_None
to be explicitly stored in the tp_hash slot. The major
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote:
> It would be nice to be able to do this:
>
> defaults = dict(a=5, b=7)
> f(**defaults, a=8) # override the value of a in defaults
>
> but unfortunately that gives a syntax error. Reversing the order would
> override the wrong value. So as Python ex
Paddy 3118 wrote:
Hi,
I'd like extra opinions on this issue please:
http://bugs.python.org/issue3214
It's about changing the definition of Duck typing to remove hasattr and
leave just EAFP in the enablers - more detail is in the issue log.
The change seems to make sense. Use of hasattr() to de
25 matches
Mail list logo
