Re: Update on localflavor move

[Claude Paroz]

Le samedi 13 octobre 2012 00:21:16 UTC+2, Adrian Holovaty a écrit :
>
> Hi all, 
>
> We've been talking about moving django.contrib.localflavor into 
> separate packages, outside of Django proper 
> (
> https://groups.google.com/d/topic/django-developers/OiyEGmXTifs/discussion). 
>
> Today I did the work of creating the django-localflavor-* packages and 
> copying code/tests/docs to them. 
>
> Now we have 44 django-localflavor-* projects on our Django GitHub 
> account, and you can see them here: 
>

Thanks Adrian for your work. 
(...)

* If you have any existing Trac tickets for localflavor, please close 
> them and open a pull request on the appropriate django-localflavor-* 
> project. 
>

You meant: open an issue?
 

> Here are the outstanding to-dos with this effort: 
>
> * Move/copy translations into the django-localflavor-* packages. This 
> is outside of my expertise, so does anybody want to take the lead on 
> this?
>

I can work on this, however I'm wondering if it makes sense to re-add all 
translations in all packages. Is adding Korean translation to Switzerland 
localflavor useful?
 

>   * Add DeprecationWarning to django.contrib.localflavor in trunk, 
> before Django 1.5. I will take care of this. 
>

Did we decide on an accelerated deprecation here, or did you mean 
PendingDeprecationWarning?

Claude

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/0HnkWf8TkvkJ.
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: Unicode SlugField

[Claude Paroz]

Le jeudi 1 novembre 2012 14:32:12 UTC+1, Russell Keith-Magee a écrit :
>
>
> However, this all hinges on someone getting:
>
>  1) consensus on a design,
>  2) a commit-ready patch that implements that design.
>
> Reading the ticket, we haven't yet achieved (1). The most recent comment 
> was 9 months ago, and hasn't been followed up. For the record, that comment 
> doesn't "promise" anything -- it's just saying that if a change is going to 
> happen, it couldn't happen any sooner than 1.5 (since 1.4 was already out, 
> and a change like this *won't* be back ported).
>
> So - if you want this, now would be a very good time to do exactly what 
> the ticket says, and lead the discussion advocating it.
>

For me, changing the outcome of validate_slug is not an option, like Paul 
wrote on the ticket. I'd suggest:
  a) creating a new validate_uslug validator (better name anyone?)
  b) allowing a custom validator to be passed to the SlugField constructor

Claude

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/bSf-Oj3VOH0J.
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: Blocker for 1.5 - representation of filesystem paths in Django

[Claude Paroz]

Le samedi 1 décembre 2012 19:43:12 UTC+1, Aymeric Augustin a écrit :
>
> Hello,
>
> Django 1.5 beta 1 contains a regression for users who install Django or 
> their projects under non-ASCII paths: 
> https://code.djangoproject.com/ticket/19357 Unfortunately, the patch 
> isn't going to be trivial. I'd like to have some feedback before making 
> changes.
> (...)
>
> 2) Keep filesystem paths handling in unicode. In general, it's a good 
> practice to work in unicode and convert at the edges ("unicode sandwich"). 
> But in this case, it also means deviating from Python's behavior. This 
> would be a major change in Django's APIs, and one whose consequences 
> haven't been well anticipated. I haven't explored this solution.
>

I've just uploaded a patch on the ticket that implements that approach. I'm 
rather confident about it, but of course, it has to be thoroughly tested.

Claude 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/_Q-QNYKxNWMJ.
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: Will be % string formatting be preferred in the future, or will string.format() be moving in?

[Claude Paroz]

Le lundi 18 février 2013 14:33:27 UTC+1, VernonCole a écrit :
>
> Dear Gurus:
>   I am a regular lurker on this list, and I have accepted the invitation 
> to use 1.5rc1 to help test it.  My group is putting together a small (but 
> very important, we think) application which will use some features of 1.5 
> and geodjango.  I have also been reading the corresponding 1.5 
> documentation, and have done some testing under Python 3.   [Job well done, 
> everyone!]
>

Thanks, it is very important that 1.5 gets as many testing as possible 
before the release.
 

>   Here comes my question:  The documentation for i18n (
> https://docs.djangoproject.com/en/dev/topics/i18n/translation/) makes 
> extensive use of percent string formatting (where the format string is the 
> left-argument of a "%" operator.)  I have been trying to convert myself and 
> my code to the more-recently-defined string.format() function. 
>   I know that the document has been recently edited, because I can see 
> "print" used as a function, and "smart_text', etc. But not one word is 
> mentioned about the new string formatting function.  Will it be / is it 
> supported by django translations, or should I revert to using % formatting 
> as my habit?
>   What do the "insiders" say?
>

There is a thread which should answer your question: 
https://groups.google.com/forum/?fromgroups#!topic/django-developers/7xiXlz5DUWM

Claude 

-- 
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: Moving database backends out of the core

[Claude Paroz]

As for me, wearing my FOSS-only developper hat, I'd suggest we only include 
backends in core  for products having an OSI-approved license. And yes, the 
Oracle backend is already problematic at this regard. That would mean I'm 
-0 to -1 for including any other db backend (or any other component) based 
on a proprietary product.

Cheers,
Claude

-- 
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: Contributing and translating django_localflavor_XX package

[Claude Paroz]

Le samedi 9 mars 2013 10:46:27 UTC+1, Alon Nisser a écrit :
>
> I'm working on translating and adding to 
> django_localflavor_il. 
> and I have a couple of questions:
>
>
>1. I'm adding another field (an Israeli mobile phone number), should I 
>open a ticket somewhere?
>
> Yes, here:  https://github.com/django/django-localflavor-il/issues

>
>1. what is the proper process of contributing? I forked the repo, 
>added the validation and tests  now what? just make a pull request?
>
> Yes, a pull request is indicated. 

>
>1. following this 
> topic: 
> is 
>using django_localflavor_xx still recommended? am I working on the wrong 
>issue?
>2. after adding the form field and validation I need to translation 
>another string to the po file. how do I 'extract messages' from this 
>package?
>
> cd into the inner django_localflavor_il directory and run "django-admin.py 
makemessages -l en" to update the locale/LC_MESSAGES/django.po file or 
"django-admin.py makemessages -a" to update all po files.

HTH,

Claude
 

-- 
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: Contributing and translating django_localflavor_XX package

[Claude Paroz]

Le samedi 9 mars 2013 19:46:18 UTC+1, Alon Nisser a écrit :
>
> Thanks Claude, I have the code and tests ready, but should I run the tests 
> (can't figure how to setup django so it would run this package test, and 
> when I try to run python tests.py directly I get a missing django settings 
> something or another missing ) or does the jenkins server run it 
> automatically and I should just submit the code?
>

Nothing is automatic currently and the testing process for localflavors is 
not well defined.
For localflavor-ch, I moved the tests folder inside the app directory so as 
I can test it like every other Django application. Once a localflavor has a 
dedicated maintainer, I think it is her choice to define the testing 
strategy.

Claude

-- 
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: Testing a django_localflavor_XX package

[Claude Paroz]

Le lundi 11 mars 2013 00:42:15 UTC+1, Alon Nisser a écrit :
>
> how am I supposed to test this? tried following some examples in other 
> repo, but all failed. I wrote the test itself but it Doesn't run due to 
> "You must either define the environment variable DJANGO_SETTINGS_MODULE or 
> call settings.configure() before accessing settings"
> my *fork here *
>
> since I'm a django testing newbie I'll be glad for detailed instructions
>

I've just moved the tests inside the django_localflavor_il directory. To 
test the app, insert it in any project of yours and simply run: ./manage.py 
test django_localflavor_il

Claude

-- 
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: Is casting Field.help_text to string in Field.__init__ necessary?

[Claude Paroz]

Le samedi 23 mars 2013 12:16:15 UTC+1, Evgeny a écrit :
>
> Hi.
>
> Is it necessary to cast help_text to string in Field.__init__ there 
> https://github.com/django/django/blob/master/django/forms/fields.py#L92 ? 
> I will be eventually displayed as string in template, and will be casted 
> there. I think it would be better design - cast string type only in last 
> moment in presentation template.
>  
> I am asking because i try to display in template two help texts one to the 
> right from the field and one to the bottom, and to do that i tried to pass 
> in help_text tuple of two strings but failed because of that cast.
>

It seems to me that it is an "historic" remainder. I suggest you remove the 
offending lines, run the entire test suite, and if you don't get any 
errors, open a ticket suggesting the removal.

Claude

-- 
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: Is casting Field.help_text to string in Field.__init__ necessary?

[Claude Paroz]

Le samedi 23 mars 2013 22:28:31 UTC+1, Claude Paroz a écrit :
>
> Le samedi 23 mars 2013 12:16:15 UTC+1, Evgeny a écrit :
>>
>> Hi.
>>
>> Is it necessary to cast help_text to string in Field.__init__ there 
>> https://github.com/django/django/blob/master/django/forms/fields.py#L92 ? 
>> I will be eventually displayed as string in template, and will be casted 
>> there. I think it would be better design - cast string type only in last 
>> moment in presentation template.
>>  
>> I am asking because i try to display in template two help texts one to 
>> the right from the field and one to the bottom, and to do that i tried to 
>> pass in help_text tuple of two strings but failed because of that cast.
>>
>
> It seems to me that it is an "historic" remainder. I suggest you remove 
> the offending lines, run the entire test suite, and if you don't get any 
> errors, open a ticket suggesting the removal.
>

Eventually, I addressed this issue in 
https://github.com/django/django/commit/066bf42675040abd7b1a42e5559890e5f9881058
Hopefully it will solve your problem.

Cheers,

Claude 

-- 
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: BCrypt + Python3

[Claude Paroz]

Le samedi 11 mai 2013 07:59:18 UTC+2, Donald Stufft a écrit :
>
> I went looking for BCrypt + Django + Python3 today and this is what I 
> found: 
>
> The current recommended solution to bcrypt + Django is using py-bcrypt 
> which is not compatible with Python3. 
>
> Someone else has taken py-bcrypt and created py3k-bcrypt however they made 
> the decision to enforce having str instances sent in for password/salt 
> instead of bytes which makes it incompatible with Django's encode function 
> on the BCrypt password hashers[1]. 
>
> So I created a library simply called `bcrypt`[2] which has the same API as 
> py-bcrypt but it functions on Python 2.6+ and 3.x (as well as PyPy 2.0 
> since it's implemented via CFFI). When testing this against Python3 + 
> Django I discovered that Django isn't properly encoding/decoding when 
> talking to the external library so I made a patch that causes it to always 
> send bytes to the external library, and str's to other pats of Django. That 
> can be found here: https://github.com/django/django/pull/1052 
>
> My bcrypt library is obviously new code but it's a small wrapper over 
> crypt_blowfish from OpenWall[3] and I'm wondering (assuming no one objects 
> to me merging my Patch) if it would make sense to switch the documentation 
> away from suggesting py-bcrypt and have it suggest bcrypt instead since it 
> will allow BCrypt to function on Python3 as well. 
>
> Thoughts? 
>
> [1] I believe this is inheriently wrong as bcrypt operates on bytes not on 
> unicode characters, and in order for this to work py3k-bcrypt must be 
> assuming a character set it can encode(). 
> [2] Found at https://crate.io/packages/bcrypt/ or 
> https://github.com/dstufft/bcrypt 
> [2] Found at http://www.openwall.com/crypt/ 
>
>
Hi Donald,

There are several approaches in string handling in Python 3, being as 
content input or output. As for me, I'm generally privileging unicode 
strings whenever possible. See for example the Python hashlib behaviour for 
digest() and hexdigest(): digest() returns a bytestring as it can return a 
full range of bytes (0-255), while hexdigest() returns a string as the 
result is guaranteed to be ASCII-safe.

Similarly I would have returned a string (unicode) from hashpw() as far as 
it is guaranteed to be ASCII-safe. As for inputs, I think it is easy enough 
to accept both bytestrings and strings, test them and encode('utf-8') when 
needed.
I recognize that it looks a bit odd on Python 2 to receive unicode when you 
fed bytes to a method.

I'm not sure there is a "right" way, it's all about design and choice. Feel 
free to ignore me :-)

