Re: i18n bug in template rendering.

[Gert Van Gool]

So for the sake of the argument I've changed the template code to use
"{% load i18n %}" and also added a filter, since that is our use-case.
http://dpaste.com/294778/

I thought that if you wanted to apply a filter to a string in a
template that you had to use _ instead of {% trans %}.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net



On Thu, Jan 6, 2011 at 00:05, Ramiro Morales  wrote:
> On Wed, Jan 5, 2011 at 12:21 PM, Jonathan S  
> wrote:
>> I guess, we found a bug, not sure if it has been reported earlier and
>> whether this is the right place to report.
>>
>> When a template contains translations in variables, like
>> {{ _("text") }}, the text seems to be translated already during the
>> creation of the Template object. Every following call of
>> Template.render() will output the translation which was made earlier.
>> (Possibly in the wrong language.)
>>
>> Templates are cached in 'django.template.loaders.cached.Loader', so
>> this bug makes constructions like  {{ _("text")|upper }} impossible.
>
> But you aren't using the i18n support correctly.
>
> You aren't supposed to use _('Foo') as a standalone variable.
> (see last paragraph here
> http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#other-tags)
>
> Also,
>
> * You need to load the i18n template tag library
>
> * Use the trans tag.
>
> Try using Template("{% load i18n %}{% trans 'Yes' %}").render(...)
> to achieve what you want.
>
> All this is covered in the docs:
>
> http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#specifying-translation-strings-in-template-code
>
> --
> Ramiro Morales
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

[Alex Gaynor]

On Wed, Jan 5, 2011 at 5:41 PM, Florian Apolloner wrote:

> Hi,
>
> On Jan 6, 12:02 am, Russell Keith-Magee 
> wrote:
> > There are no backwards compatibility concerns here. We're talking
> > about the class-based generic TemplateView.
>
> Sorry, I just noticed now, that the current function based views are
> still function based and not wrappers around the class based views.
> Then option (5) sounds great :)
>
> Cheers, Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>
My suggestion:

Have cache_page return a wrapper around TemplateResponse, which overrides
bake (or render or whatever we called it) to actually cache the rendered
page, then when cache_page fetches something from the cache have just return
the HttpResponse.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you want"
-- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

[Florian Apolloner]

Hi,

On Jan 6, 12:02 am, Russell Keith-Magee 
wrote:
> There are no backwards compatibility concerns here. We're talking
> about the class-based generic TemplateView.

Sorry, I just noticed now, that the current function based views are
still function based and not wrappers around the class based views.
Then option (5) sounds great :)

Cheers, Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: i18n bug in template rendering.

[Ramiro Morales]

On Wed, Jan 5, 2011 at 12:21 PM, Jonathan S  wrote:
> I guess, we found a bug, not sure if it has been reported earlier and
> whether this is the right place to report.
>
> When a template contains translations in variables, like
> {{ _("text") }}, the text seems to be translated already during the
> creation of the Template object. Every following call of
> Template.render() will output the translation which was made earlier.
> (Possibly in the wrong language.)
>
> Templates are cached in 'django.template.loaders.cached.Loader', so
> this bug makes constructions like  {{ _("text")|upper }} impossible.

But you aren't using the i18n support correctly.

