<br>On Fri, Jun 25, 2010 at 11:03 AM, WANG Cong <span dir="ltr"><<a href="mailto:xiyou.wangcong@gmail.com">xiyou.wangcong@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On 06/25/10 17:25, Steven D'Aprano <<a href="mailto:steve@REMOVE-THIS-cybersource.com.au">steve@REMOVE-THIS-cybersource.com.au</a>> wrote:<br><br>
</div><div class="im">> Yes, isn't it wonderful? In other languages, metaprogramming is deepest<br>
> black magic, or even completely impossible. In Python it is so easy that<br>
> anyone can do it, and it is something beginners learn.<br>
><br>

<br>
</div>The point is why making metaprogramming easy is wonderful? AND, even if<br>
it were wonderful, why only this one, i.e. creating attributes by<br>
assignments, not other things?<br>
<br>
In my points of view, a programming language is wonderful only when it<br>
is designed so, there is no other things like this one in Python, AFAIK,<br>
are as simple as this one, thus making this one really odd to me. :-)<br></blockquote><div><br></div><div>What "other things"?</div><div><br></div><div>That you define this as 'metaprogramming' is really strange to me. I have no idea what you're talking about when you decide to call adding an attribute to an object that.</div>

<div><br></div><div>Classes and instances are not static. They are created at runtime: thus, they can be changed at runtime. Why would you expect anything else? They aren't concrete 'things' like in certain other languages.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>>> 2) Metaprogramming should be distinguished with non-meta programming,<br>
>> like templates in C++, it is obvious to see if you are using template<br>
>> metaprogramming in C++.<br>
><br>
> Why should it be?<br>
<br>
<br>
</div>It is, if you consider other things of metaprogramming in Python. For<br>
example, deleting an attribute.<br></blockquote><div><br></div><div>"del obj.a" works just fine.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<div class="im">>> 4) Also, this will _somewhat_ violate the OOP princples, in OOP, this is<br>
>> and should be implemented by inherence.<br>
><br>
> Perhaps, and perhaps not. But Python has never pretended to slavishly<br>
> follow OOP "principles". Python does what works, not necessarily what is<br>
> a "pure" design. Python has functional programming, procedural<br>
> programming, and OO programming, and happily mixes them all together.<br>
><br>
<br>
</div>"Happily mixes them all together" doesn't mean it is elegant. :)<br></blockquote><div><br></div><div>Its quite elegant in fact.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<div class="im">>> 5) This could hide errors silently, for example, when I do:<br>
>><br>
>>>>>test.typooooo = "blah"<br>
><br>
> Yes, that is one downside to Python's dynamicism. The solutions are:<br>
><br>
> * Unit tests, unit tests, unit tests. Then more unit tests.<br>
>   (You're writing them anyway, aren't you?)<br>
> * Run PyChecker or PyLint to check the source code for errors.<br>
> * Don't make typos. *smiles*<br>
><br>
<br>
<br>
</div>Well, I am talking in the language design level, if we could solve<br>
this problem in the language design level, why do we need to bother<br>
these things?<br></blockquote><div><br></div><div>Why complicate the language when there's perfectly good ways to solve the problem elsewhere? Especially if those ways -also- have significant benefits of their own.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">>> I am expecting Python will compllain that "Hey! You have a typo in the<br>
>> attribute name!". Also, this could make code worse to read, if I add a<br>
>> new attribute in one place, and add another one in the another place,<br>
>> and so on, what attributes the hell do I have finally?!<br>
><br>
> Then don't do that.<br>
><br>
<br>
</div>Yeah, "don't do that" is one thing, "Python allows to do that" is<br>
another thing.</blockquote><div><br></div><div>Why shouldn't it allow it?</div><div><br></div><div>If you care about having a firm, set series of attributes that can not change, then you will never add an attribute on the fly. Therefore, you will never run into a situation where you're confused on what attributes are available. Therefore, this works perfectly well as-is.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Using 'setattr(xxxx)' could also prove Python<br>
is a dynamic programming, but Python doesn't choose this by default.<br></blockquote><div><br></div><div>I don't understand what you're saying here.</div><div><br></div><div><div class="gmail_quote">On Fri, Jun 25, 2010 at 11:18 AM, WANG Cong <span dir="ltr"><<a href="mailto:xiyou.wangcong@gmail.com">xiyou.wangcong@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div class="im">On 06/25/10 15:34, Bruno Desthuilliers <bruno.42.desthuilliers@websiteburo.invalid> wrote:<br>> Python's classes are plain objects, and like any other object are<br>> created at runtime. Having to special-case them would break the<br>