Claude

-- 
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: Support for 3D Oracle Spatial Geometries

[Claude Paroz]

Hi Michael,

At least, I found nothing shocking in your patches, so in my 
non-oracle-savvy eyes, this looks rather fine. It would then be interesting 
to see if some tests from django.contrib.gis.tests.geo3d.tests can pass 
with Oracle.
Please create a ticket and link a pull request with your proposal, and 
we'll be able to further discuss this issue.

Claude

Le lundi 3 novembre 2014 13:04:55 UTC+1, MG Sexton a écrit :
>
> Hi
>
> I have recently started using Django and tried to use it with our legacy 
> Oracle Spatial database. The geometries we store in Oracle are all 3D and 
> as such don’t work with Django. It boils down to this:
>
> select sdo_util.to_wktgeometry(sdo_geometry(3001, null, SDO_POINT_TYPE(120
> ,-30, 0), null, null))  from dual;
>
> Yielding the following error:
>
> ORA-13199: 3D geometries are not supported by geometry WKB/WKT generation.
> ORA-06512: at "MDSYS.MD", line 1723
> ORA-06512: at "MDSYS.MDERR", line 17
> ORA-06512: at "MDSYS.SDO_UTIL", line 2509
>
> However, as I discovered, all is not lost. A similar query:
>
> select sdo_util.to_gmlgeometry(sdo_geometry(3001, null, SDO_POINT_TYPE(120
> ,-30, 0), null, null))  from dual;
>
> Delivers something we can work with:
>
>  xmlns:gml="http://www.opengis.net/gml";> decimal="." cs="," ts=" ">120.0,-30.0,0.0 
>
> I am new to Python and Django, so I looked through the code, forked the 
> Django project, and made five changes:
>
> Call to Oracle uses SDO_UTIL.TO_GMLGEOMETRY to output GML:
>
> https://github.com/comtesacristain/django/commit/4a5732d3069fc648b887c7c7000e99f45fe60d56
>
> GML regex (this probably needs work as I am terrible at regexes):
>
> https://github.com/comtesacristain/django/commit/96d06f8392432121610a07ed8d7a1fc4c7f5aa8c
>
> Accessed part of the GDAL C libraries to read from GML:
> https://github.com/comtesacristain/django/commit/3cefe8651a8df60bbade66ec0410c67ee2bde1d9
>  
>
>
> Checked against the GML regex and used GDAL module
>
> https://github.com/comtesacristain/django/commit/2eaad60782f2d72836b026bd2cca0d9a1cfff541
>
> Part of GDAL module which makes the call to the GDAL C API
>
> https://github.com/comtesacristain/django/commit/ad5808a5b4b0b7e6b1efb4d29dc09e7d15a344b7
>
> I was wondering what it would take to have these made part of the Django 
> project? I am not the greatest coder, but I thought these might help with 
> what is currently a bug in the use of Django for 3D spatial geometries in 
> Oracle.
>
> Best Regards
>
> Michael Sexton.
>
>
>
>
>

-- 
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/eef9fdc9-e8d8-4f06-9ec6-c6942dbc24a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Are rasters on the GeoDjango roadmap?

[Claude Paroz]

Hi Daniel,

I've answered on the GeoDjango list. Please avoid cross-posting, thanks.

Claude

Le mercredi 12 novembre 2014 12:34:34 UTC+1, Daniel Wiesmann a écrit :
>
> Hi All
>
> I am wondering if integration of Raster data is on the roadmap of 
> GeoDjango.
>
> I am asking because I have started to work on a package to include Rasters 
> into Django (see link below). This is still very early stage, but I already 
> use the package in a Django project I am working on. For that project I 
> will continue extending the package and would like to work towards 
> integration with GeoDjango (although I am aware that this is a long way to 
> go).
>
> https://pypi.python.org/pypi/django-raster/
>
> However, before spending more time on this I wanted to make sure I am not 
> duplicating something that is already underway. Does anyone know about the 
> state of rasters in GeoDjango and/or if its on the roadmap for future 
> development?
>
> Thanks,
>
> Daniel
>

-- 
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/a3a291fb-6822-43be-b48f-880e75a39eac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backend-specific lookups

[Claude Paroz]

Hi Shai,

I was thinking about something very similar for the GIS backends, where 
this question is even more accurate, as lookup implementations are often 
very backend-specific.

I was experimenting with dynamic mixin registration, but that felt very 
hackish [1]. Anyway, a solution to this use case would be really welcome.

Claude

[1] https://gist.github.com/claudep/c234e546eab00ff9fdbf

On Saturday, November 15, 2014 8:03:18 PM UTC+1, Shai Berger wrote:
>
> Hi, 
>
> I'v been working on an old Oracle bug[1], and realized that a nice way to 
> solve it would be by overriding some builtin lookups with custom lookups 
> for 
> Oracle. However, I had some doubts about where to place the code: 
>
> On the one hand, I could just add an "as_oracle()" to  the builtin lookup 
> classes. But I felt that would be cheating -- Oracle is in core, but what 
> would 3rd-party backends do? 
>
> So I thought I would implement a custom lookup in the backend, which adds 
> an 
> "as_oracle", and register that when the backend is loaded. Loic commented 
> that 
> this is still problematic -- For example, I want to override "contains" on 
> TextField's, so I would naturally inherit the built-in Contains lookup; 
> but if 
> a user has two backends which want to override "contains", they will be in 
> conflict -- only one of them will get to install its handler. 
>
> The solution I found was to use dynamic inheritance --  the backend 
> inherits 
> not the builtin Contains, but the registered lookup for "contains" on 
> TextField. This way, another backend can also add its own as_vendor() 
> method, 
> without any of us stepping on each other's feet. 
>
> I've posted the initial example of this as a PR[2] for comments. 
>
> This is related to some of the discussions about transforms (SQL 
> Functions) 
> that happened on the mailing list a couple of months ago[3], but the topic 
> of 
> backend-specific functions was not really the topic there, so I preferred 
> to 
> open a new discussion. 
>
> Have fun, 
> Shai. 
>
>
> [1] https://code.djangoproject.com/ticket/11580 
> [2] https://github.com/django/django/pull/3544 
> [3] 
> https://groups.google.com/d/msg/django-developers/HggiPzwkono/dsnx3BuXpnkJ 
>

-- 
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/276fb0e8-0ae5-41c5-bae7-8f482af20598%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Configurable safety options for high performance Django systems

[Claude Paroz]

On Tuesday, November 18, 2014 1:58:00 PM UTC+1, Rick van Hattem wrote:
>
> Hi guys,
>
> As it is right now Django has the tendency to kill either your browser (if 
> you're lucky) or the entire application server when confronted with a large 
> database. For example, the admin always does counts for pagination and a 
> count over a table with many rows (say, in the order of 100M) can really 
> stall your app and database servers.
>


https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.show_full_result_count
 
seems to go in your direction, at least. count(*) performance is 
implementation-specific, so once again, no one-size-fits-all.
Maybe the documentation could be completed, here and there.

Claude

-- 
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/5c3ffd8f-7ac6-4ac9-863d-875581c3c127%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Windows users around?

[Claude Paroz]

Hey,

I'm one of the most Windows-breaking committers, also because I don't care 
any more for this system. Sorry for that! (for you, not for me :-)

Tim kindly pointed me to the following list of tickets which need love from 
some Windows users of Django:
https://code.djangoproject.com/query?status=!closed&keywords=~windows-test-failure

So if you are concerned and have a bit of time, please give some attention 
to the aforementioned tickets.

Thanks.

Claude

-- 
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/eb188de6-290d-4303-a838-03c751729a40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Claude Paroz]

On Friday, December 19, 2014 6:30:32 PM UTC+1, Tim Graham wrote:
>
> Yes. Claude has worked on the deprecation in 
> https://github.com/django/django/pull/3220 but it requires adding more 
> migrations to our test suite and he noted that each migration we add to 
> Django's test suite adds up to ~3.5 seconds to the run time of the test 
> suite. He also worked on some speed ups to mitigate this in 
> https://github.com/django/django/pull/3484 but there are some unsolved 
> issues.
>

I think that the first mentioned patch I worked on (PR 3220) shows that it 
should be possible to use the new schema infrastructure without requiring 
migrations, at least for apps that don't depend on other migrated apps. 
Tell me if I miss anything.

But surely, I'd really like to solve first the speed issue of migrations 
(#23745, PR 3484). Chris, if you have the opportunity to test that patch 
with your database, it would be great. The way forward for this patch is to 
first test the "if app_label == settings.AUTH_USER_MODEL and 
ignore_swappable:" line which is currently not tested and is probably not 
addressed by my patch. Andrew, do you remember why you introduced that part 
of the code?

Claude

-- 
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/1f5f37b2-5309-4af6-8b3c-aa76eee3bde1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Claude Paroz]

On Saturday, December 27, 2014 4:46:52 PM UTC+1, Tim Graham wrote:
>
> #23745 - Migrations migrate is slow 
>  (new)
> Owner: Claude
> Status: Patch seems to need improvement so it doesn't cause a regression 
> with swappable models.
>

Sorry, but I'm afraid you should remove my name as the owner at this stage.

Claude 

-- 
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/3a4293ce-4125-4313-b5ec-434c1f066cd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Keeping apps without migrations?

[Claude Paroz]

Tim recently did a fabulous job of removing deprecated code for the
future 1.9 on master. Thanks for that.

However, one thing he removed was support for apps without migrations.
https://github.com/django/django/commit/7e8cf74dc74539f40f4cea53c1e8bba82791fcb6

Considering that we have to keep internal support for Django's own test
suite anyway, I wonder if we should remove that support at all for
"normal" projects. I think one of Andrew's motivation was not to have to
keep two schema editing code bases. But now that the old syncdb also
uses the new schema editor, I think that this argument doesn't stand.

So what about keeping support for apps without migrations in the longer
term. Of course, the fact that those apps cannot depend on migrated apps
limits its use, but I think that for quick prototyping and initial
developement, migrations could be more of a hindrance. Would you see
major drawbacks with keeping this support?

Opinions welcome.

Claude
-- 
www.2xlibre.net

-- 
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/1421617394.5741.4.camel%40doulos.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8a and geodjango on windows 7, AttributeError: function 'GDALAllRegister' not found

[Claude Paroz]

Le lundi 2 février 2015 17:30:23 UTC+1, mattxbart a écrit :
>
> Hi all,
> I had a working 1.7.4 (using geodjango) on windows 7 install, no issues. 
> I'm using osgeo4w to manage all the gdal/gis libraries. When I install the 
> django 1.8a release or off git master, I get the following traceback:
>
> $ ./manage.py shell
> Traceback (most recent call last):
>  ...
> register_all = void_output(lgdal.GDALAllRegister, [])
>   File "c:\Python27\lib\ctypes\__init__.py", line 378, in __getattr__
> func = self.__getitem__(name)
>   File "c:\Python27\lib\ctypes\__init__.py", line 383, in __getitem__
> func = self._FuncPtr((name_or_ordinal, self))
> AttributeError: function 'GDALAllRegister' not found
>
> I've installed all 32b libs, looks like something in the new raster 
> functionality? How do I get this working?
>

 Hi,

This sort of issues are better handled through a ticket. Also please try to 
provide the installed versions of the geo libs, if possible.
https://code.djangoproject.com/newticket

Claude

-- 
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/880e54fa-ad55-48fc-b969-83658d2a10bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the test suite pass on a read-only filesystem?

[Claude Paroz]

Le samedi 21 février 2015 12:08:38 UTC+1, Aymeric Augustin a écrit :
(...) 