You aren't supposed to use _('Foo') as a standalone variable.
(see last paragraph here
http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#other-tags)

Also,

* You need to load the i18n template tag library

* Use the trans tag.

Try using Template("{% load i18n %}{% trans 'Yes' %}").render(...)
to achieve what you want.

All this is covered in the docs:

http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#specifying-translation-strings-in-template-code

-- 
Ramiro Morales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

[Russell Keith-Magee]

On Thu, Jan 6, 2011 at 4:48 AM, Florian Apolloner  wrote:
> Hi,
>
> Option (5) sounds great; but if you want backwards compat option (1)
> is the only way to go. cache_page isn't the only decorator affected by
> this problem; I could imagine there are many decorators in 3rd party
> apps which try to alter the response. So the question is how much code
> will we break if we not go with option (1) and does the backwards
> policy allow that at all?

There are no backwards compatibility concerns here. We're talking
about the class-based generic TemplateView. Since that was added in
1.3, there isn't anything to be backwards compatible with.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

[Florian Apolloner]

Hi,

Option (5) sounds great; but if you want backwards compat option (1)
is the only way to go. cache_page isn't the only decorator affected by
this problem; I could imagine there are many decorators in 3rd party
apps which try to alter the response. So the question is how much code
will we break if we not go with option (1) and does the backwards
policy allow that at all?

That said I am -1 on option (2) and -0 on (4) since it only fixes the
decorator and not the problem per se.

Cheers, Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Namspace packages in Django

[Nils Fredrik Gjerull]

on., 05.01.2011 kl. 09.32 +0800, skrev Russell Keith-Magee:
> A similar request was made in ticket #14087. I closed that ticket as
> wontfix because allowing multiple applications with the same name is
> fundamentally problematic; however, you have highlighted that that
> this problem isn't tied to having two apps with the same name in a
> project.

I have uploaded at git diff file to that ticket.

> Even better, you've provided a test case that demonstrates the problem
> within normal usage.
> 
> So - I'm happy to reopen this ticket, and use your github branch as an
> RFC patch. The core team is able to pull from github, but If you could
> upload a raw patch version to Trac, that would also be helpful.

That's great :)

-- 
Nils Fredrik Gjerull
-
"Ministry of Eternal Affairs"
Computer Department
( Not an official title :) )

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Does anyone know how to create a Django installer for Installatron?

[Christopher Marchfelder]

This is the Django Mailinglist for Developers, for Questions about using
Django please ask at Django Users

Am 05.01.2011 17:20 schrieb "Martijn" :

Does anyone know how to create a Django installer for Installatron?
I've two cheap providers and they both use Installatron. It would be
great to start a Django project that way. I happen to hate the
terminal, command line and other installers that waste a lot of
time ;-)

Thanx!

--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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-develop...@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.

Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

[Russell Keith-Magee]

Hi all,

Ticket #15012 highlights that you can't use a cache_page decorators on
pages that return a TemplateResponse. The problem goes like this:

 * A decorator operates on the output of a function
 * cache_page stores the output of a function so it can be used in the
future instead of invoking the function again
 * The output of a function returning a TemplateResponse hasn't been
fully computed, and (at least at present) isn't pickleable
 * So a TemplateResponse can't be cached.

This was noted as a problem during the discussion of the render()
shortcut, but #15012 points out a bigger implication -- the
TemplateView generic view uses TemplateResponse. Which means you can't
cache the output of a simple template generic view.

This is a fairly big oversight, which is why #15012 is on the blocker list.

There are at least 4 fixes to this problem that I can see.

 1) Revert the TemplateView to use old-style static responses, rather
than TemplateResponse. You would still be able to get a
TemplateResponse with a simple configuration change (specifying
TemplateResponse instead of shortcuts.render as the response_class).
This seems like a case of not eating our own dogfood, but it's the
easiest fix.

 2) Fix TemplateResponse to make it pickleable. This would work, but
does somewhat defeat the purpose of caching -- to save CPU cycles by
storing fully rendered page output. What would be pickled is a
template and a context that would need to be re-evaluated.

 3) Modify cache_page to raise an error if it is used on a
TemplateResponse. This doesn't fix the problem; it just makes sure you
know why the problem exists.

 4) Modify cache_page to force a render of the response. This defeats
the purpose of introducing TemplateResponse, and would mean that
template response middleware would be executed, but ignored.

 5) Modify cache_page so that you can decorate a function with
cache_page, but have the caching take effect later in the response
cycle (i.e., after TemplateResponse has been actually rendered).

