Re: Proposal: django.contrib.mysql

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.

Re: Django admin and messages

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

Re: Django admin and messages

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

Re: Django admin and messages

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

Re: Proposal: django.contrib.mysql

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

Proposal: django.contrib.mysql

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

Re: Annotate date intervals or ranges

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

Re: Copy-from-base inheritance

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

Proposal: Refactor Form class

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

Re: Index expressions

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

Re: Copy-from-base inheritance

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

Re: Index expressions

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

Re: Index expressions

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

Re: Annotate date intervals or ranges

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

Re: Copy-from-base inheritance

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

Re: Copy-from-base inheritance

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

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

> > 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