> 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.
> They're also easy t
+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
management.
I was suggesting in your project you subclass the ModelFormMetaclass, use
it in your own subclass of ModelForm, and use that everywhere in your
project.
Fatpage is an imaginary fork of flatpages that adds create and edit views
>
There are a lot of problems out there with imaginary third party a
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 Pyth
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 n
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.
You
> 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 didn't consider it in my re
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 ac
> On Dec 22, 2016, at 1:41 PM, Tim Graham wrote:
>
> 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:
>
> [snip]
>
> I hope we can come to a decision and at least clarify the documentation.
> Pe
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 ty
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., 3.,
My vote would be +1 for dropping support for 11.2 after Django 1.11
since it would fit quite nicely on schedule of Oracle extended support.
What comes to those listed issues I think they should work on all
supported versions (it's still ~3 years until 11.2 is decommissioned).
SRIDs are someth
I've only skimmed the original thread so idk if the following was suggested
there. What I'd suggest for your project for the first condition is:
1. Subclass the model field you want to change and make it default to
having widget=RadioSelect:
class RadioSelectForeignKey(ForeignKey):
def formfi
Wow, nice memory Tim !
Yes it's a problem I've been trying to find a solution for during the last
years. We've had a solution in DAL v2 by providing a custom model form
which would make relation fields to a model that has an autocomplete
registered use an autocomplete field by default. This soluti
Oracle's extended support for 11.2 ends Dec 2020. We don't currently have
testing on the CI servers for 11.2, and I think the Developer Days VM for
11.2 is no longer available from Oracle (I have a local copy that I've used
for testing). Making the GIS tests work on Oracle 11.2 and Oracle 12 is
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 present
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 Thursd
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 c
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
19 matches
Mail list logo
