Re: Should SECRET_KEY be allowed to be bytes?

> On Dec 22, 2016, at 5:22 PM, Adam Johnson wrote: > > +1 to what Aymeric wrote. I was just drafting an email with a similar > argument about how it's hard to manage pure bytes in config management > systems that write to env vars, that's why ascii strings are so useful. >

Re: Should SECRET_KEY be allowed to be bytes?

+1 to what Aymeric wrote. I was just drafting an email with a similar argument about how it's hard to manage pure bytes in config management systems that write to env vars, that's why ascii strings are so useful. They're also easy to copy/paste and verify when adding them to your config

Re: Should SECRET_KEY be allowed to be bytes?

Hello, In my opinion, recommending or enforcing that SECRET_KEY contain random bytes would be a backwards incompatible change, bring no practical advantage, and make it more difficult to manage SECRET_KEY securely. I’m -1 on that. startproject always generated an ASCII str on Python 2 and

Re: #26369: default formfield callback override

Absolutely ! If we don't want to monkey patch, we can use the other step: 4. get control on the flatpage form in the admin: https://gist.github.com/Kub-AT/3676137 Then, there's the fatpages use case. Fatpage is an imaginary fork of flatpages that adds create and edit views. In this case, we also

Re: #26369: default formfield callback override

Oh, I misunderstood, I thought you controlled both the models and forms but wanted to enforce consistency. If you don't control the models (like FlatPage), I presume you control the forms then?You can do it then with a custom ModelForm subclass that overrides some of the building behaviour.

Re: Should SECRET_KEY be allowed to be bytes?

> On Dec 22, 2016, at 2:32 PM, Tim Graham wrote: > > Perhaps times have changed but I forgot to mention that 8 years ago Malcolm > rejected the idea that more randomness is required in the secret key. From > the reporter of #9687: You're right, and I knew that, but

Re: Should SECRET_KEY be allowed to be bytes?

Perhaps times have changed but I forgot to mention that 8 years ago Malcolm rejected the idea that more randomness is required in the secret key. From the reporter of #9687: "The generation of the SECRET_KEY setting for a new site uses an artificially low number of characters due to a design

Should SECRET_KEY be allowed to be bytes?

There's debate in #24994 about whether or not settings.SECRET_KEY should or may be a bytestring. Some select quotes to summarize the discussion: 1. Aymeric Augustin, "Once Django drops support for Python 2 you'll have to go out of your way to put bytes in the SECRET_KEY. Currently, since the

Re: #26369: default formfield callback override

Thanks for your suggestion Adam ! However, I have a feeling that to apply that technique on the flatpages use case we'd also have to: 4. Monkey patch django.contrib.models.FlatPage.content, 5. Override and deal with flatpages migrations from now on. The proposal removes the cost of steps 1.,

Re: PyCharm & tests/runtests.py

Hey Lex, To run the tests in PyCharms I followed the following steps: 1) In Run -> Edit Configurations, I created a new Configuration. 2) In the script field I gave the path to the runtests.py file and gave script parameter as one of the test files since I only wanted to run the tests

Re: #26369: default formfield callback override

Hi, It's not clear to me whether or not this proposal considers the concerns from the last time you raised the idea some months ago. Perhaps you could summarize that discussion so we don't rehash it. Thanks. https://groups.google.com/d/topic/django-developers/zG-JvS_opi4/discussion On

#26369: default formfield callback override

Hi all, I'm looking for a way to override the default form field widget for some fields of some model classes, at the project level. Currently, we have to override all the model classes for that. That's considerable as a hack, because we don't exactly want to "override the default in every form

Re: is support for old cx_Oracle versions needed?

On Thursday 22 December 2016 00:07:05 Josh Smeaton wrote: > I don't think licensing allows OS maintainers to package up cx_Oracle and > its dependencies, so I'd like to hear from others if this is a thing. > I checked and cx_Oracle does not seem to be packaged in Debian (at least not in its free