Todo:

im_self -> __self__
im_func -> __func__
im_class -> __self__.__class__
instancemethod(func, self, cls) -> instancemethod(func, self)

Crys, why don't you give it a try yourself? It's quite easy to write
such a simple substitution.

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? :)

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 bug with 'Crys' once and I believe you mentioned it in
your intro to python-dev. :-)

You are too fast. I haven't written a fixer for new.instancemethod yet.
Do we need one?

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 warning to it in 2.6.  (This
is really part of the library reorg, but we might as well take care of
it now rather than making a temporary change to it.)

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)

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 -- we should
really export all flags via the sys module...

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)
> 		return NULL;
> 
> I don't know how to check for that flag in Python though -- we should
> really export all flags via the sys module...

I've exposed the flag in r59204 as sys.py3kwarning. I've also added a
method warnings.warnpy3k().

Christian

Does this still need to remain open?

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.__class__)
Python 3.0:
instance.method = types.MethodType(function, instance)

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)?

The 'new' module is already gone. I've ripped it out a couple of days
ago and added deprecation warnings in 2.6

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().

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.

> 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 types.MethodType should be
doubly deprecated. The types module was only ever intended for type
checking, not for creating new instances.

The correct solution will be to use whatever we end up deciding about
pyvm. Certainly the types module will go.

Maybe new in 2.6 should be a -3 deprecation only?

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. :(

> 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 a poll it ended up a lots of bad jokes. :(

Naming contests *always* end in bad jokes. :-)  Some of the jokes were
kind of cute. I got a laughing fit over the naming rights suggestion.

Must this still be open?

No reply to msg71746.