On Mon, Feb 21, 2005 at 03:53:20PM +0300, Oleg Broytmann wrote:
> I am not sure about these methods. Do we really want them?
My case - and not that I would argue a lot for it - is that both are
convenient shorthands for stuff that is often rewritten. Also, it
makes the resulting code simpler, and that's a good reason IMHO.
On Tue, 22 Feb 2005 00:07:30 +1100, Andrew Bennetts
> I don't see much value in replace. It's not hard to do:
> user = User.byName('admin')
> user.set(password='admin', ...)
It's not hard, I agree. 'replace' is just a shorthand. 'setdefault'
has more work to do (in fact, the current version needs improvement as
> setdefault is nearly as easy to do by hand. The builtin dict type has it,
> but that's at least partly because there are times when it's much faster. I
> doubt that's the case here.
There are two reasons behind setdefault: cleanliness, and the
possibility to add better tests for existence of the object. This is a
sample of the code that drove me to write it.
uadmin = User.byName('admin')
uadmin = User(name='admin', ...)
This code is long & ugly IMHO. If you have to repeat this snippet it a
few times, it's going to be much more confusing. With setdefault, it
works like this:
uadmin = User.setdefault(testKey='name', 'admin', ...)
radmin = Role.setdefault(testKey='name', 'admin', ...)
It's much cleaner and more readable.
As for the improvements for setdefault: my intention is to remove the
testKey argument, by doing an automatic search for the object using
any candidate keys provided in the argument list. The goal is to make
the system safer for use with objects that have more than one
alternate key (a strange case anyway, but that happens in some
situations - for example, the supplierCode and the itemCode for an
item may be each unique, but still different), or that have composite
keys -- a feature that SQLObject still doesn't have, but that may
available in a future release.
p.s. My motivation, for those curious...
I am writing code that is supposed to be used by simple users, that
have little idea on how to manage a database system. The system is
extensively configurable using information stored in the database
itself. This allows central configuration, which is useful for a
system that uses a Web-based interface. The system knows how to setup
itself -- the only thing that it still needs is the functionality to
create the actual database and set permissions, but apart from this,
it's pretty much self-installed & self-repaired.
Consultoria em Projetos