Re: Do people actually squash migrations?

[Hanne Moa]

On Wed, 12 May 2021 at 18:40, 'Mike Lissner' via Django developers
(Contributions to Django itself) 
wrote:
> Oh, I guess there's also a step in the manual process to reset the migrations 
> table in the DB, but I don't know how to do that. Tricky stuff!

I've made a management command for that: resetmigrationhistory, which
nukes just the migrations of *my* apps. Then I run migrate --fake
manually afterwards.

I squash as part of any major release (semver). Rewrite them a lot by
hand to get rid of any datamigrations and have lots of extra
mini-releseas to make sure everything works etc.

There's https://github.com/kingbuzzman/django-squash, which I have
considered using, their "elidable" concept is very good.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrreMp%2Bp%3D0FLVwoExv%3D8FB03Yo5NQg5Y0Oz2ev12QTbSBCQ%40mail.gmail.com.

Re: Removal of USE_L10N setting

[Hanne Moa]

On Tue, 15 Jun 2021 at 12:25, Carlton Gibson  wrote:
> I have to say, I never once set `USE_L10N = False` — I don't imagine many
> people do, but my only concern would be whole swaths of folks that depend on
> this… — do such exist in numbers? 樂

I don't think I've ever set USE_L10N to True, and I've been using
Django in production since 0.96.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrrfeMzhjEg9bFUrgsCYtUKcecwV6TYLhcB_bGryAd%3DTR8g%40mail.gmail.com.

Re: Bug in migrations when testing on Django 3.2b1

[Hanne Moa]

*phew* old cruft indeed. I wasn't using the AppConfigs I *thought* I
was using so no wonder things were flaky.

It might for paranoia's sake be worth mentioning in the upgrade notes
for 3.2 that if you get NodeNotFoundError when running
migrations/database tests on 3.2 to double check the app configs, and
the best way to do that is probably running
"django.apps.apps.app_configs.items()", and compare what the version
you're upgrading from says and what 3.2 returns.


On Fri, 19 Mar 2021 at 08:42, Hanne Moa  wrote:
>
> Reverting didn't see to do anything but I'll spread around some breakpoints 
> in 3.1 and 3.2 and compare what happens.
>
> I have another project, on 3.0, that I'm testing with 3.2 with the exact same 
> naming scheme (except every app has a a label in their AppConfig, in the one 
> that fails, not all of them do) and this other project, everything migrates 
> just fine. The failing project started life before migrations existed so 
> there might be some not-upgraded cruft that is the cause.
>
> On Thu, 18 Mar 2021 at 15:45, Carlton Gibson  wrote:
>>
>> Looking at the history for the migrations code, the was 
>> https://github.com/django/django/commit/110001d0bbbabe2a5b57b14a59bd0e4b71bf2712#diff-e7df880bdc17c719e0332fa0cfbd4eff49bd481f638e34335a6311cfcd0ebc26
>>  recently which adjusted AppConfigStub, so maybe related.
>> (You could see if reverting that helps.)
>>
>> On Thursday, 18 March 2021 at 15:39:04 UTC+1 Carlton Gibson wrote:
>>>
>>> Hi.
>>>
>>> So, first off, thanks for testing!
>>>
>>> Initial thoughts:
>>>
>>> * We might need a bit more to be able to reproduce — are you able to narrow 
>>> down the problem?
>>> * "Which migration it is varies between runs" — that sounds fun
>>> * "Changing AppConfig.name..." — The AppConfig loading was reworked, it 
>>> could be that:  
>>> https://docs.djangoproject.com/en/dev/releases/3.2/#automatic-appconfig-discovery
>>>
>>> Can I ask you to get as close as you can to directions for a reproduce and 
>>> open a ticket on Trac?
>>> https://code.djangoproject.com/newticket
>>>
>>> If you can't get to a reproduce, it's still worth opening a ticket with as 
>>> much info as you can:
>>>   * Maybe someone is able to say "Oh, it's this"
>>>   * Provides info for anyone else hitting this.
>>>
>>> Thanks again!
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> On Thursday, 18 March 2021 at 15:26:23 UTC+1 HM wrote:
>>>>
>>>> Changing AppConfig.name to just "app" leads to ModuleNotFoundError: No
>>>> module named 'app'.
>>>>
>>>> Changing the path in INSTALLED_APPS to "prefix.app.apps.AppConfig"
>>>> instead leads to the same NodeNotFoundError as before.
>>>>
>>>> On Thu, 18 Mar 2021 at 15:06, Hanne Moa  wrote:
>>>> >
>>>> > I have some migrations that runs/tests fine on Django 3.0 and 3.1, but
>>>> > not on 3.2b1.
>>>> >
>>>> > There's a specific app whose migrations fail with:
>>>> >
>>>> > django.db.migrations.exceptions.NodeNotFoundError: Migration
>>>> > prefix_app.000N_fooFoo dependencies reference nonexistent parent node
>>>> > ('app', '000M_bar').
>>>> >
>>>> > Which migration it is varies between runs, and note that the first app
>>>> > label looks different than the second. Is there some new way to
>>>> > auto-generate app labels that leads to this?
>>>> >
>>>> > In INSTALLED_APPS the app in question is by path: "prefix.app". In the
>>>> > AppConfig, "name" is identical to the path, "prefix.app", while
>>>> > "label" is "prefix_app". The models do not have an explicit tablename
>>>> > set and in the database they have been created with
>>>> > "app_modelnameinlowercase", not "prefix_app_modelnameinlowercase".
>>>> >
>>>> >
>>>> > HM
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/4424f465-3643-4a39-ac9b-f52bacbe48a8n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrrdwtzQUeSLLCF1wFWYsUCORjK5%2BDzqXx5X-ixOZPM53zA%40mail.gmail.com.

Re: Bug in migrations when testing on Django 3.2b1

[Hanne Moa]

Reverting didn't see to do anything but I'll spread around some breakpoints
in 3.1 and 3.2 and compare what happens.

I have another project, on 3.0, that I'm testing with 3.2 with the exact
same naming scheme (except every app has a a label in their AppConfig, in
the one that fails, not all of them do) and this other project, everything
migrates just fine. The failing project started life before migrations
existed so there might be some not-upgraded cruft that is the cause.

On Thu, 18 Mar 2021 at 15:45, Carlton Gibson 
wrote:

> Looking at the history for the migrations code
> <https://github.com/django/django/commits/main/django/db/migrations>, the
> was
> https://github.com/django/django/commit/110001d0bbbabe2a5b57b14a59bd0e4b71bf2712#diff-e7df880bdc17c719e0332fa0cfbd4eff49bd481f638e34335a6311cfcd0ebc26
> recently which adjusted AppConfigStub, so maybe related.
> (You could see if reverting that helps.)
>
> On Thursday, 18 March 2021 at 15:39:04 UTC+1 Carlton Gibson wrote:
>
>> Hi.
>>
>> So, first off, thanks for testing!
>>
>> Initial thoughts:
>>
>> * We might need a bit more to be able to reproduce — are you able to
>> narrow down the problem?
>> * "Which migration it is varies between runs" — that sounds fun 
>> * "Changing AppConfig.name..." — The AppConfig loading was reworked, it
>> could be that:
>> https://docs.djangoproject.com/en/dev/releases/3.2/#automatic-appconfig-discovery
>>
>> Can I ask you to get as close as you can to directions for a reproduce
>> and open a ticket on Trac?
>> https://code.djangoproject.com/newticket
>>
>> If you can't get to a reproduce, it's still worth opening a ticket with
>> as much info as you can:
>>   * Maybe someone is able to say "Oh, it's this"
>>   * Provides info for anyone else hitting this.
>>
>> Thanks again!
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Thursday, 18 March 2021 at 15:26:23 UTC+1 HM wrote:
>>
>>> Changing AppConfig.name to just "app" leads to ModuleNotFoundError: No
>>> module named 'app'.
>>>
>>> Changing the path in INSTALLED_APPS to "prefix.app.apps.AppConfig"
>>> instead leads to the same NodeNotFoundError as before.
>>>
>>> On Thu, 18 Mar 2021 at 15:06, Hanne Moa  wrote:
>>> >
>>> > I have some migrations that runs/tests fine on Django 3.0 and 3.1, but
>>> > not on 3.2b1.
>>> >
>>> > There's a specific app whose migrations fail with:
>>> >
>>> > django.db.migrations.exceptions.NodeNotFoundError: Migration
>>> > prefix_app.000N_fooFoo dependencies reference nonexistent parent node
>>> > ('app', '000M_bar').
>>> >
>>> > Which migration it is varies between runs, and note that the first app
>>> > label looks different than the second. Is there some new way to
>>> > auto-generate app labels that leads to this?
>>> >
>>> > In INSTALLED_APPS the app in question is by path: "prefix.app". In the
>>> > AppConfig, "name" is identical to the path, "prefix.app", while
>>> > "label" is "prefix_app". The models do not have an explicit tablename
>>> > set and in the database they have been created with
>>> > "app_modelnameinlowercase", not "prefix_app_modelnameinlowercase".
>>> >
>>> >
>>> > HM
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4424f465-3643-4a39-ac9b-f52bacbe48a8n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/4424f465-3643-4a39-ac9b-f52bacbe48a8n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrrfKMjBQjzJfYNbUtTYaVtsBOGAeHxJRVgQFC19R%2BvS-rg%40mail.gmail.com.

Re: Bug in migrations when testing on Django 3.2b1

[Hanne Moa]

Changing AppConfig.name to just "app" leads to ModuleNotFoundError: No
module named 'app'.

Changing the path in INSTALLED_APPS to "prefix.app.apps.AppConfig"
instead leads to the same NodeNotFoundError as before.

On Thu, 18 Mar 2021 at 15:06, Hanne Moa  wrote:
>
> I have some migrations that runs/tests fine on Django 3.0 and 3.1, but
> not on 3.2b1.
>
> There's a specific app whose migrations fail with:
>
> django.db.migrations.exceptions.NodeNotFoundError: Migration
> prefix_app.000N_fooFoo dependencies reference nonexistent parent node
> ('app', '000M_bar').
>
> Which migration it is varies between runs, and note that the first app
> label looks different than the second. Is there some new way to
> auto-generate app labels that leads to this?
>
> In INSTALLED_APPS the app in question is by path: "prefix.app". In the
> AppConfig, "name" is identical to the path, "prefix.app", while
> "label" is "prefix_app". The models do not have an explicit tablename
> set and in the database they have been created with
> "app_modelnameinlowercase", not "prefix_app_modelnameinlowercase".
>
>
> HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3Drrf6gLTENCnoiUmuM7KAwBefbGD7Db4LU1ume2bbEODfWg%40mail.gmail.com.

