Autocomplete fields and cleaned_data

[Melvyn Sopacua | 3YOURMIND]

I'm currently looking at a bug in our application, caused by
autocomplete_fields on a ModelAdmin. It seemingly removes the field from
self.cleaned_data, which means we can no longer validate it.

I can reproduce this by removing/adding the field from/to
autocomplete_fields and resubmitting the form after re-rendering. This is a
vanilla manytomany relation.

So now I wonder if this is an implementation bug in Django, with us
(something else I'm not considering) or documentation bug, as none of this
is mentioned in the documentation on either concepts.

I'm happy to file a bug report and classify it according to the above if it
is a bug. Otherwise, I'll dive down the rabbit hole.
-- 

*Backend Developer*

Mobile: +49 (0)160 179 6874
eMail: m...@3yourmind.com
Web: www.3yourmind.com


-- 


The information that has been provided should be regarded as confidential 
within the context of our non-disclosure agreement.

 

3YOURMIND GmbH


Bismarckstraße 10-12 | 10625 Berlin | Germany

 

VAT ID - USt-IdNr. gemäß 
§ 27 a Umsatzsteuergesetz: DE296555110

Company with its registered seat in 
- Sitz der Gesellschaft: Berlin



Register court - Registergericht: 
Amtsgericht Charlottenburg (Berlin)

-- 
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/CAF5kSxRx92R0S9kdtZrZANmhCjomsWy-zp85%3DO%2Bw_WicB259BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Melvyn Sopacua]

On maandag 22 april 2019 10:57:19 CEST Nick Sarbicki wrote:

> Consistency in the end is the most important thing (even PEP8 agrees
> there).

Not sure where you got that impression:
https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Pep8 clearly states consistency is less important then readability (it's the 
first thing mentioned and mentioned repeatedly that you can use as an argument 
to break consistency). And this is the primary advantage of black, since 
readability is hard to quantify (and therefore lint or format) and I think 
this is where black has succeeded (by breaking consistency where it is 
needed).
I mostly follow the discussion with interest from the sidelines, but just 
wanted to correct this consistency argument: if you want consistent code, go 
with autopep8, it'll keep your lines consistent below 79 characters and quite 
an unreadable mess.
-- 
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/2221950.OaZvUuSznM%40fritzbook.
For more options, visit https://groups.google.com/d/optout.

Re: Bugfix on #29103 creates different bug

[Melvyn Sopacua | 3YOURMIND]

Well, the testcase is a bit hard. I can reproduce it by calling
`sqlmigrate` on any migration that adds a char or text field with a default
value. The migration it self will go through, but sqlmigrate will fail.

I'll look into testcasing that.

On Mon, Apr 15, 2019 at 3:25 PM Claude Paroz  wrote:

> Please create a new ticket (where you can reference the original one).
> If you can provide a failing test case, it would be great.
>
> Claude
>
> Le lundi 15 avril 2019 13:40:53 UTC+2, Melvyn Sopacua | 3YOURMIND a écrit :
>
>> Hi,
>>
>> I've added a comment on the commit:
>> https://github.com/django/django/commit/3c4ff2176323dd20507e35658599da220fbe1741
>>
>> Should I reopen the bug or create a new one? Also it would help to know
>> what the return type is supposed to be or what the intention of the code
>> is? Should the if clause be `not instance` and should we be decoding or is
>> the test correct and should we be encoding?
>> --
>>
>> *Backend Developer*
>>
>> Mobile: +49 (0)160 179 6874
>> eMail: m...@3yourmind.com
>> Web: www.3yourmind.com
>> <http://www.google.com/url?q=http%3A%2F%2Fwww.3yourmind.com%2F&sa=D&sntz=1&usg=AFQjCNEYZ3Wap-Pu0DCItfT3gk0WDuP3nw>
>>
>>
>>
>> P.S. Ready for the #ManufacturingRevolution? Watch our new videos here
>> <https://www.youtube.com/c/3YOURMIND_DE>.
>>
>>
>>
>> P.P.S. Follow the top industry trends
>> <https://www.3yourmind.com/newsletter-sign-up?utm_campaign=email%20footer&utm_source=email>
>> in our newsletter.
>>
>>
>>
>> Meet us at:
>>
>> Rapid+TCT <https://rapid3devent.com/> | 20 - 23 May  | Detroit, USA|
>> Booth 753
>>
>> 3D Print Lyon <https://www.3dprint-exhibition.com/> | 4 - 6 June | Lyon,
>> FR
>>
>> Rapid.Tech Fabcon 3.D <https://www.rapidtech-fabcon.de/>  | 25 - 27 June
>> | Erfurt, DE | Booth 2-415
>>
>>
>>
>> We're hiring self-driven, innovative, AM-focused people here.
>> <https://www.3yourmind.com/career?utm_campaign=Career%20Offers&utm_source=Email%20footer&utm_medium=Email%20footer>
>>
>>
>> 3YOURMIND GmbH
>>
>> Bismarckstraße 10-12 | 10625 Berlin | Germany
>>
>>
>>
>> VAT ID - USt-IdNr. gemäß § 27 a Umsatzsteuergesetz: DE296555110
>>
>> Company with its registered seat in - Sitz der Gesellschaft: Berlin
>>
>> Register court - Registergericht: Amtsgericht Charlottenburg (Berlin)
>>
>> Register number - Registernummer: HRB 160616
>>
>> Executive Manager - Geschäftsführer: Aleksander Ciszek & Stephan Kühr
>>
> --
> 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/3324c145-6f7b-468f-b98a-df738f33a557%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/3324c145-6f7b-468f-b98a-df738f33a557%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Backend Developer*

