[issue1504] Add 2to3 fixer for (un)bound methods

Mark Lawrence added the comment: No reply to msg71746. -- nosy: +BreamoreBoy status: open -> closed ___ Python tracker ___ ___ Python-

[issue1504] Add 2to3 fixer for (un)bound methods

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Must this still be open? -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: > You are right about the rest. Can you start a discussion on the list? Well the only question is where to put these symbols, right? I guess I still like putting them in sys best, for the ones that don't fit in collections. > The last time I tried to kick off

[issue1504] Add 2to3 fixer for (un)bound methods

Christian Heimes added the comment: The deprecation warning in 'new' is a -3 warning. I've added a new method warning.warnpy3k for the job. You are right about the rest. Can you start a discussion on the list? The last time I tried to kick off a poll it ended up a lots of bad jokes. :(

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: > Whatever you say. But shouldn't we make people to use types.MethodType() > or whatever we use as the new module for PyMethod_Type()? People are > going to use types.MethodType() when they see the deprecation warning. Well, if new.method is deprecated, then t

[issue1504] Add 2to3 fixer for (un)bound methods

Christian Heimes added the comment: Whatever you say. But shouldn't we make people to use types.MethodType() or whatever we use as the new module for PyMethod_Type()? People are going to use types.MethodType() when they see the deprecation warning. By the way I've updated the docs in r59248. __

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: Exactly. I'm proposing that we don't bother with people who call types.MethodType(), but we *do* bother converting code that calls new.method(). __ Tracker <[EMAIL PROTECTED]> _

[issue1504] Add 2to3 fixer for (un)bound methods

Christian Heimes added the comment: The 'new' module is already gone. I've ripped it out a couple of days ago and added deprecation warnings in 2.6 __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: Aren't there equivalent ways to spell those with the "new" module? How about a fixer for that code (which may be easier to write)? __ Tracker <[EMAIL PROTECTED]> ___

[issue1504] Add 2to3 fixer for (un)bound methods

Christian Heimes added the comment: Some cases aren't covered by the fixer. I'm not sure if we need fixers for two cases: Python 2.x: Cls.method = types.MethodType(function, None, Cls) Python 3.0: Cls.method = function Python 2.x: instance.method = types.MethodType(function, instance, instance.

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: Does this still need to remain open? -- priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bu

[issue1504] Add 2to3 fixer for (un)bound methods

Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > There's C code like this: > > if (Py_Py3kWarningFlag && > PyErr_Warn(PyExc_DeprecationWarning, > "apply() not supported in 3.x") < 0) > retur

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: There's C code like this: if (Py_Py3kWarningFlag && PyErr_Warn(PyExc_DeprecationWarning, "apply() not supported in 3.x") < 0) return NULL; I don't know how to check for that flag in Python though --

[issue1504] Add 2to3 fixer for (un)bound methods

Christian Heimes added the comment: How should I issue a warning in the new module? Should and can I check for the -3 warning option or should I warn w/o checks for the -3 option? from warnings import warn as _warn _warn("The 'new' module is not supported in 3.x", DeprecationWarning, 2) ___

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: A fixer for new.instancemethod would be nice, though I doubt that there will be many uses. We could also go a different way: since new.py has a comment stating it is deprecated (in 2.5 already), perhaps we should just kill in in 3.0 and add an explicit 3.0 warn

[issue1504] Add 2to3 fixer for (un)bound methods

Christian Heimes added the comment: You are too fast. I haven't written a fixer for new.instancemethod yet. Do we need one? -- status: closed -> open __ Tracker <[EMAIL PROTECTED]> __

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: It works, though the "__self__.__class__" substitution is technically wrong -- it creates a single NAME node whose contents is that string, while in the parse tree it should really be three tokens. But as it works, I wouldn't worry about it. I saw you sign a

[issue1504] Add 2to3 fixer for (un)bound methods

Christian Heimes added the comment: Added fix_methodattrs with an unit test in r59196. Can you check it please. By the way how do you know my IRC nick? Are you lurking in #python? :) __ Tracker <[EMAIL PROTECTED]> __

[issue1504] Add 2to3 fixer for (un)bound methods

Guido van Rossum added the comment: Crys, why don't you give it a try yourself? It's quite easy to write such a simple substitution. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __

[issue1504] Add 2to3 fixer for (un)bound methods

New submission from Christian Heimes: Todo: im_self -> __self__ im_func -> __func__ im_class -> __self__.__class__ instancemethod(func, self, cls) -> instancemethod(func, self) -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: py3k messages: 57870 nosy: c