Bug in migrations when testing on Django 3.2b1

[Hanne Moa]

I have some migrations that runs/tests fine on Django 3.0 and 3.1, but
not on 3.2b1.

There's a specific app whose migrations fail with:

django.db.migrations.exceptions.NodeNotFoundError: Migration
prefix_app.000N_fooFoo dependencies reference nonexistent parent node
('app', '000M_bar').

Which migration it is varies between runs, and note that the first app
label looks different than the second. Is there some new way to
auto-generate app labels that leads to this?

In INSTALLED_APPS the app in question is by path: "prefix.app". In the
AppConfig, "name" is identical to the path, "prefix.app", while
"label" is "prefix_app". The models do not have an explicit tablename
set and in the database they have been created with
"app_modelnameinlowercase", not "prefix_app_modelnameinlowercase".


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrreGyzuJ2wuJPsdcFA_yUckFKU%3DvQouAcm4k2F2GTK1r6g%40mail.gmail.com.

Re: Regression in Set-Cookie which affects Django users

[Hanne Moa]

django-cookie-samesite has a browser version guesser, because
different browsers interpret samesite differently.

The best solution I've heard of is setting two cookies with two
different names, one the old way and one the google way. Then check
for both where checking needs done, one of them being a fallback.

‪On Sun, 23 Aug 2020 at 03:41, ‫אורי‬‎  wrote:‬
>
>
>
> On Sat, Aug 22, 2020 at 10:07 PM Adam Johnson  wrote:
>>
>> (The workaround is in this comment: 
>> https://github.com/django/django/pull/11894#issuecomment-577681440 , and if 
>> you want, a package: https://github.com/jotes/django-cookies-samesite )
>
>
> Thank you. I was not aware of this package and middleware.
>
> אורי.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CABD5YeGTtzHQMrsB%3Dc%3DHBeymNxWFJc1En9vqj%3DF1HEtO5P0odA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrrdpXMcQUmHVF9hQgXtD-1pADQMO5WoyySBw3OB-p5Oqeg%40mail.gmail.com.

Re: [Feature Request] Having an middleware to be able to force authentication on views by default

[Hanne Moa]

The oldest code at https://djangosnippets.org that fixes this is from
2008 so I guess something like this have been considered trivial to
build yourself ever since then, and hence why it's never been added.
Here are some alternatives:

https://djangosnippets.org/search/?q=login+required

I've been using some variation on LoginRequiredMiddleware since 2008
myself, see:

https://gist.github.com/hmpf/0d8faf83e7c7d868126d7c60c8dd0b6a

Some way to open up urls by string is generally necessary for 3rd
party apps otherwise I wouldn't bother to have the PUBLIC_URLS
setting. API's often use a separate authentication mechanism, so best
exempt those too. Any officially supplied login views should mark
themselves as exempt so they don't pollute PUBLIC_URLS though.

Most of my Django sites have only cared about whether you are logged
in or not, then have an "owner" foreign key on models that can be
CRUDed by users. I much prefer roles to permissions since I used to do
a lot with Zope 2.

On Thu, 19 Mar 2020 at 14:25, Fabio Caritas Barrionuevo da Luz
 wrote:
>
>
> > I'm surprised nobody has mentioned django-stronghold in this discussion 
> > which does exactly what you're looking for.
>
> Same here. django-stronghold has been working well in my projects for me for 
> years.
>
> https://github.com/mgrouchy/django-stronghold
>
>
>
> Em quinta-feira, 19 de março de 2020 07:41:35 UTC-3, Matt Magin escreveu:
>>
>> Hi all,
>>
>> I'm surprised nobody has mentioned django-stronghold in this discussion 
>> which does exactly what you're looking for.
>>
>> It's implemented as a middleware, with two settings for exclusions -- A list 
>> of named url's or a list of regex's to match url's against.
>>
>> This works well, and managing the exclusions through settings is not a big 
>> deal. Having said that, I do like the idea of putting it inside the Auth 
>> middleware as well.
>>
>> +1 from me to put this into core functionality, I include django-stronghold 
>> in basically all my projects already.
>>
>> Cheers,
>> Matt
>>
>> On Thu, Mar 19, 2020 at 7:19 PM Mehmet Ince  wrote:
>>>
>>> Hi Alasdair,
>>>
>>> On 16 Mar 2020, at 12:59, Alasdair Nicol  wrote:
>>>
>>> Hi,
>>>
>>> Creating Django settings is often discouraged, so perhaps it would be 
>>> better to create a subclass of AuthenticationMiddleware instead of adding a 
>>> setting. Then users would update MIDDLEWARE to enable the new functionality.
>>>
>>>
>>> I see, that supports my initial idea. I was planning to have new middleware 
>>> but creating a subclass of AuthenticationMiddleware with a process_view 
>>> function is way better. People who want to enabled that feature can 
>>> directly replace AuthenticationMiddleware with our new middleware.
>>>
>>> To be honest, I’m kind a confused about how to proceed. Should I continue 
>>> with settings to control it or subclass of Auth middleware ?
>>>
>>> I really want to contribute to the Django thus I’m willing to send PR for 
>>> that feature, because it looks like newbie friendly in terms of 
>>> implementation, but I think I need a kind of confirmation from core devs.
>>>
>>>
>>> Cheers,
>>> Alasdair
>>>
>>> On Sunday, 15 March 2020 17:46:48 UTC, Mehmet Ince wrote:

 Hi Adam,

 Thanks for your comments. I was thinking to implemented this as a 
 separated middleware but, as you said, AuthenticationMiddleware is much 
 better place to do it.

 I already started to implementing this in AuthenticationMiddleware. I 
 would like to send a PR if it’s okay to everyone ?

 I’m not sure it’s okay to discuss this in mailing list but I need a help 
 about naming convention for following variables/class/function:

 - Variable name to control this in settings.py. ( FORCE_LOGIN_REQUIRED 
 maybe ? )
 - Mixing name for CBV and decorator name FBV  ( AnonymousUserMixin and 
 @anonymous_user ? )

 Thanks,
 M.

 On 15 Mar 2020, at 17:13, Adam Johnson  wrote:

 Hi Mehmet,

 I like your move to fail-closed here. I've certainly seen missing auth 
 decorators as a recurring issue in my career, and I do think as an OWASP 
 top ten we should try tackle it better in the framework.

 Your implementation is very few lines of code. It could be made more 
 robust, using the attribute approach that the CSRF middleware uses: 
 https://github.com/django/django/blob/7075d27b0c75f1431f29497f4353cd742906b357/django/middleware/csrf.py#L209
  . And it could easily be added to django.contrib.auth, and the default 
 project template. AuthenticationMiddleware doesn't in fact have a 
 process_view method at current, so we could even add it there with a 
 setting to control it.

 I doubt many would be against it as an optional extra.

 Thanks,

 Adam

 On Sun, 15 Mar 2020 at 06:36, Václav Řehák  wrote:
>
> Hi Tobias,
>
> Dne sobota 14. března 2020 9:44:16 UTC+1 Tobias Bengfort 

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Hanne Moa]

This depends on the collation that is used
. On a
system sorting everything as if it was Turkish, "ı" and "i" would be
considered two different letters, but I guess everywhere else they
would be merged into "i".