Mobile: +49 (0)160 179 6874
eMail: m...@3yourmind.com
Web: www.3yourmind.com
<http://www.google.com/url?q=http%3A%2F%2Fwww.3yourmind.com%2F&sa=D&sntz=1&usg=AFQjCNEYZ3Wap-Pu0DCItfT3gk0WDuP3nw>

-- 


P.S. Ready for the #ManufacturingRevolution? Watch our new videos here 
<https://www.youtube.com/c/3YOURMIND_DE>.

 

P.P.S. Follow the top 
industry trends 
<https://www.3yourmind.com/newsletter-sign-up?utm_campaign=email%20footer&utm_source=email>
 
in our newsletter.

 

Meet us at:

Rapid+TCT <https://rapid3devent.com/> | 
20 - 23 May  | Detroit, USA| Booth 753

3D Print Lyon 
<https://www.3dprint-exhibition.com/> | 4 - 6 June | Lyon, FR

Rapid.Tech 
Fabcon 3.D <https://www.rapidtech-fabcon.de/>  | 25 - 27 June | Erfurt, DE 
| Booth 2-415

 

We're hiring self-driven, innovative, AM-focused people 
here. 
<https://www.3yourmind.com/career?utm_campaign=Career%20Offers&utm_source=Email%20footer&utm_medium=Email%20footer>





3YOURMIND GmbH

Bismarckstraße 10-12 | 10625 Berlin | Germany

 

VAT 
ID - USt-IdNr. gemäß § 27 a Umsatzsteuergesetz: DE296555110

Company with 
its registered seat in - Sitz der Gesellschaft: Berlin

Register cou

Bugfix on #29103 creates different bug

[Melvyn Sopacua | 3YOURMIND]

Hi,

I've added a comment on the commit:
https://github.com/django/django/commit/3c4ff2176323dd20507e35658599da220fbe1741

Should I reopen the bug or create a new one? Also it would help to know
what the return type is supposed to be or what the intention of the code
is? Should the if clause be `not instance` and should we be decoding or is
the test correct and should we be encoding?
-- 

*Backend Developer*

Mobile: +49 (0)160 179 6874
eMail: m...@3yourmind.com
Web: www.3yourmind.com


-- 


P.S. Ready for the #ManufacturingRevolution? Watch our new videos here 
.

 

P.P.S. Follow the top 
industry trends 

 
in our newsletter.

 

Meet us at:

Rapid+TCT  | 
20 - 23 May  | Detroit, USA| Booth 753

3D Print Lyon 
 | 4 - 6 June | Lyon, FR

Rapid.Tech 
Fabcon 3.D   | 25 - 27 June | Erfurt, DE 
| Booth 2-415

 

We're hiring self-driven, innovative, AM-focused people 
here. 






3YOURMIND GmbH

Bismarckstraße 10-12 | 10625 Berlin | Germany

 

VAT 
ID - USt-IdNr. gemäß § 27 a Umsatzsteuergesetz: DE296555110

Company with 
its registered seat in - Sitz der Gesellschaft: Berlin

