On 11/3/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On 11/3/06, Robin Munn <[EMAIL PROTECTED]> wrote:
> >
> > http://code.djangoproject.com/ticket/107 just got comment spammed.
> > And, ironically, akismet is rejecting my attempts to clean it up. :-)
> &
Comment:
(nothing but links. Removed so I won't help give them the
search-engine boost they're looking for).
Someone whom akismet likes better than me :-) should clean this up, as
I seem to be unable to.
--
Robin Munn
[EMAIL PROTECTED]
GPG key 0xD6497014
--~--~-~--~~-
per
> of an AM object. We really should have a real doc for ActiveMapper.
I may come up with some halfway decent ActiveMapper tests in the
process of figuring out the Django-SQLAlchemy mapper; if I do, I'll
make sure to send patches to SQLAlchemy. Ditto documentation.
--
Robin Munn
[EMAIL
On 8/30/06, David Elias <[EMAIL PROTECTED]> wrote:
>
>
> Robin Munn wrote:
> > The notes on implementation that Adrian posted pretty much match what
> > I'm thinking at this point. The plan is to make this 100% API
> > compatible (if possible -- you never kno
at your code, though. I like "borrowing" from other
people's work whenever I can, it means less work for me. :-) And
that's what open-source development is all about, isn't it?
--
Robin Munn
[EMAIL PROTECTED]
GPG key 0xD6497014
--~--~-~--~~~
On 8/29/06, gabor <[EMAIL PROTECTED]> wrote:
>
> Robin Munn wrote:
> >
> > The notes on implementation that Adrian posted pretty much match what
> > I'm thinking at this point. The plan is to make this 100% API
> > compatible (if possible -- you never
and SQLAlchemy" thread. If you have any
suggestions as to how you'd like the API to look, I would welcome your
comments. See that thread for more details.
--
Robin Munn
[EMAIL PROTECTED]
GPG key 0xD6497014
--~--~-~--~~~---~--~~
You received this
underlying
> database library.
>
> Robin Munn, author of an excellent SQLAlchemy tutorial
> (http://www.rmunn.com/sqlalchemy-tutorial/tutorial.html) and heavy
> contributor to Django several months ago, has agreed to be the lead
> developer on this branch. I'm sure he'
st of your objections are based either on an incorrect
understanding of the change that's being proposed, or else on
something that's going to go away. Points 1 and 2 go away (or almost
go away) with the "class Meta:" proposal, although there's a very
valid objection that that's a little bit magic and isn't the default
Pythonic behavior. But it sure does result in clean, simple,
easy-to-read code. Not concise like Perl, but concise like Python.
Point 3 is valid, and is worth pondering. And point 4 is outdated as
of a few minutes ago.
--
Robin Munn
[EMAIL PROTECTED]
GPG key 0xD6497014
.
If/when you do write a wrapper, please post it to the ticket as well.
If we can't persuade Adrian and Jacob to see sense *wink*, it'll be
handy to have an alternative.
--
Robin Munn
[EMAIL PROTECTED]
GPG key 0xD6497014
that's awesome!" syntax.
I think SQLObject got a lot of things right, except for using the name
MultipleJoin for what should have been called ForeignKey. The "Oh wow,
you can just declare your fields using class-attribute creation"
coolness was certainly one of the most attractive th
ssorted get_foo_list() functions for ForeignKeys and
ManyToManyFields? Why not add a little bit more "magic", when the
result is something that feels so much more Pythonic to the end user?
I guess what I'm asking for is a little bit more of a rationale for
rejecting the patc
12 matches
Mail list logo