On Wed, 18 Dec 2019 at 14:09, Dirk Groten  wrote:
>
> I've been looking in more detail into this issue, as some other Django 
> packages are affected also by this issue. Now, when I run the tests that are 
> provided with this fix using SQLite, the issue does not occur, whereas it 
> does happen for PostgreSQL (I haven't tested for MySQL). Is it correct that 
> in Postgres, `User.objects.filter(email__iexact='mık...@example.org')` will 
> match a user with email "m...@example.org" but SQLite won't find a match? And 
> if so, why is that? Is it dependent on specific Postgres settings?
>
> On Wednesday, December 18, 2019 at 10:23:35 AM UTC+1, Mariusz Felisiak wrote:
>>
>> Details are available on the Django project weblog:
>>
>> https://www.djangoproject.com/weblog/2019/dec/18/security-releases/
>>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7ebbc544-c113-478b-9417-7f714fef783e%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3Drrco062GzUG_tavb1mVjtMJuh%3Dvth6%2Bi_UK6sAvmPPGZWg%40mail.gmail.com.

Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

On 12/11/18 8:38 PM, Josh Smeaton wrote:
Jamesie: please see "Why not Gitlab?" [0]. While it might be better from 
a technical standpoint, it would not be better than GH Issues from an 
onboarding perspective.


[0]https://www.python.org/dev/peps/pep-0581/#why-not-gitlab


Note that they didn't even attempt moving everything to Github.


--
HM

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56550a30-6b2d-3db6-0b35-0e6785e2af4d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

On 12/12/18 12:34 AM, Jamesie Pic wrote:

Thanks Josh, love your link, seems like it dates from 2017 during the
period when GitLab UI was redesigned. But GitLab is still emerging as
a standard tool no matter what.


I'm currently attempting to move some issues from github to gitlab. The 
rant still stands. I've only managed to move a complete set of issues 
*once*, from trac to Bitbucket. IIRC there was an export-script which 
output I then hand-edited, *and* all contributors had users on bitbucket.



--
HM

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/11c6f178-fb5f-5280-3757-c836d4882759%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

Whenever I've had to move from one issue-system to another, the main
pain point has always been issue/comment ownership[*]. This is because
many systems want a login-capable, verified user for every single
person that have ever made an issue or comment. If there is no 1-to-1
mapping, the issue/comment is often owned by the importing user, and
the username/email of the original contributor is mangled into the
issue/comment-text itself.

This looks so nice for an issue with 50+ different contributors when
wind up being owned by the same user. Robert explains to Robert that
Robert's patch won't work with Roberts latest PR because Robert pulled
the wrong commit that Robert made to update the dependencies that
Robert discovered needed to be updated because Robert found a security
flaw, with apologies to Robert. There's usually no way to search for
the actual contributors either. It is as if importing to such
issue-systems are an after thought. Starting out with a design where
user and contributor are two different but potentially linked objects
would have solved the problem *correctly*.


[*] There are no doubt problems other than this, it's just the one
that bugs me the most. Especially since the solution so often is "Drop
all history, start from scratch."

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrreeXWcVCjxZGG18GDeeh98P_OxresAm9w_JrN0HSOQNhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to extend support for object permission

[Hanne Moa]

How object permissions work in the admin is also a bit of an
undocumented surprise. You need 'change_*' on the model, not just on a
specific object in order to to be able to do just about anything at
all. 'delete_selected` cannot check for object permissions etc.

I just started using django-guardian and it's the first time ever (in
ten years) I've needed to write my own subclass of ModelAdmin. Its
get_queryset() checks for whether the user has access to an object
directly via an object permission, but it also calls an optional
method since I try to use as few object permission as possible. The
plan is that if you have access to, say, a bookcase, you have the same
access to all the books therein without being explicit about it, with
the usual caveat about lousy analogies being lousy.
On Thu, 8 Nov 2018 at 11:55, Tobias Bengfort  wrote:
>
> On 08/11/2018 11:43, Carlton Gibson wrote:
> > My only concern thus far is bringing out the change well enough in the
> > release notes and docs.
> > (Split between the two PRs I'm not sure it quite does that.)
>
> My impression is that authentication backends and object permissions
> have already been underdocumented before these changes. I would like to
> help improving the documentation in general. However, the content and
> structure of the documentation could be very different depending on
> which of my changes get accepted. So my idea was to rework the
> documentation afterwards.
>
> tobias
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/0dd42320-0761-ef5d-4877-9aba8b814134%40posteo.de.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3Drrc%2B47aKUQO29cNWo%2BNwDAKDXcNF8i976C2%3Dv7mYwS3X9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: django.py makemessages --add-location=full|file|never

[Hanne Moa]

Since no flag equals "full" and "--no-location" equals "never" maybe a
new flag "--file-location" for "file" instead of "--add-location" for
all three?

On 27 March 2017 at 23:55, Adam Johnson  wrote:
> I don't see any reason against adding it. If there isn't a ticket already,
> you can make one at https://code.djangoproject.com/ , then look at the
> extensive contributing guide.
>
> On 27 March 2017 at 19:26,  wrote:
>>
>> Hello there,
>>
>> Please let me know if it is a duplicate. I would like to propose the
>> support of `--add-location` of `xgettext` in Django makemessages, in order
>> to provide a fine-grain control of the metadata of .po files.
>>
>> At present, Django makemessages support `--no-location` to completely
>> suppress the `#: file:line` lines.
>>
>> Quote from https://www.gnu.org/software/gettext/manual/gettext.html:
>>
>>> ‘--add-location=type’
>>>
>>> Generate ‘#: filename:line’ lines (default).
>>>
>>> The optional type can be either ‘full’, ‘file’, or ‘never’. If it is not
>>> given or ‘full’, it generates the lines with both file name and line number.
>>> If it is ‘file’, the line number part is omitted. If it is ‘never’, it
>>> completely suppresses the lines (same as --no-location).
>>
>>
>>
>> After consulting the Git history of GNU gettext on Savannah, I found it
>> added in March 2014:
>>
>>
>>> commit 90c76fda268779b80c2fa969b8efddbb4aa5da1e
>>> Author: Daiki Ueno 
>>> Date:   Mon Mar 24 18:43:01 2014 +0900
>>>
>>> Extend --add-location option to suppress line number output
>>>
>>> The --add-location option of msgattrib, msgcat, msgcomm, msgconv,
>>> msgen, msgfilter, msggrep, msgmerge, msguniq, and xgettext
>>> commands now takes an optional argument 'never', 'full', or
>>> 'file', to control the format of "#: ..."  comments.
>>>
>>> The default catalog reader changed to always remember file
>>> positions so the line number part can be suppressed in output
>>> phase rather than input phase.
>>>
>>
>>
>> Why adding this: it will help a lot the version control of .po files. It
>> will exclude many noises that can simply be triggered by a line
>> addition/deletion. By keeping file names but not line numbers, this would be
>> a good compromise between developers who find this metadata noisy and
>> translators who may rely on this information.
>>
>> Please kindly comment. Thank you!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/f0405b21-aee9-415a-9772-296353678da6%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2evqjYeU_%3DMqRxTNjfqeOkS3sStdSVbBR6VxcEZ3k30w%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrreXQUkgYR9AO9NfZNg%2BL5VWyD7D0cT%2BhRGXoEFwbtzvBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[Hanne Moa]

Is there a way to ignore django.utils.dateformat? That code is very
straight forward, and it is not supposed to be called manually by humans. I
can't see how a "fix" would improve things. Munging the second string in
the getattr? Adding "upper" and "lower" or something similar to each
method-name?

On 31 August 2016 at 19:50, Ivan Sevastoyanov 
wrote:

>
> 
> I'm posting the the 11 criticals. In my opinion, they are not critical,
> they are just code smells. I will try to export the report so you can
> review the major issues by groups.
>
> Regards,
> Ivan
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrrfUwi5QQNqrDYB59fi47RjQ5gUYoHjZwiTuGDXBbnakEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

I've found a better way of getting the correct sequence name on postgres

[Hanne Moa]

We needed to switch a table from using one sequence to another as the
first stage in merging two tables, and discovered that django can't
pick up the new sequence-name. Actually, it's the postgres-function
that the backend uses that is at fault.

Fortunately I found a way to introspect for the sequence name that
works in many more cases than the current use of
pg_get_serial_sequence: looking up the default value of a column in
"information_schema.columns", column "column_default". See ticket
#27090, https://code.djangoproject.com/ticket/27090 for some code.

While I'm scratching my immediate itch by updating the forked
postgres-backend we have to use anyway, switching away from
pg_get_serial_sequence would make life much easier and with fewer
surprises for everyone.

I will make a minimalistic, forked backend as a package (as soon as I
understand the style.SQL-stuff) but I do think that not using
pg_get_serial_sequence would be a general improvement for Django 1.11.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3DrreHWKjPteti2uhbvCQUZgDJGF5VjdMfcQppvaK2RiY%3DcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Hanne Moa]

On 12 April 2016 at 05:35, Martin Owens  wrote:
> There is a difference between settings intended by developers to be used by
> other developers /../ And settings used by systems administrators to define
> the environment they are deployed to as well as any deployment specific
> controls.
>
> Django has always mixed the two into one file, and it causes problems. I've
> seen keys and passwords committed to github, extravagant json or os.env
> based solutions with piles of lines of messy code to what I see most which
> is a local_settings.py with a template version which is copied in at runtime
> with sane defaults.

I used to use extravagant json messes[*] but have (on non-PaaS)
switched to having a directory /etc/django-sites.d, which is on the
python path, containing one python package per site on that host:

/etc/django-sites.d/MyProjectConf/sitetype.py

MyProject.settings.sitetype is referenced by wsgi-scripts. It first
star-imports MyProject.settings.base, then star-imports
MyProjectConf.sitetype inside a try/except.

That way I can have have important overrides/option-merging for a
sitetype in version control, and still have
puppet/chef/ansible/whatever control deploy-and-site-specific options
without touching anything inside the source tree.

> I'd be happy to see a canonical decision made for django, but I'd focus on
> "who should be editing this setting" not just what it's for, if it's a
> secret or if it should be different or the same per instance.

A tag in the settings-docs would be a good start, or a check list of
more site dependent settings. Hey, the docs are restructured text; the
tag could generate an extra index, et voila :)


-- 
HM

[*] I *know* why json doesn't survive that spurious comma at the end
of a list/dict, but I like me that comma so much that I no longer use
json for hand-written config in new stuff.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3Drrd3GyFgpxkCJkNegnk62EmR1VzVvS5OToeV6Prns4qWeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Query on BooleanField with values other than True and False, bug or intentional?

[Hanne Moa]

I don't think enforcing it would be pythonic.

Once upon a time, Python lacked True and False, all you had were
truthy and falsey and maybe per-project/team constants:

http://python-history.blogspot.no/2013/11/story-of-none-true-false.html

I remember the arguments when bool() was added. Those against were
worried that it would send a signal that would lead to a slippery
slope where truthy and falsey would disappear because people would
insist that "it's pretty sloppy to not enforce an explicit boolean
value and can lead to subtle bugs".

Well..


On 31 January 2016 at 10:34, Adam Johnson  wrote:
> Just to play devil's advocate... you're all worrying about one simple case;
> there are infinite variants of it with subtle bugs, for example imagine the
> same situation but with Value:
>
> Whatever.object.filter(is_active=Value('false'))
>
> The ORM can't predict the type of a Value call - pretty much by definition,
> since it's a raw value passed to the database. So you might be able to fix
> BooleanField for a few cases, but you can't fix them all..
>
>
>
> On Friday, January 29, 2016 at 10:38:52 PM UTC, Chris Foresman wrote:
>>
>> Sorry, sbrandt noted the issue of subtle bugs, not Maxime.
>>
>>
>> On Friday, January 29, 2016 at 4:37:51 PM UTC-6, Chris Foresman wrote:
>>>
>>> I have to agree here; it's pretty sloppy to not enforce an explicit
>>> boolean value and can lead to subtle bugs. In addition to the one mentioned
>>> by Maxime, consider the case of a nullable boolean field:
>>>
>>> >>> bool(None)
>>> False
>>>
>>> Maybe that field has a better converter for possible values and
>>> explicitly allows `None`, but I think it would be fairly trivial to add a
>>> stricter check and pretty easy to fix code that's not backwards compatible
>>> with find/replace.
>>>
>>>
>>> On Friday, January 22, 2016 at 3:18:45 PM UTC-6, Maxime Lorant wrote:

 At least, the behaviour is predictable : it uses `bool(value)`. I
 believe it is not a bug but more a question about the input definition:
 should we allow non boolean value? I don't see any problem here accepting a
 string as a `True` value, it is the job of the user to ensure the value is
 castable to a boolean.

 The same behaviour is found on `IntegerField` for example:
 `Model.objects.filter(pk="foo")` raises `ValueError: invalid literal for
 int() with base 10: 'foo'` which implies the ORM tried to cast 'foo' as an
 integer.

 On Friday, January 22, 2016 at 8:51:41 PM UTC+1, Kaveh wrote:
