Re: Add support for relative imports in django.conf.urls.include()?

[lamby]

>
> This just made me realize that the whole problem can already be fixed from 
> the user's perspective by importing the module instead of using string 
> based imports
>


Not entirely convinced. Firstly it's extra stuff you have to explicitly 
import which seems a style regression from the "oh just use these included 
urls" that you get with the string-based import.

Secondly, whilst it might look fine when you are doing it once, for example:

from django.conf.urls import url, include

from . import views
from .foo import urls

urlpatterns = (
url(r'', include(urls, namespace='foo')),

url(r'^$', views.landing, name='landing'),
)

.. but the import dance get a bit nasty when you have multiple ones - you 
have to alias each import:

from django.conf.urls import url, include

from . import views
from .foo_app import urls as foo_urls
from .bar_app import urls as bar_urls
# etc.

urlpatterns = (
url(r'', include(foo_urls, namespace='foo')),
url(r'', include(bar_urls, namespace='bar')),

url(r'^$', views.landing, name='landing'),
)

This isn't an readabiliy improvement over using the string urls IMHO.

Now, if only we could do the following:

from . import views, foo_app, bar_app

urlpatterns = (
url(r'', include(foo_app.urls), namespace='foo')),
url(r'', include(bar_app.urls), namespace='bar')),

url(r'^$', views.landing, name='landing'),
)


/lamby

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/042dfb7b-1824-4848-844e-1c70b2060f24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Copy-from-base inheritance

[Joakim Saario]

I'm aware that the name of the Meta-option isn't the best (it was just a 
working name for me)
or that it should be implemented like a Meta-option at all.

While this may be counter-intuitive from the ORM-perspective, it isn't 
counter-intuitive at all 
from the regular python-programmer's perspective, but rather the other way 
around. This is
why I think it would be great to at least have some kind of way to to 
regular class-inheritance,
in addition to relational inheritance.

The problem is that django hijacks the class-inheritance feature of python 
and uses it soley
for relational inheritance.

I'm not a fan of doing hacks either, of course you can do monkey-patching to
achive this without changes in django core, it's python after all.

Den onsdag 2 mars 2016 kl. 11:59:33 UTC+1 skrev Aymeric Augustin:
>
> Now I understand — you want to inherit from a concrete model but to use a 
> separate table.
>
> I’m not sure how widely applicable this would be. I find it 
> counter-intuitive that Parent.objects.all() isn’t a superset of 
> Child.objects.all() anymore. This is a surprising way to implement 
> inheritance.
>
> The usual ways to implement inheritance in an ORM are single-table 
> inheritance (STI) and multi-table inheritance (MTI). Django supports MTI. 
> It also supports inheriting Python classes without affecting the database, 
> with abstract or proxy models, depending on whether the database table(s) 
> are tied to the children or the parent.
>
>
>
> In your use case, the only reason why you can’t make the parent model 
> abstract is that it’s provided by a third-party app. Perhaps the general 
> problem is to customize models provided by third-party apps? At this time, 
> Django doesn’t provide a mechanism for doing that. The two solutions I know 
> of are:
>
> 1) Swappable models: this is only officially supported for the auth.User 
> model via the AUTH_USER_MODEL setting but it’s technically possible to 
> achieve a similar effect with other models.
> 2) App-registry hacks: for example, that’s what django-oscar does; I’m not 
> sure they would have ended up with the solution if they had started after 
> Django 1.7, though.
>
> So, in the current state of things, the path of least resistance is to 
> encourage authors of reusable apps to provide an abstract version of 
> inheritable models in addition to the concrete version, like Django does 
> with AbstractUser and User, and perhaps discuss making swappable models a 
> supported API.
>
>
> If we leave aside the current implementation of abstract models for a 
> moment, for your use case, I can see the logic in having the child model 
> declare what kind of inheritance it uses rather than the parent. In the 
> end, it’s the child’s database table that has either a FK to the parent of 
> a copy of all the parent’s columns (with your patch). `copy_from_base` is 
> a poor name for declaring the whether you’re using MTI or not, though.
>
> If we ever implement single table inheritance (STI), either having the 
> parent declaring that it collects database columns from all its children or 
> the children declare that they add database columns to their parent will 
> be awkward. When inheriting across applications, that will interact very 
> poorly with the migrations framework. So it’s unclear that one solution is 
> better than the other here.
>
> That said, we need to keep `abstract = True` on the parent to prevent the 
> creation of a related database table, which could be accidentally used even 
> if the model was intended to be abstract.
>
> So I don’t think we can draw a general conclusion on whether inheritance 
> behavior should be declared on parents or children.
>
>
> To sum up, Django currently provides limited but safe options for model 
> inheritance:
>
> - MTI — it's the default when inheriting from a regular model; the main 
> usability drawback is that there’s no good way to specialize a queryset of 
> parents into children
> - abstract models (declared on the parent) — the parent cannot interact 
> with the database, each child has its own table, which avoids interactions 
> between the ORM and inheritance
> - proxy models (declared on the child) — the child only specializes Python 
> behavior, only the parent has a table, which also avoids interactions 
> between the ORM and inheritance
>
> There has been some talk about introducing STI but I don’t remember seeing 
> a concrete proposal. (Also STI looks suspiciously similar to GFK which 
> aren’t very popular among the core team.)
>
> Looking at where your proposal would fit in this landscape, it’s unclear 
> to me that the benefits outweigh the bizarre result of making both 
> Parent.objects.all() and Child.objects.all() work, but not have the latter 
> be a subset of the former.
>
> I would be more comfortable with providing guidelines for reusable apps 
> whose models may be inherited.
>
>
> I suppose I just spent two pages rebuilding the reasoning behind the 
> design of abstr