> I foresee two difficulties: 
>
> - How do we enforce this in the long run? Can we run the CI server with a 
> very 
>   unprivileged user that isn’t allowed to write anywhere other than /tmp? 
> - makemessages isn’t flexible at all It’s going to be hard to convince it 
> to write 
>   its output outside of the directory it’s processing. 
>
 
Not so much. It should be possible to mock the command and add --output=... 
to its xgettext_options property.

Claude

-- 
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/547d2f77-5b78-4f21-9824-813049a5d991%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Help needed with Oracle GIS backend

[Claude Paroz]

Hi,

In ticket #24214, I built a patch to replace all geo-specific Manager 
methods by class-based ORM functions. This will allow us to get rid of 
convoluted query code in the GeoDjango ORM. It will also be far much easier 
to add support for specific database functions. The code is already in good 
shape, however we are missing the Oracle part of the patch. I won't work on 
that part myself, that's why I'm here to ask for help with it from anyone 
which is a bit familiar with the Oracle GIS backend. Help much appreciated!

https://code.djangoproject.com/ticket/24214

Claude

-- 
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/bdbfdf22-4f2b-44ca-abed-5f937c2eb446%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DKIM signing option for stmp.MailBackend?

[Claude Paroz]

Le vendredi 3 avril 2015 19:05:02 UTC+2, Loek van Gent a écrit :
>
> Hi all,
>
> Is anyone using DKIM signing for densing emails? Does it make sense to you 
> to have a feature like that in Django core or is this typically something 
> that should be in it's own app?
>

I think that generally DKIM is most often a task of the MTA (mail transfer 
agent), while Django is playing the role of the MUA (user agent) here. 
Hence I wouldn't push for a Django core integration, but more as an 
external add-on.

Claude

-- 
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/21692a8d-f5c3-4389-83a5-b7fdb4c445d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pass exception to error handlers

[Claude Paroz]

The request to pass the exception to error handlers has been won't-fixed in 
tickets #20156 / #20803.
I'd like to reopen the discussion. While the usefulness for 404 errors are 
indeed questionable, I think it makes sense to provide some context to most 
error chains through the exception. Typically a message explaining why the 
access to an object is refused (403). I don't see why Django should prevent 
such use cases. The discussion is open :-)

Claude

-- 
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/da4fc018-cad3-4d1a-bf73-5a237c20f49a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pass exception to error handlers

[Claude Paroz]

Here is some code to demonstrate a possible implementation:
https://github.com/claudep/django/commit/5617d32e8f10861fb84bf26297dfcd4e4e40d6d7

-- 
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/190d79bd-0e51-4b71-86c0-dda05d83dc77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pass exception to error handlers

[Claude Paroz]

Le mercredi 22 avril 2015 à 07:05 -0700, Tim Graham a écrit :
> I have some concerns from a security standpoint. For example, some
> exception messages are definitely not meant to be displayed to end
> users and may leak server implementation details. For example:
> 
> SuspiciousFileOperation(
> 'The joined path ({}) is located outside of the base path '
> 'component ({})'.format(final_path, base_path)
> )

That makes sense. But as SuspiciousOperation is special-cased in
get_response, we can as well pass None in the exception parameter. It's
not the typical situation where we want the user to receive a specific
message.

> If we proceed with the idea, maybe a separate exception attribute for
> a "user facing message" would be appropriate. Of course, if we pass
> the raw exception to the error handlers, we cannot prevent programmers
> from writing str(exception) (instead of using that custom attribute)
> and writing insecure code. As to whether that concern should block
> this feature, I'm not sure.

If we exclude 400 errors (500 errors are already excluded in my patch),
that leaves 403/404 codes where we should be safe with regard to error
messages. And then, Django will not print anything by default, the user
still has to provide a custom template containing the `expression`
context variable.

Claude

> On Wednesday, April 22, 2015 at 7:12:53 AM UTC-4, florent...@u-dox.com
> wrote:
> I find this interesting too. It could be very useful when
> using custom exception in the model.
> 
> On Tuesday, April 21, 2015 at 8:58:59 PM UTC+1, Claude Paroz
> wrote:
> Here is some code to demonstrate a possible
> implementation:
> 
> https://github.com/claudep/django/commit/5617d32e8f10861fb84bf26297dfcd4e4e40d6d7


-- 
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/1429719297.6554.18.camel%40doulos.
For more options, visit https://groups.google.com/d/optout.

Re: Pass exception to error handlers

[Claude Paroz]

New ticket created: https://code.djangoproject.com/ticket/24733

Claude

-- 
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/cba8b8a1-a698-4474-8ec0-d4bf34639dde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can Django assume connect privileges to the 'postgres' database?

[Claude Paroz]

Le jeudi 14 mai 2015 18:22:58 UTC+2, Carl Meyer a écrit :
>
> (...)
>
> I think the answer here is appropriate configurability. I see at least 
> two ways to make that happen: 
>
> 1) add a config OPTION to set what database is used when establishing a 
> "no-database" connection? The option would default to 'postgres', but 
> people who need to run tests against a provider who doesn't allow 
> connections to 'postgres' could set it to something else. 
>
> 2) Make it possible to specify an already-existing database to use for 
> running the tests, in such a way that Django won't try to create one or 
> tear it down, and thus won't need a no-db connection at all. 
>
> Carl 
>

Hi Carl,
I tried and proposed a patch with a third approach [1]: test the 'postgres' 
connection, catch database errors and fallback to the default database when 
the connection fails.
I guess that when no access is granted to the 'postgres' database, it's 
most probably that the user has only access to one database.
It wouldn't cost much to provide for an additional settings key, though, if 
needed.

Claude

[1] https://github.com/django/django/pull/4660

-- 
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/7ee5b870-66f6-4f5f-b50e-63dbd7d2b6ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DecimalField with no max_digits and decimal_places

[Claude Paroz]

On Sunday, June 21, 2015 at 11:17:25 AM UTC+2, Aymeric Augustin wrote:
>
> (...)
> I think we should provide the best API for our users and deal with the 
> code. 
> I’m in favor of not introducing another class and figuring out the least 
> awful 
> way to arrange the code paths in DecimalField. 
>

+1

Claude 

-- 
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/1e3bac7e-45fa-4bc6-aab2-fe4060674c74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A new setting for custom gettext domains?

[Claude Paroz]

In my opinion, the question to ask when wondering if a configuration should 
be a setting or not is: is this setting supposed to be changed for 
different installations. In this case, I would answer no. So I think this 
is more an application configuration thing which could be appropriate in an 
AppConfig.
For translation paths specified in LOCALE_PATHS (not related to an app), we 
could extend the LOCALE_PATHS setting format to accept a different 
structure, for example a dict {'path': ..., 'domain': ...}.

My 2 cents,

Claude

-- 
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/d2891fba-7bfe-4f97-88a5-a6dc04c88fdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A new setting for custom gettext domains?

[Claude Paroz]

On Monday, August 24, 2015 at 3:30:56 PM UTC+2, Krzysio Gutkowski wrote:
>
> Hi,
>
> It looks that implementing it in that ways makes more sense.
>
> However, if I were to implement it in that way, should I change both 
> settings in one PR, or should I rework the LOCALE_PATHS setting in a 
> separate PR?
>

When separate PRs are doable and have each self-contained and coherent 
changes, it's always preferred.

Claude

-- 
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/c402033c-9374-4761-8a93-b6cca92fc3b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Okay to use form field labels in admin history?

[Claude Paroz]

On Tuesday, August 25, 2015 at 1:48:55 AM UTC+2, Tim Graham wrote:
>
> Do you like the idea to use form field labels in the admin history 
> messages instead of the form field names themselves?
>
> It's been implemented here:
> https://github.com/django/django/pull/5169 
> 
>
> One consideration is that the messages are generated/stored in the current 
> language so this could increase confusion in multilingual environments 
> until this issue is addressed:
> https://code.djangoproject.com/ticket/21113
>
> I'm not sure if we should block the current pull request on that ticket or 
> not.
>

I think that the correct way would be to fix #21113 first. Having transated 
content in the database looks like a bad idea in the first place.

Claude

-- 
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/2a6dd4ea-27a5-4fc8-88a2-42f9cccd018a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: --debug-sql option for management commands

[Claude Paroz]

I like the idea. However, instead of monkey-patching the Django 
CursorDebugWrapper like DDT is doing now, I'd rather see a solution where 
we use dynamic logging configuration to output the SQL commands, if 
possible.

Claude

-- 
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/41d9f886-045b-4c99-88fb-ea24d5576e03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Provide a way to pass kwargs when initializing the storage class

[Claude Paroz]

The drawback of complex dictionary settings is that to overwrite only one 
key in a settings file, you have to copy the entire dictionary, also 
possibly defeating global settings defaults when they change.

So let's try to have many smaller dictionaries instead of few big ones. The 
initial proposal was a bit better at this regard.

Claude

-- 
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/e180cd2b-9601-44cd-9ba4-21e3a7d10157%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

manage.py test and uninstalled apps

[Claude Paroz]

Hello,

I have a Django project with different apps and settings. Let's say 
settings A have A in INSTALLED_APPS but not B, and settings B have B in 
INSTALLED_APPS but not A. Note also that I cannot have both apps installed, 
for some reason.
In that configuration and from Django 1.9, ./manage.py test will always 
fail with the message :
RuntimeError: Model class  doesn't declare an 
explicit app_label and either isn't in an application in INSTALLED_APPS or 
else was imported before its application was loaded.

Do we admit that for such type of projects, you always have to specify your 
app labels starting from Django 1.9?
Or did I miss some hidden trick to avoid that?

Claude


-- 
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/b7d021c5-bc44-48e6-8441-b57a40758c53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: manage.py test and uninstalled apps

[Claude Paroz]

Hello Aymeric,

To be clear, I don't contest in any way that design choice. I understand 
and approve it.
I'm just pointing to this unwanted side-effect, wondering if anyone has 
ideas how to circumvent it, as I think it's a legitimate use case.
I'm also aware that we have not much control over test discovery and 
importing process.

The workaround for me will probably to write a custom test management 
command to define test labels dynamically based on current settings.

Claude

On Wednesday, November 18, 2015 at 9:29:08 PM UTC+1, Aymeric Augustin wrote:
>
> Hello Claude,
>
> Generally speaking, you cannot safely use a model that isn't defined in an 
> application that is in INSTALLED_APPS. Django raises a warning when you 
> import such a model.
>
> This restriction prevents situations where relations between models aren't 
> set up correctly. There’s a string of such bugs in Trac. I discussed this 
> in my DjangoCon Europe 2014 talk.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 18 nov. 2015, at 21:04, Claude Paroz > 
> wrote:
>
> Hello,
>
> I have a Django project with different apps and settings. Let's say 
> settings A have A in INSTALLED_APPS but not B, and settings B have B in 
> INSTALLED_APPS but not A. Note also that I cannot have both apps installed, 
> for some reason.
> In that configuration and from Django 1.9, ./manage.py test will always 
> fail with the message :
> RuntimeError: Model class  doesn't declare an 
> explicit app_label and either isn't in an application in INSTALLED_APPS or 
> else was imported before its application was loaded.
>
> Do we admit that for such type of projects, you always have to specify 
> your app labels starting from Django 1.9?
> Or did I miss some hidden trick to avoid that?
>
> Claude
>
>
>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@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/b7d021c5-bc44-48e6-8441-b57a40758c53%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/b7d021c5-bc44-48e6-8441-b57a40758c53%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/6181711b-1ec2-4fbe-a4c1-29e5bbac8fa5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reopening/Refixing #20246

[Claude Paroz]

Le dimanche 19 mai 2013 09:40:25 UTC+2, Florian Apolloner a écrit :
>
> Hi,
>
> I don't think that the fix of #20246 [0] is correct. You started using 
> \xa0 while Wikipedia clearly suggests that we should use a narrow space 
> instead of a full-space (probably U+202F). This is something we learned 
> during our physics courses too, so it's in line with what science 
> departments do too. 
>
> Any objections on refixing it?
>
> Cheers,
> Florian
>
> 0: https://code.djangoproject.com/ticket/20246
>