>
> Today I discovered I can use strings and numbers to query on
> BooleanFields.
>
> Let's say we have the following model:
>
> class Whatever(models.Model):
> name = models.CharField(max_length=200)
> is_active = models.BooleanField()
>
> The following queries return all instances which their `is_active`
> field is True:
>
> Whatever.object.filter(is_active=True)
> Whatever.object.filter(is_active='some_random_text')
> Whatever.object.filter(is_active=777)
>
> and the followings return the ones which are False:
>
> Whatever.object.filter(is_active=False)
> Whatever.object.filter(is_active='')
> Whatever.object.filter(is_active=0)
>
> Is this behaviour intentional or is it a bug? Should queries on
> BooleanFields accept strings and numbers?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ec95ccb7-5ca0-410c-a52b-1ccf75f5d766%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3Drre6rRkdZWT7zjyiwfYvNxK2cXYEwHTvuVzy%3DREubO9g-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: improving debug logging in development

[Hanne Moa]

What about the yellow 500 error-page when in debug-mode? I'd like to have a
copy of the complete thing *somewhere* now that what's sent by email is
sanitized. Cloning a running system, turning DEBUG on and attempting to
trigger the same error isn't always easy. Is the 500-data loggable at all?

On 24 March 2015 at 03:18, Aron Griffis  wrote:

> On Mon, 2015-03-23 at 19:16 -0600, Carl Meyer wrote:
> > And it still seems to me that it's bad for Django's default config to
> > set `level: ERROR` and `propagate: False` on the django.request and
> > django.security loggers, as that prevents those logs from propagating to
> > higher-level handlers someone may want to install.
>
> My fix for this has been the following snippet in settings.py:
>
> # The DEFAULT_LOGGING dict is unhelpful and resides even with
> # disable_existing_loggers=True. This prevents propagation to the root
> # logger for loggers defined in DEFAULT_LOGGING.
> from django.utils.log import DEFAULT_LOGGING
> DEFAULT_LOGGING['loggers'] = {}
>
> -Aron
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" 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/1427163497.27346.3.camel%40arongriffis.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CACQ%3DrrdpDkRP_oO3OrE2rakvXbXpWw77Mewov%2B2nsRFg8WZ%3DjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: WSGI Regression 1.4 -> 1.5?

[Hanne Moa]

On 1 November 2013 14:22, Florian Apolloner  wrote:

First of all, using prefork and daemon mode is probably not the best choice
> you can make. I'd assume you are storing state in the process in your auth
> backend somehwere…
>

Prefork thanks to php, which is used to authenticate and set (with the help
of a 3rd party apache plugin) the user that RemoteUserBackend lookups up.
WSGIDaemonProcess because that's what Graham Dumpleton recommends and
because a dev-machine is running a zillion copies of several versions and
WSGIDaemonProcess is easier to deal with then in my experience. It's quite
the messy apache conf but It's only running the one wsgi script.

-- 
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/CACQ%3DrrfHTU8n1jhyygbk6Me18Oz_%3DgMnX%2BuvmbKYkuwtZXTKOA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

WSGI Regression 1.4 -> 1.5?

[Hanne Moa]

I have an auth-backend inheriting from model backend that works on 1.3.x
and 1.4.x but does not work on 1.5.x. The only difference between the
systems is the version of Django.

After much comparing and cursing and tearing of hair, it turns out what has
changed is how Django behaves under mod_wsgi with WSGIDaemonProcess under
Apache 2.2.22 prefork.

This works regardless:

WSGIDaemonProcess foo processes=1 threads=20 ...
WSGIDaemonProcess foo processes=1 threads=1 ...
WSGIDaemonProcess foo threads=1 ...
WSGIDaemonProcess foo ...

This no longer works with Django 1.5:

WSGIDaemonProcess foo processes=20 threads=20 ...
WSGIDaemonProcess foo processes=20 threads=1 ...
WSGIDaemonProcess foo processes=20 ...

The system is supposed to be running with
WSGIDaemonProcess foo processes=20 threads=20 ...

In sum: threading is ok, multiple processes is not. Furthermore, the
default RemoteUserBackend works, the one inheriting from ModelBackend does
not.

The problem seems to be that after successful authenticatiion and login,
the session (cookies) isn't changed, since after a redirect, request.user
is AnonymousUser.

According to http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading,
how processes/threads are set up affects how shared data (globals, like
module variables) are treated. I'm therefore wondering if somehing changed
in how Django's wsgi deals with globals, or if there is change in globals
usage in the auth backend system that will account for this.

Before I start making a publishable minimal version of the login backend
that still fails, I'd like to know:

1. Are other people seeing this?
2. Is this affecting other parts of Django than just auth backends?
3. What other things should I be looking for?

Should there be a warning in the docs at least, that "processes" with
WSGIDaemonProcess should be 1 or unset?


HM

-- 
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/CACQ%3DrrckZd-WNUcg9Vc1FWuPHCvqjuy8pNeyORxsCuo%3D01su9g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Design discussion: admin alert messages

[Hanne Moa]

Did you test the colors with a color-blind filter? Always a question to ask
when red and green is given significance in any way. The new error red is
better though, bigger contrast to the white.



On 7 October 2013 22:44, Ryan Allen  wrote:

> https://github.com/django/django/pull/1715
>
> Currently, all admin messages have a background color of light yellow,
> whether they are success message, warning message, or error message. Errors
> are displayed with red (#F00) text.
>
> This pull request would give success messages a green background and
> errors a light red with dark red border and text.
>
> Current alerts: http://imgur.com/a/dIO6O
> Updated alerts: http://imgur.com/a/fw54u
>
> --
> 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/2ab5f4ee-16df-4bf2-8d3e-893885d51f39%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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/CACQ%3DrrffHFa-58qenoM-5kryqYK0hDCM7Kcz0MK6fSTXU-OYbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Confusion around generic views queryset cloning.

[Hanne Moa]

On 22 July 2013 10:37, Loic Bistuer  wrote:

> I updated the PR to do away with the public `clone()` method.
>
> As long as we have a long-term goal for a `QuerySet.clone()` method, I'm
> happy.
>
> If we plan on changing the cloning behavior, now is effectively a bad time
> to introduce it.
>

No need to change existing ._clone()-behavior. Split what ._clone() does,
have ._clone() use all the new methods, .all() use the methods that it
needs, and .clone() only use the cloning bits. Or do the split and don't
add .clone() yet as it sems we're not quite in agreement. Anyway, plenty of
time to discuss before 1.7.


HM

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

Re: RFC: "universal" view decorators

[Hanne Moa]

On 3 June 2013 18:09,  wrote:

> # `DecoratorMixin`
>
> `DecoratorMixin` is a class factory that converts any view decorator into
> a class-based view mixin.
>
> Using it is easy and intuitive:
>
> LoginRequiredMixin = DecoratorMixin(login_required)
>

Now this, this feels pythonic. Bravo!  I'm so doing this in future
projects... (Though, class factories are spelled
lowercase_with_underscores, no? At least in Django. For instance
formset_factory().)

I've had a look at various LoginRequiredMixins out there (everybody makes
their own it seems, including me). It is quite common that it doesn't cover
all the things that login_required covers (like supporting the new way of
doing users in 1.5) so in the case of  LoginRequiredMixin, I think the
safest solution is to include a mixin in core anyway.


HM

-- 
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: Django's CVB - Roadmap?

[Hanne Moa]

On 1 June 2012 16:54, Jacob Kaplan-Moss  wrote:
> I think this might be a situation where we need some more feedback
> from the community and some more time to decide what the right move
> here is.
>
> So... what do *you* think?

I've used CBV's in one app so far, and have wound up only using View
and TemplateView. For the rest it seems better to make my own methods
to deal with forms etc. and not bother with any of the mixins. Even in
that app, when I redirect I use a functional style generic view. I
prefer my urlconfs to look like config, not code.

I had planned on rewriting functional views, but... no.

I think it is important to remember the difference between CBV and
*generic* CBV. It's the latter that doesn't seem to be working very
well.


HM

-- 
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: auth.user refactor: the profile aproach

[Hanne Moa]

On 3 April 2012 04:56, Alex Ogier  wrote:
> I get that Django's core is very accustomed to the relational database mode
> of thinking: "If a User might own a Twitter handle, then let's create a
> table of twitter handles in the twitter-auth app, and foreign key back to
> the default User model". It's really not that bad to go the other way for a
> moment, and say "If a User might own a Twitter handle, then let's add a
> twitter_handle field to Users."

What if the User owns more than one Twitter handle? I use six
different email-addresses regularly and several openids. The auth
backends I write use Foreign Key and not OneToOneKey back to User for
a reason.

> The reason being that the latter is *so much
> more flexible*. You can simulate the first with the second, but not vice
> versa. Twitter-auth might not need its own table (in fact, it shouldn't need
> its own table). If you really wanted to, you could make one, and foreign-key
> *from* the user model which gives you everything the first solution has,
> with no need to created magical .prof1, .prof2 proxy attributes. You could
> even let users sign in with multiple handles with a many-to-many. Heck,
> maybe your blog posts have their own twitter credentials, I don't know.

This would *only* be flexible with  a many-to-many. Then you wouldn't
have to ALTER TABLE to add an auth-backend.


HM

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

Making the EmailField RFC-compliant: proposals here!

[Hanne Moa]

As for instance per bug #17870, email-addresses can be as long as 254
bytes. Today, the length of the EmailField is less than that. If
django is to be RFC-compliant in this respect, we will need to come up
with a way to migrate existing email-fields to the new length.

1. Migration in general

No matter how we technically wind up doing that there ought to be a
standard "social" process for turning migrations on and off, so that
the time and date for the migration can be chosen by devops. Python
itself has the slightly magic module named __future__. In the spirit
of this I propose *one* setting for turning migrations on and off, the
actual name is not very important.

Using EmailField as en example:

MIGRATION_OPTIONS = ('rfc_email_addresses',)

MIGRATION_OPTIONS is by default empty. Setting it, and running a
single command, say "python manage.py migrate" runs whatever technical
means to do the migration. There should probably be a list kept
somewhere over which migrations have already been run, for
efficiency's sake if nothing else. The migrate-command does all that
can be done automatically without user intervention, and documents
anything that may or must be done manually.

