Some language proposals.

[Jacek Generowicz]

Re: Some language proposals.

Michael Hudson <mwh@python.net > writes:
[color=blue]
> Jacek Generowicz <jacek.generowi cz@cern.ch> writes:
>[color=green]
> > Michael Hudson <mwh@python.net > writes:
> >[color=darkred]
> > > Jacek Generowicz <jacek.generowi cz@cern.ch> writes:[/color][/color][/color]
[color=blue]
> Ah, ok. To make it behave like a method, you need to make it a
> descriptor, i.e. implement __get__ (and make everything in sight
> new-style classes, of course).[/color]

Yeeees, which is why waaaay upthread I wrote:
[color=blue][color=green][color=darkred]
> > > > If I were to implement them as instances then I'd have to
> > > > reimplement all the descriptors that take care of turning
> > > > functions into bound or unbound methods.[/color][/color][/color]

(although I did misplace the terminology a little, I realize.)
[color=blue]
> import types
>
> class foo(object):
> pass
>
> class Callable(object ):
> def __init__(self): # wonder why this is needed:
> self.__name__ = 'Callable'
> def __call__(self, ob):
> return ob
> def __get__(self, ob, cls=None):
> return types.UnboundMe thodType(self, ob, cls)
>
> foo.inst = Callable()
>
> print foo.inst
> print foo().inst()
>
> (needs 2.3, for 2.2 use new.instancemet hod instead).[/color]

Aha !

I was doing this stuff way back in 2.2[*], where you get
[color=blue][color=green][color=darkred]
>>> print foo.inst[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 7, in __get__
TypeError: cannot create 'instance method' instances

but it does indeed work in 2.3. Thanks for pointing that out.
[color=blue][color=green]
> > Aaah, this thread is an attempt to assimilate me :-) Now I understand.[/color]
>
> Damn, you noticed.[/color]

I'm well on the ball, I am.

Cheers,

[*] Actually, I'm still forced to use 2.2 in production for now.

[Jacek Generowicz]

Re: Some language proposals.

aahz@pythoncraf t.com (Aahz) writes:
[color=blue]
> class Callable:
> def __call__(self):
> print "!"
>
> class C:
> def __init__(self):
> self.foo = Callable()
>
> C().foo()
>
> Now tell me why this doesn't do what you want.[/color]