Hi Florian,

I'm not completely sure. The narrow space should certainly be used between 
a number and its unit symbol (kg, cm, Mb, etc.). So your proposal is at 
least valid for a part of the patch. However, for "5 hours, 4 minutes", I'm 
not sure it's the same rule. I'd suggest you add references on the ticket 
and then fix the parts that need to be fixed.

Claude 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: OpenLayers.js and shipping it in django.contrib.gis statics

[Claude Paroz]

Le lundi 27 mai 2013 07:38:54 UTC+2, Carl Meyer a écrit :
>
> Hi Kamil, 
>
> On 05/26/2013 05:39 PM, Kamil Gałuszka wrote: 
> > Hi Django developers! 
> >   
> > This is my first time here posting, so if I'm wrong please forgive me :) 
> > I wanna learn as much as possible about django development process from 
> > you guys! 
> > Thank you all for inspiring time on DjangoCon.eu sprints ! 
> > 
> > I'm writing because I'm concerned about OpenLayers that are used in 
> > django.contrib.gis.admin. For now JS of OpenLayers is shipped with 
> > external url from openlayers hosting. 
> > 
> > There are some drawback of this situation and it's causing bugs in 
> > specific circumstances. For example if you are using Chrome browser and 
> > your website is using https all non https javascript are blocked by 
> > default. So widget in django admin isn't rendering and it's broken (I 
> > think that should be considered as a bug and possibility of security 
> > problems if someone switch openlayer.js on external hosting). 
> > 
> > I think the best approach to that problem is that we should ship 
> > OpenLayer.js in Django statics. OpenLayers documentation is encouraging 
> > to ship in applications own builds of this library. To read more: 
> > http://docs.openlayers.org/library/deploying.html 
> > 
> > I have question is this approach good for Django (to actually compile 
> > own build of OpenLayer and ship it in statics) and is this change can be 
> > possible place of breaking something with backward compatibility. 
> > 
> > Things in my mind to consider: 
> > 1) With every next Django release I think there should be building of 
> > most actual OL. 
> > 2) Shipping OL actually should be optional and documented in docs. 
> > 
> > If there isn't any problem with that approach I'm ready to implement 
> this. 
>
> I'm not familiar with any history in this area (so I'll defer to anyone 
> who knows a good reason why we do it the way we do), but it makes sense 
> to me that it would be better to ship an OpenLayers.js build than link 
> to it externally, for security and reliability reasons. 
>

I was not there at the time of this design decision either, however I can 
imagine that including a lib weighing more than 700 Ko in every Django 
release just for a contrib app is not something to be taken lightly.

Note that Django 1.6 will introduce some new template-based widgets for 
GeoDjango, so changing the OpenLayers source is as simple as subclassing 
the new BaseGeometryWidget and redefining its Media class.

Claude

-- 
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: Reopening/Refixing #20246

[Claude Paroz]

Le dimanche 26 mai 2013 à 01:19 -0700, Florian Apolloner a écrit :
> Hi,
> 
> On Sunday, May 19, 2013 8:18:48 PM UTC+2, Claude Paroz wrote:
> I'm not completely sure. The narrow space should certainly be
> used between a number and its unit symbol (kg, cm, Mb, etc.).
> So your proposal is at least valid for a part of the patch.
> However, for "5 hours, 4 minutes", I'm not sure it's the same
> rule. I'd suggest you add references on the ticket and then
> fix the parts that need to be fixed.
> 
> Hmm, how do you suggest fixing it? adding a new function
> avoid_narrow_wrapping and changing everything in defaultfilters, or…
> (I am asking cause the current fix confuses me, since you didn't touch
> the translations [eg
> https://github.com/django/django/commit/7d77e9786a118dd95a268872dd9d36664066b96a#L3R825
>  ] but just replace the space later on).

Let's continue the discussion on the ticket. But basically, I would add
an optional parameter to avoid_wrapping to be able to specify the
separator character.

Claude

-- 
www.2xlibre.net

-- 
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: Revert 165f44aa?

[Claude Paroz]

Le dimanche 22 septembre 2013 14:24:20 UTC+2, Aymeric Augustin a écrit :
>
> I reverse-applied 165f44aa and committed a subset of the changes. 
>

I'm fine with these changes. Thanks for your work.

Claude

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

RFC: Remove ADMIN_FOR setting

[Claude Paroz]

Hi,

Currently, the ADMIN_FOR settings is rather obscure and only used by the 
admindocs contrib app to document stuff for other sites.
https://docs.djangoproject.com/en/dev/ref/settings/#admin-for

When working on admindocs and notably on decoupling contrib.sites and 
contrib.admindocs with Bouke Haarsma 
(https://code.djangoproject.com/ticket/21386), we were wondering if this 
option was really used in the wild.
So if you are using ADMIN_FOR in your project with a use case that can be 
somewhat common, speak now. Otherwise we are suggesting to simply remove 
the functionality in Django 1.7.

Claude

-- 
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/c8496574-54a1-4bcb-b6d5-d662781a1a8e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with number format when not using L10N

[Claude Paroz]

This is the topic of https://code.djangoproject.com/ticket/21544 where you 
can read my position.

-- 
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/55aed0dd-dcf4-4826-aba9-6ee2f5bac17d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: forms: get_changed_data(): Remember old values

[Claude Paroz]

Le jeudi 24 avril 2014 15:10:20 UTC+2, guettli a écrit :
>
> Hello, 
>
> I want to improve this method: 
>
> django/forms/forms.py: Form.get_changed_data() 
>

There are no get_changed_data() method currently, I suppose you meant 
Form.changed_data (property). 

>
> I need to have access to the old data, and would like to have a triple 
> list like this: 
>
> (field_name, old_value, new_value) 
>
> Code: 
> https://github.com/django/django/blob/master/django/forms/forms.py#L415 
>
> My current solution is to subclass Form and overwrite this method. 
>
> This overwrite is mostly a cut+paste of django's implementation and stores 
> the triple list 
> on the form instance. 
>
> I guess this triple list would be useful for other people, too. 
>
> What do you think? 
>
> Is there interest do make the above triple list available in django core? 
>

I think it could be an interesting feature. As often, the difficulty might 
be to find a solution which respects backwards compatibility, which 
probably means in this case deprecating changed_data and finding a new name.

Claude

 

-- 
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/3ed84f78-1df3-4c7b-9755-287c13a9c185%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Claude Paroz]

Count me in the +1 storm :-)

Claude

-- 
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/98b1309b-b808-439a-9508-0447eabb0bab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: integrating django-secure

[Claude Paroz]

Hi,

I'm not against reverting #23384 (I'm the commit author) because I admit it 
can be debatable, but still I don't like that wrong arguments are given 
against it.

The situation about multiple user settings file is absolutely not changed 
by that patch. If you import from a parent settings file, it's still your 
choice to either overwrite the dictionary or update it, no magics happen at 
all at this stage.

The magics merge effect is only between global settings and user settings, 
so you could define:

EMAIL = {'USE_SSL': True}

without clearing other EMAIL keys from the default global settings.

Carl, you mention several other arguments which I don't understand:
more verbosity in documentation, check warnings, and settings files, more 
complex to work with in
settings-override scenarios.

You may look at the pull request https://github.com/django/django/pull/2836 
to see if any of the above are confirmed or not in that scenario (email 
settings).

Yes, it's a design choice to make, judging if a bit of "magic" merging 
justifies or not having better logically-grouped settings. Keep also in 
mind that the original use-case (apart from django-secure new settings) was 
the addition of two new email-related settings (#20743).

Once again, I'm not advocating for dictionary settings, only for fare 
debate :-)

Cheers,

Claude

-- 
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/ac4a18e8-6a82-48cf-bef3-cf3b33fe94ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: integrating django-secure

[Claude Paroz]

Le lundi 1 septembre 2014 02:07:40 UTC+2, Carl Meyer a écrit :
>
> Hi Claude, 
>
> On 08/31/2014 12:08 PM, Claude Paroz wrote: 
> (...)
>
> > Once again, I'm not advocating for dictionary settings, only for fare 
> > debate :-) 
>
> I hope you found this email fair ;-) 
>

Thanks Carl for developing your points, and yes, they are fair!

Claude 

-- 
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/36ec2e43-468e-4d9d-bd7b-70f3f5efe2ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting dictionaries (was Re: integrating django-secure)

[Claude Paroz]

Le lundi 1 septembre 2014 09:15:21 UTC+2, Shai Berger a écrit :
>
> A case in point is a change that was introduced in 1.7 -- putting the TEST 
> settings of databases into an inner dict. When it was brought up, all 
> responses were positive. (...)

(...)

> As I said, everybody who commented on it back then liked it. I still like 
> it 
> in that  context (though, as I mostly work on the Oracle backend, I'm 
> biased). 
> If we now decide that we globally don't like the concept, perhaps it is 
> not 
> too late to revert it. Or perhaps the decision shouldn't be so global. 
>

When the dictionary setting is not initially populated in 
global_settings.py, this is less of a problem. So a rule *might* be: no 
dictionary setting if Django has default values in it. Even if I'm still +0 
on the solution I committed.

Claude

-- 
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/85931891-53df-4ff8-99ad-5a1a585a1a19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Python 3 and MySQL

[Claude Paroz]

