__name__ becoming read-write?

[Arthur]

Did I hallucinate something about __name__ becoming read-write?

Not in alpha2.

Can't find the reference to this I thought I read - that it was
concluded to be necessary in connection with PEP318.

Better get my facts straight first....

But if true that would seem to solve the main objection to:

the_horrible_na me_I _need_to_call=t ransform(__f)

And would mean that a byproduct of the PEP318 implementation would go
50% toward obviating the need for a PEP318 implementation. At least
by one measure.

But the whole thing might be a hallucination.

Art

[Hallvard B Furuseth]

Arthur wrote:

Did I hallucinate something about __name__ becoming read-write?

_Becoming_ read-write? When was it read-only?

Python 1.5.2 (#1, Jul 14 2004, 20:34:28) [GCC 3.2.3] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam

class foo: pass .... foo.__name__ = 'bar'
foo.__module__ = 'baz'
foo

<class baz.bar at c5ee0>

--
Hallvard

[Michael Hudson]

Arthur <aj******@opton line.com> writes:

Did I hallucinate something about __name__ becoming read-write?
For functions? No, you didn't hallucinate that.
Not in alpha2.
Indeed. The changes were only checked in a couple of weeks ago.
They'll be in alpha3.
Can't find the reference to this I thought I read - that it was
concluded to be necessary in connection with PEP318.
It's something that's been nagging at me for ages, but it was a PEP
318-related comment that finally prodded me into writing the patch.
Better get my facts straight first....

Glad to be of service <wink>!

Cheers,
mwh

--
I've reinvented the idea of variables and types as in a
programming language, something I do on every project.
-- Greg Ward, September 1998

[Arthur]

On 23 Aug 2004 16:50:22 +0200, Hallvard B Furuseth
<h.**********@u sit.uio.no> wrote:

Arthur wrote:

Did I hallucinate something about __name__ becoming read-write?

_Becoming_ read-write? When was it read-only?

Python 1.5.2 (#1, Jul 14 2004, 20:34:28) [GCC 3.2.3] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam

class foo: pass... foo.__name__ = 'bar'
foo.__module__ = 'baz'
foo<class baz.bar at c5ee0>

Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)]
on win32

def foo(): pass
foo.__name__='b ar'

Traceback (most recent call last):
File "<pyshell#3 >", line 1, in -toplevel-
foo.__name__='b ar'
TypeError: readonly attribute

I hope I'm not being stupid.

And what's with running 1.5.2 ;)

Art

[Michael Hudson]

Hallvard B Furuseth <h.**********@u sit.uio.no> writes:

Arthur wrote:

Did I hallucinate something about __name__ becoming read-write?

_Becoming_ read-write? When was it read-only?

When it was a function :-) Or a new style class in 2.2.

Cheers,
mwh

--
I never disputed the Perl hacking skill of the Slashdot creators.
My objections are to the editors' taste, the site's ugly visual
design, and the Slashdot community's raging stupidity.
-- http://www.cs.washington.edu/homes/k...shdot.html#faq

[Arthur]

On Mon, 23 Aug 2004 14:49:41 GMT, Michael Hudson <mw*@python.net >
wrote:

Arthur <aj******@opton line.com> writes:

Did I hallucinate something about __name__ becoming read-write?

For functions? No, you didn't hallucinate that.

Not in alpha2.

Indeed. The changes were only checked in a couple of weeks ago.
They'll be in alpha3.

Thanks for confirming I am not hullicinating. This time, anyway.

My argument - obviously, I think - is that this as a stand-alone
change does enough to ease the pain of the current syntax, and is in
proportion to the problem.

The fact that some of think we are way, way out of proportion with the
direction now headed, having been previously established.

Art

[Anthony Baxter]

On Mon, 23 Aug 2004 14:07:42 GMT, Arthur <aj******@opton line.com> wrote:

Did I hallucinate something about __name__ becoming read-write? Better get my facts straight first....

But if true that would seem to solve the main objection to: the_horrible_na me_I _need_to_call=t ransform(__f) And would mean that a byproduct of the PEP318 implementation would go
50% toward obviating the need for a PEP318 implementation. At least
by one measure.

No, it is now read-write, thanks to mwh. I think, though, that you're
misunderstandin g the difference between setting a local variable in
the function, called '__name__', and setting the actual __name__ of
the function object.