Register court - 
Registergericht: Amtsgericht Charlottenburg (Berlin)

Register number - 
Registernummer: HRB 160616



Executive Manager - Geschäftsführer: 
Aleksander Ciszek & Stephan Kühr

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

Request middleware

[Melvyn Sopacua]

Hi,

in our codebase we made use of this gist[1], which relies on a private API, but 
more importantly, creates requests without going through the response chain. 
This is relevant for catching exceptions in Middleware: there were two tests 
that 
explicitly test for DISALLOWED_HOST and I had to rewrite them to test for a 400 
response.

I don't see an easy way to restore the old behavior and stick to official 
API's. Am I 
missing something or is this correct?
-- 
Melvyn Sopacua


[1] https://gist.github.com/tschellenbach/925270

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

Re: ResolverMatch and url pattern

[Melvyn Sopacua]

On dinsdag 10 juli 2018 21:09:21 CEST Tim Graham wrote:
> There's an open ticket. Perhaps you would like to finish the patch.
> 
> https://code.djangoproject.com/ticket/28766
> https://github.com/django/django/pull/9323

I will have a look.

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

ResolverMatch and url pattern

[Melvyn Sopacua]

Hi,

I'm trying to implement a wrapper for Django's request to work with 
openapi-core[1]. In 
this endavour I discovered that obtaining the pattern that matched with the 
current URL 
is not stored on ResolverMatch and I don't see any other way to obtain it from 
a Django 
HttpRequest.

I'm apparently not alone in this[2]. And I'm wondering why it's not stored. I 
basically 
would have to setup a local url pattern cache tied to view name and resolve it 
again.

Is there a reason it's not stored on the resolver match?
-- 
Melvyn Sopacua


[1] https://github.com/p1c2u/openapi-core
[2] https://stackoverflow.com/questions/18653278/django-get-url-regex-by-name

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

Re: typeshed for Django

[Melvyn Sopacua]

Thanks, I'll see what I can integrate and I got the forms for you.
I've built mine on top of my typeshed fork (for now not bothering with
py2):

https://github.com/melvyn-sopacua/typeshed/tree/django/third_party/3/django

On Mon, Sep 18, 2017 at 1:00 AM, Maxim Kurnikov
 wrote:
> https://github.com/machinalis/mypy-django
>
>
> On Sunday, September 17, 2017 at 8:17:26 PM UTC+3, Melvyn Sopacua wrote:
>>
>> Hi,
>>
>> since recent threads about supporting python 3 type hints didn't lead
>> to a consensus that I saw I am wondering if anyone is working on
>> adding stubs to typeshed. I've just started on it and realize it's not
>> something to manage on your own.
>>
>> The reason I'm moving ahead with this is that PyCharm is integrating
>> typeshed and what is not covered by it's now deprecated skeletons
>> implementation gets poor support: method arguments like "field" get a
>> generic object with properties distilled from the method body. But
>> let's not digress in IDE choices. This is merely my stick and carrot.
>>
>> As mentioned on the typeshed project page and it being good practice
>> in general, it's a good idea to ask - before or in early stage of a
>> large undertaking - if someone is doing the same thing.
>>
>> And I also like to ask if anyone is willing and able to contribute.
>>
>> --
>> 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/97082f4e-1cfa-451f-879c-a129a4c97f66%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
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/CA%2Bgw1GV9oB2Z2jb7rEtA7vE1nTqty2wYXnkrZmLcxPB5c5n%2BfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

typeshed for Django

[Melvyn Sopacua]

Hi,

since recent threads about supporting python 3 type hints didn't lead
to a consensus that I saw I am wondering if anyone is working on
adding stubs to typeshed. I've just started on it and realize it's not
something to manage on your own.

The reason I'm moving ahead with this is that PyCharm is integrating
typeshed and what is not covered by it's now deprecated skeletons
implementation gets poor support: method arguments like "field" get a
generic object with properties distilled from the method body. But
let's not digress in IDE choices. This is merely my stick and carrot.

As mentioned on the typeshed project page and it being good practice
in general, it's a good idea to ask - before or in early stage of a
large undertaking - if someone is doing the same thing.

And I also like to ask if anyone is willing and able to contribute.

-- 
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/CA%2Bgw1GVDS%2BJvn7OXdWTBPBHbyN5B0W4dt9o9O1Nk5W3LPL%3Dagg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for multiple file fields

