Re: A new setting for custom gettext domains?

Personally (I'm the author of this PR) this is useful to me as I am using pycountry to get currency names in my project, and i can't get the translations to load without modifying the structure of that package, which shouldn't really be done. W dniu wto

Re: Django Admin New Look

Hi guys, I'm glad to say I finished work on replacing image icons with font. I used Font Awesome (GPL licence) kit to do it. I'll appreciate if you test new icons in your project and report any issues here

Re: Django Admin New Look

Font Awesome is not GPL - the code is MIT and the font itself is SIL OFL both of which are fine to include with Django. On 29 July 2015 at 12:13, elky wrote: > Hi guys, > > I'm glad to say I finished work on replacing image icons with font. I used > Font > Awesome

Re: Django Admin New Look

In https://code.djangoproject.com/ticket/20597 we discussed switching to SVG (instead of an icon font) in Django 1.10 when we can drop support for IE8. Now that Django 1.9 is slated for December and IE8 support ends the next month, I think it might be acceptable to drop IE8 support in 1.9 and g

Re: Django Admin New Look

I do a lot of projects with highly customized admins and having the full font awesome would be splendid. One option is to use optional requirements: pip install django[all-icons] but I don't think Django does this anywhere else so it's probably a big leap for a small part of contrib.admin Maybe

Re: Making max_length argument optional

Ticket is https://code.djangoproject.com/ticket/14094 On Wednesday, July 29, 2015 at 1:41:01 AM UTC-4, Loïc Bistuer wrote: > > Hi Aron, > > I'm +1 on addressing this, I often don't care about max_length, but I > still want a terse form representation. In my projects I use a subclass of > TextFi

Re: default values on database level

On 07/28/2015 11:55 PM, Loïc Bistuer wrote: > +1 on db defaults as well, I've actually started experimenting on > this last week. It's a bit tricky because migrations do use db > defaults in some operations (and drop them once they are done) so we > have to ensure that the new feature doesn't inter

Re: default values on database level

Hi Loic, Agree with having a db_default kwarg. I am not using multiple databases so no experiance with db routers. So how would should we handle routing between different databases when the db_default value is not compatible with that backend? for example Model.save(using='mysql_db') should we th

Re: default values on database level

Debatably this situation should throw an error at model validation time - assuming the expression does error out when trying to build that database. Otherwise it will error at migrate time. I would like this - it would be very good for UUID as PK On 29 July 2015 at 16:42, Podrigal, Aron wrote:

Re: default values on database level

On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron wrote: > Hi Loic, > > Agree with having a db_default kwarg. > > I am not using multiple databases so no experiance with db routers. So how > would should we handle routing between different databases when the > db_default value is not compatible wi

Re: default values on database level

My main problem with "defaults in the database" was that the current "default" kwarg is too expressive for things we can put into a database and doesn't allow representation of "NOW()", etc. I'd be happy with a default_db arg with defined semantics and that would just blow up if you tried to pass a

Re: default values on database level

OK, that makes implementation a lot easier. As the model validation can be done with Model.check() based on the backend given at that time either when running the server or makmigrations. On Wed, Jul 29, 2015 at 11:50 AM, Michael Manfre wrote: > > > On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Ar

Re: default values on database level

What about db_default allows either a constent eg. db_default= contrib.postgres.functions. or a string "MyCustomPostgresFunction()" and optionaly allowing arguments to be passed to the db function optionally also allowing F() expressions by giving a tuple db_default=('MyPostgresqlFunction()', F('co

Re: default values on database level

You could already achieve that by making MyPostgresqlFunction a subclass of models.Func, I don't think it's worth supporting alternate syntaxes. Cheers, Loïc > On Jul 29, 2015, at 23:05, Podrigal, Aron wrote: > > What about db_default allows either a constent eg. > db_default=contrib.postgres

Re: Making max_length argument optional

I see models as what defines the database ddl and and not a representation from a end users perspective. And I see the tight coupling between the 2 improper. Although in most cases the assumptions of representation and mapping of the 2 is mostly accepted, explicit is better than implicit. Of cours

Re: default values on database level

indeed that's it. On Wed, Jul 29, 2015 at 12:23 PM, Loïc Bistuer wrote: > You could already achieve that by making MyPostgresqlFunction a subclass > of models.Func, I don't think it's worth supporting alternate syntaxes. > > Cheers, > Loïc > > > On Jul 29, 2015, at 23:05, Podrigal, Aron > wrote