def foo(): pass .... foo.__name__ = 'bar'
foo.__name__ 'bar' def foo(): .... __name__ = 'bar'
.... foo.__name__ 'foo' foo.func_code.c o_names

('__name__',)

[Arthur]

On Tue, 24 Aug 2004 01:40:29 +1000, Anthony Baxter
<an***********@ gmail.com> wrote:

On Mon, 23 Aug 2004 14:07:42 GMT, Arthur <aj******@opton line.com> wrote:

Did I hallucinate something about __name__ becoming read-write?

Better get my facts straight first....

But if true that would seem to solve the main objection to:

the_horrible_na me_I _need_to_call=t ransform(__f)

And would mean that a byproduct of the PEP318 implementation would go
50% toward obviating the need for a PEP318 implementation. At least
by one measure.

No, it is now read-write, thanks to mwh. I think, though, that you're
misunderstandi ng the difference between setting a local variable in
the function, called '__name__', and setting the actual __name__ of
the function object.

You are right. I did know this to be *possibly* true, but had no
implementation to test.

Though __doc__ (and I am sure other stuff) exhjibits the same
behavior, so there is no real excuse to be surprised.

This sabotages my approach, but only to the extent that we would still
need until after __f's def to know the name we are imposing on it.

Of course I am curious as to why, and what would be involved, and
wrong,. with merging the local variable and the actual name for these
special syntax items. It would seem to have merit on its own terms.

For example I had noticed to use string substition on a function doc I
needed to assign to __doc__ outside the function.

Unless I was hallucinating.

Though I would understand if you are not in tutorial mood, or mode.

Art

def foo(): pass... foo.__name__ = 'bar'
foo.__name__'bar' def foo():... __name__ = 'bar'
... foo.__name__'foo' foo.func_code.c o_names

('__name__', )

[Anthony Baxter]

On Mon, 23 Aug 2004 15:58:26 GMT, Arthur <aj******@opton line.com> wrote:

Of course I am curious as to why, and what would be involved, and
wrong,. with merging the local variable and the actual name for these
special syntax items. It would seem to have merit on its own terms.

For example I had noticed to use string substition on a function doc I
needed to assign to __doc__ outside the function.

How would you envisage this working? Look at the following code:

def foo(arg):
__doc__ = "bingle!"
if arg < 0:
__doc__ = "bangle!"
if arg > 0:
__doc__ = "bongle!"

Now, _before_ this code is run, what's foo.__doc__ supposed to be set
to? Remember, at this point, the code has not been run. The local
__doc__ has no value at this point.

Special casing __doc__ (or __name__) so that assignments to a local
like that inside a function assign magically to the function object is
bad magic. It leads to confusion and poor coding. In general, inside a
function, you don't have access to the function object itself[1]

Anthony

[1] I except using sys._getframe() , or raising an exception and
traversing up through the traceback object, as they're hacks.

[Arthur]

On Tue, 24 Aug 2004 02:28:09 +1000, Anthony Baxter
<an***********@ gmail.com> wrote:

On Mon, 23 Aug 2004 15:58:26 GMT, Arthur <aj******@opton line.com> wrote:

Of course I am curious as to why, and what would be involved, and
wrong,. with merging the local variable and the actual name for these
special syntax items. It would seem to have merit on its own terms.

For example I had noticed to use string substition on a function doc I
needed to assign to __doc__ outside the function.

How would you envisage this working? Look at the following code:

def foo(arg):
__doc__ = "bingle!"
if arg < 0:
__doc__ = "bangle!"
if arg > 0:
__doc__ = "bongle!"

Now, _before_ this code is run, what's foo.__doc__ supposed to be set
to? Remember, at this point, the code has not been run. The local
__doc__ has no value at this point.

Special casing __doc__ (or __name__) so that assignments to a local
like that inside a function assign magically to the function object is
bad magic. It leads to confusion and poor coding. In general, inside a
function, you don't have access to the function object itself[1]

I see the point.

But.. there is always a but.

I'm thinking now a special sytnax item in the __form__ at the top of
function that would:

1) put one on notice that the function is to be transformed (as in
"see below").

2) allow a name to be assigned to it, which will become the
transform's __name__.

Something in the general direction, I think, of where Paul Morrow's
instincts were going.

I like it.

And have no idea whether it is feasible.

Art