The migrate-command only cares about keys it knows about, in this case
"rfc_email_addresses", and ignores anything else in the iterable. No
need to change the settings after the migration is done, and it serves
as a documentation of what migrations have already been done :)

If we can get this in for 1.5, people can migrate email-addresses in
1.5, and the migrate-command would forget about "rfc_email_addresses"
one version after the new email-fields became mandatory.

2. Migration in this specific case

Let's just do it. Let's not wait for a generic migration tool! I'd
rather the energy was spent on the app-refactor *now*, and fixing the
email-fields *now*, which would remove some of the pressure on fixing
the Identity/Authentication/Authorization architecture.

Go through all models in all apps, discover the email-fields, and run
an ALTER TABLE  ALTER COLUMN  TYPE varchar(254)
on each, and if that is not supported, add a column, copy old to new,
drop the old column.


HM

-- 
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: auth.User refactor: reboot

[Hanne Moa]

On 21 March 2012 09:40, Ian Lewis  wrote:
> To my mind it's the least important of the tenets of the design of
> newauth, but I personally would like to use it at least for admin
> users and normal site users. The issue for me is that the
> functionality required of users of the admin will be different from
> users of the site itself.

You don't need several user models if you have several user profiles
*per user*. With a minimal User-model (the absolute minimum is one
having only a primary key) with several user profiles (onetoone keys
to the primary key on the minimal User-model) you can still get
completely rid of users in all of their roles by nuking the entry in
the User-table and have it cascade down. If the admin-role of a user
is disconnected from the normal user role,  you'd need to manually
delete twice in two different models. Read: error-prone!

The triangle has *three* corners. Identity, Authentication,
Authorization. If any two corners are combined, yes, even if Identity
and Authentication is combined,  there *will* sooner or later be
trouble. "username" part of the Authentication-process need not be
combined with what the user sees (if anything) in a "Hello, ,
you are now logged in".message. That's what a displayname is for.
Django.admin would need to ship with an AdminProfile-model. The
auth-backends could authenticate towards a specific AuthProfile then,
splitting identity from authentication.

I am against someuser.get_profile(). If magic is needed at all there
could be a list, someuser.profiles, of all the models that have a
onetoonekey to someuser. Then it is still easy to build up a single
profile page for all the user-info if needed: just iterate over
someuser.profiles.

It might still be necessary to define the *format* of the primary key
itself of course, be it an int, a string of a fixed length or
interpretetive dance. But the format of that field should be entirely
invisible to the apps!


HM

-- 
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: Request for review / Multiple time zone support for datetime representation

[Hanne Moa]

On 18 November 2011 16:57, Anssi Kääriäinen  wrote:
> My point is that it would be very useful to know you are actually
> using aware datetimes internally. Especially when migrating an old
> project to use this feature, it is easy to miss some places that do
> not use aware datetimes. And you might find it out when you hit an
> hour where suddenly your webapp is failing all over the place. So the
> setting I proposed would report usage of naive datetimes all the year,
> so that you could spot the problems in testing, not in production.

Tying it to the DEBUG-option should be enough. If DEBUG is on, snitch
on naive date times. If locale is on you can give a warning when in
the danger zone, just before or after the DST-changeover.


HM

-- 
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: Localization on User model

[Hanne Moa]

On 10 November 2011 18:53, hcarvalhoalves  wrote:
> I believe the solution is to actually figure a migration path to move
> everything that is non-essential to outside the User model. To
> identify a User, it should be enough to have username, password and
> permissions, and have the rest of the fields live in a
> django.contrib.auth.models.DefaultUserProfile.

Why do you want the password in the User-model? There are more ways of
authenticating than user/password. There's openid, oauth, facebook,
saml, cas, pam... One to one relationships *is* a well-known and
respectable technique you know?

I might have mentioned before that the only field that we can't do
without in a User-model is the primary key. Everything else, even
username, is up for grabs.


HM

-- 
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: Cleaning up manage.py and import paths

[Hanne Moa]

On 11 October 2011 02:06, Luke Plant  wrote:
> On 10/10/11 23:05, Carl Meyer wrote:
>
>> Unless there are significant objections, I'd like to commit this in the
>> next few days and get it into 1.4. I'll also modify the patch on #16360
>> to take advantage of the new layout; hopefully that can get into 1.4 as
>> well.

I already do it this way except the manage.py is vanilla.

project-package/
project.wsgi
requirements.txt
setup.py
.git
bin/   # virtualenv
...
project/
__init__.py
manage.py
settings.py
urls.py
...

HM

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

Django and the new EU anti-cookie law

[Hanne Moa]

"From 26th May 2011 websites in the UK need to ask for permission
before they can set cookies not required for ‘essential’ means"

http://blog.silktide.com/2011/05/cookie-law-makes-most-uk-websites-illegal-what-you-need-to-know/

What cookies in Django are "essential"? When not logged in I see that
the csrf-token cookie is set, and when logged in there's the
session-cookie. Should one strive only to use csrf-protection (and
thus the cookie) only when it is needed? Are there other cookies set
by contrib apps? Should there be something about this in the docs?
" cookies is essential, you need need to get consent for these
other ones: "


yet-another-proof-that-politics-and-tech-don't-mix-ly yours,

HM

-- 
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: Test optimizations (2-5x as fast)

[Hanne Moa]

On 18 May 2011 01:46, Erik Rose  wrote:
>> Is there a sensible to way "copy" databases in SQL?
>
> SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a table. 
> It's supported in MySQL at least. You could then do a bunch of INSERT INTO 
> ... SELECTs if you deferred foreign key checks first.

Sometimes, in order to rescue data from an overfull table (because the
cleanup-job had died and a DELETE would take too long) I've done the
following:

- start transcation
- rename bad table
- receate the table (CREATE TABLE x LIKE would work)
-  INSERT INTO ... SELECT good data into the recreated table from the
renamed table
- drop renamed table
- end transaction

This works even when the system is up and running, on production servers.


HM

-- 
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: countries model or list like settings.LANGUAGES

[Hanne Moa]

On 1 May 2011 15:33, Mateusz Harasymczuk  wrote:
> I have to agree with this guy:
> http://code.djangoproject.com/ticket/5446

There are two competing third-party solutions to a country-field out
there, both helpfully named django-countries:

1) http://code.google.com/p/django-countries/
2) https://bitbucket.org/smileychris/django-countries/

No. #1 uses a country model, a foreign-key to this model is then a
"country"-field. No. #2 has the countries in a tuple and a proper
CountryField. The former is the first hit on google and it is easy to
change the list of countries, in the latter you need one fewer JOIN.
The latter is also more used, and is the only one on pypi and
djangopackages.

The keys of the  model used in #1 is compatible with the values of #2
but of course the allowed values differ.

We could just pick one of these.


HM

-- 
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: Upgrading from 1.2 to 1.3: Is there a guide?

[Hanne Moa]

On 23 March 2011 14:26, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> On Wed, Mar 23, 2011 at 9:02 PM, Hanne Moa <hanne@gmail.com> wrote:
>> Remembering the pain of going from 1.1 to 1.2 (csrf-token), is there
>> or will there be a guide/one-stop-shop for upgrading from 1.2 to 1.3?
>
> You mean -- other than the release notes [1]?

Hm, banner-blindness maybe, I've never noticed the "The Django
open-source project"-section of the main documentation-page before,
had to find it by googling :)

> If you cast your mind back, upgrading from 1.1 to 1.2 wasn't a problem
> -- *unless* you opted into new features like CSRF. The new CSRF
> handling wasn't turned on by default as the result of an update.

I always port to the new stuff as soon as possible due to
deprecation-paranoia - when it is deprecated and I *must* upgrade,
will the docs and hints and tips about it still be around? Yeah,
django is serious about docs, but other projects aren't, and it is
effort-saving to treat all projects the same, so...


HM

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

Upgrading from 1.2 to 1.3: Is there a guide?

[Hanne Moa]

Remembering the pain of going from 1.1 to 1.2 (csrf-token), is there
or will there be a guide/one-stop-shop for upgrading from 1.2 to 1.3?
That is: are there other big changes than generic view functions to
generic view classes and could there be an official/canonical  page
listing these?


argh-is-there-a--in-that-ancient-template-too-ly yours,
HM

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

Postgres sequence names (I've reopened #8901)

[Hanne Moa]

The fix in #8901 partially fixes #1946, making it easier to use django
with some egacy postgres databases. It does not however aid in the use
of legacy databases that uses postgres' own inheritance as
pg_get_serial_sequence() doesn't work on these. Until postgres gets
its act together :) we can add a function to postgres itself that
looks up the sequence names in more cases than what
pg_get_serial_sequence() can handle.

Since this might be the first time this particular type of solution
has been suggested the core devs need to have a think about whether it
is at all desirable.


HM

-- 
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: Allow slug to be prepopulated on edit

[Hanne Moa]

On 25 October 2010 15:19, rebus_  wrote:
> IMHO, proper implementation in cases where slug is used in URI should at 
> least:
>
>  * remember the old slug for the object
>  * return HTTP 301 [1] when the URI with the old slug is requested and
>   have Location field set to a URI with a new slug

Sounds like a job for the database to me, a Redirect-model or
somesuch. Lookup old url/slug, receive new url/slug.


HM

-- 
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: AutoFields, legacy databases and non-standard sequence names.

[Hanne Moa]

On 7 October 2010 19:14, akaariai  wrote:
> Django doesn't expect the sequence name to be tablename_columname_seq,
> at least not in trunk. The last_insert_id method in backends/
> postgresql/operations.py uses select
> currval(pg_get_serial_sequence(tablename, columname)).
> pg_get_serial_sequence will return the correct sequence only if the
> sequence is owned by the tablename, columname combination. If you
> happen to have just one table per sequence, then issuing
> ALTER SEQUENCE sequencename OWNED BY tablename.columname;
> should fix the problem.

You can't necessarily do this with a legacy database, as other systems
also using that database expect the existing names.

I need to use my own backend because of posgresql's own
table-inheritance. Most tables in the db inherit from the same table
and inherits its primary key and the sequence for that primary key.
Then there are a few tables that inherits from a table that inherits
from the grandfather table that defines the primary key and its
sequence. So, I need to recursively discover the oldest ancestor of
each table and use the sequence of that ancestor.


