sorry, fixed patch
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
another thing noted, the collections instrumentation fails over old
python classes (not inheriting object), e.g.
class myX: ...whatever...
it fails at _instrument_class(), because type(myX()) being
type 'instance' is recognized as builtin, and apart of that the
util.duck_type_collection()
a suggestion about _list_decorators() and similar.
they can be easily made into classes, i.e. non dynamic (and
overloadable/patchable :-).
class _list_decorators( object): #instead of def _list_decorators()
all contents/decorators stays same...
_funcs = _get_decorators(
a patch, it got even tidier ;-) -
no more _tidy() calls, all automated.
On Monday 20 August 2007 16:41:30 svilen wrote:
a suggestion about _list_decorators() and similar.
they can be easily made into classes, i.e. non dynamic (and
overloadable/patchable :-).
class _list_decorators( object):
and no need for that __new__ replacement either - just use
_list_decorators._funcs instead of _list_decorators()
On Monday 20 August 2007 17:05:32 svilen wrote:
a patch, it got even tidier ;-) -
no more _tidy() calls, all automated.
On Monday 20 August 2007 16:41:30 svilen wrote:
a
On Monday 20 August 2007 17:29:52 jason kirtland wrote:
[EMAIL PROTECTED] wrote:
hi
i need to have a list collection with list.appender (in SA 0.4
terms) that accepts either one positional arg as the value, or
keyword args which it uses to create the value. Each collection
instance
svilen wrote:
a suggestion about _list_decorators() and similar.
they can be easily made into classes, i.e. non dynamic (and
overloadable/patchable :-).
The stdlib decorators end up in a static, module-level dictionary that
can be manipulated if you want to. Wouldn't this be replacing a
On Monday 20 August 2007 18:01:49 jason kirtland wrote:
svilen wrote:
a suggestion about _list_decorators() and similar.
they can be easily made into classes, i.e. non dynamic (and
overloadable/patchable :-).
The stdlib decorators end up in a static, module-level dictionary
that can be
svilen wrote:
And anyway i need to first create the object and just then append it
(the decorators will first fire event on the object and just then
append(), that is call me), so may have to look further/deeper.
Maybe i can make my append create objects first and then call the
actual
On Monday 20 August 2007 18:09:41 jason kirtland wrote:
svilen wrote:
And anyway i need to first create the object and just then append
it (the decorators will first fire event on the object and just
then append(), that is call me), so may have to look
further/deeper. Maybe i can make my
On Monday 20 August 2007 20:58:45 [EMAIL PROTECTED] wrote:
On Monday 20 August 2007 18:09:41 jason kirtland wrote:
svilen wrote:
And anyway i need to first create the object and just then
append it (the decorators will first fire event on the object
and just then append(), that is
[EMAIL PROTECTED] wrote:
On Monday 20 August 2007 18:09:41 jason kirtland wrote:
svilen wrote:
And anyway i need to first create the object and just then
append it (the decorators will first fire event on the object
and just then append(), that is call me), so may have to look
But tacking a factory method onto a regular Python list is much
simpler with a separation of concerns:
class FactoryCollection(list):
def create(self, options, **kw):
eh sorry, i want it the hard way..
now as i think of it, its just me being lazy and fancy - preferring
implicitness and
13 matches
Mail list logo
