Extended category support for feeds

[Pavlo Kapyshin]

Hello,

I’ve made a patch that adds ability to specify “scheme” (or “domain”, for RSS)
and “label” on  elements in RSS and Atom1 feeds. Could you please
look at it and maybe suggest some improvements?

https://github.com/PavloKapyshin/django/commit/9c03f13d2442f8dacc98514e1f5d1a332bc1dfc1

There is relevant ticket: https://code.djangoproject.com/ticket/27792

-- 
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/CA%2BAo3RT_2HVAeLsf%2BOZ6KK%2B3_%2B2vP-oe%3DVin5RMq%3DN16BzZcXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

[Shai Berger]

On Sunday 29 January 2017 22:54:12 Proxy wrote:
> 
> Actually django.contrib.settings needs to be SWAPPABLE. Then it will
> receive +100. (Oooohh... Someone already proposed this. Even with code
> sample -> https://code.djangoproject.com/ticket/22779. 3 years ago and
> ticket still open... How typical... :/)
> 
> 
> In my project I'm case #2, but I still need a bunch of additional fields to
> provide for Site. Icons, descriptions, https flags. Think with SaaS and
> you'll know the drill.
> 

In that case, and until Site becomes swappable, you should be able to do what 
we all did before User was swappable: Define a "SiteProfile" model, with a 1-1 
relationship to Site, where you can add fields to your heart's content.

> Currently making it possible equals ton of hackish lines and definitely
> more DB queries.
> 

So, could you explain why that is the case?

Shai.

Re: Methodology for increasing the number of PBKDF2 iterations

[Martin Koistinen]

*IMPORTANT NOTICE:* I've just made an important change to the Google Docs 
Sheet here: 
https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing

Realizing that most security policies make requirements such as "At least 1 
character must be a numeral", etc. for other character classes, I've 
adjusted this sheet to take this into account *along with the resulting 
reduction of password strength that comes with it.* I do recognize that 
these symbol-requirements policies are there to force people to choose 
passwords that use a broader set of symbols which has the desired effect of 
raising password strength, but the actual, theoretical maximum entropy of 
the resulting passwords is *significantly *lowered as a result.

As a result, a 8-character password formed with at least 1 of each of these 
sets:

   - numerals (10);
   - lower-case letters (26);
   - upper-case letters (26);
   - and punctuation symbols (10-ish);

will offer *at most* 40.7 bits of entropy.

Passwords of this level of strength, when used on a system that uses 3 
iterations of PBKDF2 will be quickly and easily cracked by virtually any 
serious attacker. 100,000 iterations isn't really any better.

-- 
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/356048aa-d124-4088-af2f-1ad253fb9992%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

[Scot Hacker]

+1 for this change. 

This issue bites our team every time we copy a db from production to dev or 
stage or local, and certain features break because of the mis-pointed Sites 
setting.  

./s

-- 
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/903506e5-5b77-4e19-a028-3e714927b14e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Inconsistencies in Storage API

[Melvyn Sopacua]

On Monday 30 January 2017 08:47:10 Tim Graham wrote:
> I meant: where does Django call that method that's causing a problem
> for your use case?

It doesn't. But both listdir() and now that I'm looking, also path() are 
FileSystemStorage (or better: Hierarchial storage) artifects, that don't belong 
in 
Storage. Either that, or mkdir, basename, join and dirname should be 
implemented in 
Storage in the same manner. Those four are missing for my use case:

*def generate_thumbs(*self, instance, force*=False*, ***args, kwargs*) *-> 
*None:*"""Generate thumbnails for each (widht, height) tuple in 
self.sizes.
Called from signal.post_save.

/:param/ instance: The model instance being saved./:type/ instance: 
ModelKernel
/:param/ force: force saving/:type/ force: bool"""file_field *= 
/getattr/(*instance, 
self.name*)  */# type: ImageFieldFile/file_field.open*()*original *= 
*Image.open*(*file_field.file*)  */# type: Image.Image/filename *= 
*os.path.basename*(*file_field.path*)*base_path *= 
*os.path.dirname*(*file_field.path*)*base_url *= 
*os.path.dirname*(*file_field.url*)
*changed *= *0thumb_store *= *self._get_thumbnail_store*(
*instance.get_model_info*('model_name')*, instance.pk*)for *dimensions 
*in 
*self.sizes*:*combined *= *self.dimension_str*(*dimensions*)
*thumb_path 
*= *os.path.join*(*base_path, combined, filename*)if not 
*file_field.storage.exists*(*thumb_path*) or *force*:
*self.make_container*(*thumb_path*)*thumb *= *original.copy*()  
  
