Moving from PIL to Pillow

[Marijonas Petrauskas]

Hi all,

Why isn't Pillow the recommended Django image library yet? PIL has
been unmaintained for almost 3 years and has a number of annoying bugs
(e.g. fails to open some valid JPEG files, maybe has some security
issues as well). Pillow, on the other hand, is a backwards-compatible
community-maintained fork, which has most of those issues fixed and
will even support Python 3 soon.

I think this change would involve (1) running the test suite with
Pillow, (2) updating the documentation and (3) updating the ImageField
warning shown when PIL is not installed. Looks like an easy change.
What do you think?

Thanks,
-- Marijonas

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: Django Admin Site and "pretty" app name

[Marijonas Petrauskas]

This is important not only for internationalization, but also for English
app names, consisting of several words. Neither Siteconfig nor Site_config
look pretty.

I think that app name should not be defined as a static variable in
__init__.py file for this reason: if we want to translate the label, we
write _('Site config'), which depends on django.utils.translation, and
translation depends on settings. So, this means that whenever we import any
submodule/subpackage of the app, we also import much of Django machinery.

One alternative (and probably the best one) as suggested by Sergiy is to
put it in admin.py file. Another is to define a function get_app_name() in
__init__.py file.


On Fri, Dec 7, 2012 at 4:57 AM, Pedro J. Aramburu
wrote:

