[Python-ideas] anonymous object support

[Matt Joiner]

Just as a slight aside, is the special case of type() purely for convenience?
Aren't the "new-style" ways to do this __class__ and isinstance()?

On Tue, Jul 26, 2011 at 2:06 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Jul 26, 2011 at 12:58 PM, Herman Sheremetyev
> <herman at swebpage.com> wrote:
>> Well, I think it's not very intuitive that type() can be used as a
>> class constructor.
>
> Then you don't really understand metaclasses yet (now, metaclasses
> themselves certainly don't qualify as intuitive, but understanding
> them is essential to understanding many otherwise confusing elements
> of Python's type system). type() works the way it does because it is
> designed to construct a new class object from a name, a tuple of base
> classes and a namespace dictionary, just like any other metaclass. The
> slightly hacky (but very convenient) part is actually the ability to
> use the single argument form of type() to query the metaclass of an
> existing object.
>
> To get back to the ideas discussed in this thread:
>
> 1. Use cases where creating a lot of one-shot classes on the fly is a
> reasonable idea are rare and highly specialised
> 2. If you want to do so, the obvious way is to use a class statement
> and adjust __name__ and __dict__ afterwards
> 3. Alternatively, if you want this functionality as an expression,
> either the type builtin or a custom function can do the job
> 4. It is significantly more efficient to abstract out a common class
> definition and create multiple instances of that class
> 5. If you just want a namespace to store some data with consistent
> attribute names, then collections.namedtuple can be used to also make
> the instance storage efficient. If you store a function in a
> namedtuple instance then you can still call it, it just won't be
> passed 'self' as an implicit first parameter (as the descriptor
> machinery will not be invoked).
> 6. If you just want an arbitrary attribute holder, than instances of a
> trivial empty user-defined class can serve that purpose. As with named
> tuples, functions stored on the instance can still be called, but
> retrieving them won't invoke the descriptor machinery.
> 7. Mock objects do *not* qualify as a common use case. Despite the
> proliferation of libraries that choose to provide slightly different
> APIs for them, such objects may be used widely in test suites but are
> still *implemented* rarely - they fall into the "highly specialised"
> category I mentioned above.
>
> The tools are there so that people that know what they're doing can do
> what needs to be done to achieve their ends. Simplifying the API for
> dynamic type creation would be an attractive nuisance, as it will
> likely lead to people writing ill-advised code without giving the
> matter sufficient thought. Obviously, that's going to happen no matter
> what we do, but there's no reason for us to deliberately *encourage*
> bad ideas by making them too easy to write.
>
> Points 5 and 6 go back to the original question about namespace
> objects, which is independent of the dynamic type creation issue.
> Various attempts have been made to address that over the years, and
> the current answers are the original approach (just define a namespace
> type and use instances of it to store arbitrary data, with poor
> debugging support due to the relative anonymity and arbitrary content
> of each instance) and the named tuple approach, which provides
> excellent debugging information and memory efficiency at the cost of
> being explicit up front regarding the attributes possessed by each
> instance.
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>