Re: Using `SECRET_KEY` in password hashers

2015-06-08 Thread Shai Berger
On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote:
> On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney 
> wrote:
> > On 9 June 2015 at 15:16, Ram Rachum  wrote:
> >> 
> >> What do you think about using the project's `SECRET_KEY` as an
> >> additional salt in Django's password hashers?
> 
> > I think it'd royally screw you over if you ever had to change your secret
> > key [due to suspected leak, for example] as now all your passwords are
> > invalid.
> > 
> Okay, so how about if we use a separate secret?
> 

How is it different? If you suspect a leak that forces you to change the secret 
key, wouldn't you be forced to change this secret as well?

Shai.


Re: Using `SECRET_KEY` in password hashers

2015-06-08 Thread Ram Rachum
Okay, so how about if we use a separate secret?

On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney 
wrote:

> I think it'd royally screw you over if you ever had to change your secret
> key [due to suspected leak, for example] as now all your passwords are
> invalid.
>
> --
> Curtis
>
>
> On 9 June 2015 at 15:16, Ram Rachum  wrote:
>
>> Hi,
>>
>> What do you think about using the project's `SECRET_KEY` as an additional
>> salt in Django's password hashers? The advantage would be that they'll be
>> harder to crack, as an attacker would need access both to the database
>> table and the code for the secret key. The disadvantage I can think of is
>> that you couldn't change your `SECRET_KEY` without breaking old passwords
>> (so maybe we need a separate secret in the settings.)
>>
>> What do you think?
>>
>>
>> Thanks,
>> Ram.
>>
>> --
>> 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/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/fuJ5mbl8X5E/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAG_XiSAS2o1EMSn5HQd-60Q2KutQ5uUUmYORQxsZeVM8rWbWpQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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


Re: Using `SECRET_KEY` in password hashers

2015-06-08 Thread Curtis Maloney
I think it'd royally screw you over if you ever had to change your secret
key [due to suspected leak, for example] as now all your passwords are
invalid.

--
Curtis


On 9 June 2015 at 15:16, Ram Rachum  wrote:

> Hi,
>
> What do you think about using the project's `SECRET_KEY` as an additional
> salt in Django's password hashers? The advantage would be that they'll be
> harder to crack, as an attacker would need access both to the database
> table and the code for the secret key. The disadvantage I can think of is
> that you couldn't change your `SECRET_KEY` without breaking old passwords
> (so maybe we need a separate secret in the settings.)
>
> What do you think?
>
>
> Thanks,
> Ram.
>
> --
> 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/617aecb6-3156-49d1-859a-f55efb9f54f2%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAS2o1EMSn5HQd-60Q2KutQ5uUUmYORQxsZeVM8rWbWpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Using `SECRET_KEY` in password hashers

2015-06-08 Thread Ram Rachum
Hi,

What do you think about using the project's `SECRET_KEY` as an additional 
salt in Django's password hashers? The advantage would be that they'll be 
harder to crack, as an attacker would need access both to the database 
table and the code for the secret key. The disadvantage I can think of is 
that you couldn't change your `SECRET_KEY` without breaking old passwords 
(so maybe we need a separate secret in the settings.) 

What do you think? 


Thanks,
Ram.

-- 
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/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: 1.9 release planning

2015-06-08 Thread Aymeric Augustin
> On 8 juin 2015, at 15:25, Tim Graham  wrote:
> 
> Any other feedback on the proposal? I could assume no complaints is a good 
> sign, but some +1's would be easier to interpret. :-)

I think your proposal is a reasonable compromise. It came up briefly during 
some discussions among core devs at DjangoCon Europe and I don’t remember 
anyone suggesting an alternative.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/AFF39905-ACC5-4D64-B928-7926D5F81DBD%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: URL namespaces

2015-06-08 Thread Aymeric Augustin
> On 8 juin 2015, at 15:24, Marten Kenbeek  wrote:
> 
> If there is a consensus that thread-local storage is the better solution

I don’t think there’s consensus when only one person brought up the idea :-)

