Re: [Python-Dev] [issue3214] Suggest change to glossary explanation: "Duck Typing"
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 determine method availability, while not strictly "look before you leap" because it doesn't test for a specific type, certainly isn't EAFP either. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] repeated keyword arguments
"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, no, it's not > terribly useful. But it's not inherently a stupid idea. There is already an easy way to do that using functools.partial, and it is documented and therefore presumably deliberate behaviour "If additional keyword arguments are supplied, they extend and override keywords." >>> from functools import partial >>> def f(a=1, b=2, c=3): print a, b, c >>> g = partial(f, b=99) >>> g() 1 99 3 >>> g(a=100, b=101) 100 101 3 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Review needed: proposed fix for 2.6 __hash__ incompatibility (issue 2235)
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 downside is that we suffer the cost of an extra pointer comparison on every call to PyObject_Hash, but I wasn't able to come up with another solution that preserved backwards compatibility while still allowing collections.Hashable to function correctly. The patch involves a few changes to fairly deep components in typeobject.c though, so I'd like at least some kind of sanity check before I commit it. Cheers, Nick. [1] http://bugs.python.org/issue2235 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] UCS2/UCS4 default
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 sense to make the switch at this point as well? The current situation with UCS2 is particularly bad now that the CJK ideographs Extension B. has been produced (and C is under ballot and D is under development). Personally I use nothing else but UCS4 compiled Python binaries for the past years. See also http://www.python.org/dev/peps/pep-0261/ for background for the 2001 options. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Expansion of happiness is the purpose of life... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Review needed: proposed fix for 2.6 __hash__ incompatibility (issue 2235)
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 allowing Py_None to be > explicitly stored in the tp_hash slot. The major downside is that we suffer > the cost of an extra pointer comparison on every call to PyObject_Hash, but > I wasn't able to come up with another solution that preserved backwards > compatibility while still allowing collections.Hashable to function > correctly. >From your description it seems storing Py_None in the slot acts as a magic value meaning "this is defined but not usable". However it used to be pretty common for various code around to call various slots directly (after a NULL) check. That would have disastrous results if the slot value was Py_None. Would it be terribly inconvenient if the magic value was in fact another function, with a public name), whose sole purpose was to raise an exception? > The patch involves a few changes to fairly deep components in typeobject.c > though, so I'd like at least some kind of sanity check before I commit it. > > Cheers, > Nick. > > [1] http://bugs.python.org/issue2235 I can't promise I'll have time to look at this before my EuroPython keynote, but it's important for me to get it right, so if nobody else jumps in, remind me Tuesday. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Review needed: proposed fix for 2.6 __hash__ incompatibility (issue 2235)
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__"), but extends it to allowing Py_None to be explicitly stored in the tp_hash slot. The major downside is that we suffer the cost of an extra pointer comparison on every call to PyObject_Hash, but I wasn't able to come up with another solution that preserved backwards compatibility while still allowing collections.Hashable to function correctly. From your description it seems storing Py_None in the slot acts as a magic value meaning "this is defined but not usable". However it used to be pretty common for various code around to call various slots directly (after a NULL) check. That would have disastrous results if the slot value was Py_None. Would it be terribly inconvenient if the magic value was in fact another function, with a public name), whose sole purpose was to raise an exception? Not only not inconvenient, but a significant improvement - as well as addressing your concern that I missed some code that calls tp_hash directly (a concern that I share, particularly since it could be an extension module we don't control that ends up doing it), it also gets rid of that extra pointer comparison in PyObject_Hash that was bothering me. The patch involves a few changes to fairly deep components in typeobject.c though, so I'd like at least some kind of sanity check before I commit it. Cheers, Nick. [1] http://bugs.python.org/issue2235 I can't promise I'll have time to look at this before my EuroPython keynote, but it's important for me to get it right, so if nobody else jumps in, remind me Tuesday. I'd now advise waiting until I have a chance to implement your idea anyway :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
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. 2to3's test suite passes and all, but I am not sure if >> I botched it somehow since I did the change slightly blind. Can >> someone just do a quick check to make sure I did it properly? Also, >> what order should renames be declared to give priority to certain >> renames (e.g., urllib should probably be renamed to urllib.requeste >> over urllib.error when not used in a ``from ... import`` statement). > > 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 it taking longer than desired to run. Collin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
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 it taking longer than desired to run. I believe Martin was the one who disabled it. > > Collin > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
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 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. 2to3's test suite passes and all, but I am not sure if I botched it somehow since I did the change slightly blind. Can someone just do a quick check to make sure I did it properly? Also, what order should renames be declared to give priority to certain renames (e.g., urllib should probably be renamed to urllib.requeste over urllib.error when not used in a ``from ... import`` statement). >>> >>> Well for starters, you know the test for fix_imports is disabled, right? >>> >> >> Nope, I forgot and turning it on has it failing running under 2.5. >> > > And refactor.py cannot be run directly from 2.5 because of a relative > import and in 2.6 (where runpy has extra smarts) it still doesn't work > thanks to main() not being passed an argument is needs (Issue3131). Why are you trying to run refactor.py directly, rather than using 2to3 (http://svn.python.org/view/sandbox/trunk/2to3/2to3) as an entry point? > Looks like 2to3 needs some TLC. 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 be removed from the stdlib. It's causing far more trouble than it's worth. Collin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UCS2/UCS4 default
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 escape and the UTF-8 codec. I don't want to rule out UTF-16 as internal representation from the Python language spec, because JVM- and .NET-based implementations pretty much have no choice in the matter if they want to be compatible with the native string type (which is very important for performance and compatibility with other languages on those platforms). For that reason I think it's also better that the configure script continues to default to UTF-16 -- this will give the UTF-16 support code the necessary exercise. (It is mostly a superset of the UCS-4 support code, so I'm less worried about the latter getting enough exercise.) --Guido On Wed, Jul 2, 2008 at 7:13 AM, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > > 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 > sense to make the switch at this point as well? > > The current situation with UCS2 is particularly bad now that the CJK > ideographs Extension B. has been produced (and C is under ballot and D is > under development). > > Personally I use nothing else but UCS4 compiled Python binaries for the past > years. > > See also http://www.python.org/dev/peps/pep-0261/ for background for the > 2001 options. > > -- > Jeroen Ruigrok van der Werven / asmodai > イェルーン ラウフロック ヴァン デル ウェルヴェン > http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B > Expansion of happiness is the purpose of life... > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Who wants to work with Klocwork?
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 we could get some folks to look at their findings. We have a similar relationship with one of Klocwork's competitors. In my experience, each vendor's tool has a different strength, and it is likely that each will find some important bugs that the other didn't flag. So IMO it's useful to do this with each vendor that offers... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UCS2/UCS4 default
-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 that the configure script >continues to default to UTF-16 -- this will give the UTF-16 support >code the necessary exercise. (It is mostly a superset of the UCS-4 >support code, so I'm less worried about the latter getting enough >exercise.) I was under the impression that it was still UCS2 and thus limiting things to the BMP only. So you are saying it's UTF-16 nowadays? For both 2.6 and 3.0? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Nature does nothing uselessly... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UCS2/UCS4 default
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 ports makes it a configure option. > >>For that reason I think it's also better that the configure script >>continues to default to UTF-16 -- this will give the UTF-16 support >>code the necessary exercise. (It is mostly a superset of the UCS-4 >>support code, so I'm less worried about the latter getting enough >>exercise.) > > I was under the impression that it was still UCS2 and thus limiting things > to the BMP only. So you are saying it's UTF-16 nowadays? For both 2.6 and > 3.0? 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 support? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who wants to work with Klocwork?
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 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 we could get some folks to look at > their findings. > > We have a similar relationship with one of Klocwork's competitors. In > my experience, each vendor's tool has a different strength, and it is > likely that each will find some important bugs that the other didn't > flag. So IMO it's useful to do this with each vendor that offers... > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UCS2/UCS4 default
-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 support?
Well, unless I misunderstand things, a Python 3 compiled with the default
Unicode option gives this:
>>> len("\N{MUSICAL SYMBOL G CLEF}")
2
Whereas a Python 3 with --with-wide-unicode gives:
>>> len("\N{MUSICAL SYMBOL G CLEF}")
1
This, of course, causes problems with splitting, finding, and so on. So that
means that a Python 3 with only 2 byte Unicode support is not to be
used/recommended for Unicode outside of the BMP.
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Tomorrow's battle is won during today's practice...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UCS2/UCS4 default
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 directions. It's been like this for a long time. What else would
>>you expect from UTF-16 support?
>
> Well, unless I misunderstand things, a Python 3 compiled with the default
> Unicode option gives this:
>
>>>> len("\N{MUSICAL SYMBOL G CLEF}")
> 2
>
> Whereas a Python 3 with --with-wide-unicode gives:
>
>
>>>> len("\N{MUSICAL SYMBOL G CLEF}")
> 1
>
> This, of course, causes problems with splitting, finding, and so on.
Understood.
> So that
> means that a Python 3 with only 2 byte Unicode support is not to be
> used/recommended for Unicode outside of the BMP.
I disagree. Instead, I would say that such code needs to be aware of surrogates.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UCS2/UCS4 default
-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 encountered? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Learn from the past -- don't wear it like a yoke around your neck... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UCS2/UCS4 default
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 to be made aware of surrogates? No, Python already is aware of surrogates. I meant applications processing non-BMP text should beware of them. > If so, do you want me to log issues for the things encountered? If you find places where the Python core or standard library is doing Unicode processing that would break when surrogates are present you should file a bug. However this does not mean that every bit of code that slices a string at an arbitrary point (and hence risks slicing in the middle of a surrogate) is incorrect -- it all depends on what is done next with the slice. I'd also prefer to receive bug reports about breakages actually encountered in the wild than purely theoretical issues. And in all cases a fragment of test code to reproduce the problem would be appreciated. > -- > Jeroen Ruigrok van der Werven / asmodai > イェルーン ラウフロック ヴァン デル ウェルヴェン > http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B > Learn from the past -- don't wear it like a yoke around your neck... > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
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 that modules that have been split up in 3.0 can be >>> properly fixed. 2to3's test suite passes and all, but I am not sure if >>> I botched it somehow since I did the change slightly blind. Can >>> someone just do a quick check to make sure I did it properly? Also, >>> what order should renames be declared to give priority to certain >>> renames (e.g., urllib should probably be renamed to urllib.requeste >>> over urllib.error when not used in a ``from ... import`` statement). >> >> 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 it taking longer than desired to run. I think it may have been to turn off a failing test just before a release and it was just never switched back on. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
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 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. 2to3's test suite passes and all, but I am not sure if > I botched it somehow since I did the change slightly blind. Can > someone just do a quick check to make sure I did it properly? Also, > what order should renames be declared to give priority to certain > renames (e.g., urllib should probably be renamed to urllib.requeste > over urllib.error when not used in a ``from ... import`` statement). Well for starters, you know the test for fix_imports is disabled, right? >>> >>> Nope, I forgot and turning it on has it failing running under 2.5. >>> >> >> And refactor.py cannot be run directly from 2.5 because of a relative >> import and in 2.6 (where runpy has extra smarts) it still doesn't work >> thanks to main() not being passed an argument is needs (Issue3131). > > Why are you trying to run refactor.py directly, rather than using 2to3 > (http://svn.python.org/view/sandbox/trunk/2to3/2to3) as an entry > point? > Because I honestly did not see it yesterday in my terminal. I blame it on Canada Day. =) >> Looks like 2to3 needs some TLC. > > 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 be removed from the stdlib. It's causing far > more trouble than it's worth. Fine by me. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
> 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 than keeping them broken. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
> 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 be removed from the stdlib. It's causing far > more trouble than it's worth. I disagree. I think it is quite useful that distutils is able to invoke it, and other people also asked for that feature on PyCon. Why do you think the trouble wouldn't be caused if it wasn't a standard library package? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
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 and 2969 in return. So you did. I didn't notice them, sorry. > It is policy that tests that break > get disabled, rather than keeping them broken. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
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 library; once that's done (or even preferably >> before), lib2to3 should be removed from the stdlib. It's causing far >> more trouble than it's worth. > > I disagree. I think it is quite useful that distutils is able to > invoke it, and other people also asked for that feature on PyCon. But distutils currently *doesn't* invoke it, AFAICT (unless that support is implemented somewhere other than trunk/Lib/distutils/), and no-one has stepped up to make that happen in the months since PyCon. Moreover, as I told those people who asked for this at PyCon, 2to3 is and will never be perfect, meaning that at best, distutils/2to3 integration would look like "python setup.py run2to3", where distutils is just a long-hand way of running 2to3 over your code. This strikes me as a waste of time. > Why do you think the trouble wouldn't be caused if it wasn't > a standard library package? Problems with the current setup: 1) People are currently confused as to where they should be commit fixes. 2) Changes to the sandbox version have to be manually merged into the stdlib version, which is more overhead than I think it's worth. In addition, the stdlib version lags the sandbox version. 3) At least one bug report (issue3131) has mentioned problems with the stdlib 2to3 exhibiting problems that the stand-alone version does not. This is again extra overhead. 4) The test_imports test was commented out because of stdlib test policy. I'd rather not have that policy imposed on 2to3. Collin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can someone check my lib2to3 change for fix_imports?
> 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 version have to be manually merged into the > stdlib version, which is more overhead than I think it's worth. In > addition, the stdlib version lags the sandbox version. It's not a real problem, IMO, using msgmerge is fairly straight-forward. > 3) At least one bug report (issue3131) has mentioned problems with the > stdlib 2to3 exhibiting problems that the stand-alone version does not. > This is again extra overhead. I think the 2to3 packaging issue is otherwise unresolved. Do you want 2to3 to be excluded completely from 2.6 and 3.1 releases? If not, how do you want them packaged? Will it work if packaged in that way? > 4) The test_imports test was commented out because of stdlib test > policy. I'd rather not have that policy imposed on 2to3. It would be possible to comment out the test only in the copy in the stdlib version, or to omit testing 2to3 in the stdlib altogether, if that helps. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
