namespaces module (a.k.a. bunch, struct, generic object, etc.) PEP

rzed jello at comics.com
Fri Feb 11 12:07:34 EST 2005


Jeremy Bowers <jerf at jerf.org> wrote in
news:pan.2005.02.11.11.49.35.869566 at jerf.org: 

> On Fri, 11 Feb 2005 22:23:58 +1000, Nick Coghlan wrote:
>> This is one of the reasons why Steven's idea of switching to
>> proposing a new module is a good one. It then provides a
>> natural location for any future extensions of the idea such as
>> Records (i.e. namespaces with a defined set of legal fields)
>> and NamedTuples and NamedLists (i.e. namespaces with a defined
>> field order) 
> 
> I'm not very good at reading Guido's mind, but it might be worth
> feeling out whether mentioning this will improve the chances of
> this passing or not, because while I do not know, can not know,
> and am not trying to predict, it is at least possible that Guido
> may feel as I have been: That this proposal on its own isn't
> that exciting, but as the foundation of some *other* standard
> functionality as described it might be very good. In that case
> that should be emphasized. 
> 
> See, now it still doesn't make me jump up and down because I can
> write what I need fairly easily, but it would be a great boon to
> beginners or people who just want to do work and re-write this
> again, but slightly differently, and would also provide some
> standardization where otherwise we all roll our
> not-quite-similar-enough implementations, which would help us
> read each other's code. 
> 
> Y'all are bringing me around, slowly but surely :-)

Yes, it seems that the main benefit is to provide a Python-standard 
way of doing something that many individuals see as useful. Like 
many others, I've implemented my own variation (a class I call 
Data) to do essentially the same thing as the bunch/namespace 
proposal. If there had already been an existing standard way to do 
it, I would at most have needed to subclass the standard method. 

I would bet that subclassing is *still* going to be common, though, 
as each of us individually roll our own version to get that one 
vital feature the standard doesn't cover (for me, it's update with 
numerous other types), so the net effect may actually not be all 
that different from what happens now. Still, I could happily give 
up some features as long as the functionality is still available 
and presuming I intended the code for public consumption, and for 
that, Namespace would be most useful. 

Though I'd like it to have a shorter name. I'm lazy.

-- 
rzed




More information about the Python-list mailing list