I’m unconvinced at this time and I’ll probably argue against it if it gets more 
seriously considered.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/51E1F2FB-593E-4224-B1B3-66A8BD5A7E23%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Proposing DEP 3 (JS tests and linting) for acceptance

2015-06-08 Thread Carl Meyer
Hi all,

After lots of great work by Trey Hunner on the draft implementation (and
review from Tim Graham, Aymeric Augustin, Tomasz Paczkowski, and James
Da Costa), I think DEP 3 is ready for acceptance.

The latest draft of the DEP is here:
https://github.com/django/deps/blob/master/draft/0003-javascript-tests.rst#reference-implementation

The draft implementation is broken into two pull requests, which are
nearing merge-readiness: https://github.com/django/django/pull/4573 and
https://github.com/django/django/pull/4577

Review of both the DEP and the pull requests welcome! Barring feedback
that reveals a major problem with the DEP, I plan to submit it to the
technical board for acceptance within the next couple days.

(The DEP process is outlined at
https://github.com/django/deps/blob/master/final/0001-dep-process.rst.
"Acceptance" does not mean that the implementation is finished, just
that the major decisions have been made and accepted as a plan of
action. Once the implementation is finished and merged, the DEP will
move to "final" state.)

Thanks again to Trey for pushing this forward!

Carl

-- 
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/5575FAF9.6030102%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: Making management forms for formsets optional

2015-06-08 Thread Carl Meyer
On 06/07/2015 02:18 AM, Shai Berger wrote:
> Semi-devil's-advocate suggestion: Replace the management form with a 
> management field, a hidden field with
>  
>   name = "__manage__%s" % (formsetname) 
> 
> and 
> 
>   value="x"
> 
> Then instead of taking the number of forms from a field on a management form, 
> we can just take the accumulated length of the management field (which would 
> be 
> returned as an array). This also offers a better solution to the checkboxes-
> only-form problem, I think.

I think this is a promising germ of an idea for a better approach to
formsets. It would be tricky to make it backwards-compatible (and it
simply can't be backwards-compatible in terms of markup, meaning it
would break all the dynamic-formset JS out in the wild).

> Do we use the management form for anything other than counting forms in the 
> formset?

We do - we also use it for counting "initial" vs "extra" (or new) forms.
However, your idea could easily be extended to cover that as well.

We also use it for communicating min-num and max-num to the client side,
for use by dynamic-formset JS. (Such JS usually also relies on the
total-form-count and initial-form-count values).

Carl

-- 
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/5575E8AC.50200%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: Making management forms for formsets optional

2015-06-08 Thread Carl Meyer
On 06/08/2015 04:11 AM, Patryk Zawadzki wrote:
> 2015-06-07 10:18 GMT+02:00 Shai Berger :
>> Semi-devil's-advocate suggestion: Replace the management form with a
>> management field, a hidden field with
>>
>> name = "__manage__%s" % (formsetname)
>>
>> and
>>
>> value="x"
>>
>> Then instead of taking the number of forms from a field on a management form,
>> we can just take the accumulated length of the management field (which would 
>> be
>> returned as an array). This also offers a better solution to the checkboxes-
>> only-form problem, I think.
> 
> This is what Rails prefers but I think it is only added for checkbox fields.
> 
>> Do we use the management form for anything other than counting forms in the
>> formset?
> 
> Yes, we currently have the concept of initial forms even for bound
> formsets. This does not mirror form behaviour as bound forms don't
> have the concept of initial data. I'd like to get rid of that as well
> but Russell is not sure whether there are cases that require initial
> forms to work correctly.

There definitely are a number of cases that require initial forms to
work correctly, as can be easily seen by simply grepping for
`initial_form_count`. It's especially heavily used by the
inline-formsets code.

The formsets code is complex and fragile in general, IMO. I've often had
the feeling that a rewrite could simplify it and make it more robust,
though it's hard to say for sure without actually attempting such a rewrite.

