Metaprogramming Example

[bruno.desthuilliers at gmail.com]

On 19 avr, 16:34, andrew cooke <and... at acooke.org> wrote:
> On Apr 18, 4:48 am, Bruno Desthuilliers <bruno.42.desthuilli... at websiteburo.invalid> wrote:
>
> [...]
>
> > Practically, this means that (amongst other niceties) :
> > - you can define functions outside classes and use them as instance or
> > class methods
> > - you can add/replaces methods dynamically on a per-class or
> > per-instance basis
> > - you can access the function object of a method and use it as a function
> > - you can define your own callable types, that - if you implement the
> > appropriate support for the descriptor protocol - will be usable as
> > methods too
>
> ok, that's convincing (i had thought the majority of these were
> already
> possible, albeit with some kind of hard-coded "magic" behind the
> scenes).

Yep, the whole point is that it's not that hard-coded anymore. Python
exposes most of it's inner mechanisms, so that you can taylor quite a
lot of things to your needs. This is quite useful for writing clean
frameworks needing very few boilerplate in the user code.

> [...]
>
> > > by referring to the titanic
> > > i didn't mean that python was a disaster, rather that the "iceberg" is
> > > still there (i am not 100% sure what the iceberg is, but it's
> > > something
> > > to do with making namespaces explicit in some places and not others).
>
> > I guess you're thinking of the self argument, declared in the function's
> > signature but not "explicitly passed" when calling the method ?
>
> not really.  more to do with when namespaces (i am not sure i have the
> right term - the dictionary that provides the mapping from name to
> object)
> are explicit or implicit.  for example, python has closures (implicit
> lookup) and "self" (explicit lookup).
>
> but as i said, i don't have a clear argument - something just feels
> "odd".
> at the same time, i know that language design is a practical business
> and so this is probably not important.

The fact is that everything you do with closures can be done with
objects. OTHO, there are quite a lot of cases where defining a
specific class would be just way too heavy, and a closure is much more
lightweight. So yes, it's a matter of "practicality beats purity".
While trying to remain as clean as possible, Python is definitively a
practical language.

> finally, thank you for pointing me to sql alchemy (i think it was
> you?).

Seems so.

> it really is excellent.

Indeed !-)