From: Chris Rebert on 26 Jun 2010 21:35
On Sat, Jun 26, 2010 at 6:06 PM, Steven D'Aprano
> CPython is a fairly plodding implementation. But that's due to the
> conservativeness of CPython: Unladen Swallow is faster, and PyPI is
> faster still, and the PyPI people expect to eventually be competitive
> with C for speed.
PyPy (http://pypy.org/), *not* PyPI (http://pypi.python.org/pypi).
You're confusing a package index with a self-hosting interpreter; darn
From: Steven D'Aprano on 26 Jun 2010 21:48
On Sat, 26 Jun 2010 18:35:25 -0700, Chris Rebert wrote:
> On Sat, Jun 26, 2010 at 6:06 PM, Steven D'Aprano
> <steve(a)remove-this-cybersource.com.au> wrote: <snip>
>> CPython is a fairly plodding implementation. But that's due to the
>> conservativeness of CPython: Unladen Swallow is faster, and PyPI is
>> faster still, and the PyPI people expect to eventually be competitive
>> with C for speed.
> PyPy (http://pypy.org/), *not* PyPI (http://pypi.python.org/pypi).
> You're confusing a package index with a self-hosting interpreter; darn
> typos, eh?
Damn news client, it should force me to write:
to catch these sorts of errors and reduce the need for me to proof-read
From: Carl Banks on 27 Jun 2010 00:01
On Jun 25, 8:24 pm, WANG Cong <xiyou.wangc...(a)gmail.com> wrote:
> Understand, but please consider my proposal again, if we switched to:
> setattr(foo, 'new_attr', "blah")
> by default, isn't Python still dynamic as it is? (Please teach me if I
> am wrong here.)
> This why I said the questionable thing is not so much related with dynamic
> programming or not.
Because it makes dynamicism harder to do.
Like I said, Python's goal isn't simply to make dynamicism possible,
it's to make it easy.
"foo.new_attr = 'blah'" is easier than using setattr.
From: Bruno Desthuilliers on 27 Jun 2010 06:35
WANG Cong a écrit :
> On 06/25/10 15:34, Bruno Desthuilliers <bruno.42.desthuilliers(a)websiteburo.invalid> wrote:
>> WANG Cong a écrit :
>>> Hi, list!
>>> I have a doubt about the design of dynamic attribute creation by
>>> assignments in Python.
>>> As we know, in Python, we are able to create a new attribute of
>>> a class dynamically by an assignment:
>>>>>> class test: pass
>>>>>> test.a = "hello"
>>> However, I still don't get the points why Python designs it like this.
>>> My points are:
>> Python's classes are plain objects, and like any other object are
>> created at runtime. Having to special-case them would break the
>> simplicity and uniformity of Python for no good reason. Just like
>> there's no good reason to make setattr() working differently for class
>> and non-class objects.
> For implementaiton, perhaps, but not for the language design, how could
> a language design be perfect if we can use setattr() like assignments
> while use other things, e.g. delattr(), not? Is there any way to express
> delattr() as simple as expressing setattr() with assignments? I doubt...
cf Ethan's answer on this.
> Using assignments to create an attribute hides metaprogramming
> while using delattr() exposes it.
Once again : in Python, none of this is "metaprogramming" - just plain
ordinary programming. So called "metaprogramming" is just an artefact of
static languages where datastructures are created at compile time.
From: Bruno Desthuilliers on 27 Jun 2010 06:44
WANG Cong a �crit :
> The point is why making metaprogramming easy is wonderful?
Because it makes life easier ?-)
> AND, even if
> it were wonderful, why only this one, i.e. creating attributes by
> assignments, not other things?
a = 1
>>> 2) Metaprogramming should be distinguished with non-meta programming,
>>> like templates in C++, it is obvious to see if you are using template
>>> metaprogramming in C++.
>> Why should it be?
> It is, if you consider other things of metaprogramming in Python. For
> example, deleting an attribute.
>>> 3) Thus, allowing dynamic attribute creation by assignment _by default_
>>> is not a good design for me. It is not obvious at all to see if I am
>>> doing metaprogramming at a first glance.
>> Why do you care if you are doing metaprogramming? Perhaps other languages
>> make it seem difficult and scary, but in Python it is not. It is simple
>> and easy.
> I do care, programming for a class is quite different from programming
> for a non-class,
Not when a class is just another ordinary object.