Re: Django 1.5.2
Thanks Jacob! Greatly appreciated :) Le mardi 9 juillet 2013 19:04:26 UTC-4, Jacob Kaplan-Moss a écrit : > > Hey Michael - > > We don't have a schedule for 1.5.2 at the moment, but I'll take a look and > see if I can get a release out sometime soon. No promises, but I'll do my > best. > > Jacob > > > On Tue, Jul 9, 2013 at 11:00 AM, Michael Mior > > > wrote: > >> Just wondering if there's an ETA on Django 1.5.2. Currently there's one >> blocking issue in 1.5.1 that's preventing me from upgrading from 1.4 ( >> https://code.djangoproject.com/ticket/20257). If there's some >> outstanding things that need to be cleaned up, I'm happy to pitch in. >> Thanks! >> >> Cheers, >> -- >> Michael Mior >> michae...@gmail.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com . >> To post to this group, send email to >> django-d...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/django-developers. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: make Model __unicode__() default to self.name
On 11 juil. 2013, at 05:46, cmawebs...@gmail.com wrote: > What do your __unicode__/__str__ methods look like? Is this a bad idea? In addition to the previous answers, I find it important to have an unambiguous __unicode__ / __str__, and name isn't necessarily unique. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
It's less efficient because of the extra table but that's pretty much the only option when you need a FK on a model that you can't edit. GFK are not exactly efficient either, yet most will agree that it's sometime the best option to a given problem. I agree that the distinction between FK and O2M might be a little confusing to newcomers but I think it can be addressed with sufficient documentation. I would work on a patch if we have an accepted ticket. -- Loic On Jul 11, 2013, at 7:13 AM, Carl Meyer wrote: > On 07/10/2013 05:40 PM, Carl Meyer wrote: >>> I'm not sure I completely agree with Carl that is breaks correspondence >>> -- after all, m2m fields don't correlate to a field, either. However, in >>> the absence of a built-in migrations framework, I suspect a O2M field >>> would be a pretty efficient foot-gun for newcomers. >> >> I mentioned the m2m case in my email. The more basic invariant (that is >> currently respected by all built-in fields) is "when you put a field on >> a model, it creates or changes db tables in that model's app, not some >> other app." >> >> What's being requested here is essentially an ORM variant of >> monkeypatching third-party apps. While I accept that monkeypatching >> third-party code is sometimes pragmatically the best of bad options, I >> don't think it's a technique that we should be blessing with a built-in >> first-class field type. > > Er, never mind all this. I missed that the latest version of the > proposal is for an M2M-like table with a unique constraint on one side > of it, rather than adding a real FKey to the remote table. In that case, > this "monkeypatching" objection doesn't apply. > > It's still a slightly unnatural (and less efficient) way to model the > data, even if useful in some cases; not sure it meets the barrier for > inclusion in core, but we can see how it works out externally. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: make Model __unicode__() default to self.name
Luke beat me to it... We have a couple of abstract models which will fall through a small list of field names, trying to guess a useful default for __str__ ... but it makes me feel dirty every time I see it. Beyond "blessing" a particular (set of?) field names as default str names... this also adds more magic, and the trend I'm seeing now in the IRC channel is people are believing too much in magic. Just my 0.000152 bitcoins... -- Curtis On 11 July 2013 13:51, Luke Sneeringer wrote: > What makes “name” special. Why not “label”, “title”, “code”, or any number > of other things that people use internally? > > It also seems like you could solve this very easily by creating a stub > model: > > from django.db import models > > class MyModel(models.Model): > class Meta: > abstract = True > > def __unicode__(self): > return self.name > > This has the advantage of your not having to repeat yourself often (and it > gives you another place to put your own particular things which you > consistently practice), while not becoming opinionated about a naming > scheme across the entire framework. > > Best Regards, > Luke Sneeringer > > P. S. A place where I *would* love to see a better Django default would be > in the __repr__ method. > > On Jul 10, 2013, at 9:46 PM, cmawebs...@gmail.com wrote: > > Hi All, > > Have you ever quickly set up a model, ran syncdb, and added a few sample > objects in the admin to only see a bunch of "MyModel object"s in the > changelist? I always forget to add a __unicode__()/__str__() method on my > models. > > I ran "git grep -1 __unicode__" on some of my django projects and noticed > a lot of repeated code. In fact, it seems that in about a _third_ of all my > cases, I'm just returning self.name, or returning self.name would have > been a good default. I looked at a few 3rd party apps for comparison and > found similar results, though not for every app. > > IMHO, returning self.name (if the field or property exists) is a sensible > default for __unicode__. We can still return "MyModel object" if there's no > "name" attribute. You'll still end up adding your own __unicode__ method > much of the time, just like you always have. > > Yes, it's "magic", but we can document it. > Yes, it's a little more confusing, but we don't have to explain it during > the tutorial. > Yes, it's backwards incompatible, but only in rare cases should it be a > problem. > Yes, it could look like any Model without a "name" field is "wrong", but > it's not. > Yes, "title" is also very popular, but name is better. :) > > It has the effect of being a little more friendly in many cases, and can > result in more DRY code. > > What do your __unicode__/__str__ methods look like? Is this a bad idea? > > Thanks, > Collin > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: make Model __unicode__() default to self.name
What makes “name” special. Why not “label”, “title”, “code”, or any number of other things that people use internally? It also seems like you could solve this very easily by creating a stub model: from django.db import models class MyModel(models.Model): class Meta: abstract = True def __unicode__(self): return self.name This has the advantage of your not having to repeat yourself often (and it gives you another place to put your own particular things which you consistently practice), while not becoming opinionated about a naming scheme across the entire framework. Best Regards, Luke Sneeringer P. S. A place where I *would* love to see a better Django default would be in the __repr__ method. On Jul 10, 2013, at 9:46 PM, cmawebs...@gmail.com wrote: > Hi All, > > Have you ever quickly set up a model, ran syncdb, and added a few sample > objects in the admin to only see a bunch of "MyModel object"s in the > changelist? I always forget to add a __unicode__()/__str__() method on my > models. > > I ran "git grep -1 __unicode__" on some of my django projects and noticed a > lot of repeated code. In fact, it seems that in about a _third_ of all my > cases, I'm just returning self.name, or returning self.name would have been a > good default. I looked at a few 3rd party apps for comparison and found > similar results, though not for every app. > > IMHO, returning self.name (if the field or property exists) is a sensible > default for __unicode__. We can still return "MyModel object" if there's no > "name" attribute. You'll still end up adding your own __unicode__ method much > of the time, just like you always have. > > Yes, it's "magic", but we can document it. > Yes, it's a little more confusing, but we don't have to explain it during the > tutorial. > Yes, it's backwards incompatible, but only in rare cases should it be a > problem. > Yes, it could look like any Model without a "name" field is "wrong", but it's > not. > Yes, "title" is also very popular, but name is better. :) > > It has the effect of being a little more friendly in many cases, and can > result in more DRY code. > > What do your __unicode__/__str__ methods look like? Is this a bad idea? > > Thanks, > Collin > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Proposal: make Model __unicode__() default to self.name
Hi All, Have you ever quickly set up a model, ran syncdb, and added a few sample objects in the admin to only see a bunch of "MyModel object"s in the changelist? I always forget to add a __unicode__()/__str__() method on my models. I ran "git grep -1 __unicode__" on some of my django projects and noticed a lot of repeated code. In fact, it seems that in about a _third_ of all my cases, I'm just returning self.name, or returning self.name would have been a good default. I looked at a few 3rd party apps for comparison and found similar results, though not for every app. IMHO, returning self.name (if the field or property exists) is a sensible default for __unicode__. We can still return "MyModel object" if there's no "name" attribute. You'll still end up adding your own __unicode__ method much of the time, just like you always have. Yes, it's "magic", but we can document it. Yes, it's a little more confusing, but we don't have to explain it during the tutorial. Yes, it's backwards incompatible, but only in rare cases should it be a problem. Yes, it could look like any Model without a "name" field is "wrong", but it's not. Yes, "title" is also very popular, but name is better. :) It has the effect of being a little more friendly in many cases, and can result in more DRY code. What do your __unicode__/__str__ methods look like? Is this a bad idea? Thanks, Collin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
On 07/10/2013 05:40 PM, Carl Meyer wrote: >> I'm not sure I completely agree with Carl that is breaks correspondence >> -- after all, m2m fields don't correlate to a field, either. However, in >> the absence of a built-in migrations framework, I suspect a O2M field >> would be a pretty efficient foot-gun for newcomers. > > I mentioned the m2m case in my email. The more basic invariant (that is > currently respected by all built-in fields) is "when you put a field on > a model, it creates or changes db tables in that model's app, not some > other app." > > What's being requested here is essentially an ORM variant of > monkeypatching third-party apps. While I accept that monkeypatching > third-party code is sometimes pragmatically the best of bad options, I > don't think it's a technique that we should be blessing with a built-in > first-class field type. Er, never mind all this. I missed that the latest version of the proposal is for an M2M-like table with a unique constraint on one side of it, rather than adding a real FKey to the remote table. In that case, this "monkeypatching" objection doesn't apply. It's still a slightly unnatural (and less efficient) way to model the data, even if useful in some cases; not sure it meets the barrier for inclusion in core, but we can see how it works out externally. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
Hi Russ, On 07/10/2013 05:33 PM, Russell Keith-Magee wrote: > On Wed, Jul 10, 2013 at 4:20 PM, Curtis Maloney > mailto:cur...@acommoncreative.com>> wrote: > > I've seen enough people in #django suffering because they need a > FKey on a table they simply can't alter -- be it because it's in a > 3rd party app, or simply a table their DBA won't permit them to > alter, or what have you. > > In the end they wind up having to create the equivalent of a m2m > through table, but with one side being a 1to1. > > ISTM that the sugar to make this behave wouldn't be much greater > than that used for MTI, but I say that having not delved yet, so... > what would I know? :) > > > This is a use case I've seen many times in the past -- most commonly > with the User model, but with others as well. To that end, I have a > certain sympathy for the request. > > I'm not sure I completely agree with Carl that is breaks correspondence > -- after all, m2m fields don't correlate to a field, either. However, in > the absence of a built-in migrations framework, I suspect a O2M field > would be a pretty efficient foot-gun for newcomers. I mentioned the m2m case in my email. The more basic invariant (that is currently respected by all built-in fields) is "when you put a field on a model, it creates or changes db tables in that model's app, not some other app." What's being requested here is essentially an ORM variant of monkeypatching third-party apps. While I accept that monkeypatching third-party code is sometimes pragmatically the best of bad options, I don't think it's a technique that we should be blessing with a built-in first-class field type. Carl > That said - I agree that it should be possible to implement this > external to core. There's a certain amount of "here be dragons" in the > django.db.models.fields.related code, but it should be relatively > straightforward to implement the reverse of a ForeignKey. If someone is > interested in this, I'd rather see it proven as an external tool before > we add it to core. For sure. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
On Wed, Jul 10, 2013 at 4:20 PM, Curtis Maloney wrote: > I've seen enough people in #django suffering because they need a FKey on a > table they simply can't alter -- be it because it's in a 3rd party app, or > simply a table their DBA won't permit them to alter, or what have you. > > In the end they wind up having to create the equivalent of a m2m through > table, but with one side being a 1to1. > > ISTM that the sugar to make this behave wouldn't be much greater than that > used for MTI, but I say that having not delved yet, so... what would I > know? :) > This is a use case I've seen many times in the past -- most commonly with the User model, but with others as well. To that end, I have a certain sympathy for the request. I'm not sure I completely agree with Carl that is breaks correspondence -- after all, m2m fields don't correlate to a field, either. However, in the absence of a built-in migrations framework, I suspect a O2M field would be a pretty efficient foot-gun for newcomers. That said - I agree that it should be possible to implement this external to core. There's a certain amount of "here be dragons" in the django.db.models.fields.related code, but it should be relatively straightforward to implement the reverse of a ForeignKey. If someone is interested in this, I'd rather see it proven as an external tool before we add it to core. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
I've seen enough people in #django suffering because they need a FKey on a table they simply can't alter -- be it because it's in a 3rd party app, or simply a table their DBA won't permit them to alter, or what have you. In the end they wind up having to create the equivalent of a m2m through table, but with one side being a 1to1. ISTM that the sugar to make this behave wouldn't be much greater than that used for MTI, but I say that having not delved yet, so... what would I know? :) -- Curtis On Sunday, June 16, 2013 3:04:36 AM UTC+10, Carl Meyer wrote: > > Hi Amir, > > On Jun 15, 2013, at 9:11 AM, Amir Rachum > > wrote: > > I'm not sure if this feature was discussed before (I've seen some mentions > of it when searching this group, but nothing definitive). > I have written a blog post regarding the reasons (and the suggested > syntax) to use this relationship, and would love some feedback > > > http://blog.amir.rachum.com/post/53019452363/a-case-for-a-onetomany-relationship-in-django > > > The strongest reason not to do this is that it breaks the correspondence > between model fields and database columns. If you added a new OneToMany > field on Band pointing to Musician, suddenly the (unmodified) Musician > model's db table would require a schema migration, while the Band table > would remain unchanged. (Yes, ManyToManyField already sort of breaks this > correspondence, but only in that it causes a new table to be created in the > same app where you added the field. It never requires a schema migration > for an untouched model class, possibly in a different app, which is much > worse.) > > I think this downside alone is enough to kill the proposal for Django > core, especially considering the rationale in favor isn't that strong; it's > just a new way to spell the exact equivalent of a ForeignKey. > > That said, I'm pretty sure you could code this up outside of core, if > you'd like to experiment with it. > > Carl > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
I totally agree that we can't have a field on one model that modifies the underlying table of another model, especially with migrations in mind. That said, I see value in a OneToManyField backed by a M2M with a unique constraint on one side. This is particularly useful when you don't want to modify a third-party app. Of course it can be done manually, but then the API isn't that great. Generalizing (documenting) swappable models could be another answer to this issue and yet it would probably be overkill for this purpose. -- Loic On Jun 16, 2013, at 12:04 AM, Carl Meyer wrote: > The strongest reason not to do this is that it breaks the correspondence > between model fields and database columns. If you added a new OneToMany field > on Band pointing to Musician, suddenly the (unmodified) Musician model's db > table would require a schema migration, while the Band table would remain > unchanged. (Yes, ManyToManyField already sort of breaks this correspondence, > but only in that it causes a new table to be created in the same app where > you added the field. It never requires a schema migration for an untouched > model class, possibly in a different app, which is much worse.) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Oracle users -- which first, Python 3 or Oracle 12?
Hi Oracle users, As you may be aware, Oracle 12 was released last month, and Django 1.6 declares Python 3 fully supported. As you may also be aware, Django currently cannot be tested with Oracle 12 [1] or with earlier Oracle under Python 3 [2], so these two must be declared unsupported for the time being. I am working on both, but either will take some time for me to provide a reasonable solution. So my question to the Django/Oracle community is -- which would you prefer to work first? My instinct (and input from people around me) is that Oracle12 is more important, but any input is welcome. Also, of course, help wanted. For Python3 the problem appears to be in cx_Oracle -- so to help, you should probably be a C programmer. For Oracle12, for me, the main obstacle is a testing environment. While I'm working on that, any patches and/or help testing would be much appreciated. Thanks, Shai. [1] https://code.djangoproject.com/ticket/20707 [2] https://code.djangoproject.com/ticket/20725 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Regarding 3D model in Django
Sometime the answers can be a bit harsh and multiple people reply immediately, which probably gives the impression of being scolded. Maybe we could have a template with careful wording that we use every time. We could also forward the message to django-users like a moderator would do on a forum when a thread is opened in the wrong section. This could be done automatically by a view on djangoproject.com after people report this kind of messages, that way we also prevent replying multiple times to the same person. -- Loic On Jul 10, 2013, at 12:00 PM, Russell Keith-Magee wrote: > That said, I'll completely concede that it would be better to manage this > sort of problem a different way. A single mailing list with tags for > developer content, for example, would avoid the problem of having to give > people a hostile response when they hit the wrong mailing list. However, > Google Groups doesn't really give us many options here. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