HM

-- 
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: AutoFields, legacy databases and non-standard sequence names.

[Hanne Moa]

On 6 October 2010 04:02, Tom Eastman  wrote:
> I'm using Django to create an interface for a legacy PostgresQL database.
>  The primary keys for my tables use sequences that aren't named the way
> django expects them to be (i.e. '__seq'), this means I can't
> call them AutoFields.
>
>> http://code.djangoproject.com/ticket/1946

I still use my custom backend that recursively looks up a
sequence-name, which means I have to be extra-careful on every new
django-version since I need to upgrade that backend myself. With 1.2
at least I don't need to mess with django's own directories anymore.


HM

-- 
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: #6735 -- Class based generic views: call for comment

[Hanne Moa]

On 1 October 2010 07:26, Russell Keith-Magee  wrote:
> I already have one specific piece of API feedback: the current
> implementation requires that all view logic is contained in GET(),
> POST() etc style views. This is fine, except for the fact that there
> are occasions where GET and POST share a lot of common logic.

This! is! Python! Any shared logic can be in another method, or
function for that matter, and need not be canonicalized in an API. All
that would be needed is an example in the docs:

class TheView(views.ClassView):

def _common(self, bla):
# set up models, forms, other preprocessing here
# return models/forms or set them on class
# could be run from __init__  or __new__ or whatever we wind up with

def GET(self, bla):
self._common(bla)

def POST(self, bla):
self._common(bla)

(Indent-dots to make surer that gmail doesn't meddle with the text.)

Surely class-based views shouldn't disallow methods not named nor
given meaning in an API? Since you needed to explicitly wish for a
specific method, that's how it can be interpreted.


HM

-- 
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: #12012 Logging: request for comments

[Hanne Moa]

On 27 September 2010 17:16, Luke Plant <l.plant...@cantab.net> wrote:
> Anyway, this seems good to me, and I can't think of a better place.  For
> the probably rare case of putting logging calls in your settings.py
> (like Hanne Moa does), there is nothing to stop you setting up logging
> yourself inside settings.py, which Hanne must presumably do already.
> The only problem is that logging could be set up twice.  For this case,
> I guess we could support some convention like 'LOGGING_CONFIG = None' to
> stop Django configuring logging altogether and add a note in the docs.
> This might also be useful for the command line app situation.

This might be useful for switching over to the official logging
system, easily turning it on and off.

I've been using the logging system since before it was added to
python. There used to be problems with it hiding some exceptions but
that was in some hideously complex threads, multicast and
ldap-disaster, so it might have been something else hiding those
exceptions. I haven't seen any such in the duct tape-and-chewing gum
setup I use in my django projects right now.

If anyone is looking for inspiration: most modules longer than twenty
lines starts with

import logging
_LOG = logging.getLogger(__name__)
_LOG.info(__name__)

.. so I know that they imported correctly on the production-server.

I've also on occasion used decorators to log state on entry and exit
of views and functions, in addition to liberal sprinkling through code
that really ought to be refactored. I even add it to django itself in
order to understand what's going on.


HM

-- 
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: #12012 Logging: request for comments

[Hanne Moa]

On 25 September 2010 08:16, Russell Keith-Magee  wrote:
> At this point, I'm calling for feedback, particularly on the following:
>
>  * logging config as the last stage of settings loading. Is this the
> right place? Can anyone think of a better place?

Well naturally you can't log what happens in the settings-file itself
:) I currently import logging at the end of settings.py but just
before importing local settings files, so that I can log the specifics
of the local settings.


HM

-- 
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: proposal for lazy foreignkeys

[Hanne Moa]

On 25 September 2010 19:47, Carl Meyer  wrote:
> 1. Reusable apps overuse GenericForeignKey. GFKs are inefficient and
> smell bad.

I seem to gradually be going away from GenericForeignKey and using
"Glue"-models instead. App1, model1, is connected to App2, model2 via
App3, Glue-model3, which has foreign-keys to model1 and model2, and
sometimes a little extra. App1 and App2 need not know about eachother
at all that way.

I'm considering making my own tagging-module this way, as tags *is*
one of the reusable apps that is useful to connect to more than one
model in a project. Ditto for comments.


HM

-- 
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: Possible bug discovered

[Hanne Moa]

On 19 September 2010 09:08, Yo-Yo Ma  wrote:
>  File "C:\Python26\Lib\site-packages\django-trunk\django\template
> \__init__.py", line 352, in add_library
>    self.tags.update(lib.tags)
>
> AttributeError: 'NoneType' object has no attribute 'tags'

Check for import loops. I've seen these often. Try peppering the code
with "assert False", check especially whether functions can see
variables outside its own scope, e.g: imports on module level, or must
you import in the inner scope of the function/method to make a name
visible?

Check also that you don't have a namespace collision, that is: a
django app has the same name as something non-django in you
python-path and you import the wrong module.


HM

-- 
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: Datetimes with timezones for mysql

[Hanne Moa]

On 17 August 2010 05:24, Russell Keith-Magee  wrote:
> On Tue, Aug 17, 2010 at 12:13 AM, Vitaly Babiy  wrote:
>> I been doing a lot with timezone aware dates and I noticed that the mysql
>> store will not allow you to store a datetime aware datetime.
>
> Adding timezone sensitivity to Django's time/datetime fields is
> something that has been on the project to-do list for almost as long
> as I've been associated with the project (coming up on 5 years). If
> you're interested in tackling this problem, here's a couple of things
> to keep in mind:
>
>  * Backwards compatibility. Suddenly introducing a 'convert to local
> timezone' behavior (or similar) will break any existing install.
>  * The interaction between application timezone and database server timezone.
>  * MySQL. Postgres supports timezones in date fields. MySQL doesn't.
> We need to have a solid answer for how this feature will work on
> databases that don't support timezone handling.

As I see it there's two possible usage scenarios of date(time)s.

1. Those who don't need to care about timezones at all, for instance
because no dates are ever shown or shared, or all data will be from a
single timezone that doesn't utilise daylight savings time, or
accuracy better than two hours each way is not needed. This is
unfortunately what Python's datetime-module were designed for.
2. Everybody else.

1 is already solved today. There's more than one way to solve 2.

a) Convert to a single timezone on save (typically UTC but need not
be), and convert to a local timezone when showing. The question then
is whether it is relevant to save the timezone of the original
datetime. This might leak the location of where the input originated.
I currently store everything as UTC and throw away timezone info.
b) Store timezone directly, convert to local timezone when showing.
Then your dates are only as good as your locale-database since
daylight savings start/end tends to be changed by whoever has
political power at the moment.
c) 


HM

-- 
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: Make "required=True" on forms.fields.NullBooleanField do something useful?

[Hanne Moa]

On 17 June 2010 13:01, Matt Hoskins  wrote:
> For the reasons I gave in my explanation above - which bit isn't
> clear?

Why not reuse the NullBoolean widget with a Boolean field?


HM

-- 
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: EmailMessage mangles body text

[Hanne Moa]

On 28 April 2010 16:13, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> On Apr 28, 1:11 pm, Hanne Moa <hanne@gmail.com> wrote:
>> the-real-solution-is-to-ditch-SMTP-ly yours,
>> HM, postmaster
>
> And your suggestion for a replacement would be ... what?

I would say it doesn't exist yet. Though, instant messaging is now so
common that *that* might take over, at least jabber can send to
offline users. Kids these days don't know what email is anyway, they
use SMS :/ (Yes, it leads to problems when they get employed.)


HM

-- 
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: EmailMessage mangles body text

[Hanne Moa]

On 28 April 2010 03:38, Leo  wrote:
> This is a fun one.

A bit like finding fossils, methinks.

> The message that appears on the other end has this in the body:
>
> >From puppies
>
> A From at the beginning of any lines in the body gets a > prepended to
> it.

The reason this exists at all is of course because once upon a time,
email was stored on disk in the mbox format, several messages per
file, and a new message started with 'From ' at the start of the line
meaning that 'From ' as the start of the line in message contents
therefore had to be escaped somehow. Just to be safe, many
mail-systems still do so even if they no longer use mbox. This problem
*will* sooner or later bite anyone who touches an email system, it is
as inevitable as earthquakes.


the-real-solution-is-to-ditch-SMTP-ly yours,
HM, postmaster

-- 
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: Templates by app

[Hanne Moa]

On 20 March 2010 12:48,   wrote:
> You can use both schemes.

Defaults in app/templates, overrides of defaults in project/templates.


HM

-- 
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: contrib.Auth

[Hanne Moa]

On 10 February 2010 23:33, Sayane  wrote:
> I think that an easy way to define your own user model is better idea. Auth
> app should be more generic. It should define a protocol for user, group and
> permission objects /../

Why should permissions and groups be in the same app as the user? Less
reusable that way. Identity is different from authentication is
different from authorization.

Premature optimization or not, as it is today on many sites the
user-table is hit extremely frequently. I'm not sure it is wise to
have layer upon layer between the user in the db and the zillion
things that has a foreign key to it.


HM

-- 
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: contrib.Auth

[Hanne Moa]

On 9 February 2010 09:09, Harro  wrote:
> - Make email unique and username non-required on the model. That would
> make implementing something that authenticated by email a lot
> easier :)

Pff, move emails out entirely. Email-addresses may change. Usernames
shouldn't change. One may have more than one email-address.

Maybe the time is right to make that branch now...


HM

-- 
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: Porting Django to Python 3

[Hanne Moa]

2010/1/13 Tobias McNulty :
> I am by no means an expert on the matter, but I remember seeing a comment
> awhile back suggesting that it generally makes more sense to fix the 2to3
> script than to maintain two branches of the same library. Might that be the
> case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.


HM
-- 
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: Possible contrib.humanize addition

[Hanne Moa]

2010/1/6 sago :
>> If you present some research to
>> demonstrate how this tag could/would work for non-English languages,
>> it would be a lot more compelling.
>
> That's not going to work, in any meaningful sense. That peculiarity of
> the article is highly English-specific. The generalization would
> surely be something like
>
> {% if /some-regex/.matches(word) %}{{ form1 }} {{ word }}{% else %}
> {{ form2 }} {{ word }}{% endif %}