Because
[color=blue][color=green][color=darkred]
>>> C.foo[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: class C has no attribute 'foo'

for a start.

[Antoon Pardon]

Re: Some language proposals.

Op 2004-02-25, Anton Vredegoor schreef <anton@vredegoo r.doge.nl>:[color=blue]
> Antoon Pardon <apardon@forel. vub.ac.be> wrote:
>[color=green]
>>I don't see much difference between a function changing a higher up
>>variable that is global or just in between.[/color]
>
> If you want a function with its own namespace, that is already
> possible as you showed yourself in an earlier post. On the other hand,
> if a function has its own namespace what is the difference between a
> function and a class? Why not use a class in the first place?[/color]

Maybe because somtimes it is more easy or natural to think
of a problems in terms of a function and sometimes in terms
of a
[color=blue]
> Remember that "global" is just a way for a function to tell the
> interpreter that this variable belongs to the global namespace.
>
> There is some inconsistency if one has a function inside a function
> and that function has a global 'x' but the outer function doesn't have
> a global 'x'. Modifications of 'x' from the deepest function do not
> reach the global namespace, in fact they do not even reach the
> namespace of the containing function.
>
> Only if both functions have a global 'x' the name is visible at the
> global and intermediate level.[/color]

Well that looks like either poor design or poor implementation to
me.
[color=blue]
> However there is already a mechanism to solve these kind of problems:
> namespaces! Why not use them?[/color]

Maybe because that solution can sometimes seem forced onto the
problem. Like if all you have is carpenting tools you only
can provide carpenting solutions.
[color=blue]
>[color=green][color=darkred]
>>> a,b = A.a,A.b[/color]
>>
>>Well maybe my wording was off, but this doesn't accomplisch what I
>>want since after your statement followed by: a = new_value; A.a will
>>not be changed.[/color][/color]

Aaargh!!!!, A dreadfull type on my part that completly changed the
meaning of what I wanteds to say. "not" should read "now"

--
Antoon Pardon

[Antoon Pardon]

Re: Some language proposals.

Op 2004-02-25, Paul Prescod schreef <paul@prescod.n et>:[color=blue]
> Jacek Generowicz wrote:
>[color=green]
>> Paul Prescod <paul@prescod.n et> writes:
>>
>>[color=darkred]
>>>I disagree. Closures are rare in Python because Python is primarily an
>>>OOP language.[/color]
>>
>> I disagree, Python is a multi-paradigm language ...[/color]
>
> In Python functions are objects but objects are not functions. In (e.g.)
> Scheme the opposite is true.
>[color=green]
>> ... I fail to see how
>> this has any bearing on the use of closures ... all of which is
>> irrelevant to my original point, which was to note out that saying
>> "people don't use it much" is not a very convincing argument for not
>> fixing something that is broken ... because the very fact that it is
>> broken probably contributes to people not using it much.[/color]
>
> But the more important point is that people do not NEED it much. Guido
> writes hundreds of lines of Python code per week. If he often ran into
> situations where a mutable closure would make a big difference then he
> would presumably find some way of doing it. The people who want this
> seem most often to be people trying to import their coding styles from
> another language.[/color]

I think this can be turned around. People who don't want this included
are people who want python to be used in a "pythonic" style.

My idea is that there is nothing wrong with a laguage that supports
different coding styles. Personnaly I switch styles according to
how view the solution to the problems I have to solve. Sometimes
I view such a solution in a very object oriented way, sometimes
I don't. So when I envision a particular solution, that is best
implemented in a particular style, why shouldn't I use that style
just because I program in python.

--
Antoon Pardon

[Michael Hudson]

Re: Some language proposals.

Jacek Generowicz <jacek.generowi cz@cern.ch> writes:
[color=blue][color=green]
> > import types
> >
> > class foo(object):
> > pass
> >
> > class Callable(object ):
> > def __init__(self): # wonder why this is needed:
> > self.__name__ = 'Callable'
> > def __call__(self, ob):
> > return ob
> > def __get__(self, ob, cls=None):
> > return types.UnboundMe thodType(self, ob, cls)
> >
> > foo.inst = Callable()
> >
> > print foo.inst
> > print foo().inst()
> >
> > (needs 2.3, for 2.2 use new.instancemet hod instead).[/color]
>
> Aha ![/color]

Glad to be of service...
[color=blue]
> I was doing this stuff way back in 2.2[*], where you get
>[color=green][color=darkred]
> >>> print foo.inst[/color][/color]
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "<stdin>", line 7, in __get__
> TypeError: cannot create 'instance method' instances
>
> but it does indeed work in 2.3. Thanks for pointing that out.[/color]

This is one of the many little ways -- particularly in the area of
new-style classes -- in which Python 2.3 is just Python 2.2 done
right.

Cheers,
mwh

--
I also feel it essential to note, [...], that Description Logics,
non-Monotonic Logics, Default Logics and Circumscription Logics
can all collectively go suck a cow. Thank you.
-- http://advogato.org/person/Johnath/diary.html?start=4

[Josiah Carlson]

Re: Some language proposals.

>>class Callable:[color=blue][color=green]
>> def __call__(self):
>> print "!"
>>
>>class C:
>> def __init__(self):
>> self.foo = Callable()
>>
>>C().foo()
>>
>>Now tell me why this doesn't do what you want.[/color]
>
>
> Because
>
>[color=green][color=darkred]
>>>>C.foo[/color][/color]
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> AttributeError: class C has no attribute 'foo'
>
> for a start.[/color]

Perhaps you want the below. You seem to be interested in doing things
with classes and not instances.

class Callable:
def __call__(self):
print "!"

class C:
foo = Callable()

- Josiah

[Jacek Generowicz]

Re: Some language proposals.

Josiah Carlson <jcarlson@nospa m.uci.edu> writes:
[color=blue]
> Perhaps you want the below. You seem to be interested in doing things
> with classes and not instances.
>
>
> class Callable:
> def __call__(self):
> print "!"
>
> class C:
> foo = Callable()
>
> - Josiah[/color]

Perhaps you want to read <tyfk72amei6.fs f@pcepsft001.ce rn.ch> again:

http://www.google.com/groups?safe=images&ie=UTF-8&oe=UTF-8&as_umsgid=tyfk72amei6.fsf%40pcepsft001.cern.ch&lr=&hl=en

Here's the relevant part:

Jacek Generowicz <jacek.generowi cz@cern.ch> writes:
[color=blue][color=green][color=darkred]
> >>> class foo: pass[/color][/color]
> ...[color=green][color=darkred]
> >>> class callable:[/color][/color]
> ... def __call__(self): print self
> ...[color=green][color=darkred]
> >>> instance = callable()
> >>> def meth(self): print self[/color][/color]
> ...[color=green][color=darkred]
> >>> foo.meth = meth
> >>> foo.instance = instance
> >>> f = foo()
> >>> f[/color][/color]
> <__main__.foo instance at 0x815fa64>[color=green][color=darkred]
> >>> f.meth()[/color][/color]
> <__main__.foo instance at 0x815fa64> # self == f[color=green][color=darkred]
> >>> f.instance()[/color][/color]
> <__main__.calla ble instance at 0x815f624> # self != f[color=green][color=darkred]
> >>> f.meth[/color][/color]
> <bound method foo.meth of <__main__.foo instance at 0x815fa64>>[color=green][color=darkred]
> >>> f.instance[/color][/color]
> <__main__.calla ble instance at 0x815f624> # Hmm, it's not a method[color=green][color=darkred]
> >>>[/color][/color]
>
> meth behaves like a Python method, instance does not.[/color]