Carlos Ribeiro <[EMAIL PROTECTED]> writes:
> On 06 Dec 2004 10:09:25 +0100, Jacek Generowicz
> <[EMAIL PROTECTED]> wrote:
> [great explanation about function descriptors]
>
> Thanks. Now I know more about function descriptors than I ever wanted
> to :-) With a little polish,
Yeah, replace the tw
On 06 Dec 2004 10:09:25 +0100, Jacek Generowicz
<[EMAIL PROTECTED]> wrote:
[great explanation about function descriptors]
Thanks. Now I know more about function descriptors than I ever wanted
to :-) With a little polish, this post would make a great addition to
the descriptors documentation, don't
Jp Calderone <[EMAIL PROTECTED]> writes:
> When the class object is created, the namespace is scanned for
> instances of . For those and only those, a
> descriptor is created which will produce bound and unbound methods.
This isn't quite correct. A descriptior is any object which has
callable at
Steven Bethard wrote:
Ian Bicking wrote:
class bunch(object):
def __init__(self, **kw):
for name, value in kw.items():
# IMPORTANT! This is subclass friendly: updating __dict__
# is not!
setattr(self, name, value)
Good point about being subclass fri
Istvan Albert wrote:
but what are you saying? that a man cannot exaggerate and
fudge the facts in order to embellish his argument? :-)
Heh heh. Yeah, something like that. ;)
Steve
--
http://mail.python.org/mailman/listinfo/python-list
Steven Bethard wrote:
module) not to the __builtins__. I don't see how this "litters the
standard namespace".
Maybe then it doesn't.
but what are you saying? that a man cannot exaggerate and
fudge the facts in order to embellish his argument? :-)
Istvan.
--
http://mail.python.org/mailman/listinfo
Ian Bicking wrote:
class bunch(object):
def __init__(self, **kw):
for name, value in kw.items():
# IMPORTANT! This is subclass friendly: updating __dict__
# is not!
setattr(self, name, value)
Good point about being subclass friendly... I wonder if t
Istvan Albert wrote:
On the other hand, it would be nice to have a module that
implements various design patterns. The Bunch, the Borg, the Null,
the Proxy all nicely documented tucked away in their separate
module. That would feel a lot less like littering the standard name space
with an class tha
Istvan Albert wrote:
Steven Bethard wrote:
> The question is not how easy it is to write,
> but how many times it's going to get written.
but with that logic we could create a standard
"looping" construct called loop(x) that would stand in for
for i in range(x):
IMHO, that example is quite the o
On Fri, 03 Dec 2004 08:58:48 -0500, Istvan Albert
<[EMAIL PROTECTED]> wrote:
> On the other hand, it would be nice to have a module that
> implements various design patterns. The Bunch, the Borg, the Null,
> the Proxy all nicely documented tucked away in their separate
> module. That would feel a l
Istvan Albert wrote:
> On the other hand, it would be nice to have a module that
> implements various design patterns. The Bunch, the Borg, the Null,
> the Proxy all nicely documented tucked away in their separate
> module. That would feel a lot less like littering the standard name space
> with an
Steven Bethard wrote:
> The question is not how easy it is to write,
> but how many times it's going to get written.
but with that logic we could create a standard
"looping" construct called loop(x) that would stand in for
for i in range(x):
or a file_reader('whatever') generator that would be
a s
On Fri, 03 Dec 2004 07:41:59 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
> Next question: bunch is a cute name, but not very suggestive of purpose.
> Who can think of a better one?
"Better"is highly subjective in this context. There are several alternatives:
Bunch
Generic
Record
DataRecord
I
Paul Rubin wrote:
Steven Bethard <[EMAIL PROTECTED]> writes:
IMHO this too easy to accomplish right now to warrant
an "official" implementation:
class Bunch:
pass
b = Bunch()
b.one, b.two, b.three = 1,2,3
works just fine, depending on the problem I might add a few special
operators. For anything
Peter Otten wrote:
> Functions written in Python have a __get__ attribute while builtin
> functions (implemented in C) don't. Python-coded functions therefore
> automatically act as descriptors while builtins are just another
> attribute.
Jp Calderone <[EMAIL PROTECTED]> wrote:
> When the class ob
Steven Bethard <[EMAIL PROTECTED]> writes:
> > IMHO this too easy to accomplish right now to warrant
> > an "official" implementation:
> > class Bunch:
> > pass
> > b = Bunch()
> > b.one, b.two, b.three = 1,2,3
> > works just fine, depending on the problem I might add a few special
> > operator
Istvan Albert wrote:
Steven Bethard wrote:
I promised I'd put together a PEP for a 'generic object' data type for
Python 2.5 that allows one to replace __getitem__ style access with
dotted-attribute style access (without declaring another class). Any
comments would be appreciated!
IMHO this to
Steven Bethard wrote:
I promised I'd put together a PEP for a 'generic object' data type for
Python 2.5 that allows one to replace __getitem__ style access with
dotted-attribute style access (without declaring another class). Any
comments would be appreciated!
IMHO this too easy to accomplish r
On Thu, 02 Dec 2004 12:26:31 -0800, Scott David Daniels <[EMAIL PROTECTED]>
wrote:
>Nick Craig-Wood wrote:
> > Scott David Daniels <[EMAIL PROTECTED]> wrote:
> >> You can simplify this:
> >> class Hash(object):
> >> def __init__(self, **kwargs):
> >> for key,value in kwargs.items():
Nick Craig-Wood wrote:
Scott David Daniels <[EMAIL PROTECTED]> wrote:
You can simplify this:
class Hash(object):
def __init__(self, **kwargs):
for key,value in kwargs.items():
setattr(self, key, value)
__getitem__ = getattr
__setitem__ = setattr
That doesn't wor
Nick Craig-Wood wrote:
> Scott David Daniels <[EMAIL PROTECTED]> wrote:
>> Nick Craig-Wood wrote:
>> > class Hash:
>> > def __init__(self, **kwargs):
>> > for key,value in kwargs.items():
>> > setattr(self, key, value)
>> > def __getitem__(self, x):
>> > return
Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Nick Craig-Wood wrote:
> > class Hash:
> > def __init__(self, **kwargs):
> > for key,value in kwargs.items():
> > setattr(self, key, value)
> > def __getitem__(self, x):
> > return getattr(self, x)
> > def __s
Steven Bethard <[EMAIL PROTECTED]> wrote:
> Nick Craig-Wood wrote:
> > Steven Bethard <[EMAIL PROTECTED]> wrote:
> >
> >> I promised I'd put together a PEP for a 'generic object' data type for
> >> Python 2.5 that allows one to replace __getitem__ style access with
> >> dotted-attribute style a
Peter Otten wrote:
Steven Bethard wrote:
def __eq__(self, other):
"""x.__eq__(y) <==> x == y"""
return (isinstance(other, self.__class__)
and self.__dict__ == other.__dict__)
This results in an asymmetry:
from bunch import Bunch
class B(Bunch): pass
...
B().__eq__(Bunch())
False
B
Steven Bethard wrote:
> Peter Otten wrote:
>> Steven Bethard wrote:
>>
>>>def __eq__(self, other):
>>>"""x.__eq__(y) <==> x == y"""
>>>return (isinstance(other, self.__class__)
>>>and self.__dict__ == other.__dict__)
>>
>> This results in an asymmetry:
>>
> [snip]
>>
>> Whe
Jp Calderone wrote:
One thing I notice with both of these versions:
>>> Hash(self=10)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: __init__() got multiple values for keyword argument 'self'
Good call. I've adjusted my methods to look like:
def __init_
On Tue, 30 Nov 2004 17:52:33 -0500, =?iso-8859-1?Q?Fran=E7ois?= Pinard <[EMAIL
PROTECTED]> wrote:
>[Scott David Daniels]
>
> > You can simplify this:
> > class Hash(object):
> > def __init__(self, **kwargs):
> > for key,value in kwargs.items():
> > setattr(self, key, value
[Scott David Daniels]
> You can simplify this:
> class Hash(object):
> def __init__(self, **kwargs):
> for key,value in kwargs.items():
> setattr(self, key, value)
Might it be:
def __init__(self, **kwargs):
self.__dict__.update(kwargs)
--
François Pinard h
Scott David Daniels wrote:
Nick Craig-Wood wrote:
class Hash:
def __init__(self, **kwargs):
for key,value in kwargs.items():
setattr(self, key, value)
def __getitem__(self, x):
return getattr(self, x)
def __setitem__(self, x, y):
setattr(self, x, y)
Nick Craig-Wood wrote:
class Hash:
def __init__(self, **kwargs):
for key,value in kwargs.items():
setattr(self, key, value)
def __getitem__(self, x):
return getattr(self, x)
def __setitem__(self, x, y):
setattr(self, x, y)
You can simplify this:
class
Nick Coghlan wrote:
The proposed use cases sound more appropriate for a "named tuple" than
any sort of dictionary. (This may have been mentioned in previous
discussions. I wasn't keeping track of those, though)
For the return values, yeah, a "named tuple" is probably at least as
appropriate. I'
Nick Craig-Wood wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
I promised I'd put together a PEP for a 'generic object' data type for
Python 2.5 that allows one to replace __getitem__ style access with
dotted-attribute style access (without declaring another class). Any
comments would be appr
Peter Otten wrote:
Steven Bethard wrote:
def __eq__(self, other):
"""x.__eq__(y) <==> x == y"""
return (isinstance(other, self.__class__)
and self.__dict__ == other.__dict__)
This results in an asymmetry:
[snip]
Whether this is intended, I don't know. If someone can enlighten me...
Fredrik Lundh wrote:
Steven Bethard wrote:
Currently, if a Python programmer makes this design decision, they are
forced to declare a new class, and then build instances of this class.
FORCED to create a new class, and FORCED to create instances of
their own class instead of your class?
I don't see
On Tue, 30 Nov 2004 22:30:21 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The proposed use cases sound more appropriate for a "named tuple" than any
> sort
> of dictionary. (This may have been mentioned in previous discussions. I wasn't
> keeping track of those, though)
I agree with it. I was
The proposed use cases sound more appropriate for a "named tuple" than any sort
of dictionary. (This may have been mentioned in previous discussions. I wasn't
keeping track of those, though)
Notice that I've used 'fromPairs' rather than 'fromMapping', since consistent
order matters for a tuple.
Steven Bethard <[EMAIL PROTECTED]> wrote:
> I promised I'd put together a PEP for a 'generic object' data type for
> Python 2.5 that allows one to replace __getitem__ style access with
> dotted-attribute style access (without declaring another class). Any
> comments would be appreciated!
T
Steven Bethard wrote:
> def __eq__(self, other):
> """x.__eq__(y) <==> x == y"""
> return (isinstance(other, self.__class__)
> and self.__dict__ == other.__dict__)
This results in an asymmetry:
>>> from bunch import Bunch
>>> class B(Bunch): pass
...
>>> B().__eq__(Bunch())
F
Steven Bethard wrote:
> Currently, if a Python programmer makes this design decision, they are
> forced to declare a new class, and then build instances of this class.
FORCED to create a new class, and FORCED to create instances of
their own class instead of your class? without this, Python must
I promised I'd put together a PEP for a 'generic object' data type for
Python 2.5 that allows one to replace __getitem__ style access with
dotted-attribute style access (without declaring another class). Any
comments would be appreciated!
Thanks!
Steve
-
40 matches
Mail list logo