Re: Copy-from-base inheritance

[Aymeric Augustin]

Hi Joakim,

On 03 Mar 2016, at 11:03, Joakim Saario  wrote:

> The problem is that django hijacks the class-inheritance feature of python 
> and uses it soley
> for relational inheritance.


I understand that you would like each model class to have its own table with 
all its fields,
whether they’re defined in this class or in a superclass.

However, according to the regular OOP model, Django considers that children ORM 
classes
specialize their parent class. You must be able to take a child instance and 
cast it to a parent
instance by throwing away attributes not used in the parent and using the 
parent’s methods.

In other words, if Child.objects.get(pk=1) works, Parent.objects.get(pk=1) is 
supposed to give
you a Parent instance that is a more generic version of the Child instance. (I 
have to admit
that this isn’t always true with Django. If the Parent is abstract, 
Parent.objects.get will raise
an exception.)

My main concern with your proposal is that Parent.objects.get(pk=1) would 
return an object
that is totally unrelated to Child.objects.get(pk=1)! I have a hard time 
believing this qualifies
as “regular class inheritance”. I suspect many Python programmes would find it 
surprising.

That is why Django cannot ignore the fact that an ORM model is backend by a 
database
table. It needs to decide what table to use — or disable database access 
entirely to avoid
this problem.

I’m sorry if this feels like “hijacking” to you. It’s prevents data corruption 
bugs, though.

Best regards,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1A4487D5-6918-40FA-B3E0-29A24B2D7CE0%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Annotate date intervals or ranges

[Marc Tamlyn]

Probably just because there hasn't been an immediate need, and because it
working on every database the same way could be... awkward. When you have
dates, you also have to think about the timezone implications as well -
which timezone do you need that date in?

It's also worth mentioning that if you don't care about those subtleties
for your application, you can use Func() to do this:

.annotate(day_created=Func(Value('day'), 'created_date',
function='date_trunc'))

https://docs.djangoproject.com/en/1.9/ref/models/expressions/#func-expressions

On 2 March 2016 at 11:44, Sam Peka  wrote:

> It would be great if there was a way within the standard Queryset api to
> annotate ranges of dates. The use case is that it would remove the need to
> resort to RawSQL when grouping things by date ranges, such as the day of
> the month. I know the postgres extras package has a DateRangeField, but
> it's surprisingly difficult to do this dynamically.
>
> So I'd propose something like this:
>
> queryset.annotate(day_created=DateRange('day', 'created_date'))
>
> Which for Postgres would equate to:
>
> SELECT date_trunc('day', "created_date") as day_created from ...
>
> Is there a technical reason why this hasn't already been done? Or has
> there not been much of a need for it?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fe7dcfc9-cbb5-439b-bf08-f45e854a99c6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HTh4pFyWSDPXQ1L-_2QznoDo%3DDYUoELDDiKv5ASiYykg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Index expressions

[Tim Graham]