[Melvyn Sopacua]

On Sat, Sep 2, 2017 at 10:37 AM, Adam Johnson  wrote:

> ArchiveField sounds a bit too specific for Django core, the most common case
> for uploading multiple files would probably be to access them individually,
> which it would prevent.

Yeah, was on the fence on that one myself. The use cases are very domain
specific, the obvious one being a backup application, but also design specs
or legal documents that site staff downloads and never actually views on site
individually. The upside of the field being that you have control of the archive
format and/or can encrypt the archive with user specific key before sending.

I researched it for an upcoming project and all the hooks are in place to
create such a model and you're right, it goes beyond "batteries included".
-- 
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/CA%2Bgw1GWTn%2B8f_bUV7mmJ8gEFodwUrtK_yzF_zEWA%2Bv5ew332gA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for multiple file fields

[Melvyn Sopacua]

eceiving 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/2b9bb49f-1cbc-4ea6-94df-774dfad43114%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/CAFNZOJPrZZDJHhXpGKi9nbWA6RKnZBfxnHP1GFnt0Bf1HhFjmA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
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/CA%2Bgw1GWrv3pKTva9SxzycO%2Bc88EuLkKXkG%3DvDUdU2uoCHAt87g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trimming in the settings file (Was: Re: Follow-up to #28307: Possible app_template improvements)

[Melvyn Sopacua]

Hi and thanks Aemeric,


On Tue, Jun 27, 2017 at 7:55 AM, Aymeric Augustin
 wrote:
> Hello Melvyn,
>
>> On 26 Jun 2017, at 12:21, Melvyn Sopacua  wrote:
>>
>> keep STATIC_URL (which I rarely change) but remove STATIC_ROOT (which is 
>> different per project and sometimes even per install) is beyond me.
>

> Nowadays it's more common to serve static files from a third-party system 
> such as CloudFront + S3 which doesn't require STATIC_ROOT or with a 
> middleware like whitenoise which doesn't suffer from this concern. Only in 
> the latter case is `STATIC_ROOT = os.path.join(ROOT_DIR, 'static')` a valid 
> default.

Thanks, that clarifies it this specific setting (all though not all
prefer to use services that interfere with SSL trust). But...

> Given this range of options, I still find it best for users to think about 
> what they're doing, read the docs, hopefully review security considerations, 
> define the settings they need and understand their deployment. I also believe 
> that unused settings can be confusing and make it more difficult to diagnose 
> deployment problems.

... this is where we respectively disagree. While it's possible that
things may get clouded, you *can* in fact see what is set.

This:
# DEBUG = False

trumps this:


Also note that if you want things concise, it's much faster to "select
and delete" then "lookup name of setting, copy, paste and alter".

And finally, a diff will show what changed, as opposed to what was
added (which may or may not be a change of the default).

> I'm sure there's a more extensive project template somewhere that will suit 
> your needs better.

Yep, probably should do that and allocate time maintaining it.
-- 
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/CA%2Bgw1GXs6a4GKig%3DUkZFMZZ2v2gmzH1xwTWyKAtTLhwZpzkq0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trimming in the settings file (Was: Re: Follow-up to #28307: Possible app_template improvements)

[Melvyn Sopacua]

On Monday 26 June 2017 20:25:58 Curtis Maloney wrote:
> On 26/06/17 20:21, Melvyn Sopacua wrote:
> > On Thursday 15 June 2017 08:14:02 Aymeric Augustin wrote:
> > 
> > I see the point for the number of useless files. But in every
> > release, settings.py has been trimmed more and more to the point
> > that it's next to useless. I'm wondering about the upside of that.
> > Cause I'm seeing plenty of downsides for both new and veteran
> > users.
> 
> Can't say I agree it's useless... I find I need very little to modify
> the start project template to get under way... especially now that
> admin is in by default.

Right. Sane defaults are a good thing. Doesn't address why trimming it down is 
a good thing.

> > Not to mention the choice of what to remove. To keep STATIC_URL
> > (which I rarely change) but remove STATIC_ROOT (which is different
> > per project and sometimes even per install) is beyond me.
> 
> Because STATIC_URL is useful always, whereas STATIC_ROOT typically
> only makes sense when you deploy...

But in doing so the educational part is removed. That there's a STATIC_URL and 
a STATIC_ROOT 
that need to be mapped by the webserver. The drawback of what is there now, is 
that it works 
and you have no clue why it doesn't once deployed, as you have had no reason to 
click the link.

And since STATICFILES is suddenly one word, I've spent several minutes trying 
to find out why 
my static dir isn't picked up. Or why I can't connect to the database, because 
it's 'USER' not 
'USERNAME'.

Boiler plate is supposed to save you time in typing and looking up things and 
it's in shear 
contrast with this trimming fashion.
-- 
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/1702467.YTQEXA1zWP%40devstation.
For more options, visit https://groups.google.com/d/optout.

Trimming in the settings file (Was: Re: Follow-up to #28307: Possible app_template improvements)

[Melvyn Sopacua]

On Thursday 15 June 2017 08:14:02 Aymeric Augustin wrote:

> The more files get generated to startapp, the more empty useless files
> accrue in many projets, because devs don't take the time to delete
> those they don't use.

...

> For this reason, I'm skeptical of attempts to extend the startapp
> template. I'm more interested in trimming it down.

I see the point for the number of useless files. But in every release, 
settings.py has been 
trimmed more and more to the point that it's next to useless. I'm wondering 
about the 
upside of that. Cause I'm seeing plenty of downsides for both new and veteran 
users.

Not to mention the choice of what to remove. To keep STATIC_URL (which I rarely 
change) 
but remove STATIC_ROOT (which is different per project and sometimes even per 
install) 
is beyond me.

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

Re: Default to BigAutoField

[Melvyn Sopacua]

On Friday 09 June 2017 15:59:50 Kenneth Reitz wrote:
> However, it should also be noted that those same larger applications
> are the ones that are likely to run into this problem eventually, so
> perhaps forcing the migration is the best path moving forward.


Existing models are the problem. Then again the database knows the truth. So 
with a little inspection during apps.get_models we might be able to do the 
right 
thing and even allow migrating in steps.

Apps is also the place to mark an app as migrated.

In fact - couldn't an AppConfig grow a method "get_autoid_type()" and inject 
the right one?

You asked fr thoughts, so there's my 2c stream.
-- 
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/8118805.cf4lglgPtt%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: A proposal for a new auto-reloader in Django

[Melvyn Sopacua]

On Thursday 30 March 2017 22:01:00 qingnian...@gmail.com wrote:
> Hi Carl,
>   Thanks for mentioning this awesome project! I saw it in one of the
> discussions but did not take a close look. I'll definitely check this
> out and try to integrate wsgiwatcher/watcher.py into Django.
> 
> On Thursday, March 30, 2017 at 7:47:13 AM UTC-7, Carl Meyer wrote:
> > Anyone working on this project should at least be aware of
> > https://github.com/Pylons/hupper
> > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FPylons%2Fhu
> > pper&sa=D&sntz=1&usg=AFQjCNGVwtqvdo53UFfK80kaQ1qxL7ST8Q> (based 
on
> > work David Glick and I
> > originally did in https://github.com/carljm/wsgiwatcher
> > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcarljm%2Fws
> > giwatcher&sa=D&sntz=1&usg=AFQjCNGqLfsmxsp37Lng7_d_DaVzja9c6Q>),
> > which aims to
> > be a framework-agnostic solution to this problem for any Python web
> > project. Docs at
> > http://docs.pylonsproject.org/projects/hupper/en/latest/
> > 
> > Carl
I was going to suggest the same, because you already get watchdog support for 
free 
and can probably build on that integration to pick up watchman. Also, it's used 
in 
devpi[1], so it gets some scruteny from there (and devpi is awesome to 
distribute 
internal or augmented Django apps amongst projects).
-- 
Melvyn Sopacua


[1] http://doc.devpi.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/1871865.SgAvvE3WaE%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[Melvyn Sopacua]

On Tuesday 28 March 2017 03:52:59 guettli wrote:
> Am Montag, 27. März 2017 16:11:06 UTC+2 schrieb Melvyn Sopacua:
> > On Friday 24 March 2017 04:31:32 guettli wrote:
> > > I know this is a crazy idea, and it will get the "won't fix" tag
> > > very
> > > 
> > > soon.
> > > 
> > > 
> > > 
> > > Nevertheless I want to speak it out.
> > > 
> > > 
> > > 
> > > My use case: Get a queryset of users who have a given permission.
> > 
> > I'm still thinking about this use case.
> > 
> > Cause it's not for normal use - you don't normally use permissions
> > as
> > data, you use permissions to deny / allow access to data.
> > 
> > So, you're already in the "specialized" corner.
> 
> I can use more words, to make this use case more colorful.
> 
> Imagine a approval workflow: Only some users are allowed to do the
> approval.
> 
> An invoice instance needs to be forwarded to someone with the matching
> permissions.

>From an object perspective, you need to send the invoice to the group 
>"Approvers". 
Again, best solved at the group level.
And it's questionable if superusers should be in there. They are the equivalent 
of the 
Posix 'root' user, which has the power to lock/unlock everything in and about 
the 
system. Data privilege and system privilege are always in fight and in this 
case it's 
questionable if superusers should automatically be Approvers and while they 
still could 
do it, the UI shouldn't present them.

As said, a good group structure solves a lot of your problems -  in fact you 
wouldn't 
need a user selection to begin with, as the mail can simply be sent to all 
members of 
the Approvers group.

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

Re: Deprecate is_superuser, is_staff and is_active

[Melvyn Sopacua]

On Friday 24 March 2017 04:31:32 guettli wrote:
> I know this is a crazy idea, and it will get the "won't fix" tag very
> soon.
> 
> Nevertheless I want to speak it out.
> 
> My use case: Get a queryset of users who have a given permission.

I'm still thinking about this use case.
Cause it's not for normal use - you don't normally use permissions as data, you 
use 
permissions to deny / allow access to data.
So, you're already in the "specialized" corner.

> At the moment this query is complex and results in performance issues,

For a small install this works fine. When performance becomes an issue because 
there's a large number of users and groups, my first instinct is to regroup 
users so 
that no permission exceptions exist anymore at the user level.
I'd add all superusers to the "wheel" group ("root", "superuser", whatever 
floats your 
boat).
Now the query to get this info no longer requires the user model for conditions 
and 
you can simply query the group manager.
It is what groups are for and it'll be always faster get all the matching 
groups as one 
set and combine it with all the users that have  the permission assigned 
directly.
The "one query" requirement conflicts with your performance requirement.

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

Re: To keep or not to keep: logging of undefined template variables

[Melvyn Sopacua]

On Thursday 16 March 2017 12:03:07 Tim Graham wrote:
> Ticket #18773 [0] added logging of undefined template variables in
> Django 1.9 [1], however, I've seen several reports of users finding
> this logging more confusing than helpful. 

With channels hitting 2.0 and the already large stack of moving parts 
surrounding 
Django you need some basic system administration skills and programming 
experience to work with the system. And there are quite a few examples to link 
to 
from the user's list that deal with those moving parts rather then Django 
itself. It is 
*not* an application that you download, install and run.

An introduction "What you need to know before starting Django" would help a lot 
in 
this respect and explaining the noisiness of some logging belongs in there.

Because it *is* useful if you defined that variable to True in your settings, 
and it's 
working in all projects but this one. It could be there's an extra piece of 
context 
middleware that uses the same name and deletes the variable from the context. 
It 
could be there's a Mixin missing in the view hierarchy. Or a typo you don't 
notice 
anymore after plowing through 20+ included template bits.

Noisy logging is exactly what you want when debugging. It should log things 
that may 
be working as designed, especially things that are ambiguous (like undefined 
and 
false).

Another thing is that logging is the ugly duckling of Django. It's not 
mentioned much if 
at all in the tutorial. It is not mentioned at all in "How to write reusable 
apps" and it 
shows in the eco system. It's like finding a diamond when an app actually has 
logging 
implemented.

But it also means that novice users touching the LOGGING configuration are 
exceptions and I don't think Django should cater to the exceptions.

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

Re: Supporting a template database for test db

[Melvyn Sopacua]

On Wednesday 22 March 2017 06:12:49 Tim Graham 
wrote:
> This is already implemented in Django 1.11:
> https://code.djangoproject.com/ticket/27061.

Fantastic, thank you.

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

Supporting a template database for test db

[Melvyn Sopacua]

Hi,

I'm currently running into the problem that in order to run tests, I need to 
grant my 
database user super-user privileges.
No problem for dev, but I'd like to avoid that on any system resembling 
production.

This is a Postgresql specific issue, as there is no seperate privilege I can 
grant that 
makes it more secure, but even if there was / is going to be, I'd be reluctant 
to grant 
it.
I do however want to be able to run tests in staging / production environments.

The problem can be avoided by using a template database that already has the 
required extensions installed. The problem obviously exists for 
django.contrib.postgres but also for django.contrib.gis and any reusable apps 
that 
require an extension (like the custom JSONField implementations out there).

I did a coarse search if this was discussed before, but template and database 
are 
common words in this group :), so if this has been discussed before, feel free 
to point 
me to it.

The question being: is there any aversion to supporting TEMPLATE in the 
DATABASES[TEST] setting and that the database will then be created using the 
template database (so mapping to CREATE DATABASE ... TEMPLATE ..)?
-- 
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/1771797.SbPkkOfdAJ%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[Melvyn Sopacua]

On Wednesday 08 March 2017 18:18:26 Melvyn Sopacua wrote:
> On Monday 06 March 2017 10:10:41 David Seddon wrote:
> > Hi all,
> > 
> > One thing I've always found challenging with Django is to adjust the
> > functionality of forms from other apps.  An example might be to add
> > an extra field to a login form provided by a third party module.
> > 
> > What I end up doing is often overriding the urlconf, view and form
> > class. Or, worse, monkey patching the form class.
> > 
> > A much nicer way to do this would be to add a few well chosen
> > signals
> > to forms.
> > 
> > Potential ones could be:
> > 
> > - post_init
> 
> Putting in a +1 and use case for pre_init: Inject dynamically
> generated form.prefix.
> 
> Right now I have to inject PrefixedFormView in every view using it and
> carefully watch my mro of already complex views.
> 
> Use case is having several modals containing forms on a single page
> ("Edit this", "Add related", "New this"). They need to be prefixed to
> deal with naming conflicts since id_{fieldname} will not be page
> unique anymore.
> 
> With the signal, I can do away with the view mixin and the WrappedForm
> is solely responsible for it.
> I have no preference for the technology used (signal, hook, injection,
> new buzzword), as long as the net result is that the object creating
> the prefix can handle the prefix for all views.
> 
> Is there a ticket yet?
> 

Apologies for the formatting.
https://gist.github.com/melvyn-sopacua/dbf3c8f71023d6fc261131cb0a851f58


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

Re: Feature idea: forms signals

[Melvyn Sopacua]

On Monday 06 March 2017 10:10:41 David Seddon wrote:
> Hi all,
> 
> One thing I've always found challenging with Django is to adjust the
> functionality of forms from other apps.  An example might be to add an
> extra field to a login form provided by a third party module.
> 
> What I end up doing is often overriding the urlconf, view and form
> class. Or, worse, monkey patching the form class.
> 
> A much nicer way to do this would be to add a few well chosen signals
> to forms.
> 
> Potential ones could be:
> 
> - post_init

Putting in a +1 and use case for pre_init: Inject dynamically generated 
form.prefix.

Right now I have to inject PrefixedFormView in every view using it and 
carefully watch 
my mro of already complex views.

Use case is having several modals containing forms on a single page ("Edit 
this", "Add 
related", "New this"). They need to be prefixed to deal with naming conflicts 
since 
id_{fieldname} will not be page unique anymore.

With the signal, I can do away with the view mixin and the WrappedForm is 
solely 
responsible for it.
I have no preference for the technology used (signal, hook, injection, new 
buzzword), 
as long as the net result is that the object creating the prefix can handle the 
prefix for 
all views.

Is there a ticket yet?

Use case code:

*class PrefixedFormView(*generic.FormView*):def post(*self, request, 
***args, 
kwargs*):*self.prefix *= *request.GET.get*('prefix'*, *None)
return 
/super/()*.post*(*request, ***args, kwargs*)*

*class WrappedForm(/object/):def __init__(*self, form_class*: *BaseForm, 
action_url*: *str, is_multipart*: *bool *= False*, 
model_instance*: *Model 
*= None*, initial*: *dict *= None*, prefix*: *str *= 'auto'*, 
kwargs*):*
*

**if *prefix *== 'auto':*self.prefix *= *uuid4*()*.hex  
  *else:
*self.prefix *= *prefixself.form *= None
*self._set_query_prefix*()

def _set_query_prefix(*self*):*final_url *= 
*urlparse*(*self.action_url*)
*query *= *QueryDict*(*query_string*=*final_url.query, mutable*=True)
*query[*'prefix'*] *= *self.prefixparts *= (*final_url.scheme, 
final_url.netloc, 
final_url.path, final_url.params, query.urlencode*()*, 
final_url.fragment*)
*self.action_url *= *urlunparse*(*parts*)


*

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

Re: Template handling of undefined variables

[Melvyn Sopacua]

On Saturday 25 February 2017 16:28:17 Tim Graham wrote:
> My proposal was only for the use of undefined variables in template
> tags. I didn't realize that the behavior of undefined variables in
> some tags resolving to None is documented, but I still think it's a
> useful change to raise an exception instead. The philosophy that
> template tags shouldn't raise exceptions is more unhelpful than
> helpful in my experience.

I sincerely hope that the change only affects DEBUG mode (including the 
include change). But once the templates are validated and working as they 
should, they should not generate exceptions unless Django provides a way 
to catch them. For example, if a service is unavailable that makes up a 
small part of a page, I do not want the whole page to crash or information to 
leak.

-- 
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/2409576.D1JWrnJBHJ%40devstation.
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>
&g

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.

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: Authenticating with Django without the password being sent to the server

[Melvyn Sopacua]

On Saturday 14 January 2017 10:24:24 Chris Priest wrote:
> The way django's authentication system works is that when you
> register, you send the password to the server, then the server runs
> that password through some hashing algorithms, then the resulting
> hash is stored in the database. When the user logs in, the password
> again is sent to the server, and the hash is calculated and then
> compared to the hash that was calculated when they registered.
> 
> This results in the plain text password not being stored in the
> database, but the password is still being sent back to the server.

The solution is to use SRP, originally coined by Stanford University[1]. There 
used to 
be a Django enabled implementation[2], but it died a long time ago.
I don't know a well-maintained alternative and would welcome it in contrib.
-- 
Melvyn Sopacua


[1] http://srp.stanford.edu/
[2] http://code.google.com/p/srp-js/

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

Re: new syntax for management commands

[Melvyn Sopacua]

On 13-8-2012 1:54, Alex Gaynor wrote:

> In my view, the current largest source of boilerplate with management
> commands is where they have to be, you have to stick them 3 directories
> deep.  Writing a command itself is pretty boilerplate free.

Ironically, this is easily fixed with a createcommand  
management command.

-- 
Melvyn Sopacua

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

Re: Django 1.4.x support for Firebird

[Melvyn Sopacua]

On 2-8-2012 14:40, Anssi Kääriäinen wrote:
> It seems there is need for "max decimal digits" feature or something
> like that

Actually, what I'm interested in is that anything from a model field
definition that can apply to a form field (yes, that general) is added
to a form field's attributes of a ModelForm and passed on to the widget.
In addition, 'localize' should be supported on the model level as well
(and a translate attribute, but that's a larger can of worms).

The reason for it, is that it you can stick to creating widgets for a
specific field, instead of having to connect the entire model to widget
chain. For example, say I have an 'introduction' field in my model that
is a TextField(). The reason that it's a TextField is that 255
characters is too small and that requires me to use that field type.
However, I don't want the introduction to be any larger than 400
characters, so I set the max_length attribute on the model field to 400
and create a widget that uses JavaScript to limit the number of
characters. The problem is that I now do not have access to max_length
and need to subclass the form field and specify that form field on the
ModelForm.

So my approach would be to pass all these attributes on to ModelForm and
the widgets and for the default form fields simply ignore the attributes
you're not interested in.

I'm willing to come up with a patch if there is interest in this approach.
-- 
Melvyn Sopacua

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

Ticket 16226

[Melvyn Sopacua]

Hello,

I've got bitten by parts of bug 16226[1] - the default_if_none filter
being used and I think it exposes a few issues:
- prepopulated_fields is a badly chosen name if it only works for slugs.
- the current javascript API allows one to easily complete fields using
a declarative syntax
- model attributes are arbitrarily exposed to form fields and widgets.
For an integer field a max_length attribute is equally valid and
probably should be set to the number of base-10 positions of the
max_value attribute if max_length is not set.

As aaugustin advises, I'm therefore asking what the devs would like to
do with above issues and what the problems are implementing or not
implementing the proposed fixes.
[1] https://code.djangoproject.com/ticket/16226
-- 
Melvyn Sopacua

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