I feel like 5 would be the the most desirable outcome, but I have no
idea how it could even be implemented. The only thought I've had is
that maybe the decorator could annotate the response with a callback
that is invoked once the rendering process has been completed.
However, this would be prone to ordering problems -- for example,
consider the following stack:

@other_dec
@cache_page
def my_view(request):
   ...

At present, if other_dec is page modifying, those modifications will
not be cached; if the effect of cache_page are deferred, they will be.

So - opinions? Have I missed any options? Any other ideas on how to achieve (5)?

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Does anyone know how to create a Django installer for Installatron?

[Martijn]

Does anyone know how to create a Django installer for Installatron?
I've two cheap providers and they both use Installatron. It would be
great to start a Django project that way. I happen to hate the
terminal, command line and other installers that waste a lot of
time ;-)

Thanx!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Regressions in 1.2.4

[Russell Keith-Magee]

Hi all,

As I just noted on a blog entry, I've tagged the 1.3 release blocking
bugs in Trac:

http://code.djangoproject.com/query?status=new=assigned=reopened=%7Eblocker

Most of these are fairly minor issues. However, there are 5 tickets
that are regressions from 1.2.3 to 1.2.4:

 * #14880 - raw_id_fields failing in admin when used with limit_choices_to
 * #14947 - a test failure uner Python 2.7, only visible in 1.2.4
 * #14975 - a test in contrib.auth causing *all* TransactionTestCases
to fail in user code
 * #14982 - EMPTY_CHANGELIST_VIEW not being honored in list_display;
again, in admin.
 * #14948 - A problem with multidb routers with m2m fields

There is also one problem with the security patch itself:
 * #14999 - A problem with the security patch not allowing queries on
local fields.

This last ticket has been fixed in 1.2.X, but is obviously in the
wild. 1.1.X is also affected, but I haven't backported to 1.1.X.

We will obviously to do a 1.2.5 release when we hit 1.3 final; but I'm
not sure if we should push an 1.2.5 (and 1.1.4) ASAP addressing these
regressions, and then do 1.2.6 when we cut 1.3 final.

This also points out that we should perhaps reconsider our release
policy. Putting out security releases that include unrelated fixes is
a bit of a risk. We've been bitten by this in the past, but never this
bad. I would suggest that when security issues arises in 1.2.3, we
should be releaseing 1.2.3.1 rather than 1.2.4. If a security release
coincides with a point release -- as it did when we released 1.3beta1
-- we should release 1.2.3.1 (to address the security issue) *and*
1.2.4 (to get the other bugfixes). This will ensure that it is
possible to update production code and get just the security fix,
without any risk of regressions.

Any opinions on these two points?

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

i18n bug in template rendering.

[Jonathan S]

I guess, we found a bug, not sure if it has been reported earlier and
whether this is the right place to report.

When a template contains translations in variables, like
{{ _("text") }}, the text seems to be translated already during the
creation of the Template object. Every following call of
Template.render() will output the translation which was made earlier.
(Possibly in the wrong language.)

Templates are cached in 'django.template.loaders.cached.Loader', so
this bug makes constructions like  {{ _("text")|upper }} impossible.


=Test code: =

from django.utils import translation
from django.template import Template, Context


def language(language_code):
class with_block(object):
def __enter__(self):
self._old_language = translation.get_language()
translation.activate(language_code)
def __exit__(self, *args):
translation.activate(self._old_language)
return
with_block()


with language('en'): # Output 'Yes'
 Template("{{ _('Yes') }}").render(Context({}))


with language('fr'): # Output 'Oui'
 Template("{{ _('Yes') }}").render(Context({}))


with language('nl'): # Output 'Ja'
 Template("{{ _('Yes') }}").render(Context({}))


with language('nl'): # create template, while environment language is
dutch
t = Template("{{ _('Yes') }}")

with language('fr'): # Render in French -> output is still Dutch
('Ja')
t.render(Context({}))