FYI, I'm aware of another student working on a proposal for that project. 
You're welcome to develop a competing proposal, but you're at a 
disadvantage at this point since the other student has a track record of 
successful contributions.

On Wednesday, March 2, 2016 at 2:46:29 PM UTC-5, Asif Saifuddin wrote:
>
> Hi Josh,
>
> I'm willing to work on django orm improvment for gsoc and considering 
> custom index as a project idea. I have gone through the available resources 
> like dep, POC on class based index, unification of transform API etc. What 
> others stuff do you suggest me to look into to have some concrete ideas to 
> complete a very good proposal.
>
> Thanks
> Asif
>
> On Sunday, February 7, 2016 at 5:11:59 PM UTC+6, Curtis Maloney wrote:
>>
>>
>> So, in #django recently there was a discussion about adding an index on 
>> a date field for just the year. 
>>
>> I know the idea was raised some time ago, and several ideas on the 
>> syntax were expressed.  But most of that focused on different types of 
>> indices - not on indexing expressions. 
>>
>> It occurred to me that with the recent advances in expression syntax, it 
>> should be fairly easy to add an indexes list to Meta to define complex 
>> expressions. 
>>
>> Input? 
>>
>> -- 
>> C 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/85c0e4bf-e613-45d3-a855-298b5dc9e23a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Index expressions

[Asif Saifuddin]

Hi Tim,

Thanks for your early input on the issue. I don't think I should compete 
with any specific proposal which already have another better competitor. I 
did some research on  SQLalchemy backend support on django and relevant 
improvement long ago before class based index. I will go for a sqlalchemy 
support on django then. and will try to contribute on relevant field too to 
prove myself as a strong candidate for that proposal. do you know any one 
else working on SQLalchemy support? or should I proceed aboout this?

Thanks

On Sunday, February 7, 2016 at 5:11:59 PM UTC+6, Curtis Maloney wrote:
>
>
> So, in #django recently there was a discussion about adding an index on 
> a date field for just the year. 
>
> I know the idea was raised some time ago, and several ideas on the 
> syntax were expressed.  But most of that focused on different types of 
> indices - not on indexing expressions. 
>
> It occurred to me that with the recent advances in expression syntax, it 
> should be fairly easy to add an indexes list to Meta to define complex 
> expressions. 
>
> Input? 
>
> -- 
> C 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/59d4cf64-2816-4d3d-8252-20faf9df835c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Copy-from-base inheritance

[Joakim Saario]

Yes, Child would be "unrelated" in the sense that it doesn't have any 
connections to its parent
other than the fields. Is the problem that this uses the inheritance 
semantics?

Python doesn't offer a mechanism for accessing parent objects or vice 
versa, this is something you
will have to implement yourself if you want it. So I don't see how this 
would be surprising for
any python programmers.

The relational inheritance can actually cause data corruption when you 
don't expect the parents
data to be a superset of the childrens data. However, the the parent's 
definition may still be
a superset of the childrens definition, if you don't override any fields.

As an example of this, consider:

class 3DTable(models.Model):
width = models.IntegerField()
height = models.IntegerField()
depth = models.IntegerField()

class 4DTable(3DTable):
some_other_dimension = models.IntegerField()

Now, of course this depend of what a 4DTable is. It may NOT even be 
projectible in the 3D space at all, at least not in a sensible way. So it s 
houldn't be presented as if it were.

As for the definition, they are mostly the same, 4DTable adds another 
dimension. It should in this case inherit the definition only.

