Nick Coghlan wrote:
class Namespace(object):
# etc
def _update_dict(self, other):
for k in other:
setattr(self, k, other[k])
This doesn't work, as it doesn't allow the sequence of 2-tuples. So I copied the
relevant check for a keys() attribute from d
Yeah, talking to myself again. I had a couple of further thoughts on how to do
things in an inheritance friendly way. . .
Firstly, for Namespaces handling of special names, I think it would be good to
make it easy for subclasses to change the sets of names that are handled using
either Namespac
rzed wrote:
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)
This is certainly what I expect to happen. It's the main reason
Nick Coghlan wrote:
Steven Bethard wrote:
>>> ns = Namespace(eggs=1)
>>> Namespace.update(ns, [('spam', 2)], ham=3)
>>> ns
Namespace(eggs=1, ham=3, spam=2)
Note that update should be used through the class, not through the
instances, to avoid the confusion that might arise if an 'up
Nick Coghlan wrote:
Py> class NS(namespaces.Namespace):
... x = prop
...
Oops - c&p error here. This was actually:
Py> class NS(namespaces.Namespace):
... x = prop
... __x__ = prop
...
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
Steven Bethard wrote:
Should namespace chaining be supported? One suggestion would add a
NamespaceChain object to the module::
This does have the advantage of keeping the basic namespace simple.
However, it may also be worth having native chaining support in
Namespace:
I think I prefer the sep
Nick Coghlan wrote:
There *is* a problem with using __getattr__ though - any attribute in
the chained namespaces that is shadowed by a class attribute (like
'update') will be picked up from the class, not from the chained
namespaces. So we do need to use __getattribute__ to change that lookup
o
Steven Bethard wrote:
> Hmmm... This does seem sensible. And sidesteps the issue about
> suggesting that subclasses use Namespace.update instead of
> namespaceinstance.update -- the latter just won't work! (This is a Good
> Thing, IMHO.)
Yeah, I thought so too. It also crystallised for me that t
Jeremy Bowers <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> 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
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 f
Michele Simionato wrote:
FWIW, you can count me about the people who (re)wrote this same thing
(actually with some difference, since I wanted to keep the order, so
I used nested lists instead of nested dictionaries, but the idea was
similar). I would welcome some module in the standard library to s
Steven Bethard wrote:
In the "empty classes as c structs?" thread, we've been talking in some
detail about my proposed "generic objects" PEP. Based on a number of
suggestions, I'm thinking more and more that instead of a single
collections type, I should be proposing a new "namespaces" module
Jeremy Bowers <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> On Thu, 10 Feb 2005 11:56:45 -0700, Steven Bethard wrote:
>
> > In the "empty classes as c structs?" thread, we've been talking in some
> > detail about my proposed "generic objects" PEP. Based on a number of
> > sug
BJörn Lindqvist wrote:
I like it alot! My only minor complaint is that the name is to long.
Also I *really wish* the Namespace could do this:
r, g, b = col = Namespace(r = 4, g = 3, b = 12)
But alas, I guess that's not doable within the scope of the Namespace PEP.
You can almost spell that already
I like it alot! My only minor complaint is that the name is to long.
Also I *really wish* the Namespace could do this:
r, g, b = col = Namespace(r = 4, g = 3, b = 12)
But alas, I guess that's not doable within the scope of the Namespace PEP.
--
mvh Björn
--
http://mail.python.org/mailman/list
On Thu, 10 Feb 2005 13:39:29 -0700, Steven Bethard wrote:
> Yeah, I guess that was really the motivation of this module. I
> personally wouldn't use it all that often -- certainly not with the
> frequency that I use, say, Python 2.4's set type -- but I think there
> are enough of us out here wh
Jeremy Bowers wrote:
On Thu, 10 Feb 2005 11:56:45 -0700, Steven Bethard wrote:
In the "empty classes as c structs?" thread, we've been talking in some
detail about my proposed "generic objects" PEP. Based on a number of
suggestions, I'm thinking more and more that instead of a single
collections t
On Thu, 10 Feb 2005 11:56:45 -0700, Steven Bethard wrote:
> In the "empty classes as c structs?" thread, we've been talking in some
> detail about my proposed "generic objects" PEP. Based on a number of
> suggestions, I'm thinking more and more that instead of a single
> collections type, I shoul
In the "empty classes as c structs?" thread, we've been talking in some
detail about my proposed "generic objects" PEP. Based on a number of
suggestions, I'm thinking more and more that instead of a single
collections type, I should be proposing a new "namespaces" module
instead. Some of my r
19 matches
Mail list logo