= Output =

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.utils import translation
>>> from django.template import Template, Context
>>>
>>>
>>> def language(language_code):
... class with_block(object):
... def __enter__(self):
... self._old_language = translation.get_language()
... translation.activate(language_code)
... def __exit__(self, *args):
... translation.activate(self._old_language)
... return
with_block()
...
>>>
>>> with language('en'): # Output 'Yes'
...  Template("{{ _('Yes') }}").render(Context({}))
...
u'Yes'
>>>
>>> with language('fr'): # Output 'Oui'
...  Template("{{ _('Yes') }}").render(Context({}))
...
u'Oui'
>>>
>>> with language('nl'): # Output 'Ja'
...  Template("{{ _('Yes') }}").render(Context({}))
...
u'Ja'
>>>
>>> with language('nl'): # create template, while environment language is dutch
... t = Template("{{ _('Yes') }}")
...
>>> with language('fr'): # Render in French -> output is still Dutch ('Ja')
... t.render(Context({}))
...
u'Ja'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Namspace packages in Django

[David Reynolds]

On 4 Jan 2011, at 20:15, Nils Fredrik Gjerull wrote:
> 
> Hi, Django folks!
> 
> This is my first time posting on the Django developer list. Thanks for
> an amazing framework.
> 
> The Distribute build system supports namespaced packages
> (http://packages.python.org/distribute/setuptools.html#namespace-packages).
> 
> I have found namespaced packages to be of great help for my use case. A
> project I am working on started out with some apps that were specific
> for that project. Now I need to create a sub-site that uses only some of
> the apps of the original project. I pulled out two of the apps and
> created two separate packages for them. Because the apps had quite
> common package names I did not want to occupy my namespace with them, so
> I put them in a namespace package. This appeared to work correctly until
> I tried to put a management command into one of them. The command were
> not discovered. I traced this to the find_management_module function in
> the django.core.management module.
> 
> I have found a way to discover all management packages without having to
> import all the app modules. I tried to do it by importing, but the
> manage.py script were running noticeably slower. I have also made a test
> case.
> 
> The code is in:
> https://github.com/nilsfr/django/blob/pht/django/core/management/__init__.py
> https://github.com/nilsfr/django/blob/pht/django/utils/importlib.py
> https://github.com/nilsfr/django/tree/pht/tests/regressiontests/admin_scripts
> 
> I do not intend to use this for including different apps with the same
> name, in the same project. Only to avoid occupying the namespace with
> common names, so I can use the same app name for different projects.
> 
> Any chance of getting this into core?

I have a similar problem but with using pkgutil.extend_path().

I have 2 packages set up a bit like this:

company/
common/


company/
apps/
news/
management/
commands/


each using the pkgutil.extend_path() trick. However only the first one on the 
path will be searched for management commands.

Hopefully Nils' patch will fix this situation too



-- 
David Reynolds
da...@reynoldsfamily.org.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-develop...@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: app loading

[Arthur Koziel]

Hey Alex,

thanks for taking the time to review the code. However, we've agreed not to
construct the app instances in the settings.py file as it would require
imports to be used, and stick to the convention of dotted paths. You might
want to read this thread [0], but especially this [1] reply from Jannis
Leidel.

We also discussed this whole thing at the DjangoCon sprints, which led us to
the current implementation. There are now 2 settings with which apps can be
installed:

- APP_CLASSES: which is a list of dotted paths pointing to App classes
- INSTALLED_APPS: stays the same, dotted paths to python modules

Arthur

[0]:
http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/
[1]: http://groups.google.com/group/django-developers/msg/fd2e3bc0593f4158

On Sun, Jan 2, 2011 at 12:17 PM, Alex Kamedov  wrote:

> Hi all! Happy new year!
> Sorry for my bad english.
>
> On this weekend I reviewed app-loading branch[1] and want to propose some
> improvements.
>
> Now app-loading branch resolve how to load application, store its meta data
> and load its models.
> I plan to extend it to get simple way for replacing the same type
> applications. This problem is
> know as Lazy Foreign Key and now can be resolve through settings, but
> django contrib modules
> currently is not supported it. I propose more beautiful way to resolve this
> problem.
>
> The main goal of my improvements is adding ability to simple replace one
> application to another
> with the same type but another functionality.  For example, if you need
> replace `django.contrib.auth`
> on your own application you must rewrite all used 3rd-party applications
> linked with it now. I
> propose way to resolve this problem and I think It is not hard to implement
> with saving backward
> compatibilities.
>
>
> 1. Change INSTALLED_APPS form tuple to dictionary or may be it's better to
> use something with
> the same interface as tuple and dictionary
>
> INSTALLED_APPS = {
> 'auth': 'django.contrib.auth',
> 'comments': 'django.contrib.comments'.
> ...
> }
>
> For backward compatibility it checks on setting load stage and convert to
> dictionary if it need.
>
> INSTALLED_APPS will be low level API to install applications. I propose
> install application through
> `install_applications` function like this:
>
> from django.core.apps import install_applications
>
> INSTALLED_APPS = install_applications(
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> ...
> auth = 'django.contrib.auth',
> comments = 'django.contrib.comments'
> gallery = App(path='my_gallery', db_prefix='new_gallery',
> verbose_name=u'My new gallery')
> )
>
>  There are args and kwargs passed to `install_applications`. It can be
> python module names of
> django applications. Keys of kwargs are system names of the installed
> applications. This names
> will be used to get application instance in other applications (see next
> for more details).
> For applications passed through args keys will be auto generated.
>
> The main benefit is a manage installed applications in project settings
> module without make
> changes in this applications.
>
> Application loading process will be as listed below:
>  * iterate over INSTALLED_APPS items
>  * if item is string - try to load application definition
> (`Application`class) from python package
> defined in this string and create its instance. If application
> definition is not provided, it will be
> auto generated. `django.core.apps.App` class will be used for it.
>  * if item is `App` instance, check existence of python package at `path`
> attribute of `App` instance
>and `ImproperlyConfigured` exception will be raised if this python
> package is not installed.
>
> 2. Way to organize relations between models of different applications
> (something like this it
> already exist in app-loading branch and trunk. I show this only for example
> and demonstrate
> syntax)
>
> from django.core.apps import get_app, get_model
>
> auth = get_app('auth')
>
> class MyModel(models.Model):
> user = models.ForeignKey(auth.models.User)
>
> or
>
> class MyModel(models.Model):
> user = models.ForeignKey(get_model('auth.User'))
>
>
> 3. Add new exceptions: `AppIsNotInstalled` (instead of
> `ImproperlyConfigured`) will be raised if it is
> try to load not installed applications through `get_app`.
>
>
> [1] http://code.djangoproject.com/wiki/SummerOfCode2010#Apploading
>
>
> Waiting for your comments.
>
> Cheers!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this 

Re: Problem with ``Model.objects.create``

[Valts]

On Jan 4, 8:46 pm, Waylan Limberg  wrote:
> That being said, it does strike me as being a little odd that there is
> no way to validate your data when using create() or get_or_create().
> In fact, the docs [1] describe both those methods as shortcuts. But if
> you're writing an app that always needs to validate your data, then
> you will never use those shortcuts which makes them rather useless. Of
> course, they existed long before (the current) model validation
> mechanism did, so I wonder if it would be reasonable to propose that
> they (at least optionally) be updated to run validation before saving.

Just my $0.02: I think that such feature would be useful when using
get_or_create() when I don't want the object to be saved into the
database if it does not validate. There could be added another special
keyword argument "full_clean", "validate" or similar to
get_or_create(). If the proposed idea gets the green light I am
willing to create the ticket and the necessary patches.

In case of create() IMO there is no need for any changes as create()
is really simple and I'd rather make create_clean() shortcut in my own
project without polluting keyword arguments with special cases.

Best regards,
Valts.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.