App-loading reloaded - apps without a models module
Merge request I sent a pull request implementing my first goal: https://github.com/django/django/pull/2076. It allows creating apps without a models module, and that’s it. As far as I can tell it’s fully backwards-compatible. It even includes deprecation paths for some private APIs for extra safety. It was reviewed by Florian Apolloner and Marc Tamlyn. They had some suggestions which I implemented and they gave it a +1. It was tested by Loic Bistuer. He found a small issue with migrations which I fixed. I want to merge it soon because it contains huge refactorings that could go stale. Since it has some overlap with Andrew’s work on migrations, it’s safer to perform continuous integration by merging to master often. I haven’t written documentation yet. It’s just a matter of removing all suggestions that Django apps must contain a models module and adding an entry in the release notes. I’ll do that in time for 1.7 alpha. Even if failed to reach my other goals, this patch would be worth merging because it improves the design of the app cache and paves the way for interesting features. If you see a good reason not to merge it, please tell me as soon as possible! Notes for reviewers Here’s a digest of the daily notes I sent to potential reviewers while I was working on this patch. Day 1 My priorities are backwards-compatibility, minimalism, and reviewability. I want something to be merged even if it’s just the first step in a series of incremental improvements. After spending some time studying Jannis’ and Preston’s latest patches [1] [2], sadly, I came to the conclusion that it would be inefficient for me to start by rebasing Preston’s branch on top of master. First, it’s quite outdated. Then, there’s just much code that I don’t understand to make rebasing a realistic option. Finally, some code was written to support goals that I’ve excluded from my scope, some is a work in progress, and some looks left over from previous iterations of the patch. I’m sorry. I’ll still try to extract as much value as I can from past efforts. My plan is to get to a minimal working solution with incremental changes, then review Preston’s diff to see if I’ve missed something interesting, and finally steal the tests and docs in bulk. I know that TDD would be cleaner but I don’t have enough motivation and time to do it that way. I started coding today: https://github.com/aaugustin/django/tree/yet-another-app-loading-branch [1] https://code.djangoproject.com/attachment/ticket/3591/app-loading.2.diff [2] https://github.com/ptone/django/compare/master...app-loading Day 2 Yesterday I replaced all direct calls to the get_app, get_model, etc. functions by method calls on the app_cache object, in order to normalize the code base and make it more obvious when we’re relying on global state. I saw how pervasive our use of the app cache was, wept quietly and moved on. Today I created an AppConfig class. I gathered from past discussions that there was a consensus on this name. (“App” already means something else.) Then I refactored the app cache to store state in one AppConfig instance per application. I haven't introduced any changes in behavior — at least not knowingly. The code is too complicated for my tastes because Django allows using models from apps that aren’t in INSTALLED_APPS. I’ve known about this behavior for some time and I’m still wondering why we need it. I’d like to deprecate this possibility by raising a warning and then an exception when a model is imported from an app that isn’t in INSTALLED_APPS. But I’ll leave that for later in order to keep my branch backwards-compatible. I plan to continue to refactor code that uses the models module as a key. That means replacing all uses of app_cache.get_app(label), which returns a models module, by something that operates on an AppConfig instance. I will go as far as possible with 100% backwards-compatible refactoring before introducing changes. Day 3 Today I’ve introduced get_app_config() and get_app_configs() methods and refactored get_app() and get_apps() to use them. The first one was tricky because get_app() has grown some cruft over the years that doesn’t seem useful any more. I’ve written a detailed explanation in the commit message. I’ve then deprecated get_app_package(), get_app_path() and get_app_paths(). They were barely used. I’ve also simplified some parts of the app cache code. I broke the test suite countless times and it’s still broken right now. That’s good news, because it means that the existing tests go though many code paths in the app cache. I’m relying on that to validate my refactoring. Tomorrow I’ll make sure that the test suite passes after each commit. (I’m rewriting history heavily to keep the branch reviewable.) Then my next step will be to replace all uses of get_app() and get_apps() in Django and deprecate these two methods. All this aims at making the app cache code as tight as
Strange crash with ugettext_lazy when accent letter
Hi,
I want ask to this mailing list before open bug issue on code.django.
When use ugettext_lazy with accent like "â" some strange behaviour happens.
Exemple:
# -*- coding: utf-8 -*-
> from django.db import models
>
from django.utils.translation import ugettext_lazy as _
>
class MyModel(models.Model):
>
> name = models.CharField(_(u"name"), max_length=80)
> type = models.CharField(max_length=1,
> choices=(('a', '*â*'), ('b', 'b')),
> default='b')
>
With this code the form will not be render. No error or warning, form is
just not rendered. If 'â' is replaced by 'a', form is rendered correctly.
ugettext_lazy Should not report error or somethig ?
Thank's.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1db21371-e1b6-4426-83f7-b6ba7d2cb025%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Strange crash with ugettext_lazy when accent letter
On Mon, Dec 16, 2013 at 11:19 AM, Bastien Sevajol
wrote:
> Hi,
>
> I want ask to this mailing list before open bug issue on code.django.
> When use ugettext_lazy with accent like "â" some strange behaviour happens.
> Exemple:
>
>> # -*- coding: utf-8 -*-
>> from django.db import models
>>
>> from django.utils.translation import ugettext_lazy as _
>>
>> class MyModel(models.Model):
>>
>> name = models.CharField(_(u"name"), max_length=80)
>> type = models.CharField(max_length=1,
>> choices=(('a', 'â'), ('b', 'b')),
You aren't using ugettext_lazy with accent like "â" al all here.
--
Ramiro Morales
@ramiromorales
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAO7PdF_3eVehj64H6_9FmFMkkTS5d%2BecEhyk-45dCG2CkB-uLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Strange crash with ugettext_lazy when accent letter
please see your settings.py [1],
default_charset is utf-8?;
use_l10n is set true?
what is default content-type?
we have this issue when use pt-br chars like õ and ç but with correct setup
this has worked.
[1] https://docs.djangoproject.com/en/dev/ref/settings/
2013/12/16 Bastien Sevajol
> Hi,
>
> I want ask to this mailing list before open bug issue on code.django.
> When use ugettext_lazy with accent like "â" some strange behaviour
> happens. Exemple:
>
> # -*- coding: utf-8 -*-
>> from django.db import models
>>
> from django.utils.translation import ugettext_lazy as _
>>
> class MyModel(models.Model):
>>
>> name = models.CharField(_(u"name"), max_length=80)
>> type = models.CharField(max_length=1,
>> choices=(('a', '*â*'), ('b', 'b')),
>> default='b')
>>
>
> With this code the form will not be render. No error or warning, form is
> just not rendered. If 'â' is replaced by 'a', form is rendered correctly.
> ugettext_lazy Should not report error or somethig ?
>
> Thank's.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1db21371-e1b6-4426-83f7-b6ba7d2cb025%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAP9G-NJ_6U1vMnMKX7FMvZbv%2B%3DE_MOx1CrTgm3wRsBzP%2BY-p9g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