Den torsdag 3 mars 2016 kl. 12:36:08 UTC+1 skrev Aymeric Augustin:
>
> Hi Joakim, 
>
> On 03 Mar 2016, at 11:03, Joakim Saario > 
> wrote: 
>
> > The problem is that django hijacks the class-inheritance feature of 
> python and uses it soley 
> > for relational inheritance. 
>
>
> I understand that you would like each model class to have its own table 
> with all its fields, 
> whether they’re defined in this class or in a superclass. 
>
> However, according to the regular OOP model, Django considers that 
> children ORM classes 
> specialize their parent class. You must be able to take a child instance 
> and cast it to a parent 
> instance by throwing away attributes not used in the parent and using the 
> parent’s methods. 
>
> In other words, if Child.objects.get(pk=1) works, Parent.objects.get(pk=1) 
> is supposed to give 
> you a Parent instance that is a more generic version of the Child 
> instance. (I have to admit 
> that this isn’t always true with Django. If the Parent is abstract, 
> Parent.objects.get will raise 
> an exception.) 
>
> My main concern with your proposal is that Parent.objects.get(pk=1) would 
> return an object 
> that is totally unrelated to Child.objects.get(pk=1)! I have a hard time 
> believing this qualifies 
> as “regular class inheritance”. I suspect many Python programmes would 
> find it surprising. 
>
> That is why Django cannot ignore the fact that an ORM model is backend by 
> a database 
> table. It needs to decide what table to use — or disable database access 
> entirely to avoid 
> this problem. 
>
> I’m sorry if this feels like “hijacking” to you. It’s prevents data 
> corruption bugs, though. 
>
> Best regards, 
>
> -- 
> Aymeric. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e29047cf-fc18-47e5-8003-5576dca7252d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Index expressions

[Tim Graham]

No, I'm not aware of any ongoing work or plans to add SQLAlchemy support. 
Let's continue the discussion in a separate thread since this is now off 
topic.

On Thursday, March 3, 2016 at 11:36:16 AM UTC-5, Asif Saifuddin wrote:
>
> Hi Tim,
>
> Thanks for your early input on the issue. I don't think I should compete 
> with any specific proposal which already have another better competitor. I 
> did some research on  SQLalchemy backend support on django and relevant 
> improvement long ago before class based index. I will go for a sqlalchemy 
> support on django then. and will try to contribute on relevant field too to 
> prove myself as a strong candidate for that proposal. do you know any one 
> else working on SQLalchemy support? or should I proceed aboout this?
>
> Thanks
>
> On Sunday, February 7, 2016 at 5:11:59 PM UTC+6, Curtis Maloney wrote:
>>
>>
>> So, in #django recently there was a discussion about adding an index on 
>> a date field for just the year. 
>>
>> I know the idea was raised some time ago, and several ideas on the 
>> syntax were expressed.  But most of that focused on different types of 
>> indices - not on indexing expressions. 
>>
>> It occurred to me that with the recent advances in expression syntax, it 
>> should be fairly easy to add an indexes list to Meta to define complex 
>> expressions. 
>>
>> Input? 
>>
>> -- 
>> C 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9c791156-99da-4ac8-8cc8-f0d02bb40960%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: Refactor Form class

['Moritz Sichert' via Django developers (Contributions to Django itself)]

Hello,

I want to propose a refactor of the Form class to make it
easier to customize and subclass.


Motivation:

Currently the Form class (combined with Field, Widget and
BoundField) has many responsibilities and combines much
functionality into a single class. It currently does:

- data validation (using Field validators and clean*
  methods)
- parsing HTTP form data and handling special cases like
  file upload (using Widget.value_from_datadict() and
  Field.to_python())
- displaying values as HTML input fields (using
  Widget.render(), BoundField.value(), Field.prepare_value()
  and even the Media class)

Although those three functionalities are closely related one
can easily think of situations where only one is needed.
Following Django's principle of loose coupling it would also
be desirable to be able to exchange components.

For example, it's conceivable that the form data doesn't
come from a HTTP request with x-www-form-urlencoded or
multipart/form-data content but gets transferred as JSON. In
this case it should be easy to replace the HTTP parsing
component with a JSON parser.

Also HTML forms may not be the only place where data
validation is needed. An application may get an untrusted
dict of Python objects that doesn't have to be parsed but
should still be validated. In that case it would be nice to
be able to just use the data validation component.

Currently it is also pretty hard to subclass or customize
the Form class without having to rewrite most of the class.
An example is the handling of "initial" and "files" data.
Those two arguments provide all the data of a form in
conjunction with the "data" argument. Those three attributes
are accessed explicitly all over the classes of django.forms
(i.e. Form, BoundField, Field, Widget). So if one wanted to
change the semantics of "initial" data it would be necessary
to change all of those classes. In the spirit of loose
coupling those classes should rely as little as possible on
the existence of certain attributes like "initial" and
"files".

Therefore I propose splitting the Form class into multiple
components that can be easily exchanged and used without
another.



Rationale:

To give you a better idea about the proposal I already
prepared a general architecture of how I think this could be
implemented. This is of course in no way final and I'll be
happy to receive feedback and suggestions!

Components:

Each of the aforementioned components is implemented in a
class of its own:

- FormValidator:
  Implements the data validation as the name suggests. It
  uses Field instances that can be declared declaratively as
  it is possible with the old Form class. Furthermore it
  provides all methods of the old Form class that dealt with
  data validation, i.e. clean*(), is_valid(), errors(), etc.
- DataProvider:
  Implements the "parsing and providing data" component. It
  has only one method "get_value(name)" that must be
  overwritten by subclasses and returns the data for a given
  field name.
  HtmlFormProvider is a subclass of DataProvider that
  provides the parsing of HTTP form content by using Widget
  objects and their "value_from_datadict()" method in
  particular. The widgets of a HtmlFormProvider can be
  specified declaratively just like the fields of a
  FormValidator.
- HtmlForm:
  Implements the "displaying values as HTML input fields"
  component. Same as HtmlFormProvider it uses Widget objects
  and their "render()" method in particular. It also
  features all methods of the old Form class that were used
  mainly in templates, like __iter__(), __getitem__(),
  __str__(), as_p(), etc.
  Furthermore it fetches its data from a given
  HtmlFormProvider instance and provides handling of error
  messages with a FormValidator instance. It is also
  possible to decouple HtmlForm and HtmlFormProvider such
  that HtmlForm works with any DataProvider subclass.


Changes to existing classes:

Obviously the Form class does not exist anymore, however
the Field class was also changed slightly. As it isn't used
for any display logic anymore but solely for validation it
loses a few attributes that are better suited to the Widget
class like "label", "help_text" and "show_hidden_inital" and
it isn't possible to define a set a Field's widget. To
compensate those attributes where moved to the Widget class.


New classes:

To demonstrate the new possibilities there are also two new
classes called "SimpleDataProvider" and "JsonProvider". They
take a Python dict and a JSON string respectively instead of
a QueryDict from a HTTP request.


The attached file shows a class diagram of the proposed
classes.



Additional thoughts:

The long standing issue about replacing the Media class
(#22298 and friends) will probably be easier to solve if
this proposal is accepted. As a result of being able to
subclass HtmlForm without having to rewrite large parts of
code it will be easier for third party apps to define mixins
or subclasses of HtmlForm that deal with HTML 

Re: Copy-from-base inheritance

[Shai Berger]

Hi Joakim,

You seem to be taking the very view that inheritance means nothing but reuse 
of definitions. This view, however, is not accepted in any principled approach 
to OOP that I'm aware of.

On Thursday 03 March 2016 19:58:30 Joakim Saario wrote:
> Yes, Child would be "unrelated" in the sense that it doesn't have any
> connections to its parent
> other than the fields. Is the problem that this uses the inheritance
> semantics?
> 

Mostly, yes; inheritance encodes an "is-a" relation between concepts, which 
you seem to disregard completely.

> Python doesn't offer a mechanism for accessing parent objects or vice
> versa, this is something you will have to implement yourself if you want it.
> So I don't see how this would be surprising for any python programmers.
> 

There is a difference in terms here: Aymeric referred to "casting into 
parents", you are referring to "accessing parent objects". The point is that 
the parent object is not some distinct entity that you need to navigate to, 
but just a different way to look at the same instance.

Python does support a form of this casting to a parent with super().

> The relational inheritance can actually cause data corruption when you
> don't expect the parents data to be a superset of the childrens data.

If you don't expect this, your understanding of inheritance is at odds with 
the rest of the world's.

> However, the the parent's
> definition may still be
> a superset of the childrens definition, if you don't override any fields.
> 
> As an example of this, consider:
> 
> class 3DTable(models.Model):
> width = models.IntegerField()
> height = models.IntegerField()
> depth = models.IntegerField()
> 
> class 4DTable(3DTable):
> some_other_dimension = models.IntegerField()
> 
> Now, of course this depend of what a 4DTable is. It may NOT even be
> projectible in the 3D space at all, at least not in a sensible way. So it s
> houldn't be presented as if it were.
> 

If so, it shouldn't be a subclass of 3DTable.

> As for the definition, they are mostly the same, 4DTable adds another
> dimension. It should in this case inherit the definition only.
> 

If the two classes share nothing but a set of fields -- and these fields do not 
make sense as some independent concept that is common to the two classes -- 
then the best design is to keep them completely separate (this is true even if 
they are not Django models), because they are likely to evolve independently.

If the shared part does make sense as a full concept, but you still intend the 
two classes to be unrelated, then that concept should be defined as a common 
parent class (or abstract model):

class BaseDimensions(models.Model):
width = models.IntegerField()
height = models.IntegerField()
depth = models.IntegerField()
class Meta:
abstract = True

class 3DTable(BaseDimensions):
pass

class 4DTable(BaseDimensions):
some_other_dimension = models.IntegerField()


HTH,
Shai.

Re: Annotate date intervals or ranges

[Josh Smeaton]

A somewhat related ticket: https://code.djangoproject.com/ticket/25774 
which attempts to make current datetime transforms/expressions public. 
These focus mainly on EXTRACT() type transformations, but there's certainly 
a place for date_trunc type transformations too. Feel free to create a 
ticket proposing such expressions if one does not already exist.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/948e7c5e-2d21-45db-bc1e-159558016d25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: django.contrib.mysql

[Adam Johnson]

The *django.contrib.postgres* docs state:

There is no fundamental reason why (for example) a contrib.mysql module 
> does not exist


*Well...* over the past year and a bit I've been developing Django-MySQL. 
It has a ton of features specific to MySQL and/or MariaDB. For a quick tour 
of the features, see the exposition in the 
documentation: https://django-mysql.readthedocs.org/en/latest/exposition.html 
(it's not all suitable for Django core, some is kinda hacky (but well 
tested!))