On Thursday, August 14, 2014 3:01:07 PM UTC+2, Naoki INADA wrote:
>
>
> MySQL-Connector/Python was not so popular (as far as I know).
> But 1.2.2 GA was released recently.  It looks nice to me. It may be 
> popular if Django recommend it.
> It's repository was moved from launchpad to github. 
> https://github.com/oracle/mysql-connector-python 
> 
>
> Although it looks nice to me, there are 2 drawbacks.
>
> * They don't put package to PyPI. `--allow-external 
> mysql-connector-python` option is required for `pip install`.
> * Although repository was moved to Github, bug database is still bit 
> unfriendly (http://bugs.mysql.com/ ).
>
>
> I think if Oracle will be more familiar with OSS community (accepting pull 
> requests, using Travis-CI, etc...),
> It can replace PyMySQL. Because it's development is more active than us.
>

Naoki,

Are you aware of performance benchmarks comparing your MySQLdb1 fork and 
mysql-connector-python?

About your fork, do you plan to maintain it in the middle/long term? I saw 
that issues were not enabled on your Github repo. Is it on purpose? What's 
the plan about bug tracking of your fork?

Claude

-- 
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/ca6afdc5-a5f2-43e4-a0e8-c7755e916276%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Python 3 and MySQL

[Claude Paroz]

Le lundi 8 septembre 2014 08:33:39 UTC+2, Naoki INADA a écrit :
>
>
> On Monday, September 8, 2014 2:04:26 PM UTC+9, Naoki INADA wrote:
>>
>> > 
>> > Naoki, 
>> > 
>> > Are you aware of performance benchmarks comparing your MySQLdb1 fork 
>> and 
>> > mysql-connector-python? 
>>
>
> I've posted quick benchmark:
> https://github.com/methane/mysql-driver-benchmarks
>
> Most heavy part of MySQL Driver is parsing packet.
> There are (number of columsn) descripter packet and (number of columns * 
> number of rows) result packet in query response.
>
> On PyPy, packet parsing is faster after JIT warmup.
> MySQL-Connector/Python reads from socket packet by packed.  It makes many 
> system call.
> PyMySQL uses buffering for faster receiving.
>

Great, 8-9x difference in favor of the C implementation (which might be 
expected). That's a clear sign for me that we should continue using 
primarily the C version. That doesn't mean we shouldn't make efforts to 
support at least one Python-only driver (as asked in #12500).

> About your fork, do you plan to maintain it in the middle/long term? I 
> saw 
> > that issues were not enabled on your Github repo. Is it on purpose? 
> What's 
> > the plan about bug tracking of your fork? 
> > 
>
> Thanks for pointing it out.  I've enabled github issue. 
>
> I'll maintain mysqlclient-python until MySQLdb1 development is restarted. 
> Since I hope MySQLdb1 and mysqlclient-python merged someday (like 
> setuptools and distribute were merged), 
> I don't want to implement new feature. 
> 'maintain' means bugfix, support new Python, new libmysqlclient and 
> new OS, etc... 
>

That makes sense.
Tim, Florian, would it be possible to switch to that fork on the CI server 
(both for Python 2 and 3) for MySQL?
Then of course, if all goes well, we would need to update our documentation.

Claude 

-- 
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/7487c9c9-0b46-4e84-8203-7841ab0b0bba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Python 3 and MySQL

[Claude Paroz]

On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>
> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham  > wrote: 
> > We'd need mysqlclient to support Python 3.2 (or drop official support 
> for 
> > MySQL/Python 3.2): 
>
> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
> many Unicode API has 
> been changed and deprecated.  It also introduce unicode literal. 
> Supporting Python 3.2 will make code messy. 
>
> I want to drop Python 3.2 support since I believe most Python 3 users 
> are aggressive enough 
> to go forward. 
>
> How Python 3.2 important for you? 
>

I think we could live with MySQL not supporting Python 3.2. 

> Python 2.7 test failures: 
> > 
> > 
> > custom_pk.tests.CustomPKTests.test_required_pk 
> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
> > 
> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>  
>
> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
> > model_fields.tests.BooleanFieldTests.test_null_default 
>

Thanks Tim for testing. These errors seem to all have the same origin, null 
inserts into not-null columns generate OperationalError instead of 
IntegrityError.
 

> > Python 3.4 test failures: 
> > 
> > 
> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
> > 
> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator 
>
> > custom_pk.tests.CustomPKTests.test_required_pk 
> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
> > 
> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>  
>
> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
> > model_fields.tests.BooleanFieldTests.test_null_default 
> > raw_query.tests.RawQueryTests.test_pyformat_params 
>
>
In addition of the above issue, it seems that pyformat isn't supported for 
Python3. Something around these lines:
cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
{"val1": value_1, "val2": value_2})

I've created issues on the mysqlclient bug tracker.
https://github.com/PyMySQL/mysqlclient-python/issues/3
https://github.com/PyMySQL/mysqlclient-python/issues/4

Claude

 

-- 
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/0d73b65e-e90e-48bc-9e19-68e0970fab86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unifying locale time formats

[Claude Paroz]

On Saturday, September 13, 2014 10:01:56 AM UTC+2, Wim Feijen wrote:
>
> Hi everyone,
>
> I wonder if we should unify the time format which is sometimes displayed 
> as G:i and sometimes as H:i, where hours are displayed with or without a 
> leading zero. For the same reasons as stated above I think it nicer to be 
> consistent here. I would prefer G:i (hour without leading zero). 
>
> Or is that a problem in some languages?
>

I think that this might be language/country specific, so I wouldn't unify 
it in a general manner.

Claude 

-- 
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/242537d5-bc6a-488e-973f-67a7ed0d167a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate HttpRequest.is_ajax

[Claude Paroz]

I'm afraid that implementing a whole content negociation framework is a bit 
ambitious, unless someone has much time to devote to that.

We could start smaller, similar to django-accept-header. I quickly sketched 
what it could look like in:
https://github.com/django/django/compare/master...claudep:accept_header?expand=1

Claude

Le dimanche 17 novembre 2019 12:32:50 UTC+1, Asif Saif Uddin a écrit :
>
> any plan with 
> https://github.com/django/deps/blob/master/draft/content-negotiation.rst 
> one?
>
 

-- 
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/7aff16cc-aeff-4b5e-b402-e4d587bc9315%40googlegroups.com.

Re: Deprecate HttpRequest.is_ajax

[Claude Paroz]

Le 20.11.19 à 22:46, Curtis Maloney a écrit :
> My reading of this discussion boils down to "if we get rid of is_ajax (a
> buy-in convention nobody can rely on), how do people decide if it's an
> AJAX call or not?". To my mind, the "content negotiation" advocates have
> it right: HTTP has a mechanism for determining what response format is
> desired.

It doesn't cover all use cases. For example, I have a use case where an
AJAX call only returns a partial HTML snippet while a non-AJAX call is
returning a full HTML page (same content type in both cases)
.
But in that case, I agree with a previous poster that it's a matter of
convention between client and server. I can rather easily create my own
`is_ajax(request)` utility depending on the convention I choose.

Claude
-- 
www.2xlibre.net

-- 
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/53992754-6e8d-b138-a88b-85d4cfc68891%402xlibre.net.

Re: ngettext_lazy and ngettext

[Claude Paroz]

Le mercredi 4 décembre 2019 03:41:51 UTC+1, Matemática A3K a écrit :
>
> (...)
>
> But, then I realized that there is major caveat on this approach, and that 
> is that updates on the plural equation won't reach users' catalogs, because 
> their catalogs will be kept separately one the plural form differs. This 
> would be the case that Shai pointed on Django 2.2 with the incorrect plural 
> equation for HE. People who have generated their catalogs with makemessages 
> on 2.2 will have a wrong plural equation, that once it is fixed on a new 
> release, it won't reach their catalogs because they will be kept apart.
>

Sorry, I'm not following you here. The catalog merge process is happening 
in realtime when Django starts, so any po file update is instantly 
reflected in the translation infrastructure. I don't see any caveat here.

Claude

-- 
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/5f2bf52a-997c-467d-b927-f2959507d32e%40googlegroups.com.

Re: New Merger nomination.

[Claude Paroz]

Hey! Thanks for suggesting me as a merger!

However, I'd like to clarify that I'm not requesting this commit bit. If 
the project thinks it's good that I get it, I'll accept that and do my best 
to use it as the new DEP suggests. If not, I can certainly continue to 
contribute as I've done in the past.

Cheers,

Claude

-- 
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/a3ae8f2e-b6a8-4d93-8c62-954dc1646b3d%40googlegroups.com.

Re: Filtering window expressions. Ticket #28333

[Claude Paroz]

Le dimanche 5 avril 2020 00:06:15 UTC+2, charettes a écrit :

> This subquery operation would address a few other cases that I know 
> Claude[3] is interested in seeing addressed as well. Maybe you'd be able to 
> pair on this problem given his interest in the problem and your past 
> interactions with some of the ORM's internal.
>

Yes, I confirm my strong interest in solving that, particularly the 
"simple" use case of #30592. Unfortunately, my knowledge of the ORM 
internals is really poor.

Claude

-- 
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/0193386b-160c-43d7-a1f8-fc4a568044ad%40googlegroups.com.

Generate JWTs with Django

[Claude Paroz]

Hi all,

With the recent addition of the algorithm parameter to the signing.Signer 
class, it's now rather straightforward for Django to generate HS256 
(non-encrypted) JSON Web Tokens.
With a growing popularity of JS-client/Django server communications (DRF 
and al.), I think there might be some interest for Django to be able to 
generate and decode such tokens. For any other types of JWTs which 
generally require access to a cryptography module, we can point users to 
third-party libs like PyJWT (the docs should be clear about that).

I made a proof-of-concept PR (docs missing) here:
 - https://github.com/django/django/pull/12728

What people here think about that proposal?

Claude

-- 
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/5f67fefb-d158-4722-b704-6c34d72692a8%40googlegroups.com.

Re: Generate JWTs with Django

[Claude Paroz]

Thanks Abhijeet for the pointer, I know there are some rather complete
JWT libs around, but my proposal is not about a complete package to
manage JWT in general.
It's rather some low level ability for Django to produce and decode
simple HS256 JWT. Then other third-party libs could build on that
ability to write more elaborate packages.

The main doubt I have about my proposal is whether HS256 JWTs are too
limited for most usages or in the contrary if they are appropriate for a
fair amount of use cases.

Claude

Le 15.04.20 à 21:13, Abhijeet Viswa a écrit :
> Hi,
> 
> You might want check out django-restframework-simplejwt. It requires the
> Django Rest Framework. But, then again, if you are making an API, you'd
> already be using it.
> 
> Regards,
> Abhijeet
> 
> On Thu, 16 Apr, 2020, 00:39 Claude Paroz,  <mailto:cla...@2xlibre.net>> wrote:
> 
> Hi all,
> 
> With the recent addition of the algorithm parameter to the
> signing.Signer class, it's now rather straightforward for Django to
> generate HS256 (non-encrypted) JSON Web Tokens.
> With a growing popularity of JS-client/Django server communications
> (DRF and al.), I think there might be some interest for Django to be
> able to generate and decode such tokens. For any other types of JWTs
> which generally require access to a cryptography module, we can
> point users to third-party libs like PyJWT (the docs should be clear
> about that).
> 
> I made a proof-of-concept PR (docs missing) here:
>  - https://github.com/django/django/pull/12728
> 
> What people here think about that proposal?
> 
> Claude

-- 
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/9f5f4df0-64d3-68aa-0ae7-302e037d406a%402xlibre.net.

Re: Generate JWTs with Django

[Claude Paroz]

For your information, I now added docs to the tentative patch:

https://github.com/django/django/pull/12728

Claude

Le 15.04.20 à 21:26, Claude Paroz a écrit :
> Thanks Abhijeet for the pointer, I know there are some rather complete
> JWT libs around, but my proposal is not about a complete package to
> manage JWT in general.
> It's rather some low level ability for Django to produce and decode
> simple HS256 JWT. Then other third-party libs could build on that
> ability to write more elaborate packages.
> 
> The main doubt I have about my proposal is whether HS256 JWTs are too
> limited for most usages or in the contrary if they are appropriate for a
> fair amount of use cases.
> 
> Claude
> 
> Le 15.04.20 à 21:13, Abhijeet Viswa a écrit :
>> Hi,
>>
>> You might want check out django-restframework-simplejwt. It requires the
>> Django Rest Framework. But, then again, if you are making an API, you'd
>> already be using it.
>>
>> Regards,
>> Abhijeet
>>
>> On Thu, 16 Apr, 2020, 00:39 Claude Paroz, > <mailto:cla...@2xlibre.net>> wrote:
>>
>> Hi all,
>>
>> With the recent addition of the algorithm parameter to the
>> signing.Signer class, it's now rather straightforward for Django to
>> generate HS256 (non-encrypted) JSON Web Tokens.
>> With a growing popularity of JS-client/Django server communications
>> (DRF and al.), I think there might be some interest for Django to be
>> able to generate and decode such tokens. For any other types of JWTs
>> which generally require access to a cryptography module, we can
>> point users to third-party libs like PyJWT (the docs should be clear
>> about that).
>>
>> I made a proof-of-concept PR (docs missing) here:
>>  - https://github.com/django/django/pull/12728
>>
>> What people here think about that proposal?
>>
>> Claude

-- 
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/87ddf575-0756-b99e-51d8-99de1b258c21%402xlibre.net.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Claude Paroz]

Le mercredi 22 avril 2020 15:06:12 UTC+2, Adam Johnson a écrit :
>
> I'd like to propose using this new full coverage of operation naming to 
> remove the "auto_MMDD" behaviour, and instead always combine 
> operations' "suggested migration names" up until a limit of say 60 
> characters. I made a commit for that here: 
> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6
> ...
> Mariusz wrote on the PR:
>
> Personally, I'm against removing auto named migrations. IMO chaining 
>> operation names is even more confusing.  
>>
>
An alternative could be to ask the user in interactive mode (and keep the 
current behaviour in non-interactive mode).

Claude

-- 
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/515d4b08-e17f-4267-800f-966146ff0886%40googlegroups.com.

Re: Management of static assets

[Claude Paroz]

Le mercredi 22 avril 2020 17:22:02 UTC+2, Carlton Gibson a écrit :
>
> ...
> *Not sure* how much of this we need to pull into Django itself? 
> compressor, say, does the whole combine and compress thing well. If we pull 
> that in are we going to do the same for image optimization? Or pull in 
> Whitenoise? Or...? For a user just with contib.staticfiles, what's the very 
> next thing we could do that would make life easier? (i.e. is "I can't run 
> webpack" top of their list?) — What can we do better in core vs a 
> third-party app? — Is that just awareness, which is not a nothing? 
> Note the "not sure" — I think about this a lot, it's a big issue, but I 
> don't have a single answer: I've got what I do, and that works for me, but 
> I see lots of people doing different with success. 
>

I fully understand that it's not necessarily the role of Django to provide 
a full backed solution to management of assets, which is indeed changing 
quickly in some aspects.
However, I think that the problem now is that Django isn't aware of global 
project or app assets (they are just lines in templates), which means that 
third-party packages must provide their own different implementation of 
asset "objects". It does also mean that Django is helpless with regards to 
any management of static assets, typically in a case like subresource 
integrity.

My opinion is still the same, that we should add basic blocks of asset 
objects in Django core, giving ability to Django to offer basic services 
that are useful for most projects, while letting third party apps to build 
upon those "blocks" to give specific functionalities that need a quicker 
development pace than Django itself.

Claude

-- 
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/10528a3d-4838-4358-804b-3f1f258a57f3%40googlegroups.com.

Re: Generate JWTs with Django

[Claude Paroz]

Hey Markus,

In fact, when I had to implement that in one of my projects, I realized 
that Django has already most tools needed to (in my opinion) properly 
handle those tokens. And indeed, this only covers HS256-type of JWTs, for 
any other type, we would recommend using a third-party package (see the 
docs type of my patch).
If we had to reimplement all the hard work of signing and verifying, I 
would not have proposed this addition to Django.

Claude

Le vendredi 24 avril 2020 16:32:27 UTC+2, Markus Holtermann a écrit :
>
> Nice work, Claude! 
>
> However, dealing with JWTs, and especially verifying them is notoriously 
> hard and fragile. Frankly, I think I'd rather see smaller libraries do one 
> job and do it well, than having Django implement an incomplete JWT spec. As 
> far as I can tell, only HS256 signing/verification is implemented, but 
> nothing else, right? 
>
> Cheers, 
>
> Markus 
>
> On Wed, Apr 22, 2020, at 3:38 PM, Adam Johnson wrote: 
> > Hi Claude 
> > 
> > JWT's are indeed popular for API's. I think if Django was being created 
> > "from the ground up" today, JWT's would be a no-brainer to include, so 
> > it seems reasonable to add some support. 
> > 
> > I've had a look at the PR, and yes it is indeed a small amount of code 
> > - and thanks for the documentation. 
> > 
> > Have you got any data on how often encrypted vs. non-encrypted JWT's 
> > are used? Personally I can't remember from the projects I've worked on 
> > which format has been used. 
> > 
> > Thanks, 
> > 
> > Adam 
> > 
> > On Wed, 22 Apr 2020 at 09:57, Claude Paroz  > wrote: 
> > > For your information, I now added docs to the tentative patch: 
> > > 
> > > https://github.com/django/django/pull/12728 
> > > 
> > >  Claude 
> > > 
> > >  Le 15.04.20 à 21:26, Claude Paroz a écrit : 
> > >  > Thanks Abhijeet for the pointer, I know there are some rather 
> complete 
> > >  > JWT libs around, but my proposal is not about a complete package to 
> > >  > manage JWT in general. 
> > >  > It's rather some low level ability for Django to produce and decode 
> > >  > simple HS256 JWT. Then other third-party libs could build on that 
> > >  > ability to write more elaborate packages. 
> > >  > 
> > >  > The main doubt I have about my proposal is whether HS256 JWTs are 
> too 
> > >  > limited for most usages or in the contrary if they are appropriate 
> for a 
> > >  > fair amount of use cases. 
> > >  > 
> > >  > Claude 
> > >  > 
> > >  > Le 15.04.20 à 21:13, Abhijeet Viswa a écrit : 
> > >  >> Hi, 
> > >  >> 
> > >  >> You might want check out django-restframework-simplejwt. It 
> requires the 
> > >  >> Django Rest Framework. But, then again, if you are making an API, 
> you'd 
> > >  >> already be using it. 
> > >  >> 
> > >  >> Regards, 
> > >  >> Abhijeet 
> > >  >> 
> > >  >> On Thu, 16 Apr, 2020, 00:39 Claude Paroz,   
> > >  >> <mailto:cla...@2xlibre.net >> wrote: 
> > >  >> 
> > >  >> Hi all, 
> > >  >> 
> > >  >> With the recent addition of the algorithm parameter to the 
> > >  >> signing.Signer class, it's now rather straightforward for Django 
> to 
> > >  >> generate HS256 (non-encrypted) JSON Web Tokens. 
> > >  >> With a growing popularity of JS-client/Django server 
> communications 
> > >  >> (DRF and al.), I think there might be some interest for Django to 
> be 
> > >  >> able to generate and decode such tokens. For any other types of 
> JWTs 
> > >  >> which generally require access to a cryptography module, we can 
> > >  >> point users to third-party libs like PyJWT (the docs should be 
> clear 
> > >  >> about that). 
> > >  >> 
> > >  >> I made a proof-of-concept PR (docs missing) here: 
> > >  >> - https://github.com/django/django/pull/12728 
> > >  >> 
> > >  >> What people here think about that proposal? 
> > >  >> 
> > >  >> Claude 
>

-- 
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/3d7304c8-79d7-4ea5-a602-15131f85b7ee%40googlegroups.com.

Re: Status of 3.1 release blockers.

[Claude Paroz]

Hi Mariusz,

I think we should also address:

https://code.djangoproject.com/ticket/30678 - GDAL 3 support

as release blocker, because more and more installations will have GDAL 3 by 
default and the backwards compatibility issues are serious. I'll try to 
prepare a patch ASAP. As this is only affecting GeoDjango projects, we 
might make an exception to the rule and fix it between alpha and beta, 
depending on the time it takes to solve it.

Claude

-- 
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/e911f152-a427-4c92-b3ab-db72a5c23ba4%40googlegroups.com.

Re: timesince 'depth' parameter

[Claude Paroz]

Le samedi 23 mai 2020 16:41:04 UTC+2, Toby Such a écrit :
>
> Maybe the logic for calculating the time before formatting could be taken 
> out of the function? That way it would be far easier to implement your own 
> custom versions of the function without copying and pasting, and makes the 
> code more readable too.
>

I like that, make it easy to customize, in the same spirit as the Truncator 
class.
Feel free to ping me regarding the strings stuff and translatability, I 
worked a bit on that in the past.

Claude

-- 
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/9dca9cb1-b2cb-4556-95e3-1f80c425c03f%40googlegroups.com.

Re: The blacklist / master issue

[Claude Paroz]

Note that the term "blacklist" only appears twice in the Django tree and 
only in comments/docs, as shown by David's patch. The first one can be 
omitted while the second one can be replaced by "exclude". That is trivial 
to do and shouldn't even require a discussion.

About replacing "whitelist" par "allowlist", I'm not totally convinced but 
will accept any community decision. It has a very small impact change in 
code (in EmailValidator).

Changing git "master" branch names is really looking ridiculous to me, but 
I can understand that it might be linked to cultural sensibilities. This 
will generate many work overhead, for what gain? A "master" is a totally 
valid word in many contexts that have nothing to do with slavery.
We should primarily fight against racism by education and our own 
day-to-day behavior.

Claude

-- 
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/d327c497-18f7-4b50-8b38-93b0c0bea330o%40googlegroups.com.

Ticket #21289 - Login rate limiting

[Claude Paroz]

Hi all,

I thought a bit about login rate limiting again in recent times.
https://code.djangoproject.com/ticket/21289

We know that there are some packages (django-ratelimit, django-defender,
etc.) that can do the job, but the main issue here is to provide a
*default* behavior for any fresh new Django project.

A must-read on this subject is:
https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

I would like to suggest one mitigation measure for default Django, which
seems to me the least controversial, considering that hard-locking by
username and/or ip address can open Denial of Service vectors which may
or may not be acceptable for some sites.

My suggestion is to add a time delay of 5 seconds in the
contrib.auth.forms.AuthenticationForm after the first failure on any
username. This choice of 5 seconds is a compromise between not too much
annoying users after a failed login attempt, and still set a significant
throttling limit for some brute force attacks. You can consider that
after a failed login, a real user will spend at least 2-3 seconds just
to re-enter a new password and re-submit the form, so the real wait
penalty should not be more than 2-3 seconds.

This is of course NOT the panacea against all type of brute force
attacks, as you can read on the OWASP article above. But it appears to
me as a reasonable measure that can be widely accepted by most Django
projects that use the default authentication form.

The WIP PR is available here:
https://github.com/django/django/pull/13242

Kind regards,

Claude
-- 
www.2xlibre.net

-- 
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/49b80757-9117-fa11-3f53-731af1f0c206%402xlibre.net.

Re: Ticket #21289 - Login rate limiting

[Claude Paroz]

Hi Adam,

Le lundi 27 juillet 2020 16:55:35 UTC+2, Adam Johnson a écrit :

> Hi Claude,
>
> A delay of 5 seconds seems quite long. Often I fail to log into a site due 
> to mis-selection of credentials from my password manager, so I can resubmit 
> a login form within 1-2 seconds.
>

That 5-secs choice is debatable, we can agree on a shorter delay. We may 
also wait for the second or third failure before throttling (suggested on 
the PR).
 

> A real rate-limiting solution has the advantage of buckets of requests per 
> time period, allowing users a few rapid attempts before being locked.
>
> Additionally, the default PBKDF2 hasher already enforces a (smaller) 
> arbitrary delay via its algorithm iterations. I can't find a source but I 
> think I remember reading it should be tuned to take about 100ms. This is 
> about 1.5 orders of magnitude less than a 5 second delay, which is perhaps 
> not so significant in terms of password brute-forcing (less difference than 
> one extra password character). Not sure if 100ms is where Django's current 
> default ends up on a modern CPU, but we probably aren't far off given we 
> increase the iterations according to a formula that roughly tracks Moore's 
> law.
>
> I'd rather see something like django-ratelimit merged to core. It's more 
> general purpose so users can reuse and customize it, and we could 
> potentially use it for other features in Django too.
>

Sure, that might be the better long-term solution. However, I'm afraid this 
will be delayed forever... (note the ticket is already 7 years old). In my 
opinion, a "battery-included" framework like Django should include at least 
a basic brute force protection. That's why I'd like to push some minimal 
mitigation for Django 3.2, then we can always add a more elaborate tooling 
set later.

Claude
 

> On Mon, 27 Jul 2020 at 12:13, Claude Paroz  > wrote:
>
>> Hi all,
>>
>> I thought a bit about login rate limiting again in recent times.
>> https://code.djangoproject.com/ticket/21289
>>
>> We know that there are some packages (django-ratelimit, django-defender,
>> etc.) that can do the job, but the main issue here is to provide a
>> *default* behavior for any fresh new Django project.
>>
>> A must-read on this subject is:
>> https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks
>>
>> I would like to suggest one mitigation measure for default Django, which
>> seems to me the least controversial, considering that hard-locking by
>> username and/or ip address can open Denial of Service vectors which may
>> or may not be acceptable for some sites.
>>
>> My suggestion is to add a time delay of 5 seconds in the
>> contrib.auth.forms.AuthenticationForm after the first failure on any
>> username. This choice of 5 seconds is a compromise between not too much
>> annoying users after a failed login attempt, and still set a significant
>> throttling limit for some brute force attacks. You can consider that
>> after a failed login, a real user will spend at least 2-3 seconds just
>> to re-enter a new password and re-submit the form, so the real wait
>> penalty should not be more than 2-3 seconds.
>>
>> This is of course NOT the panacea against all type of brute force
>> attacks, as you can read on the OWASP article above. But it appears to
>> me as a reasonable measure that can be widely accepted by most Django
>> projects that use the default authentication form.
>>
>> The WIP PR is available here:
>> https://github.com/django/django/pull/13242
>>
>> Kind regards,
>>
>> Claude
>> -- 
>> www.2xlibre.net
>>
>

-- 
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/7720e6a7-b214-4602-b576-c0277b60e749o%40googlegroups.com.

Re: Ticket #21289 - Login rate limiting

[Claude Paroz]

Le mardi 28 juillet 2020 08:31:51 UTC+2, Aymeric Augustin a écrit :
>
> - We should focus this on usernames and ignore IP addresses, as most sites 
> are behind a reverse proxy of some kind and no one handles X-Forwarded-For 
> headers right (even Heroku doesn't care — when I reported they were 
> vulnerable to XFF injection, their security team [or, more accurately, 
> their subcontractors] didn't understand the report, even after several 
> rounds of explanation and a working proof of concept)
>

What if we consider REMOTE_ADDR? In the worst case, it is not filled or 
filled with the same proxy address for all requests and we found ourselves 
in the same case where it is not considered at all. In the best case, it is 
properly filled and then the user is getting a bit better DOS protection. 
Am I missing something?

Claude

-- 
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/77d835d8-85bc-4c7b-ae99-9f27cb4a6543o%40googlegroups.com.

Re: Rethink (?) how we handle security headers.

[Claude Paroz]

By the way, while reviewing the SecurityMiddleware, I would suggest that 
the redirection part be moved to a different middleware.
http to https redirection should preferably be done at the Web server 
level, and for those doing that properly, they still pay for the unneeded 
(albeit small) overhead of the `SecurityMiddleware.process_request`.

> 3. For new headers I think we could add a setting called e.g. ADD_HEADERS 
- a dict of keys to values that 
> CommonMiddleware (or similar) could add to outgoing responses' headers. 

+1 to that proposal.

Claude

-- 
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/3da2e385-551e-4905-83e8-7f2b99896f18o%40googlegroups.com.

Anonymous access to the forum

[Claude Paroz]

Hello,

Am I the only one or did Google closed anonymous access to Google groups?
Could it be a setting in the group config?

In my opinion, it is not acceptable for the project if accessing the
Django group posts require authentication.

If someone has more information about that change, that would be great.

Claude
-- 
www.2xlibre.net

-- 
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/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.net.

Re: Anonymous access to the forum

[Claude Paroz]

Looks like it works again like before, now.
It may have been a temporary "accident"…

Claude

-- 
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/2bb2c81b-8ec3-4ec2-8f3d-e184ca7fd7aeo%40googlegroups.com.

Re: Anonymous access to the forum

[Claude Paroz]

Maybe I spoke too quickly.
Now I'm asked for login again :-(

Claude

Le mardi 18 août 2020 13:27:35 UTC+2, Claude Paroz a écrit :
>
> Looks like it works again like before, now.
> It may have been a temporary "accident"…
>
> Claude
>
>

-- 
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/87b5460e-9979-498e-b74e-a20e06d0f2aeo%40googlegroups.com.

Re: French translation - Mispelling

[Claude Paroz]

Le vendredi 30 octobre 2020 à 23:14:07 UTC+1, hcharpent...@gmail.com a 
écrit :

> I saw a spelling error in a menu, and I thought I could contact some 
> french translators team or something? (It would be much easier to me to 
> explain it in French).
>
 
Adam's suggestion is good, but you can also directly contact me.

Claude (@2xlibre.net)

-- 
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/286e06ad-a59a-43cd-b18d-7fbc72bb8623n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Claude Paroz]

Like others in this thread, I think that dropping Python 3.7 for Django 4.0 
is too aggressive, even if it complies with the written policy.
So I would plead for an exception and ask to keep Python 3.7 for Django 4.0 
at least. Is there support for this idea here?

Claude

-- 
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/08401d40-1a0a-414c-9c1b-bcc443e3bfbdn%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Claude Paroz]

When I see that Python 3.7 will be supported the whole time of the 4.0 
support period, it's enough for me. For the rest, let the people choose and 
see by themselves through the support graphs what their interest is. I 
think we should stop patronizing developers.

Claude

-- 
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/be97212d-00b8-4f9a-b8c7-1753580b8123n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Claude Paroz]

Le mercredi 20 janvier 2021 à 16:19:09 UTC+1, timog...@gmail.com a écrit :

> ... It seems like this policy makes it more likely that the last Django 
> version to support a Python would be a non-LTS rather than an LTS. Maybe 
> that's fine.


In my opinion, that's fine. As Python supported versions for Django 
releases are documented, people can decide by themselves their choice and 
assume it. It's not like it has come by surprise.

Claude

-- 
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/c05845d8-7e25-437f-9683-7474a80d75ffn%40googlegroups.com.

Re: Allow turning off fuzzy matching for makemessages (Reopen #10852)

[Claude Paroz]

As you can see in the ticket you mention (see last comment), it is already 
possible to do so by adding a custom version of the makemessages command in 
your project.

Hope this helps,

Claude

-- 
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/57856ae7-3c31-4da1-9915-5a3dd35ed016n%40googlegroups.com.

Re: Question: django.contrib.gis GDAL support of /vsi*

[Claude Paroz]

Hi Jordi,

Our GDAL Raster expert is Daniel Wiesmann (https://github.com/yellowcap), 
you may try to ping him somehow so that he can give his lights on the 
subject here.

And how should I properly enable the `gis_tests` to confirm everything 
> works as expected?
>

If you use settings configured  with a spatially-enabled database, the 
gis_tests should run (runtests.py --settings=...).

Claude

-- 
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/cbb15069-7f84-4b53-9eca-a8d4effbb56dn%40googlegroups.com.

Removal of USE_L10N setting

[Claude Paroz]

Hi,

I eventually took some time to try implementing an idea I had since some 
time: remove the USE_L10N setting.

The draft PR is here:
https://github.com/django/django/pull/14519

My motivations are:
 - one less setting
 - simplication of the code and logic regarding USE_18N/USE_L10N/USE_TZ 
settings

 - a user-friendly default behavior

As usual, the main drawback is backwards compatibility. The possibly 
affected projects are those having USE_L10N = False, along with multiple 
LANGUAGES.


Is this a good idea?
I would also like to get opinions here about the compatibility issues.
Are they acceptable?
Is there a possible deprecation path?

Regards,

Claude
--
www.2xlibre.net

--
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/8cb0c69a-1900-30b4-51de-e61d6cd66a8a%402xlibre.net.

Re: Removal of USE_L10N setting

[Claude Paroz]

Le dimanche 13 juin 2021 à 01:09:26 UTC+2, re...@fleschenberg.net a écrit :

> I have run into bugs because template authors forgot to unlocalize 
> values, in particular database IDs. These bugs often go unnoticed for 
> quite a while because they only show up once you reach 1000 database 
> rows. Forgetting to localize a value would typically be a much more 
> obvious bug. 
>

I understand this concern. I wonder if that could be solved separately, for 
example by:
 - returning int subclasses from AutoField's to_python (a bit like 
str/SafeString for handling escaping)
 - not localizing those integers, unless use_l10n is forced (True)
Does this look like a plan (even without touching USE_L10N)?

On 6/11/21 6:50 PM, Claude Paroz wrote: 
> > Is there a possible deprecation path? 
> Maybe add a system check that warns if the setting is still present?

Sure, the warning could suggest some tips or redirect to some part of the 
docs.

Thanks for the input.
Claude

-- 
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/cf8b1556-551c-45b0-889b-2ccf885acab3n%40googlegroups.com.

RSS access to Google groups?

[Claude Paroz]

Hi,
It looks like from several days now, access to Google groups by RSS feeds 
is producing an error.
E.g. 
https://groups.google.com/forum/feed/django-developers/msgs/rss.xml?num=50

Does anyone know if this means that Google stopped supporting reading 
groups by RSS?

Claude

-- 
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/2fcd34e2-a8c9-4df5-a491-6088bd9ce00cn%40googlegroups.com.

Re: RSS access to Google groups?

[Claude Paroz]

Thanks a lot Jason for the link to the support thread. Let those who rely 
on the RSS group feed go and upvote the thread! 

-- 
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/c2056885-7b11-4f18-b2f6-988041517b09n%40googlegroups.com.

Re: RSS access to Google groups?

[Claude Paroz]

Le vendredi 30 juillet 2021 à 10:14:51 UTC+2, carlton...@gmail.com a écrit :

> Upvoted, but I'm not holding out hope. 🤨
>
> There was discussion a while back about moving the discussion here to the 
> Forum. 
> Perhaps it's time to think again about doing that? 
> (Andrew and Tom were discussing migrating the history. I don't think we 
> should block on that.)
>

+1 for doing that. Maybe we could start by moving django-i18n and geodjango 
lists?

Claude

-- 
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/26e1acf8-7f18-4386-88bd-dfbd4c41a263n%40googlegroups.com.

Re: RSS access to Google groups?

[Claude Paroz]

> Maybe we could start by moving django-i18n and geodjango lists?
>
>
> So, rough steps: 
>
> 0: Update docs to point to Forum rather than Google Groups. 
> 1. Post on django-i18n and geodjango lists that the action is now on the 
> Forum. https://forum.djangoproject.com
> 2. We can create new sub-categories (say) under "Django Internals" if you 
> think? 
>

Nice. I would start with step 2 so we can directly point to sub-categories 
in docs.

Claude

-- 
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/33b413a6-7f38-4c38-9032-f82182f6539bn%40googlegroups.com.

Re: Removal of USE_L10N setting

[Claude Paroz]

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

What would be most interesting to know is whether setting USE_L10N to True 
would cause issues in your projects.

Claude

-- 
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/7da3ed2b-8d31-4c9e-9423-c8eac33f93cfn%40googlegroups.com.

Re: RSS access to Google groups?

[Claude Paroz]

A question received privately: imagine someone wants to follow the 
Internationalization topic by email, is it possible and how? There is a 
Mailing list mode in the forum prefs, but then I guess that this will send 
messages from all forum topics.

-- 
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/d9fb0ba1-3dd9-47d9-9fb6-5cd1a633788cn%40googlegroups.com.

Re: RSS access to Google groups?

[Claude Paroz]

So I activated mailing list mode, and chose i18n/geodjango in the watch 
list. I'm still receiving all forum messages by email, which is evidently 
not an option. If I have to manually mute/exclude all other categories, it 
will not be very practical either, as I would have to do it again each time 
new topics appear. Any other "magical" solution ? 

Le vendredi 13 août 2021 à 18:57:16 UTC+2, carlton...@gmail.com a écrit :

> Hey Claude. 
>
> Here: 
>
> https://forum.djangoproject.com/my/preferences/categories
>
> You can set to watch particular categories (or just first posts in a 
> thread or … ) 
>
> C. 
>
> On 13 Aug 2021, at 18:24, Claude Paroz  wrote:
>
> A question received privately: imagine someone wants to follow the 
> Internationalization topic by email, is it possible and how? There is a 
> Mailing list mode in the forum prefs, but then I guess that this will send 
> messages from all forum topics.
>
> -- 
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/d9fb0ba1-3dd9-47d9-9fb6-5cd1a633788cn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/d9fb0ba1-3dd9-47d9-9fb6-5cd1a633788cn%40googlegroups.com?utm_medium=email&utm_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/5464cff4-d6ef-4b35-851c-e081359b4738n%40googlegroups.com.

Re: RSS access to Google groups?

[Claude Paroz]

So according to my experience and confirmed by 
https://discourse.mozilla.org/t/how-do-i-use-discourse-via-email/15279, 
mailing list mode is not really an option, unless you want to triage 
interesting email by mail client filters.


I'm trying now different combinations of preferences, but if anyone has 
something to share about those settings, it would be welcome.


Claude

Le 13.08.21 à 22:53, Claude Paroz a écrit :
So I activated mailing list mode, and chose i18n/geodjango in the watch 
list. I'm still receiving all forum messages by email, which is 
evidently not an option. If I have to manually mute/exclude all other 
categories, it will not be very practical either, as I would have to do 
it again each time new topics appear. Any other "magical" solution ?


Le vendredi 13 août 2021 à 18:57:16 UTC+2, carlton...@gmail.com a écrit :

Hey Claude.

Here:

https://forum.djangoproject.com/my/preferences/categories
<https://forum.djangoproject.com/my/preferences/categories>

You can set to watch particular categories (or just first posts in a
thread or … )

C.


On 13 Aug 2021, at 18:24, Claude Paroz  wrote:

A question received privately: imagine someone wants to follow the
Internationalization topic by email, is it possible and how? There
is a Mailing list mode in the forum prefs, but then I guess that
this will send messages from all forum topics.


--
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/7a7909f9-bc77-fed6-d1be-9d9cde2eced0%402xlibre.net.

Re: makemessages management command should not touch POT-Creation-Date

[Claude Paroz]

As the won't fixer person 11 years ago, I'm also more in favour of the 
change now, even if it changes a bit the meaning of POT-Creation-Date from 
"last time the pot file was updated" to "last time a change was detected in 
the pot file".

-- 
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/fab66810-4722-46fe-a5fa-75111d7e6498n%40googlegroups.com.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Claude Paroz]

Le mardi 8 août 2017 01:45:55 UTC+2, Tim Graham a écrit :

> Has anyone changed their thinking in the last few months? If not, I guess 
> we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.
>

I am not strongly opposed to dropping 3.4 support, but I still think we 
should keep it for Django 2.0.
The speed improvements in 3.5/3.6 are still available if you run more 
recent versions in your own projects.
I have not yet read any compelling reason to drop Python 3.4 support now.

Claude

-- 
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/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Claude Paroz]

>
>
> Perhaps we can find a compromise to ship this feature in the alpha with 
> minimal docs and complete the docs later?
>
>
I'm in favour.

Claude 

-- 
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/54648204-45c4-474c-a9e4-ccdc3de3f1de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MariaDB, official support

[Claude Paroz]

Hi,

I would like to push a bit for that functionality in Django 2.1. Adam, any 
progress?

In https://github.com/django/django/pull/7778, you talked about a better 
plan. Show us your plan, please :-)

Claude

-- 
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/2c525ee9-ed0c-4b4b-9dd2-f4750496b2c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation Error with Latin characters

[Claude Paroz]

Hi Adrian,

I don't see anything related to Django development in your post. Maybe this 
was more for the django-users mailing list?

Claude

Le jeudi 30 novembre 2017 02:39:31 UTC+1, Adrian Mansilla a écrit :
>
> I am using the function 'validate_password (password, new_user)' and I 
> have my settings configured in Spanish, the problem comes when the 
> validate_password function raises an error with the word 'contraseña' and 
> shows me this error:
> ValidationError: [u'La contrase\xf1a es demasiado similar a la de nombre 
> de usuario.']
> I am using python 2.7 and Django 1.11.4
>
> This is the traceback:
>
> Traceback (most recent call last):
>   File 
> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/core/handlers/exception.py",
>  line 41, in inner
> response = get_response(request)
>   File 
> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/core/handlers/base.py",
>  line 187, in _get_response
> response = self.process_exception_by_middleware(e, request)
>   File 
> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/core/handlers/base.py",
>  line 185, in _get_response
> response = wrapped_callback(request, *callback_args, **callback_kwargs)
>   File 
> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/contrib/auth/decorators.py",
>  line 23, in _wrapped_view
> return view_func(request, *args, **kwargs)
>   File 
> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/utils/decorators.py",
>  line 185, in inner
> return func(*args, **kwargs)
>   File "/Users/adrianmansilla/Documents/sisgos/sisgos/company/views.py", line 
> 129, in new_user
> validate_password(password, new_user)
>   File 
> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/contrib/auth/password_validation.py",
>  line 56, in validate_password
> raise ValidationError(errors)
> ValidationError: [u'La contrase\xf1a es demasiado similar a la de nombre de 
> usuario.']
>
>

-- 
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/41974e26-5baf-41bd-90c6-bd5232f2a5c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug in django.contrib.auth.forms.UserChangeForm's password field's help_text setup

[Claude Paroz]

This looks like a reasonable improvement. Please open a ticket, and 
possibly a pull request. Thanks!

Claude

Le vendredi 22 décembre 2017 03:29:56 UTC+1, Shaheed Haque a écrit :
>
> Hi,
>
> In Django 2.0, the help_text for the password field of 
> django.contrib.auth.forms.UserChangeForm looks like this:
>
> help_text=_(
> "Raw passwords are not stored, so there is no way to see this "
> "user's password, but you can change the password using "
> "this form."
> ),
>
> where the curly brackets are dealt with i nthe __init__() like this:
>
> self.fields['password'].help_text = 
> self.fields['password'].help_text.format('../password/')
>
> As far as I can see, this works just fine when the form is used as-is when 
> logging in to the admin site. However, the hardcoded path "../password/" 
> breaks in other contexts. In such other places, I see that doing this 
> resolves the issue that ../password does not point to the right place:
>
> from ... import reverse
> self.fields['password'].help_text = 
> self.fields['password'].help_text.format(reverse('password_change'))
>
> I have checked, and my 
> /usr/local/lib/python3.6/dist-packages/django/contrib/auth/urls.py does use 
> the name implied here, so as far as I can see, it ought to be a safe fix. 
> However, I am not familiar enough with Django to be sure of that (or indeed 
> if this use case constitutes a bug), so am posting here for advice before 
> opening a defect. Please advise if a defect is warranted/desired.
>
> Thanks, Shaheed
>
>
>

-- 
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/997ff992-f173-4475-98b2-a5a695664784%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DJANGO ET BASE DE DONNEES

[Claude Paroz]

Bonjour Alphonse,

Cette liste de discussion n'utilise que l'anglais et est dédiée au 
développement de Django lui-même.
La liste francophone se trouve ici :
https://lists.afpy.org/mailman/listinfo/django

Cordialement.

Claude

Le lundi 29 janvier 2018 14:52:27 UTC+1, Alphonse Aka a écrit :
>
> Salut  les membres de Django  Developpers , je me nomme Alphonse Aka  ,  
> je vis en côte d'ivoire , je suis un développeur  en  python-Django  et je 
> me suis inscrit  aujourd'hui  sur votre site pour devenir membre de Django  
> Developpers et bénéficier aussi de votre conseils  et aussi de votre aide 
> lorsque  je suis sur un projet ,  c'est maintenantj'apprend  Django  
> Rest  Framework et j'aime ,  pour l'instant j'ai pu  avancer  sur  django  
> mais c'est  la  base de données  avec  django , j'ai un problème   ,  
> j'arrive pas à  afficher les informations du client lorsque  je  saisi tous 
> ses informations  du  client ,  svp , j'ai besoin de votre aide.
>

-- 
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/5d515b9a-50e0-4064-ae4a-7d30f9895b8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Humanize naturaltime alternative phrasing

[Claude Paroz]

I think I'd rather do some refactoring so that creating its own filter with 
custom strings is easier.
I played a bit with the idea and obtained that:
https://github.com/claudep/django/commit/b776f120f180

Claude

-- 
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/41d8f9b7-d44b-4907-9cb1-961fbbb13dca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Default upload permissions

[Claude Paroz]

Hi all,

https://code.djangoproject.com/ticket/28540 explains that unless 
FILE_UPLOAD_PERMISSION is set (not set by default), uploaded file 
permissions are often a mix of 0o600 and 0o644 (or another value 
depending of the default umask), based on the upload method (memory or 
temporary file) which itself vary depending on the file size.


My opinion is like the reporter's that those permissions should not vary 
depending on the used upload method, that's why I suggested the PR 
(probably not the cleanest one!):

https://github.com/django/django/pull/10116

Please read the conversation and tell us if you have anything to add 
that could help make a decision. Thanks.


Claude
--
www.2xlibre.net

--
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/c39e0821-4634-7ae3-983b-9554021f04f4%402xlibre.net.
For more options, visit https://groups.google.com/d/optout.

App static files (#29586)

[Claude Paroz]

Hi,

I just created a new feature request [1] to be able to define static 
files per application, including a POC patch [2].


[1] https://code.djangoproject.com/ticket/29586
[2] https://github.com/django/django/pull/10218

Feel free to discuss it here for general discussion on the feature 
utility, or comment on the ticket or on the pull request for 
implementation details.


Cheers,

Claude
--
www.2xlibre.net

--
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/fddae41c-d53b-20fc-0b24-444f89e64f52%402xlibre.net.
For more options, visit https://groups.google.com/d/optout.

Re: App static files (#29586)

[Claude Paroz]

Le lundi 23 juillet 2018 18:12:32 UTC+2, Florian Apolloner a écrit :
>
> Hi Claude,
>
> a few things after a quick glance at it. Overall the feature seems rather 
> simple and I do not see any reason why this would have to be in core from 
> the start; ie it could easily evolve as a 3rd party app. 
>

I purposely kept minimal functionality to start with. The idea is to have a 
minimal common structure in core, so as 3rd party apps can build upon that 
minimal structure and add more functionality. e.g. more Asset subclasses 
can be created to customize behavior.
 

> I am not that much into frontend dev, but from my experience a few things 
> popped up rather quickly:
>
>  * I generally do not load all js/css in bulk, but rather only the 
> essential stuff in  and the rest before the  ends. (or even 
> just selecting files by type; css vs js etc…)
>

I think that once you have an asset list, you can program the logic 
specific to your application. The site_static template tag could be 
considered mainly as an implementation example.
 

>  * The app level seems to be a rather coarse grained separation, I could 
> imagine people wanting more control over it without generating more apps 
> for separation.
>

Once again, one can program a more specific logic by Asset subclasses in 
the app config assets. A JS() subclass could accept a 'section' parameter 
which could then be used to segment asset rendering. 
 

>  * How would support for subressource integrity etc look like; integration 
> with the storage system would be interesting here
>

I think this is typically something that should be trivial to implement 
after this patch is in core. It might be as simple as adding an appropriate 
kwarg to the Asset() class.
 

>  * Any thoughts on asset pipelines?
>

Sure, the idea is to put a base structure in place to support such 
functionalities at a later stage (in core or as 3rd party like 
django-compressor). 

Thanks for your input!

On Monday, July 23, 2018 at 5:36:05 PM UTC+2, Claude Paroz wrote:
>
> Hi, 
>
> I just created a new feature request [1] to be able to define static 
> files per application, including a POC patch [2]. 
>
> [1] https://code.djangoproject.com/ticket/29586 
> [2] https://github.com/django/django/pull/10218 
>
> Feel free to discuss it here for general discussion on the feature 
> utility, or comment on the ticket or on the pull request for 
> implementation details. 
>
> Cheers, 
>
> Claude 
> -- 
> www.2xlibre.net 
>

-- 
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/8601fa06-0b66-487d-8d76-165f8f334f65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: App static files (#29586)

[Claude Paroz]

Le lundi 23 juillet 2018 20:32:55 UTC+2, Florian Apolloner a écrit :
>
> Hi Claude,
>
> On Monday, July 23, 2018 at 8:14:23 PM UTC+2, Claude Paroz wrote:
>>
>> Sure, the idea is to put a base structure in place to support such 
>> functionalities at a later stage (in core or as 3rd party like 
>> django-compressor). 
>>
>
>  I am just a little bit worried about adding this without any concrete 
> plan on how 3rd party apps are going to use it. What speaks against trying 
> this outside of core like channels? (I'll happily put it under the django 
> umbrella, but core seems a little bit fast tracked to me).
>
>
I think that such little code doesn't make much sense as a 3rd party app. 
Either we consider it a common base to build upon by 3rd parties or we 
conclude that it isn't worth to have such a base. 
One of the goal of this thread is to hear from potential users of this 
proposed API.
I'll see if I can add subresource integrity support to demonstrate a 
potential added value.

Claude

-- 
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/4cfce3d2-2b66-49be-ad1b-e25f98659713%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.