Disclaimer: I have a masters degree in Computational Linguistics. Ths
is a simplified account of  "last year of bachelor"-stuff:

Human language cannot (mathematically proven) be modelled by a mere
regexp, as human language is not only context-free, (needing a full
parser) but context-sensitive (needing parsers we don't really have
yet). Nice, yes?

It cannot go in humanize but it could go in localflavor for English.
It would be necessary with a stemmer and a replaceable wordlist
though, as what words get "an" and what get "a" not only depends on
country but also on specific publishing styles - and all of this has a
tendency to change over time.


HM
-- 
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: Add querystring helper methods to Page class

[Hanne Moa]

2009/12/22 Ben Spaulding :
> I have created a patch that would allow for something much simpler, like so:
>
> Next page

This is what I do in my own homemade paginators. It works well.

> Though there has been much talk of creating template tags which would
> produce all-out pagination bars, I believe this particular
> functionality should be an actual method on the page object for two
> reasons:
>
>  1. This is basic functionality whose end result is hard to dispute
> (as opposed to a full pagination bar where markup and features could
> be disputed eternally),

Actual full pagination-bars could be shipped around as templates,
whether to be used in inclusion-tags or included directly. No need to
lock ourselves to the one, true pagination-style.


HM

--

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: auth.User: a new approach

[Hanne Moa]

On Tue, Oct 20, 2009 at 16:18, Russell Keith-Magee
<freakboy3...@gmail.com> wrote:
>
> On Mon, Oct 19, 2009 at 11:52 PM, Hanne Moa <hanne@gmail.com> wrote:
>>
>> It doesn't look like Contrib-06, covering ticket #3011, Allow for
>> extendable user module, will be in for 1.2. This is
>> my pony for *2.0*:
>
> I completely agree that we need to do something about #3011. /../
> However, the time has really past for big ticket discussions for v1.2,
> and it certainly isn't the time to talk about ponies for v2.0.

Saying it's for 2.0 makes it possible to ignore backwards compatibility...

> I don't want to dampen your enthusiasm here /../ I just want to point out that
> now isn't the best time to start an abstract discussion about big
> changes.

I had to post the idea now in order to not forget it, though. It's
been simmering for months. This way it's just a google-search away.

> One of the big problems that needs to be solved that you haven't
> addressed is the migration path. Obviously, we can't just replace the
> current auth.User model - we need to have a migration plan for all
> existing users of contrib.auth.

auth.User as an "auth-profile" on the MinimalUser, then it could start
out looking exactly as today except having its primary key be a
foreign key. Then we could make some of the other fields on auth.User
fetch its data from minimalUser.

The tricky part IMO is getting 3rd parties to use the MinimalUser so I
foresee the big job as to rewrite tons of examples, tutorials, howtos.
Pushing it, basically. Oh and there should be screencasts, I love
those.

> I have some ideas on how this could be done, but I'd be interested
> in hearing what others come up with. There are also complications
> with integrating with admin that need to be worked through.

Sometimes it seems babying the admin is keeping us from doing a lot of
cool stuff. I couldn't use the admin at all in my very first django
project (legacy database + cranky DBA), so I guess I never grew used
to having it available.

> So, if you want to play around with ideas in this space, I encourage
> you to do so. Having a working implementation of an alternative auth
> module would be a good starting point for discussions when we make the
> call for proposals for v1.3.

NP, I'll make a branch to play with, have been looking for a good
excuse to learn git or mercurial better anyway :)

> If you need feedback on a design issue you confront, django-developers
> is still the right place to ask. However, I want to moderate your
> expectations regarding the level of intense design discussion that the
> core will be able to engage in while simultaneously working on v1.2.

What, you mean "no feedback whatsoever" is *not* the normal state of
affairs in all things in life? =)


HM

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

auth.User: a new approach

[Hanne Moa]

It doesn't look like Contrib-06, covering ticket #3011, Allow for
extendable user module, will be in for 1.2. So: let's think afresh,
start from scratch, think about what we really, really want. This is
my pony for *2.0*:

The underlying problem of today's auth.User is IMO that it conflates
two things: authentication and a hook for authorization/ownership.

For the former, there are a zillion and growing ways to authenticate:
OpenID, OpenAuth, Federated with Shibboleth or SAML, YubiKey, good old
HTTP-password straight on the server (RemoteBackend), local user and
password (Backend), etc, etc. etc. They can't all be smudged together
in a single table, so let's decouple things.

The absolutely minimum User-model looks like this:

class MinimalUser(models.Model):
   pass

There's nothing wrong with your eyes. That's a model containing just a
primary key. Authentication-specific models could then be:

class SomeAuthUser(models.Model):
user = models.OneToOneField(MinimalUser)
... auth-specific fields

All other models that have been edited by/owned by someone is as usual:

class MyBlogEntry(models.Model):
edited_by = models.ForeignKey(MinimalUser)
... other fields

We already have a way of specifying a default profile, that's where
we'd put first name, last name, favorite pet, whatever. Since neither
first_name nor last_name is mandated anywhere, even Madonna and Prince
can use the site, with no hacks.

You might think that we *must* have a username in MinimalUser. But
what a username looks like is frequently determined by the
authentication-method, we can't validate for that in MinimalUser. A
minimal username would wind up being a CharField(max_length=255). One
user can also have several usernames, depending on the
authentication-method used. What *would* be useful in the MinimalUser
is a "display name", the user's preferred name/pseudonym to be shown
to others, in full glorious high-plane unicode if needed.

As for an email-address: "You want my email-address? Which one? I log
in with openid and you want my email-address? But I'm already verified
by the provider?! Is that *really* why you want my email-address? Ah,
I thought so, you're harvesting good addys. No thanks, I'll use this
other site instead." If you do need email-addresses, do as in
django-email-confirmation: allow more than one. Decouple. Don't put it
directly on the user. Don't make the user depend solely on an
email-address: what happens if the user switches from, say, gmail, to
hot-mailer-of-the-day.com?

Date-joined might be useful:

class BasicUser(models.Model):
date_joined = models.DateTimeField(default=datetime.now)

but last-login might be better coupled with which
auth-backend/username was used, as a many2many relation:

class BasicUser(models.Model):
display_name = models.CharField(max_length=32)
date_joined = models.DateTimeField(default=datetime.now)
sightings = models.ManyToManyField(Sightings, ...)

@property
def last_seen(self):
# fetch last username/backend-combo from Sightings here

@property
def most_recent_username(self):
# fetch last username/backend-combo from Sightings here


This all assumes that there is more than one way to log in. But guess
what, that's what I'm increasingly seeing: log in with
yahoo/openid/facebook/whatever. Monoliths like django-socialauth is
not the solution (how do you add yet another login-method?)  but it
certainly underlines the problem.

Let a thousand flowers bloom. Think. What do we really want. What do
we really need?


HM

--~--~-~--~~~---~--~~
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: Are threading.local objects evil? (was Re: shortcut proposal)

[Hanne Moa]

On Fri, Oct 16, 2009 at 23:30, Michael P. Jung  wrote:
> Cal Henderson in the Keynote "Why I Hate Django" pointed out in a very
> funny way that most projects never get THAT big that you need multi db
> support, partitioning, extensive database clusters, etc. Just skip to
> 19:20 to see his "scientific graph".

Multi-db will make working with legacy-systems much easier. Not
systems that are partioned for scalability but due to for instance
separation of concerns; different tables in each db, with different
use cases, but that needs to be presented as a whole now and then.

I've got systems here that use more than one database-backend...

"Scalability" isn't all.


HM

--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[Hanne Moa]

On Tue, Oct 13, 2009 at 14:22, Tobias McNulty <tob...@caktusgroup.com> wrote:
> On Tue, Oct 13, 2009 at 3:53 AM, Hanne Moa <hanne@gmail.com> wrote:
>> In fact, it would be very useful to both log and add a message at the
>> same time, iff there is an error. So that shouldn't deliberately be
>> made hard to do but maybe suitable for a lazy man's shortcut: one call
>> that does both.
>
> That is binding together two technologies that are still fairly
> conceptual in terms of their integration with Django at this point.
>
> I'm a little worried that we wouldn't get it right the first time
> around.  The extreme case would involve implementing messaging as a
> python logging handler.  Frankly I'm not sure it's worth it.

I think y'all misunderstood what I tried to say. I think it'll be
common to "bundle" them like this (it's not as if we can prevent
anyone from doing it!) and that there might one day be a desire for an
official shortcut to do it.

> Short of providing this do-all call in the implementation itself, I
> see a few options:
>
> 1) write your own wrapper if you do a lot of that

Already have, for django-notify. Since I already need to test that a
request has a "notifications"-attribute I have a handy place to attach
other "messaging" in the wide sense too, like logging, debug-stuff,
assert False when manually checking things...

> 2) add some logging calls to the messaging code so that you can see
> messages that were shown to the user if you want to, under a static
> logging level (e.g., INFO)

... or under its own prefix so that it can be nulled.
getLogger('msg.'+__name__) or however it winds up looking.


HM

--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[Hanne Moa]

On Tue, Oct 13, 2009 at 09:27, Russell Keith-Magee
 wrote:
> I'm just
> noting that adding Django support for Python logging is also on the
> cards for v1.2, and it seems weird that we would introduce two APIs
> with similar external APIs, but not try to maintain parity.

In fact, it would be very useful to both log and add a message at the
same time, iff there is an error. So that shouldn't deliberately be
made hard to do but maybe suitable for a lazy man's shortcut: one call
that does both.


HM

--~--~-~--~~~---~--~~
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: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

[Hanne Moa]

On Sun, Oct 11, 2009 at 01:46, Russell Keith-Magee
<freakboy3...@gmail.com> wrote:
>
> On Sun, Oct 11, 2009 at 6:19 AM, Hanne Moa <hanne@gmail.com> wrote:
>>
>> On Sat, Oct 10, 2009 at 13:51, Russell Keith-Magee
>> <freakboy3...@gmail.com> wrote:
>>> Looking at #3591 in particular - another big part of the problem is
>>> that the ticket tries to solve a theoretical problem that, in
>>> practice, doesn't really exist - that of namespace collisions in
>>> applications.
>>
>> That's funny, has happended three times to me this far.
>
> If I may ask - which apps (or app names) caused the collision?