At DUTH in November I talked with Josh Smeaton about posting a suggestion 
here for *django.contrib.mysql*. Since then, I've simply been 
lazy/forgetful, but now I'm here getting round to it.

I'm also a bit motivated by my recent completion of its *JSONField* for 
MySQL 5.7+ which is very similar to the *contrib.postgres* one, copying and 
adapting large parts of code from Marc Tamlyn's work. We all know how much 
everyone loves JSON these days. If anything, this could be a core field 
rather than a *contrib* one - Oracle and SQLite also have JSON capabilities 
now. JSON everywhere!

Anyway... what's the interest in *django.contrib.mysql*? And where woudl we 
go from here...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ed9245ea-f908-4c1c-91ad-cb94f0147959%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: django.contrib.mysql

[Tim Graham]

Nice work, Adam. What's your main motivation for wanting to include it in 
Django itself? Do you think that including it will simplify the code much? 
Do you hope to attract new contributors by including it in Django itself? 
It's a bit concerning to me that the project seems like a one man show as 
there are only 3 other contributors with 3 commits each to your 454 
commits. Do you have a long term interesting in maintaining the module as 
part of Django itself?

Who else would step up to provide expertise here, especially if you have to 
step away for whatever reason?

On Thursday, March 3, 2016 at 6:09:00 PM UTC-5, Adam Johnson wrote:
>
> The *django.contrib.postgres* docs state:
>
> There is no fundamental reason why (for example) a contrib.mysql module 
>> does not exist
>
>
> *Well...* over the past year and a bit I've been developing Django-MySQL. 
> It has a ton of features specific to MySQL and/or MariaDB. For a quick tour 
> of the features, see the exposition in the documentation: 
> https://django-mysql.readthedocs.org/en/latest/exposition.html (it's not 
> all suitable for Django core, some is kinda hacky (but well tested!))
>
> At DUTH in November I talked with Josh Smeaton about posting a suggestion 
> here for *django.contrib.mysql*. Since then, I've simply been 
> lazy/forgetful, but now I'm here getting round to it.
>
> I'm also a bit motivated by my recent completion of its *JSONField* for 
> MySQL 5.7+ which is very similar to the *contrib.postgres* one, copying 
> and adapting large parts of code from Marc Tamlyn's work. We all know how 
> much everyone loves JSON these days. If anything, this could be a core 
> field rather than a *contrib* one - Oracle and SQLite also have JSON 
> capabilities now. JSON everywhere!
>
> Anyway... what's the interest in *django.contrib.mysql*? And where woudl 
> we go from here...
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57f5059e-b49d-4d94-9938-2a7dc77540ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django admin and messages

[Cristiano Coelho]

By "we are doing" do you mean that's how it is translated by django, or are 
you patching translations on your projects? Any ideas why would it be 
different for spanish? It really burns my eyes seeing those grammar 
mistakes :D