*thumb.thumbnail*(*dimensions*)*thumb.save*(*thumb_path*)   
 
*thumb_url *= *os.path.join*(*base_url, combined, filename*)
*thumb_store.thumbs[combined] *= {'path': *thumb_path,  
  *'url': 
*thumb_url*}*changed *+= *1

*if *changed*:*thumb_store.save*()

*
(ModelKernel is simply models.Model with a get_model_info() method that 
provides 
read-only access to some meta class properties and some other goodies tacked on 
for the project in question).

make_container:
*def make_container(*self, filename*):*container *= 
*os.path.dirname*(*filename*)if not *os.path.exists*(*container*):
if not 
*os.path.exists*(*os.path.dirname*(*container*)):
*self.make_container*(*container*)*mkdir*(*container, 
settings.FILE_UPLOAD_DIRECTORY_PERMISSIONS*)

*

thumb_store is:
*class ThumbnailStore(*models.Model*):*image_model *= 
*models.CharField*(*max_length*=*200*)*image_model_pk *= 
*models.CharField*(*max_length*=*63*)*image_field_name *= 
*models.CharField*(*max_length*=*63*)*thumbs *= *HStoreField*()

class Meta:*unique_together *= ('image_model'*, *'image_model_pk'*, 
*'image_field_name')*

So my objective below is to either not have anything in Storage that deals with 
a 
hierarchy or support a hierarchy completely.

> 
> On Monday, January 30, 2017 at 11:43:27 AM UTC-5, Melvyn Sopacua wrote:
> > On Monday 30 January 2017 08:16:20 Tim Graham wrote:
> > > Hi, could you point to where the problematic storage.listdir()
> > > call is
> > > 
> > > in Django?
> > 
> > Sure.
> > 
> > 
> > https://docs.djangoproject.com/en/1.10/ref/files/storage/#django.cor
> > e.files.storage.Storage.listdir> 
> > > On Monday, January 30, 2017 at 11:02:32 AM UTC-5, Melvyn Sopacua wrote:
> > > > Hello,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > the current Storage API has some inconsistencies and in short
> > > > it's
> > > > 
> > > > impossible to write anything that requires a directory to be
> > > > made
> > > > 
> > > > (if
> > > > 
> > > > storage is FileSystemStorage) in an implementation agnostic way.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Aside from that, there's a listdir() method that only makes
> > > > sense in
> > > > 
> > > > a FileSystemStorage based implementation (DB storage could
> > > > emulate
> > > > 
> > > > it, but it isn't natural).
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > So, I had two ideas to fix it and would like to know developer
> > > > 
> > > > preference>
> > > > 
> > > > before filing a PR:
> > > > 
> > > > 1. Remove FileSystemStorage API's from Storage (specifically
> > > > 
> > > > listdir)
> > > > 
> > > > and make save() do all the work to save the file, where the only
> > > > 
> > > > acceptable failures are outside Django's control (read-only
> > > > 
> > > > mounts, (table-)space issues, etc)
> > > > 
> > > > 2. Change listdir() to list_container and add methods that
> > > > handle
> > > > 
> > > > Storage containers: abstract things that hold the file. save()
> > > > 
> > > > either
> > > > 
> > > > deligates to container methods or requires that container exists

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  

Re: Inconsistencies in Storage API

[Tim Graham]

I meant: where does Django call that method that's causing a problem for 
your use case?

On Monday, January 30, 2017 at 11:43:27 AM UTC-5, Melvyn Sopacua wrote:
>
> On Monday 30 January 2017 08:16:20 Tim Graham wrote:
>
> > Hi, could you point to where the problematic storage.listdir() call is
>
> > in Django?
>
>  
>
> Sure.
>
>
> https://docs.djangoproject.com/en/1.10/ref/files/storage/#django.core.files.storage.Storage.listdir
>
>  
>
> > On Monday, January 30, 2017 at 11:02:32 AM UTC-5, Melvyn Sopacua wrote:
>
> > > Hello,
>
> > > 
>
> > > 
>
> > > 
>
> > > the current Storage API has some inconsistencies and in short it's
>
> > > impossible to write anything that requires a directory to be made
>
> > > (if
>
> > > storage is FileSystemStorage) in an implementation agnostic way.
>
> > > 
>
> > > 
>
> > > 
>
> > > Aside from that, there's a listdir() method that only makes sense in
>
> > > a FileSystemStorage based implementation (DB storage could emulate
>
> > > it, but it isn't natural).
>
> > > 
>
> > > 
>
> > > 
>
> > > So, I had two ideas to fix it and would like to know developer
>
> > > preference> 
>
> > > before filing a PR:
>
> > > 1. Remove FileSystemStorage API's from Storage (specifically
>
> > > listdir)
>
> > > and make save() do all the work to save the file, where the only
>
> > > acceptable failures are outside Django's control (read-only
>
> > > mounts, (table-)space issues, etc)
>
> > > 2. Change listdir() to list_container and add methods that handle
>
> > > Storage containers: abstract things that hold the file. save()
>
> > > either
>
> > > deligates to container methods or requires that container exists
>
> > > before saving.
>
> > > 
>
> > > The use case that prompted this was that I've created an ImageField
>
> > > subclass that generates thumbnails in model-specified sizes and puts
>
> > > them in directories below the one of the current image (named
>
> > > widthxheight, f.e. 64x64). In doing so I had to go outside
>
> > > FieldFile.storage to have the intermediate directory created, so my
>
> > > code now isn't portable to different Storage subclasses.
>
> > > 
>
> > > 
>
> > > 
>
> > > Is there any interest in either of these (another?) approach and if
>
> > > so, what preference?
>
> > > 
>
> > > 
>
> > > Melvyn Sopacua
>
>  
>
> -- 
>
> Melvyn Sopacua
>

