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:17 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> I ran into a situation today where for every future site I set up,
> I'll want to load an initial_data fixture, but for some existing sites
> that I'm upgrading, it's very useful to be able to run syncdb without
> loading an
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 ran into a situation today where for every future site I set up,
I'll want to load an initial_data fixture, but for some existing sites
that I'm upgrading, it's very useful to be able to run syncdb without
loading any fixtures. Thus http://code.djangoproject.com/ticket/6511
I'll write up the do
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.
Jeremy Dunck said the following:
> On Dec 28, 2007 11:35 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>> I'm happy to take care of this -- I just don't know what's involved in
>> registering a channel. Could you provide some more information on whom
>> to talk to about getting it done?
>
> http
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
On 1/28/08, Bryan McLemore <[EMAIL PROTECTED]> wrote:
> I'm more looking for discussion. Feedback on what I've said and on
> the implementation if people are so inclined. I'm not done yet by
> far, so making an official patch submission would be premature.
The problem is that reading patches in
There are a lot of good reasons to have username ascii-only
1. You may want to login to your site from non-national keyboard/OS
2. URLs with unicode characters look ugly
3. Paths and filenames may be broken
4. It's not hard to transliterate your real name with ascii-only
letters
--~--~-~--
No! Unicode usernames is a bad idea. Usernames can be used for URLs,
paths and other technical stuff. Unicode usernames is a source of
unlimited potential bugs. It might be a good idea to add the unicode
'nickname' field that can be used instead of username in views - and
still use 'username' for
26 matches
Mail list logo