The really annoying hair-raising one had a generic name (not blog :)
), mark or pick or something, and was pulled in as a suggested
dependency by aptitude and put in a zipped egg. I don't like those
either, breaks find/locate and studying sys.path  :)


HM

--~--~-~--~~~---~--~~
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: Proposal for 1.2: built-in logging with django.core.log

[Hanne Moa]

On Sun, Oct 11, 2009 at 04:42, Simon Willison  wrote:
> I'm keen to receive as much feedback on the implementation as possible.

It is perfectly possible to set up logging in such a way that all the
logs for several programs wind up in the same file, or there are
duplicate entries. The first happens/happened if/when several programs
used the same interpreter. The second is user error. Been there been
stumped by both. Users need to be protected from both, somehow, but
how... Might be that a standard way for doing it in Django will
suffice for case 2. Will a warning/docs be needed for case 1?

When I first used the logging-library (2002?) I had a problem in
threaded programs, some exceptions were swallowed that shouldn't have
been, leading to rather mysterious behaviour. The exception-hierarchy
have been changed (a couple of times ;) ) since then so it might no
longer be an issue but I'd sleep better if there was tests for this
too. Vinay?


HM

--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[Hanne Moa]

On Sat, Oct 10, 2009 at 19:53, Tobias McNulty  wrote:
> I should have also added:
>
> * Coming to consensus on a de facto standard API suitable for
> inclusion in Django

The suggested API: how hard will it be to use different message-types
in addition to the syslog-like ones? I use django-notify now and the
types I use is nothing (for info), "error", and "help" (for
help/tips). I've also made django-notify optional in my reusables,
with a dummy-object if it is not installed. Locking them down with
class.attributes will find typos of course, but right now I don't have
to import anything just to use session-messages, I just do a
hasattr(request, 'notifications') .


HM

--~--~-~--~~~---~--~~
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.2 roadmap and schedule

[Hanne Moa]

On Sat, Oct 10, 2009 at 13:51, Russell Keith-Magee
 wrote:
> Looking at #3591 in particular - another big part of the problem is
> that the ticket tries to solve a theoretical problem that, in
> practice, doesn't really exist - that of namespace collisions in
> applications.

That's funny, has happended three times to me this far. Not to mention
clashes with globally installed weirdo python libraries I didn't even
know existed before django broke. And it is quite the struggle to
figure out what is actually wrong when this happens. Relative imports
identical to absolute imports are Evil(tm). (Good incentive to always
use virtualenv everywhere though.)

Also, contentypes are less useful because its unicode() only shows the
model, not the app, I have several models with the same (class)name
from different sources... I always use db_table in my models too now
after being burned by clashes in the database.

The way to prevent such clashes is of course to *never* use reusable
apps directly but always fork, and in addition always use
virtualenv...

I can't wait 'till one has to prefix relative imports with dots as one
may in 2.6, even if the syntax *is* bug-ugly.


HM

--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[Hanne Moa]

On Fri, Sep 11, 2009 at 01:00, Tobias  wrote:
> There are a number of usable solutions out there but django-notify is
> the most complete, polished one that I know of.

I've just tested django_notify, so far it seems plenty good enough to
replace all my pass-on-message hacks (not to mention being much more
elegant than any of 'em) expect for not being able to set a message
php-style in the GET, this way:

http://example.com/?msg=Shiver+me+timbers

Whether being able to do that at all is desirable is another question
entirely ;)

Big bonus in my view: it's completely independent of the
django.contrib.auth-system.

> What needs to be done to get this or something like it into contrib?

Yes, this inquiring mind also wants to know.


HM

--~--~-~--~~~---~--~~
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: Suggestion: Better way to extend user table

[Hanne Moa]

On Thu, Aug 20, 2009 at 04:54, Andrew Fong wrote:
> The real problem is all of the code and third-party contrib that
> expects the User model to live at django.contrib.auth.models. Ideally,
> all of these apps should be rewritten to expect not the actual User
> model but any model that implements a User interface. More broadly
> speaking, if your third-party app relies on an external app, this
> reliance should be contained within some variable in the settings
> module (or equivalent) that other Django users can easily alter as
> they see fit.
>
> For example, your settings.py would do this by default:
>
> MY_APP_USER = 'auth.User'
>
> And you would alter your app code from this:
>
> user = models.ForeignKey(User)
>
> to this:
>
> user = models.ForeignKey(settings.MY_APP_USER)

I do something like this for my apps meant to be third-party, but I
use a function get_user_model() to check the setting (if not set it
uses auth.User), then run

User = get_user_model()

instead of

from blbl import user

in models.py and thus the models may look "normal" and need not import
settings at all:

user = models.ForeignKey(User)

The only fields I expect to find in a user-model is passwd and
username, though the absolute minimal user-model possible is of course
just a primary key for other tables to link to.


HM

--~--~-~--~~~---~--~~
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: append_slash alternative: remove_slash

[Hanne Moa]

On Tue, Jun 16, 2009 at 22:08, M. N. Islam Shihan wrote:
> I think another toggle flag ENABLE_REMOVE_SLASH_MODE (or any other
> appropriate name) can be added to the settings.py and setting that
> tlag to true will alter the existing APPEND_SLASH flag to be treated
> as prposed REMOVE_SLASH setting and act accordingly. In this way the
> existing APPEND_SLASH will act like a tristate variable to dictate url
> resolver to append slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE
> false), do nothing (APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE false
> and APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE true)  and remove
> slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE true). In all cases
> the extra slashes should be removed anyway.

And I want the bikeshed to be painted blue with yellow stars on.


HM

--~--~-~--~~~---~--~~
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: 1.1: Ticket #3569 (Enhanced Atom Support)

[Hanne Moa]

On Mon, Mar 9, 2009 at 01:40, Eric Holscher  wrote:
> I have talked to James Tauber about ticket #3569 which is about adding
> better support for Atom to the syndication feeds framework.
>
> I know a lot of people (myself included) use his atom.py[1] file
> instead of Django's  atom feed framework.

And myself, without the compatibility-layer. The API seems easier
somehow. Less magic.

> I think that including the new code in a place like
> django.contrib.atom would also be an option, for in the future there
> might be more support added for Atompub.

Now that is an elegant solution. The old framework could then slowly
be deprecated and new stuff could start out using the one, true^W^W...
*cough*. Also, feeds feel a little to the side of the bread and butter
"ORM and forms"-stuff and so suitable for contrib.

What plans are there for more support for Atompub? I write news items
directly in the admin these days.


HM

--~--~-~--~~~---~--~~
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: Distributed workflow and the woes of slow testsuite

[Hanne Moa]

On Mon, Jan 12, 2009 at 18:04, mrts  wrote:
> As of now, I'll stop pursuing this further, but when I come back to
> this,
> would the approach outlined in http://dpaste.com/108140/ be
> acceptable?
>
> I.e. if
> 1) not specified explicitly (by the --multiprocessing option to test)
> 2) there's only a single core in the system
> 3) importing the multiprocessing module fails
> run the ordinary single-process test runner.

Django doesn't need this yet but to show what is happening elsewhere...

CPAN have plans for fully automated testing: an os-image with the
needed libraries is created and distributed, tests are run in the
vhost and results are sent to an accumulator, in essence: c...@home...

:)


HM

--~--~-~--~~~---~--~~
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: SessionWizard

[Hanne Moa]

On Thu, Dec 4, 2008 at 03:34, David Cramer <[EMAIL PROTECTED]> wrote:
> When the done() method is called, the session is also cleared unless
> done(). Maybe this should only happen if say a ValidationError isn't
> raised? Maybe a setting that makes this not happen? In all of my
> situations it makes sense to erase it when it's complete, and not have
> to call methods manual. Let's decide which is more common.

How about making it easier to have a preview also? As per today,
FormWizard and FormPreview aren't really combinable. Should probably
be it's own ticket...


HM

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dropping Python 2.3 compatibility for Django 1.1

[Hanne Moa]

On Tue, Nov 25, 2008 at 18:08, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> I'd like to officially drop Python 2.3 support in Django 1.1. Discuss.

Yes please.

Maybe put up a poll, prominently, on the djangoproject.com homepage?

Maybe make a timeline? Drop 2.3-support by date x, drop 2.4-support by
date y, drop 2.5-support by date z, then stay with 2.6 until all the
world is 3.x?
Python 2.6 for django 2.x maybe?


HM

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[Hanne Moa]

On Wed, Nov 19, 2008 at 19:12, David Cramer <[EMAIL PROTECTED]> wrote:
> You guys are really bad about keeping on topic. :)

Good way to prevent a discussion from entering Godwin-territory :)

I should perhaps have mentioned something along the lines of  "this is
an example of where there is (perhaps) an unnecessary need for a
primary key". After all, the fewer places that *must* have x, the
easier it is to change the underlying structure of x.

To go back off track (wouldn't do to stay on it for long), maybe we
need an official place to discuss the use of legacy databases in
Django.


HM

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[Hanne Moa]

On Mon, Nov 17, 2008 at 00:55, Frank Liu <[EMAIL PROTECTED]> wrote:
> Plus, if you had a chance to look at the type of databases that I have
> to deal with by day, you will see why this is so important to me.

Yo. Not that big, but there's a DBA involved for some of 'em. Let's
just say I can't use the auth-system or anything depending on that :)

Funny thing though, got a manytomany-table without a primary key: I
can add a new row easily enough, the only problem is in delete()-ing
specific rows, since that seems to use the primary key. So I clear()
and re-add instead of delete()-ing, since that doesn't use the primary
key. Fragile, but it beats doing the puppy-eyes to the DBA.


HM

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ticket 9483

[Hanne Moa]

On Tue, Nov 4, 2008 at 15:26, H. de Vries <[EMAIL PROTECTED]> wrote:
> Well, I searched around and it seems that a lot of people aren't too
> happy with Python's default title() functionality. (
> http://muffinresearch.co.uk/archives/2008/05/27/titlecasepy-titlecase-in-python/
> )
>
> From a publishing point of view,

Which publishing point of view? News? Tabloid? Scientific publication?
Fiction? Other? From which country? If English, which English? At what
point in time? Is there a house-style?

It might be that Python's existing titlecasing reflects international
usage, or Dutch usage (I'm not Dutch). Titlecasing is generally not
used in my country however. So, this is a localization-question
really.


HM, helpful computational linguist

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---