-- 
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/688d1474-8891-44c7-95d6-1e797d099776%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Inconsistencies in Storage API

[Melvyn Sopacua]

On Monday 30 January 2017 08:16:20 Tim Graham wrote:
> Hi, could you point to where the problematic storage.listdir() call is
> in Django?

Sure.
https://docs.djangoproject.com/en/1.10/ref/files/storage/#django.core.files.storage.Sto
rage.listdir

> On Monday, January 30, 2017 at 11:02:32 AM UTC-5, Melvyn Sopacua wrote:
> > Hello,
> > 
> > 
> > 
> > the current Storage API has some inconsistencies and in short it's
> > impossible to write anything that requires a directory to be made
> > (if
> > storage is FileSystemStorage) in an implementation agnostic way.
> > 
> > 
> > 
> > Aside from that, there's a listdir() method that only makes sense in
> > a FileSystemStorage based implementation (DB storage could emulate
> > it, but it isn't natural).
> > 
> > 
> > 
> > So, I had two ideas to fix it and would like to know developer
> > preference> 
> > before filing a PR:
> >1. Remove FileSystemStorage API's from Storage (specifically
> >listdir)
> >and make save() do all the work to save the file, where the only
> >acceptable failures are outside Django's control (read-only
> >mounts, (table-)space issues, etc)
> >2. Change listdir() to list_container and add methods that handle
> >Storage containers: abstract things that hold the file. save()
> >either
> >deligates to container methods or requires that container exists
> >before saving.
> > 
> > The use case that prompted this was that I've created an ImageField
> > subclass that generates thumbnails in model-specified sizes and puts
> > them in directories below the one of the current image (named
> > widthxheight, f.e. 64x64). In doing so I had to go outside
> > FieldFile.storage to have the intermediate directory created, so my
> > code now isn't portable to different Storage subclasses.
> > 
> > 
> > 
> > Is there any interest in either of these (another?) approach and if
> > so, what preference?
> > 
> > 
> > Melvyn Sopacua

-- 
Melvyn Sopacua

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

Re: Inconsistencies in Storage API

[Tim Graham]

Hi, could you point to where the problematic storage.listdir() call is in 
Django?

On Monday, January 30, 2017 at 11:02:32 AM UTC-5, Melvyn Sopacua wrote:
>
> Hello,
>
>  
>
> the current Storage API has some inconsistencies and in short it's 
> impossible to write anything that requires a directory to be made (if 
> storage is FileSystemStorage) in an implementation agnostic way.
>
>  
>
> Aside from that, there's a listdir() method that only makes sense in a 
> FileSystemStorage based implementation (DB storage could emulate it, but it 
> isn't natural).
>
>  
>
> So, I had two ideas to fix it and would like to know developer preference 
> before filing a PR:
>
>1. Remove FileSystemStorage API's from Storage (specifically listdir) 
>and make save() do all the work to save the file, where the only 
> acceptable 
>failures are outside Django's control (read-only mounts, (table-)space 
>issues, etc) 
>2. Change listdir() to list_container and add methods that handle 
>Storage containers: abstract things that hold the file. save() either 
>deligates to container methods or requires that container exists before 
>saving.
>
>  
>
> The use case that prompted this was that I've created an ImageField 
> subclass that generates thumbnails in model-specified sizes and puts them 
> in directories below the one of the current image (named widthxheight, f.e. 
> 64x64). In doing so I had to go outside FieldFile.storage to have the 
> intermediate directory created, so my code now isn't portable to different 
> Storage subclasses.
>
>  
>
> Is there any interest in either of these (another?) approach and if so, 
> what preference?
>
> -- 
>
> Melvyn Sopacua
>