But I think such a project needs to be approached as a full rewrite,
probably first as a third-party module and then later (if it works out
well) considered for merge as a separate replacement module. It does not
seem likely to me that tugging on individual threads like "remove
management form" and "remove initial forms" will result in changes to
the current formset code that are both backwards-compatible and an
improvement in the design. I'm willing to be proven wrong, but so far
the current pull request only strengthens that feeling.

Also, it's important to note that many people (including the admin) are
using the management form fields in JS code to allow for dynamic
formsets, so backwards compatibility needs to take that into account as
well.

I think it will be much more productive to focus on minimalist changes
that address the problem of a missing management form causing a 500
error, without trying to deeply change the design of the formsets code.

Carl

-- 
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/5575DD65.60902%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: 1.9 release planning

2015-06-08 Thread Asif Saifuddin
+1 dude!! go for it!

On Mon, Jun 8, 2015 at 7:25 PM, Tim Graham  wrote:

> Any other feedback on the proposal? I could assume no complaints is a good
> sign, but some +1's would be easier to interpret. :-)
>
>
> On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson wrote:
>>
>> I see. I missed the "first upgrade Django to the last release before the
>> next
>> LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the
>> newer version that supports both 2.0 and 2.1, and then finally upgrade
>> to 2.1." part.
>>
>> Thanks,
>> Collin
>>
>> On Monday, June 1, 2015 at 11:02:01 AM UTC-4, Tim Graham wrote:
>>>
>>> If we dropped 1.8 deprecated features in 2.0, then it would require
>>> libraries to add conditional code to support both the old and new ways of
>>> doing something. The idea is that a third-party app wouldn't need to make
>>> any updates (except those needed to accommodate for backwards incompatible
>>> changes) until the next LTS release.
>>>
>>> The idea is *not* to suggest apps should try to support two LTS
>>> releases. Making that easy on Django's end would require keeping deprecated
>>> features in Django significantly longer than this proposal. See Carl's post
>>> in the thread where we discussed the deprecation cycle changes:
>>> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>>>
>>> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:

 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no
 longer supported].
 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer
 supported].
 2.0 - Aug. 2016: No features dropped.
 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no
 longer supported, third party apps can update to support 2.0 as a minimum
 version; 1.8 users should use an old version of the third-party app for the
 ~1 year until 1.8 is unsupported].
 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer
 supported].

 This is awesome.

 So why not to have 2.0 drop features features deprecated in 1.8? If the
 replacement pattern/feature is available in 1.8, the 3rd party app should
 be able to use the new feature to stay compatible, right? If anything I'd
 like to see us hold off on dropping features deprecated in 1.9 until after
 the LTS to help people migrate between LTSs.

 Thanks,
 Collin


 On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>
> I put together a draft proposal in the form of a potential
> djangoproject.com blog post. I've enabled commenting in case you have
> minor cosmetic comments, but please keep discussion about the content of
> the proposal itself on this mailing list. Also, please let me know of any
> additional questions or complaints that you'd like to see addressed in the
> last section.
>
> The overview is:
> * New major release every 8 months
> * New long-term support release every 2 years. LTS releases continue
> to be supported with security updates for 3 years.
> * Adjust the deprecation policy to make it easier for third-party apps
> to support all versions back to the last LTS.
>
>
> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and having a LTS in every two years and
>>> supporting the old LTS atleast 3 years from the release date? there 
>>> will be
>>> 3 version between two LTS.
>>>
>>
>> Interesting. I like the idea of having predictable release dates.
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/MTvOPDNQXLI/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/d35a73d6-0974-403c-b1dd-dc12f3a8a21a%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 

Re: 1.9 release planning

2015-06-08 Thread Tim Graham
Any other feedback on the proposal? I could assume no complaints is a good 
sign, but some +1's would be easier to interpret. :-)