> As I explained on the Django users forums (
> https://groups.google.com/forum/?fromgroups=#!topic/django-users/ZUxZHi_-5ug)
> I'm spanish speaking so my users are too. Writing code in spanish isn't
> pretty and with characters like "á" or "ñ" it's very difficult to name the
> apps a way that would make sense to show on the Admin site.
> That being said, I would like to propose a solution because all the
> tickets and solutions I found won't work properly or are very outdated but
> I need consent and guidance on how to approach it and with the internals of
> django.contrib.admin and django.db.
>
> My solution consists on a class on the __init__.py file on the module
> (app), maybe it can be call AppConfig, where some metadata about the app
> can be stored. Then, django.contrib.admin could pick it up to name the app
> and maybe add a description or help_text and if it's not there it could
> fall back to the previous method with app_label.
>
> As an example:
>
> __init__.py
>
> class AppConfig:
> verbose_name = 'app pretty name in any'
> description = 'app short description'
>
> I chose verbose_name to keep it consistent with fields and models but it
> could be called however you want (even pretty_name). Maybe on the future
> AppConfig could be used for other purposes but it has to start somewhere.
> This way you could also use ugettext_lazy to translate the name and
> description.
>
> django.db.models won't need to be touched because they don't need the
> "pretty name" but django.contrib.admin could try to pick up the AppConfig
> to get the pretty name.
>
>
> https://github.com/django/django/blob/1.4.2/django/contrib/admin/sites.py#L365
>
> https://github.com/django/django/blob/1.4.2/django/contrib/admin/sites.py#L421
>
> There it could return the verbose_name.title() or fall back to the
> app_label.title() so then in the template there will be no need to change
> anything (if we don't implement any other functionality yet).
>
> What do you think? Please let me know if it's the best approach and if it
> would be considered to merge it on the project. Mostly because non-english
> speakers need some default solution to make the django admin work for their
> sites but keeping the code in english.
>
> Thank you in advance for your thoughts on this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/hwUExTid2UEJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Admin UI improvement - actions displayed as buttons rather than drop-down list

[Marijonas Petrauskas]

Yes, it's created by me. Sorry for not referencing it.


On Sun, Nov 4, 2012 at 2:06 PM, Łukasz Rekucki  wrote:

> Hi,
>
> Isn't this https://code.djangoproject.com/ticket/19235 ?
>
> Regards,
> Łukasz Rekucki
>
> --
> 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 email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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 email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Admin UI improvement - actions displayed as buttons rather than drop-down list

[Marijonas Petrauskas]

Hello,

Sorry if this was already discussed before. I find current action interface
a bit of an overkill when the number of actions is small. At least 3 clicks
are needed to execute an action and sometimes important functionality gets
hidden under the drop-down and can be harder to find for inexperienced
users. This leads to implementing actions as a pseudo-column containing
links.

My suggestion is to enable some actions to be shown as buttons in a similar
way that we can set short_description or allow_tags. Alternatively, all
actions could be displayed as buttons when the number of them is, say, less
than 5.

Example mock-up:
[image: Inline image 1]

What are your thoughts? I would be happy to provide a patch.

Sincerely,
-- Marijonas

-- 
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 email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

<>

Re: save() method could return the object

[Marijonas Petrauskas]

There already exists create method that does exactly what you need:
obj = SomeModel.objects.create(name='foo', age=42)

On Fri, Oct 12, 2012 at 2:33 PM, David Winterbottom <
david.winterbot...@tangentlabs.co.uk> wrote:

> While such a change is initially appealing, it violates the command-query
> separation principle in that a 'command' method such as 'save' should not
> return anything.
> http://en.wikipedia.org/wiki/Command-query_separation
>
>  Hence, it's not a good idea to make this change.  It's more important to
> have clearly purposed methods than saving a line of code.
>
> David
>
>
> On 12 October 2012 14:25, Chris Wilson  wrote:
>
>> Hi all,
>>
>> If the save() method returned the object itself, then we could chain it
>> like this:
>>
>> old_status = Status(last_contact=None).**save()
>>
>> Instead of having to do this:
>>
>> old_status = Status(last_contact=None)
>> old_status.save()
>>
>> It's a trivial one-line change to the Model class and I don't think it
>> would break backwards compatibility, as I doubt that anyone is relying on
>> the save() method returning None. Should I submit a patch?
>>
>> Cheers, Chris.
>> --
>> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
>> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>>
>> Aptivate is a not-for-profit company registered in England and Wales
>> with company number 04980791.
>>
>> --
>> 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 email to
>> django-developers+unsubscribe@**googlegroups.com
>> .
>> For more options, visit this group at http://groups.google.com/**
>> group/django-developers?hl=en
>> .
>>
>>
>>
>
>
> --
> *David Winterbottom*
> Head of Programming
>
> Tangent Labs
> 84-86 Great Portland Street
> London W1W 7NR
> England, UK
>
>  --
> 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 email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Marijonas Petrauskas]

You can use:

obj = next(iter(SomeModel.objects.filter(foo='bar')), None)

The 'iter' part is not particularly elegant, but it's the only one-liner
known to me.


-- Marijonas

On Thu, Oct 11, 2012 at 3:45 PM, Ole Laursen  wrote:

> On Tuesday, October 9, 2012 7:15:55 PM UTC+2, ptone wrote:
>>
>> Earlier discussion
>> https://groups.google.com/**forum/?fromgroups=#!topic/**
>> django-developers/Saa5nbzqQ2Q
>>
>
> This was the thread I referred to. If was from 2006 and ended up being
> about something else.
>
>
>> tickets:
>>
> https://code.djangoproject.**com/ticket/17546
>>
>
> Closed as dupe with no further analysis.
>
>
>> https://code.djangoproject.**com/ticket/2659
>>
>
> This is about a different API which is a bit more cumbersome. And it was
> closed 6 years ago with a - "this could be feature creep".
>
>
>> https://code.djangoproject.**com/ticket/11352
>>
>
> This is a different proposal.
>
>
> Just to expand slightly on my proposal - I don't actually want to get
> anything else than None out of get. I just want something that makes
> intuitive sense to a Python programmer and saves me from the annoying
> try-except pattern or the related:
>
> objs = SomeClass.objects.filter(slug="xyz")
> obj = None
> if objs:
> obj = objs[0]
>
> which I often end up shortening as
>
> obj = SomeClass.objects.filter(slug="xyz")
> if obj:
> obj = obj[0]
>
> You can't get a zero or one objects out of the ORM elegantly, something I
> find I have to do relatively often in some code bases. I don't consider
> try-except intuitive for a situation where the exception case isn't
> exceptional.
>
> default=None makes sense when you are used to dicts, .first() or
> .get_or_none() or .getnone() or .single() would be fine too.
>
>
> Ole
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/r8vZ2A9tIkgJ.
>
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django 1.3 google3 statics files not found

[Marijonas Petrauskas]

Also, you should not post confidential stuff here (the link is only
accessible from internal network).

On Fri, Sep 28, 2012 at 8:50 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> Please post questions about using Django to django-users.
>
> The topic of this list is the development of Django itself.
>
> Thanks!
>
> --
> Aymeric.
>
> Le 28 sept. 2012 à 21:36, sandeez  a écrit :
>
> Hi I am newbie to django in google3 app engine. I am currently working on
> a project and am using django 1.3 in appengine. Everytime I build the
> project, statics are not found. Please suggest any settings required for
> this.I have refferred following link to build the project.
> https://sites.google.com/a/google.com/django/home/hosting-platforms/app-engine
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/aArr60smSFEJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>  --
> 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 email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.