-- 
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/17b0c816-4375-49a3-856c-360cf3decca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Inconsistencies in Storage API

[Melvyn Sopacua]

Hello,

the current Storage API has some inconsistencies and in short it's impossible 
to write 
anything that requires a directory to be made (if storage is FileSystemStorage) 
in an 
implementation agnostic way.

Aside from that, there's a listdir() method that only makes sense in a 
FileSystemStorage based implementation (DB storage could emulate it, but it 
isn't 
natural).

So, I had two ideas to fix it and would like to know developer preference 
before filing a 
PR:
 1. Remove FileSystemStorage API's from Storage (specifically listdir) and 
make 
save() do all the work to save the file, where the only acceptable failures are 
outside 
Django's control (read-only mounts, (table-)space issues, etc)
 2. Change listdir() to list_container and add methods that handle Storage 
containers: abstract things that hold the file. save() either deligates to 
container 
methods or requires that container exists before saving.

The use case that prompted this was that I've created an ImageField subclass 
that 
generates thumbnails in model-specified sizes and puts them in directories 
below the 
one of the current image (named widthxheight, f.e. 64x64). In doing so I had to 
go 
outside FieldFile.storage to have the intermediate directory created, so my 
code now 
isn't portable to different Storage subclasses.

Is there any interest in either of these (another?) approach and if so, what 
preference?
-- 
Melvyn Sopacua

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

Re: Removing and renaming Django's Python 2 related helpers

[Collin Anderson]

Hi All,

django.utils.six _is_ documented, so I think it should go through the
normal deprecation timeline.

https://docs.djangoproject.com/en/1.11/topics/python3/#writing-compatible-code-with-six

Seems fine to me to start the deprecation in 2.0, but I'm sure people would
appreciate starting the timeline later.

Collin


On Wed, Jan 25, 2017 at 2:34 PM, Tim Graham  wrote:

> A difference is that a deprecation starting in 2.2 is in 2 releases (2.2,
> 2.3) while the deprecation starting in 3.0 is in 3 releases (3.0, 3.1, 3.2).
>
> On Wednesday, January 25, 2017 at 10:30:40 AM UTC-5, Aymeric Augustin
> wrote:
>>
>> Hello Tim,
>>
>> On 25 Jan 2017, at 16:11, Tim Graham  wrote:
>>
>> - in Django 2.2 for removal in Django 3.1 (August 2020)
>> - in Django 3.0 for removal in Django 4.0 (Dec. 2021)
>>
>>
>> Either option seems fine to me.
>>
>> Are there advantages to starting the deprecation in a LTS (2.2) vs. in
>> the release that follows a LTS (3.0)?
>>
>> --
>> Aymeric.
>>
>>
>>
>> --
> 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/75ba8da6-dac2-4b3f-bf7a-
> b64c0732693e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Migrating to new Servers / Trac downtime

[Florian Apolloner]

The migration was successfully completed. The docs are still 
building/updating, but if you encounter any other errors please tell us so.

Cheers,
Florian

On Monday, January 30, 2017 at 3:07:35 PM UTC+1, Markus Holtermann wrote:
>
> Hi y'all,
>
> We'll be migrating parts of our infrastructure to new servers. This comes 
> with a short (read-only) downtime of Trac, our issue tracker. We expect the 
> documentation and website to remain online. We'll update here when the 
> migration is done.
>
> Cheers,
>
> /Markus
>

-- 
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/1b5533b1-caf2-4a8d-9700-82e96d35e286%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Migrating to new Servers / Trac downtime

[Markus Holtermann]

Hi y'all,

We'll be migrating parts of our infrastructure to new servers. This comes 
with a short (read-only) downtime of Trac, our issue tracker. We expect the 
documentation and website to remain online. We'll update here when the 
migration is done.

Cheers,

/Markus

-- 
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/eafe3494-6551-49be-a7fa-7a4a461fe833%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Patryk Zawadzki]

W dniu poniedziałek, 16 stycznia 2017 18:55:25 UTC+1 użytkownik Martin 
Koistinen napisał:
>
> Also, if a developer is experienced/motivated enough to *lower* the hash 
> iterations, s/he'll be more likely to also be experienced/motivated enough 
> to put other controls in place to compensate.
>

Or they just copy-pasted from an out-of-date response to a Stack Overflow 
question. I'm concerned that if someone is motivated enough to do it they 
may not get the memo to bump it by 40% every year even if they are 
experienced and competent.

-- 
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/63200c19-59fd-4345-bc76-eab94b158374%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.