On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson wrote:
>
> I see. I missed the "first upgrade Django to the last release before the 
> next 
> LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the 
> newer version that supports both 2.0 and 2.1, and then finally upgrade 
> to 2.1." part.
>
> Thanks,
> Collin
>
> On Monday, June 1, 2015 at 11:02:01 AM UTC-4, Tim Graham wrote:
>>
>> If we dropped 1.8 deprecated features in 2.0, then it would require 
>> libraries to add conditional code to support both the old and new ways of 
>> doing something. The idea is that a third-party app wouldn't need to make 
>> any updates (except those needed to accommodate for backwards incompatible 
>> changes) until the next LTS release.
>>
>> The idea is *not* to suggest apps should try to support two LTS releases. 
>> Making that easy on Django's end would require keeping deprecated features 
>> in Django significantly longer than this proposal. See Carl's post in the 
>> thread where we discussed the deprecation cycle changes: 
>> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>>
>> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>>>
>>> 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no 
>>> longer supported].
>>> 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer 
>>> supported].
>>> 2.0 - Aug. 2016: No features dropped.
>>> 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no 
>>> longer supported, third party apps can update to support 2.0 as a minimum 
>>> version; 1.8 users should use an old version of the third-party app for the 
>>> ~1 year until 1.8 is unsupported].
>>> 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer 
>>> supported].
>>>
>>> This is awesome.
>>>
>>> So why not to have 2.0 drop features features deprecated in 1.8? If the 
>>> replacement pattern/feature is available in 1.8, the 3rd party app should 
>>> be able to use the new feature to stay compatible, right? If anything I'd 
>>> like to see us hold off on dropping features deprecated in 1.9 until after 
>>> the LTS to help people migrate between LTSs.
>>>
>>> Thanks,
>>> Collin
>>>
>>>
>>> On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:

 I put together a draft proposal in the form of a potential 
 djangoproject.com blog post. I've enabled commenting in case you have 
 minor cosmetic comments, but please keep discussion about the content of 
 the proposal itself on this mailing list. Also, please let me know of any 
 additional questions or complaints that you'd like to see addressed in the 
 last section.

 The overview is:
 * New major release every 8 months
 * New long-term support release every 2 years. LTS releases continue to 
 be supported with security updates for 3 years.
 * Adjust the deprecation policy to make it easier for third-party apps 
 to support all versions back to the last LTS.


 https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing

 On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>
> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>
>> How about
>>
>> a 8 month release cycle and having a LTS in every two years and 
>> supporting the old LTS atleast 3 years from the release date? there will 
>> be 
>> 3 version between two LTS.
>>
>
> Interesting. I like the idea of having predictable release dates.
>


-- 
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/d35a73d6-0974-403c-b1dd-dc12f3a8a21a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: URL namespaces

2015-06-08 Thread Marten Kenbeek
I actually don't think this behaviour should extend to reverse(). There are 
good reasons to use request.current_app in the template, but I don't 
believe this implicit behaviour is warranted outside the templates. Not 
everyone might agree, but I also believe that get_absolute_url() should 
return a single canonical url, independent of the current app. Using the 
current app wouldn't even make sense in most cases, such as the admin or 
pretty much any app other than the model's app itself. I also plan to 
change or replace get_absolute_url somewhere in the next few months, so 
that use case of thread-local storage will soon become obsolete if it's up 
to me. 

If there is a consensus that thread-local storage is the better solution, 
I'll follow suit, but I don't plan on implementing it in this patch. It is 
easily implemented as a third-party app if it suits your use cases. 

I'd like to focus on the best way to solve the backwards compatibility 
issues. 