El miércoles, 2 de marzo de 2016, 6:45:24 (UTC-3), Claude Paroz escribió:
>
> Le mercredi 2 mars 2016 02:42:05 UTC+1, Cristiano Coelho a écrit :
>>
>> Another approach for gender languages like spanish would be to use "el 
>> objeto %(obj)" rather than "el/la %(obj)".
>>
>
> That's exactly what we are doing for French.
>
> Claude 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/98cd7f1e-5369-41ab-bf8e-191f0e522c0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django admin and messages

[Ramiro Morales]

On Thu, Mar 3, 2016 at 11:06 PM, Cristiano Coelho 
wrote:

> By "we are doing" do you mean that's how it is translated by django, or
> are you patching translations on your projects? Any ideas why would it be
> different for spanish? It really burns my eyes seeing those grammar
> mistakes :D
>

You could the es_AR translation. I think we have all these cases covered.

-- 
Ramiro Morales
@ramiromorales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO7PdF_N_DMA6Pd0uNY8-o7NDdHykjfoZNMj6XnC9kZGB6t5aQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django admin and messages

[Cristiano Coelho]

The issue is that we do not force any particular es language, it is pretty 
much up to the browser so it can be es, es_AR, es_UY etc. And it is not 
really an issue with this spanish project (all susscess messages are not 
shown) but a translation issue with spanish translations in general

El jueves, 3 de marzo de 2016, 23:31:19 (UTC-3), Ramiro Morales escribió:
>
> On Thu, Mar 3, 2016 at 11:06 PM, Cristiano Coelho  > wrote:
>
>> By "we are doing" do you mean that's how it is translated by django, or 
>> are you patching translations on your projects? Any ideas why would it be 
>> different for spanish? It really burns my eyes seeing those grammar 
>> mistakes :D
>>
>
> You could the es_AR translation. I think we have all these cases covered.
>
> -- 
> Ramiro Morales
> @ramiromorales
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30f4fc65-7191-4e16-a5f3-d55c93491403%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: django.contrib.mysql

[Aymeric Augustin]

Hi Adam,

django-mysql has a rather large API surface. I think the first step would be to 
make a list of the most stable and generally useful bits that are candidate for 
inclusion in Django and to write that list down in a DEP.

The fields, functions, lookups, and aggregates are good candidates. I’m less 
sure about the QuerySet extensions because we don’t have anything similar yet. 
We’d have to think about the implications.

Looking forwards, django-mysql could be an experimental ground for features. 
When they stabilize, the most common features could go into 
django.contrib.mysql.

Since making changes to public APIs is a pain, you only want to put code in 
Django when it’s done. To a lesser extent, we have Python’s “standard library 
is where modules go to die” problem.

It would obviously help if other community members expressed interest in 
django.contrib.mysql or, even better, intent to help maintain it in the future.

I hope this helps,

-- 
Aymeric.

PS: if this plan comes to fruition, most likely you’ll get commit access along 
the way ;-)


> On 04 Mar 2016, at 00:09, Adam Johnson  wrote:
> 
> The django.contrib.postgres docs state:
> 
> There is no fundamental reason why (for example) a contrib.mysql module does 
> not exist
> 
> Well... over the past year and a bit I've been developing Django-MySQL. It 
> has a ton of features specific to MySQL and/or MariaDB. For a quick tour of 
> the features, see the exposition in the documentation: 
> https://django-mysql.readthedocs.org/en/latest/exposition.html (it's not all 
> suitable for Django core, some is kinda hacky (but well tested!))
> 
> At DUTH in November I talked with Josh Smeaton about posting a suggestion 
> here for django.contrib.mysql. Since then, I've simply been lazy/forgetful, 
> but now I'm here getting round to it.
> 
> I'm also a bit motivated by my recent completion of its JSONField for MySQL 
> 5.7+ which is very similar to the contrib.postgres one, copying and adapting 
> large parts of code from Marc Tamlyn's work. We all know how much everyone 
> loves JSON these days. If anything, this could be a core field rather than a 
> contrib one - Oracle and SQLite also have JSON capabilities now. JSON 
> everywhere!
> 
> Anyway... what's the interest in django.contrib.mysql? And where woudl we go 
> from here...
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ed9245ea-f908-4c1c-91ad-cb94f0147959%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/75F75DCA-C37E-4622-A87A-2FC6EAF7A283%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.