> simplicity and uniformity of Python for no good reason. Just like<br>> there's no good reason to make setattr() working differently for class<br>> and non-class objects.<br>><br><br></div>For implementaiton, perhaps, but not for the language design, how could<br>

a language design be perfect if we can use setattr() like assignments<br>while use other things, e.g. delattr(), not? Is there any way to express<br>delattr() as simple as expressing setattr() with assignments? I doubt...<br>

</blockquote><div><br></div><div>Huh?</div><div><br></div><div>Python 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) </div><div>[GCC 4.0.1 (Apple Inc. build 5465)] on darwin</div><div>Type "help", "copyright", "credits" or "license" for more information.</div>

<div>>>> delattr</div><div><built-in function delattr></div><div><br></div><div>"del obj.x" invokes obj.__delattr_("x") just like "obj.x = 1" invokes obj.__setattr__("x", 1), and there are delattr() and setattr() convenience functions for both. There's also a getattr() function (which ultimately calls obj.__getattr__) for the 'reading' of said attribute. </div>

<div><br></div><div>I'm not sure what you think is missing. The object protocol is fully documented (and customizable).</div><div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

Using assignments to create an attribute hides metaprogramming behide,<br>while using delattr() exposes it.<br></blockquote><div><br></div><div>I don't understand what you're saying here either.</div><div><br></div>

<div><br clear="all">-- Ix<br>  m e (AT) i x o k a i (DOT) i o<br><br><br><br><div class="gmail_quote">On Fri, Jun 25, 2010 at 11:23 AM, WANG Cong <span dir="ltr"><<a href="mailto:xiyou.wangcong@gmail.com">xiyou.wangcong@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

On 06/25/10 14:31, Richard Thomas <<a href="mailto:chardster@gmail.com">chardster@gmail.com</a>> wrote:<br><div class="im">> If you desperately want to limit the attribute assignments that can be<br>> performed on an object you can set the __slots__ attribute of its<br>

> type. However, the Python ethos has always been to restrict as little<br>> as necessary to provide the tools it needs. Performing additional<br>> checks every time an attribute assignment is performed is completely<br>

> unnecessary. Remember that unlike C these checks would have to be<br>> performed at run-time.<br>><br><br></div>I don't care in which way I can limit this, I care why I should limit<br>this by default, not vice versa?<br>

<br>Yeah, I do understand this could be a performance issue, but comparing<br>it with a language design issue, _I think_ the latter thing is much more<br>important than the former one.</blockquote><div><br></div><div>In general, Python does not enforce restrictions upon the programmer. That's simply the way it is. If you don't like it, if you think it should protect you from yourself -- this is not the language for you, that's all.</div>

<div><br></div><div>Python allows you to do basically whatever you want, with certain exceptions -- it won't generally guess what you mean, and will almost never do any sort of implicit conversion, and hell, 'implicit' is just a dirty word in general so its not likely to do much automagically. </div>

<div><br></div><div>From a "language design issue", the dynamism IS one of the key fundamental design decisions of the language. Its not accidental. Sure, there's tradeoffs for that. Its got strengths, and weaknesses. Pros and cons. But that's the language. A "less-Dynamic" Python is possible, but it wouldn't be Python anymore, and a LOT of very successful things people do with Python would stop working.</div>

<div><br></div><div>Or just be a lot uglier. Pretty is actually a fundamental design decision too :)</div><div><br></div><div>Generally speaking. Exceptions always exist. </div><div><br></div><div>--S</div></div></div></div>

</div></div>