Op maandag 8 juni 2015 02:32:58 UTC+2 schreef Tai Lee:
>
> I still think that even though `get_absolute_url` might be disliked these 
> days for various reasons, it is very common in the wild and is a perfect 
> example of a legitimate need to be able to reverse URLs in code that 
> executes in response to a request, but that doesn't have the request passed 
> to it as an argument.
>
> So I'd still like to consider the option of adding a default `current_app` 
> hint to thread local storage (which has a life cycle of one request), and 
> for `reverse()` and therefore also `{% url %}` to use that hint as a 
> default. It could still be overridden by explicitly passing `current_app` 
> to `reverse()` (and also `{% url %}`).
>
> This could be done with a middleware class, and in fact a quick search 
> reveals there are many django snippets and blog posts out where users have 
> re-implemented a `ThreadLocalRequestMiddleware` or similar. But I would 
> prefer to see it done before middleware is applied to make it non-optional, 
> since the value will be read in `reverse()` which can and is often called 
> completely outside the request/response cycle.
>
> For any such code that executes outside the request/response cycle, I 
> think we could provide a context manager that sets the `current_app` 
> default hint on `__enter__` and restores it on `__exit__`.
>
> Django appears to use thread locals already to set the current active 
> language. It's been said that is more of a wart than a design pattern to 
> follow, but clearly it can be used safely in Django, and just like the 
> current active language, having apps that are able to resolve their own 
> URLs properly and consistently is an important feature.
>
> Here's a relevant conversation from a couple years back: 
> https://groups.google.com/forum/#!topic/django-developers/VVAZMWi76nA
>
> Cheers.
> Tai.
>
>
> On Monday, June 8, 2015 at 5:29:56 AM UTC+10, Marten Kenbeek wrote:
>>
>> So 2) has been fixed (#24904 and #24906), and I got a PR for 1) (
>> https://github.com/django/django/pull/4724). 
>>
>> About #24127: I see a few options here:
>>
>>
>>1. A context processor or similar that sets `current_app` if it isn't 
>>set. By default `current_app` doesn't exist, so there's a good 
>> distinction 
>>between not set and set to `None`. This would be 100% backwards 
>> compatible, 
>>but IMO it's not the best solution in the long term. 
>>2. Provide a new flag to {% url %} to reverse with current_app set to 
>>request.resolver_match.namespace. This feels slightly less awkward than 
>> the 
>>current method recommended by the docs.
>>3. Deprecating a non-existing current_app to force an explicit choice 
>>between the old and new behaviour, then add the new behaviour after the 
>>deprecation period. This would be coupled with option 1 for ease-of-use. 
>>4. A setting? A setting! Yay, another setting...
>>5. Document the slight backwards-incompatible change? And provide an 
>>easy way to retain the old behaviour, of course. 1 through 4 are all far 
>>from ideal, and I don't think there's an easy, backwards-compatible fix 
>>here. 
>>
>> Thoughts?
>>
>> Op dinsdag 2 juni 2015 14:32:42 UTC+2 schreef Marten Kenbeek:
>>>
>>> The admin proves problematic. Looking at the uses of `AdminSite.name`, 
>>> it's not easily replaced. There are quite a few places that use the name to 
>>> reverse urls, but don't have access to the request and the current 
>>> namespace. I think the best solution for now is to document that you should 
>>> pass `admin.site.urls` directly to `url()`. `include()` does a bunch of 
>>> stuff, but none of it is needed in the case of the admin urls. This allows 
>>> the new `include()` API to be as intended, but it doesn't put an 
>>> unnecessary burden of providing the "correct" namespace for an admin 
>>> instance on the end-developer. 
>>>
>>> In time I'd like to see a method on the AdminSite that returns an actual 
>>> resolver 

Re: Making management forms for formsets optional

2015-06-08 Thread Patryk Zawadzki
2015-06-07 10:18 GMT+02:00 Shai Berger :
> Semi-devil's-advocate suggestion: Replace the management form with a
> management field, a hidden field with
>
> name = "__manage__%s" % (formsetname)
>
> and
>
> value="x"
>
> Then instead of taking the number of forms from a field on a management form,
> we can just take the accumulated length of the management field (which would 
> be
> returned as an array). This also offers a better solution to the checkboxes-
> only-form problem, I think.

This is what Rails prefers but I think it is only added for checkbox fields.

> Do we use the management form for anything other than counting forms in the
> formset?

Yes, we currently have the concept of initial forms even for bound
formsets. This does not mirror form behaviour as bound forms don't
have the concept of initial data. I'd like to get rid of that as well
but Russell is not sure whether there are cases that require initial
forms to work correctly.

-- 
Patryk Zawadzki
I solve problems.

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