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.
Thanks, Paddy.
___
Python-Dev
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] wrote:
I just committed r64651 which is my attempt to add support to
fix_imports so
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
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 exists now,
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
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
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 it to
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
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 fixed.
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 problem of
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] wrote:
I just
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
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
-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 also better
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 for everything anyway.
FreeBSD's
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 some
-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 expect from UTF-16
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 supports surrogate pairs in
both
-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 the things
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 understood you:
Python's code needs
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
fix_imports so
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] wrote:
On
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
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 should
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
reports 2968
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 refactoring
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
27 matches
Mail list logo
