[BangPypers] Object Oriented Programming in python

Saager Mhatre saager.mhatre at gmail.com
Mon Oct 21 20:10:17 CEST 2013

On Mon, Oct 21, 2013 at 7:11 PM, Dhananjay Nene <dhananjay.nene at gmail.com>wrote:

> Since you suggested that "Superior constructs
> implemented inferiorly." and did not respond to the line which
> wondered if that was based on syntactic or stylistic differences,

I believe I responded to that statement by saying that the difference I
note is neither syntactic, nor stylistic; it is semantic in that
metaclasses behave very differently in other platforms by interacting with
objects at run-time as opposed to just at compile-time. That simple
difference makes them significantly more powerful to me.

> I presumed that comment was based on one or two examples of scenarios
> that you had run into where you found python metaprogramming /
> metaclasses constraining in some particular way. Anyways it seems
> there aren't any such examples I can elicit from a continuing
> discussion.

Again, if we re-read the conversation so far (and I just did), I have been
avoiding a discussion on metaprogramming as that has little to do with
metaclasses in all the other platforms I mentioned. AFAICT, only Python
conflates these two[*], YMMV. Any examples of metaprogramming in
Ruby/Groovy I provide will provide no value in demonstrating the
capabilities of metaclasses therein.

As for metaclasses, I find Python's implementation constraining
specifically for the point I mentioned above in this very note. For a
whirlwind tour of what Groovy's MetaClass has to offer try the Dynamic
Groovy <http://groovy.codehaus.org/Dynamic+Groovy> section of the Groovy
User Guide <http://groovy.codehaus.org/User+Guide>. I could give you more
contrived examples, but that would only lead to a pissing match where you
show me how X can be achieved in Python with P + Q - R. But, to really get
a hang of these features I'll give you the same advice that several
pythonistas (including yourself) gave me when I started with it and found
things out of place- give Ruby/Groovy a shot, take them out for a spin
(preferably a long drive) and then you'll discover the benefits.

My grievance with Python's metaprogramming capabilities is another matter
altogether and warrants a different thread. But, just because you mentioned
it, I''ll put it down in one line- I don't find Python's metaprogramming
inadequate, it's all there; it's just that the capability is (both
syntactically and semantically) cumbersome at best and clumsy at worst.

> >
> > Also, just to clarify, metaprogramming is distinct from metaclasses and
> > presence of one in a platform is not essential to the presence of the
> > other. Metaprogramming is more to do with code that writes, unwrites or
> > modifies more code; while metaclasses are about some seriously dynamic
> > dispatch.
> >
> > Incidentally, that is another place Python's implementation departs from
> > metaclasses in other languages. Where Python provides metaclasses as a
> hook
> > to rewrite class internals/implementation before it becomes available to
> > other code, other platforms attach metaclasses to classes (or objects, in
> > some cases) at runtime to control/alter the way messages to/methods of
> the
> > class (or object) are dispatched. Python conflates metaprogramming into
> > metaclasses where it is not a necessity, in that Python metaclasses can
> do
> > little more of value than add/remove/modify attributes of the class; in
> > other words, metaprogram elements of class definition.
> Sure python does do a lot of things differently. But the question I am
> interested in an answer to is does it empower the user to do /
> constrain the user from doing certain things as compared to similar
> languages, distribution of functionality within meta* terms
> notwithstanding.

To reiterate, yes, I believe Python's metaclasses (differently implemented
as they are) are constraining specifically for the point I mentioned above
in this very note. Python's metaclasses do not allow for the modification
of the behaviour of a class/object at runtime. The way I see it, the best
they do is extract boilerplate code from class definitions. I can get that
with class decorators and avoid all the confusion about how Python does
metaclasses differently as well as how metaclasses wire into the type
system. To me, Python's metaclasses provide too little value for the
cognitive load they add, YMMV.

- d

* They really should've stuck to Class Decorators and avoided the
confusion, or did those come after metaclasses?

More information about the BangPypers mailing list