On Tue, Jan 29, 2008 at 03:43:22PM -0600, Jacob Kaplan-Moss wrote:
> On 1/29/08, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> > Yes, but why not have fromtuple classmethod optimized for this use-
> > case? And I believe this way of initialization could be really faster
> > than keyword initializati
I somehow can't see the custom_query solving our issues with needing
custom queries. How is it going to handle JOINs?
On Feb 2, 4:06 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Jan 29, 2008 2:13 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> > I'd like to deprecate initializing mo
On Jan 29, 2008 2:13 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'd like to deprecate initializing models using positional arguments
> (i.e. ``p = Person(1, 'Joe Somebody')``) in favor of only allowing
> keyword-argument initialization (i.e. ``p = Person(id=1, name='Joe
> Somebody')``).
I
On Tue, 2008-01-29 at 14:13 -0600, Jacob Kaplan-Moss wrote:
> Howdy folks --
>
> The short version:
>
> I'd like to deprecate initializing models using positional arguments
> (i.e. ``p = Person(1, 'Joe Somebody')``) in favor of only allowing
> keyword-argument initialization (i.e. ``p = Person(
On Tue, 2008-01-29 at 12:50 -0800, Ivan Illarionov wrote:
> > One of the other things planned as part of qs-rf is the ability to use
> > custom queries to initialize models -- something like
> > ``Model.objects.custom_query("SELECT ...")``
> That's not enough - I need this feature to initialize m
> I'd like to deprecate initializing models using positional arguments
> (i.e. ``p = Person(1, 'Joe Somebody')``) in favor of only allowing
> keyword-argument initialization (i.e. ``p = Person(id=1, name='Joe
> Somebody')``).
+1 from me. I've been doing some interesting model stuff lately and
th
I'm +1 for deprecating positional arguments from __init__().
> Relying on the order of fields in the model definition is asking for a
> heaping load of fail. Hence my desire to see it go away.
While I agree this argument applies for having positional args in
__init__(), those instantiating using
On 1/30/08, Nicola Larosa <[EMAIL PROTECTED]> wrote:
> No, wait, make that +1 to erasing the ruttin' posargs "feature" from the
> gorram *language*. Dong ma?
Whoa, now, don't go quoting Firefly on me or we'll be here all day :)
Jacob
--~--~-~--~~~---~--~~
You rec
On 1/30/08, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> I'm not arguing against removing positional argument support from model
> constructors, just wondering about the 1.0 focus.
Yeah, you're totally right that the feature is a perfect post-1.0
candidate. I'm just using it as a vehicle for getti
I would have thought Adrian's deferred fields proposal would fall
squarely in the post-1.0 bucket. It clearly has no backward
compatibility issues, so it can be added after 1.0. Maybe you aren't
proposing to include it in 1.0; it wasn't clear from your message.
I'm not arguing against removi
Jacob Kaplan-Moss wrote:
> I'd like to deprecate initializing models using positional arguments
> (i.e. ``p = Person(1, 'Joe Somebody')``) in favor of only allowing
> keyword-argument initialization (i.e. ``p = Person(id=1, name='Joe
> Somebody')``).
Huh?
+1 to that.
No, wait, make that +1 to e
The use of *args also seems like it will be a barrier/just messy if/
when schema evolution ever gets(or with 3rd party apps), I'm +1 on
this.
On Jan 29, 8:01 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Jan 30, 2008 8:57 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
>
>
> >
On Jan 30, 2008 8:57 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> There should be one-- and preferably only one --obvious way to do it.
> ...
>
> On top of that, as I keep saying, it leads to brittle code -- I've
> been bitten a number of times.
...
> Relying on the order of fields
http://pastebin.com/m62466a6b
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send ema
Then it makes sense to check for number of arguments (len(args) ==
len(obj._meta.fields)) and raise an error if it's not equal to number
of fields. The *args instantiation is useful and fast. QSRF
improvements may make it less useful nut **kwargs instantiation just
always be slower due to the natu
On 1/29/08, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> Jacob, why are you opposed to alternative instantiation methods?
>>> import this
...
There should be one-- and preferably only one --obvious way to do it.
...
On top of that, as I keep saying, it leads to brittle code -- I'
> I'm pretty strongly opposed to a fromtuple (or whatever) method: it's
> brittle and to tightly couples code to the arbitrary order of defined
> fields.
Jacob, why are you opposed to alternative instantiation methods?
Standard Python does it with dict.fromkeys() Why not?
--~--~-~--~~-
Speed:
>>> t1.timeit() # Model.__init__ from django trunk with args stuff stripped
179.84739959966981
>>> t2.timeit()
139.67626695571641 # Model.fromargs()
Implementation:
def fromtuple(cls, values):
dispatcher.send(signal=signals.pre_init, sender=cls,
args=values, kwargs={})
new_
I'm with Ivan. If QSRF supports everything we do + everything we want,
there's no need for args (as theres no need for custom queries), but
until it does, *args is very valuable, or at least a method which can
do the same.
On Jan 29, 1:43 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 1/
On 1/29/08, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> Yes, but why not have fromtuple classmethod optimized for this use-
> case? And I believe this way of initialization could be really faster
> than keyword initialization.
I'm pretty strongly opposed to a fromtuple (or whatever) method: it's
I agree that positional arguments instantiation is confusing and
mixing it with keyword instantiation is even more confusing - it would
be great if default Model.__init__ will be keyword argument only. But
I think we still need a faster alternative. Comment in Model.__init__
states that 'nstantiat
On 1/29/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'd make the ``*args`` style start issuing DeprecationWarnings
> immediately, and remove support entirely when we wipe deprecated
> features in the run-up to 1.0. I'd make this change on the
> queryset-refactor branch.
I'm inclined to lik
> kwargs = dict([(cls._meta.fields[i].attname, v) for (i, v) in
> enumerate(args)])
>
> Seems like any code which explicitly needs to handle tuple
> instantiation (likely the minority) can supply a helper method using
> something similar to the above.
Yes, but why not have fromtuple classmethod
In the worst case, generating a kwargs dictionary from an args tuple
isn't really all that difficult.
kwargs = dict([(cls._meta.fields[i].attname, v) for (i, v) in enumerate(args)])
Seems like any code which explicitly needs to handle tuple
instantiation (likely the minority) can supply a helper
Ok I really can use Model.objects.custom_query("EXECUTE
PROCEDURE ...") but someone may need more options.
On 29 янв, 23:50, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> > One of the other things planned as part of qs-rf is the ability to use
> > custom queries to initialize models -- something l
> One of the other things planned as part of qs-rf is the ability to use
> custom queries to initialize models -- something like
> ``Model.objects.custom_query("SELECT ...")``
That's not enough - I need this feature to initialize models from the
result of stored procedures, not just simple queries
On 1/29/08, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> If you depricate this functionality please provide an alternative like
> Model.fromargs() classmethod. It is extremely useful when you need to
> create Model objects from custom queries.
Good point.
One of the other things planned as part
On Jan 29, 2008 3:13 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Thoughts?
I haven't run into any problems with this as of yet, but I'd like to
wholeheartedly support this move. I was sincerely amazed when I
noticed that models could be instantiated either way, and I couldn't
think of a re
If you depricate this functionality please provide an alternative like
Model.fromargs() classmethod. It is extremely useful when you need to
create Model objects from custom queries. Like here:
http://code.djangoproject.com/browser/django/trunk/tests/modeltests/custom_methods/models.py
in Article.
Howdy folks --
The short version:
I'd like to deprecate initializing models using positional arguments
(i.e. ``p = Person(1, 'Joe Somebody')``) in favor of only allowing
keyword-argument initialization (i.e. ``p = Person(id=1, name='Joe
Somebody')``).
I'd make the ``*args`` style start issuing
30 matches
Mail list logo
