Re: Proposal: Drop dependency on pytz in favor of zoneinfo

[Nick Pope]

Hi Carlton,

Sorry I didn't reply on the PR about advancing anything for 3.2. I ran out 
of capacity and at this late stage it is best to wait until 4.0 anyway.

I see that Aymeric is in favour of forging ahead to use zoneinfo in 4.0 as 
was my preference, but with the addition of an opt-out falling back to the 
deprecation shim.

I'm also +1 for this approach, rather than an opt-in. I don't think it is a 
bad idea to promote this and get people to think about it sooner rather 
than later.
For those with complex and/or significant use of  pytz's API, there is then 
the option to opt-out and have another two or three releases to address the 
issue.

Cheers,

Nick

On Tuesday, 5 January 2021 at 12:20:18 UTC wksch...@gmail.com wrote:

> Just wanted to chime in with a +1 from a user in favor of moving away from 
> pytz. Doing so will be very helpful for frozen Python environments: 
> https://bugs.launchpad.net/pytz/+bug/1834363
>
> On Sunday, January 3, 2021 at 2:43:01 AM UTC-6 Aymeric Augustin wrote:
>
>> Hi Carlton,
>>
>> IIUC-at-first-pass: your suggestion differs in jumping straight to the 
>> end-point with a fallback for those who need it. (In contrast to getting 
>> folks to opt-in early if they want it.)
>>
>>
>> Indeed. The majority will switch when the default changes; better earlier 
>> than later.
>>
>> what did you think about allowing an early opt-in for Django v3.2?
>>
>>
>> The more options we create, the more confusion we may generate e.g. when 
>> users try to understand release notes or to ask for support. This is why I 
>> tried to keep options to a minimum (1. initial situation, 2. target 
>> situation, 3. with shim) and to make as few users as possible go through 
>> option 3.
>>
>> Implementing USE_PYTZ_DEPRECATION_SHIM is Django 3.2 makes the situation 
>> a bit more complex, as the setting will mean "use pds instead of pytz" in 
>> 3.2 and "use pds instead of zoneinfo" in 4.0. We'd have four options 
>> instead of three.
>>
>> I'm pretty confident that the transition will go smoothly and I don't 
>> think the flaws in pytz are bad enough to warrant urgent action. As a 
>> consequence, offering opt-in in Django 3.2 doesn't seem all that valuable 
>> to me.
>>
>> I'm OK with starting the migration in one year in Django 4.0. I'm also OK 
>> with offering the opt-in in Django 3.2 if others have a different value 
>> assessment!
>>
>> Cheers,
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 3 Jan 2021, at 09:12, Carlton Gibson  wrote:
>>
>> Hi Aymeric. 
>>
>> Thanks for inputting! 
>>
>> I need to read in-depth what you’ve said here, but IIUC-at-first-pass: 
>> your suggestion differs in jumping straight to the end-point with a 
>> fallback for those who need it. (In contrast to getting folks to opt-in 
>> early if they want it.) This sounds better if we can. 
>>
>> The Autumn hasn’t allowed time to make progress here but, what did you 
>> think about allowing an early opt-in for Django v3.2? (I’m not sure we have 
>> capacity to get the in in-time now anyway, so it may be moot.)
>>
>> Kind regards, 
>> Carlton.
>>
>>
>>
>> On Sat, 2 Jan 2021 at 10:29, Aymeric Augustin <
>> aymeric@polytechnique.org> wrote:
>>
>>> Hello,
>>>
>>> As the original author of support for timezone aware datetimes in 
>>> Django, I've been meaning to review this... for six months... Better late 
>>> than never I guess?
>>>
>>> In this discussion, we're assuming settings.USE_TZ = True.
>>>
>>>
>>> The original design 
>>> <https://groups.google.com/g/django-developers/c/zwQju7hbG78>, which 
>>> still matches 80% of the current implementation, was very much based on 
>>> advice found in the documentation of pytz. This has three consequences:
>>>
>>> 1. By default, users manipulate aware datetimes in UTC, which limits the 
>>> breakage to cases where they explicitly switch to another timezone. This is 
>>> auditable e.g. "look for timezone.activate or timezone.override in your 
>>> code".
>>>
>>> 2. Django provides custom wrappers in order to take care of the pitfalls 
>>> of pytz automatically e.g. timezone.make_aware. Backwards-compatibility can 
>>> be implemented transparently there.
>>>
>>> 3. A strategy designed for migrating from pytz to zoneinfo should be 
>>> applicable to Django.
>>>
>>>
>>> I'm seeing three areas that need care:
>

Re: Status of 3.2 release blockers.

[Nick Pope]

Hi Carlton,

Just wondering if you're still willing to accept the following for 3.2:

   - https://code.djangoproject.com/ticket/16117
   - https://github.com/django/django/pull/13532
   
Adam marked it "ready for checkin" about 6 weeks ago.

Cheers,

Nick

On Wednesday, 6 January 2021 at 10:04:18 UTC carlton...@gmail.com wrote:

> Hey Florian. 
>
> OK +1, no problem. 
>
> > Let me know if I can help somewhere else in exchange ;)
>
> Super. 
>
> On Wednesday, 6 January 2021 at 10:31:54 UTC+1 f.apo...@gmail.com wrote:
>
>> Hi Carlton,
>>
>> I'd like to put 
>> https://github.com/django/django/pull/12553
>> https://github.com/django/django/pull/13800
>>
>> onto this list as well. They are imo basically finished and I'd love 
>> reviews from our fellows. Let me know if I can help somewhere else in 
>> exchange ;)
>>
>> Cheers,
>> Florian
>>
>> On Monday, January 4, 2021 at 10:56:42 AM UTC+1 carlton...@gmail.com 
>> wrote:
>>
>>> Hi all,
>>>
>>> Happy New Year! 
>>>
>>> Time to begin release process for the next major release, Django 3.2!
>>>
>>> Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap
>>>
>>> The 3.2 feature freeze is scheduled for January 14. 
>>> We'll probably release the alpha that day.
>>>
>>> We have a few larger patches we want to finish reviewing:
>>>
>>> https://github.com/django/django/pull/11929 - Fixed #26167 -- Added 
>>> support for functional indexes.
>>> https://github.com/django/django/pull/13618 - Fixed 30360 -- Support 
>>> rotation of secret keys.
>>> https://github.com/django/django/pull/13435 - Fixed #32018 -- Extracted 
>>> admin colors into CSS variables.
>>> https://github.com/django/django/pull/11026 - Fixed #29010, Fixed 
>>> #29138 -- Added limit_choices_to and to_field support to autocomplete 
>>> fields.
>>>
>>> We'll update this thread for any schedule changes. 
>>>
>>> Kind regards, 
>>> Carlton
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/31c418ca-438d-4c75-b550-31272c9024a0n%40googlegroups.com.

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

[Nick Pope]

Hi Carlton,

Thanks for coming back to this.

Your reasoning makes a lot of sense. I too think it'll be good not to land 
this in 3.2 LTS and focus on making any changes in 4.0.

The question is then which path we choose to take:

   1. The deprecation route using pytz_deprecation_shim in 4.0 changing to 
   zoneinfo in 5.0
   2. Just make a hard break to zoneinfo in 4.0 replacing the pytz dependency 
   with backports.zoneinfo;python_version<"3.9"

If I'm honest, I actually prefer the second option for the following 
reasons:

   - It avoids having to go through the rigmarole of updating this stuff 
   twice. One release with big shouty warnings is better than two.
   - People jumping from 3.2 LTS to 4.2 LTS to 5.2 LTS will still have two 
   "consecutive" releases fiddling with this.
   - When Django 5.0 is released in January 2024, we'll still need to use 
   the backport as Python 3.8 isn't retired until October 2024.
   - We don't need to introduce, maintain, deprecate, and remove any extra 
   settings for choosing the pytz vs zoneinfo.
   - As Paul mentioned, most people are probably not using pytz's 
   .normalize() properly anyway...

The disadvantage is that users have to make a major change. But they're 
going to have to sooner or later anyway.
Using the shim doesn't stop them from having to rewrite their code a second 
time to switch over to zoneinfo.
With good documentation and examples on how to migrate, I think it would be 
a better approach.

On a final note, I'd like to say thank you to Paul for fixing this major 
timezone handling wart. I'm looking forward to life becoming much easier!

Kind regards,

Nick

On Wednesday, 7 October 2020 at 16:26:21 UTC+1 Paul Ganssle wrote:

> This sounds like a reasonable timeline to me. I think the breakage will be 
> relatively small because I suspect many end-users don't really even know to 
> use `normalize` in the first place, and when introducing the shim into a 
> fundamental library at work I did not get a huge number of breakages, but I 
> am still convinced that it is reasonably categorized as a breaking change.
>
> I do think that there's one additional stage that we need to add here (and 
> we chatted about this on twitter a bit), which is a stage that is fully 
> backwards compatible where Django supports using non-pytz zones for users 
> who bring their own time zone. I suspect that will help ease any breaking 
> pain between 3.2 and 4.0, because no one would be forced to make any 
> changes, but end users could proactively migrate to zoneinfo for a smoother 
> transition.
>
> I think most of what needs to be done is already in my original PR, it 
> just needs a little conditional logic to handle pytz as well as the shim.
>
> I am not sure how you feel about feature flags, but as a "nice to have", I 
> imagine it would also be possible to add a feature flag that opts you in to 
> `zoneinfo` as time zone provider even in 3.2, so that people can jump 
> straight to the 5.0 behavior if they are ready for it.
>
> I should be able to devote some time to at least the first part — making 
> Django compatible with zoneinfo even if not actively using it — but likely 
> not for a few weeks at minimum. If anyone wants to jump on either of these 
> ahead of me I don't mind at all and feel free to ping me for review.
>
> Best,
> Paul
> On 10/7/20 10:48 AM, Carlton Gibson wrote:
>
> Hi Paul.  
>
> Thanks for the input here, and for your patience 
>
> > I am fairly certain this is going to be a tricky migration and will 
> inevitably come with *some* user pain. I don't think this will be Python 
> 2 → 3 style pain, but some users who have been doing the "right thing" with 
> pytz will need to make changes to their code in the long run, which is 
> unfortunate.
>
> Looking at all the docs, your migration guide on pytz_deprecation_shim, 
> the example Kevin gave <https://repl.it/@severian/pytzshim#main.py>, 
> where we do some arithmetic in a local timezone, and call `normalize()` in 
> case we crossed a DST boundary, there's no way we can do this without 
> forcing a breaking change somewhere.
>
> So, probably, I've been staring at this too long today, but I think we 
> should introduce the shim in Django 4.0. Django 3.2, the next major release 
> will be an LTS. If we hold-off introducing the change until 4.0, we can 
> flag it as a breaking change in the 4.0 release notes, with big warnings, 
> allowing folks extra time to hang out on the previous LTS if they need it. 
>
> What I wouldn't want to do is to bring the breaking change in in Django 
> 3.2, because we'll have a whole load of folks updating from the 2.2 LTS at 
> about the time when it goes End of Life, and with no warning, that'd be a 
> hard breaking change to throw on 

Re: f-strings again.

[Nick Pope]

Hi,

So I'm in favour of using f-strings, but agree that there are places where 
they are not appropriate.

I am also against bulk updates in this case as mentioned in my previous 
comment <https://github.com/django/django/pull/12650#issuecomment-607707454>. 
I don't think we should exclude replacing .format() with f-strings on a 
case-by-case basis, however, where performance is a concern.

Thanks for your initial documentation, Carlton. Am wondering whether we 
should be more explicit about the pros and cons of each to help people make 
the correct decision? Here are my thoughts:

%-formatting:

+ Simple to use printf-style familiar to all.
+ Default (can be changed 
<https://docs.python.org/3/howto/logging-cookbook.html#formatting-styles>) 
style used internally by the logging module, e.g. logging.info('Message 
with %s.', value)
− Much less flexibility for formatting, see pyformat.info.

``.format()``:

+ Useful for interpolating a stored template string, e.g. from a database, 
which isn't possible with f-strings.
− Worst performance due to method call.
− Much more verbose, makes code less readable.

f-strings:

+ Better performance than other methods due to dedicated FORMAT_VALUE 
<https://bugs.python.org/issue25483> opcode.
+ Allows for embedding more complex expressions, e.g. f'Hello 
{user.get_full_name()}'
+ Much more concise, makes code more readable.
− Cannot be used if string must be translated.
− Complex expressions can get out of control. A sensible balance needs to 
be struck.

Regarding performance, here are some simple numbers:

python -m timeit -s 'x="test"' 'f"{x}"'
2000 loops, best of 5: 11.8 nsec per loop
$ python -m timeit -s 'x="test"' '"%s" % x'
1000 loops, best of 5: 39.1 nsec per loop
$ python -m timeit -s 'x="test"' '"{}".format(x)'
500 loops, best of 5: 76.1 nsec per loop

I think it is probably also worth updating the documentation added in this 
commit 
<https://github.com/django/django/commit/c3437f734d03d93f798151f712064394652cabed>.
 
It isn't that xgettext doesn't support f-strings... It does:

$ echo "_('Hello %s') % user.username" | xgettext --language=python 
--omit-header --output=- -
#: standard input:1
#, python-format
msgid "Hello %s"
msgstr ""
$ echo "_('Hello {}').format(user.username)" | xgettext --language=python 
--omit-header --output=- -
#: standard input:1
msgid "Hello {}"
msgstr ""
$ echo "_('Hello {name}').format(name=user.username)" | xgettext 
--language=python --omit-header --output=- -
#: standard input:1
#, python-brace-format
msgid "Hello {name}"
msgstr ""
$ echo "_(f'Hello {user.username}')" | xgettext --language=python 
--omit-header --output=- -
#: standard input:1
#, python-brace-format
msgid "Hello {user.username}"
msgstr ""
$ echo "_(f'Hello {user.get_full_name()}')" | xgettext --language=python 
--omit-header --output=- -
#: standard input:1
msgid "Hello {user.get_full_name()}"
msgstr ""

It is actually that Python doesn't support modifying the template string 
prior to interpolating the values which is the requirement for injecting 
the translated string. PEP 498 <https://www.python.org/dev/peps/pep-0498/> 
makes no explicit mention of this. PEP 501 
<https://www.python.org/dev/peps/pep-0501/> was initially looking at 
solving the problem but was deemed a poor fit and was also deferred.

Kind regards,

Nick
On Tuesday, 21 July 2020 at 08:28:54 UTC+1 Mariusz Felisiak wrote:

> Hi y'all,
>
> I will not stand against f-strings, I think we can allow them. My main 
> concerns is readability. f-strings are powerful and it's quite common that 
> they are used with functions calls and complex formatting which makes code 
> hard to understand and maintain, *"With great power comes great 
> responsibility" ...*
>
> I'm strongly against any bulk updates to conform to this style. This 
> will just create unnecessary noise in the history, I know that there are 
> tools, please don't start this discussion again :)
>
> I would also be in favor of keeping only %-formatting and f-strings in 
> Coding style docs. I don't see any reason to use also `format()` in a new 
> code.
>
> Best,
> Mariusz
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ceba9695-9d21-436f-84b5-53381aa3ea15n%40googlegroups.com.

Re: HttpResponse headers interface

[Nick Pope]

I would agree that `response.headers` *is* by far clearer especially to 
those not familiar with Django or coming from other frameworks. As Tom 
says, we only visually know that setting a key on a response object is for 
headers because of the key name itself, e.g. "Content-Type". I also think 
that having `response.headers` brings a symmetry with `request.headers` 
that makes it easier for developers to remember how this all works. I am 
all for being concise, but I don't hold to the argument that the something 
isn't to be preferred just because it is more verbose and you "know" 
Django. The addition of ".headers" is hardly excessively verbose.

I think there has to be a balance struck between making things more 
accessible for developers that are new to Django and those that are 
long-time developers who need to maintain their existing code. There is 
always going to be some contention between satisfying both camps. I 
understand that there are the concerns raised referencing the API stability 
policy that there should be "one way to do it", but it does come with 
various provisos, e.g. "(eventually)" and "very high priority" (which *also* 
does not equal "the only priority" -  it isn't absolute).

In addition, I can highlight places with multiple ways of doing things, 
e.g. `Field.choices` with the ability to use enumeration classes or not, 
`Meta.indexes` or the not-yet-deprecated and only lightly discouraged 
`index_together` and `unique_together`, etc. While I think that "one way to 
do it" is an admirable goal, I don't think that we need to be quite so 
militant at adhering to that principle. Maybe this has originated from the 
Zen of Python, but even that states "There should be one-- and preferably 
only one --obvious way to do it." I see that as meaning "it is preferable 
to have one obvious way to do it" but not discounting multiple ways if that 
cannot be achieved or is undesirable.

If we're going to be driven forcibly by these principles it comes down to a 
tussle between Python's "obvious" - undisputedly `response.headers` - and 
Django's "superior" - well, arguably, neither, unless we choose clarity 
(`response.headers`) or Python's data model as what makes something 
"superior". In that regard we have a contradiction if we were to choose 
Python's data model as the "superior" solution as Python - or at least the 
"Zen of Python" - commends what is "obvious".

I honestly thought the approach Carlton mentioned in 
https://github.com/django/django/pull/13186#discussion_r454956921 struck 
the correct balance and we could even, if desired, highlight in the release 
notes for the new `response.headers` that the old approach has not gone 
away such that developers do not need to rush to update their code. As 
highlighted by the examples above, it feels like there is precedent for 
that. Also if the data model approach is plumbed in to use `.headers` as in 
the proposed implementation, I don't see this as being a burden to maintain.

Please let's be pragmatic about this stuff and not be driven to adhering to 
"one way to do it" as an extremist ideology rather than a laudable 
preference.
On Thursday, 16 July 2020 at 14:58:39 UTC+1 carlton...@gmail.com wrote:

> The concern is the backwards incompatibility. 
>
> I do see the reasons for the new approach. I accept that it’s easier to 
> grok if you don’t know Django already — “principal of least astonishment” I 
> think you opened with. 
>
> I just can’t balance those gains against forcing a change on the entire 
> community. It just doesn’t balance. (And being negative, as soon as you do 
> know Django the new proposal is more verbose, so not to be preferred.)
>
> I had thought that it would be additive but the API stability policy is 
> quite clear on the “one way of doing things”.
>
> Thus, as much as I do like the idea, I don’t think we can do this. 
>
> On Thu, 16 Jul 2020 at 15:39, Tom Carrick  wrote:
>
>> Hmm. I do think that Python's data model is a Good Thing. Where we might 
>> disagree is that I don't think this is an appropriate use of it.I'll try to 
>> illustrate with an example. Consider this code:
>>
>> response = HttpResponse()
>> response['foo'] = 'bar'
>>
>> Now, if I try to look at this code without context, putting my Django 
>> knowledge to the back of my head, intuitively, this doesn't look like I'm 
>> setting a header. To me it actually looks more like my response is JSON 
>> (increasingly common these days) and I'm setting the 'foo' key on it to 
>> 'bar'. Now, is this likely to happen and cause confusion? Probably not, 
>> since we tend to spell out our headers such as Content-Type rather than 
>> content-type, and custom headers tend to be prefixed with 'X-'. But I do 
>> think there is potential confusion, especially to beginners or perhaps 
>> people who know a little frontend development and expect any request to 
>> return JSON, and perhaps haven't had to interact with headers as their 
>> libraries take care of 

Re: Adding ability to choose AutoField type (signed vs unsigned)

[Nick Pope]

Ah. I hadn't thought about that - only got as far as being able to define a new 
default value in DEFAULT_AUTOFIELD in the start project template so that 
existing projects are not suddenly forced to migrate.

An alternative is to have something on the AppConfig. I'm sure for most people 
the large tables that may need this will be in their own, rather than 
third-party, apps. People can also choose to set this for a third-party app by 
subclassing the AppConfig, but as you say, they'd then be forced to handle 
migrations manually - is this even avoidable? I'm not sure how this would look 
for moving to a new default though.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dfb45121-8ce6-4d6b-8505-5831778e4c3f%40googlegroups.com.

Re: Python version support for LTS Django (in particular v2.2)

[Nick Pope]

I think that the main reason for supporting Python 3.7 in Django 1.11 was 
to help make things easier for those migrating from Python 2 to 3.

Python 3.8 was only released ~3 months before the Python 2 EOL, so most 
people in the last year and up to the end of this year will likely migrate 
to Python 3.7.

I also feel the policy was a little aggressive given that the total change 
to support Python 3.7 was 
https://github.com/django/django/compare/216398d1...c11a7b4

So +1 to Python 3.8 for Django 2.2, with an option on Python 3.9 if trivial.

On Wednesday, 30 October 2019 14:44:20 UTC, Carlton Gibson wrote:
>
> Hi all. 
>
> In November last year we added official Python 3.7 support to Django 1.11.
>
> https://groups.google.com/d/topic/django-developers/H7fP5w0YU2I/discussion
>
> This was 18 months after release, and well into the extended support 
> period. 
>
> There had been a long-line of requests to add that support. It seems that 
> lots of users want both the latest 
> Python and the Django LTS. 
>
>
> Django 2.2 officially only supports Python 3.8. 
>
> Python 3.8 is already available. 
>
> Python 3.9 will be available Oct 2020, which is a ≈18months before 2.2. is 
> EOL, and is roughly equivalent to when we added support for Python 3.7 to 
> Django 1.11. 
>
>
> I predict a similarly strong demand to support the newer Python versions 
> in Django 2.2. 
>
> I'm happy to take whatever line we deem appropriate here, but I'd like to 
> avoid, for example, saying "No, it's not supported" for many months, before 
> then changing our minds. 
>
> So what shall we do? 
>
> Django 2.2 is still in mainstream support and I think it should 
> automatically get Python 3.8 support. 
> I think version of Django should support the new Python versions whilst in 
> mainstream support, but I think this applies doubly to the LTS, even though 
> the LTS isn't my thing, simply because of the demand for it. 
>
> Data point: I didn't test the full matrix but, tests are already passing 
> here. 
>
> For Python 3.9 I think we should probably declare now that we will review 
> whether we will support it for 2.2 LTS when it's released. 
> (i.e. if it's a small back port like the one required for 3.7/1.11 then 
> yes, otherwise no.) 
>
>
> What do we think? 
>
> Thanks 
> Kind Regards,
>
> Carlton
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/613aee69-1d8b-445c-a64b-0917eed976a7%40googlegroups.com.

Re: django-admin startproject settings.py has some security holes

[Nick Sarbicki]

I strongly disagree with this.

I've not seen a common standard between companies when it comes to settings
in Django and for good reason. Different companies employ different
standards and practices when it comes to configuration and security.
Enforcing an arbitrary standard - such as a settings file for each env - is
too opinionated for me and would often involve extra work on setup to
remove this initial way of doing things.

Likewise in my experience ignoring settings files is actually quite rare.
Most companies store secrets external to the settings file and prefer to
keep their settings in git. Adding a .gitignore with the settings files
would actually cause issues on future projects where you aren't expecting
this.

As mentioned this isn't necessarily to say having multiple settings files
or ignoring settings files are bad in an individual project. But that every
project has its own way of handling configuration and secrets, so enforcing
the standard *you* follow on everyone else - not because it is the best
possible way of doing things, but because it is how you do things - is
unlikely to be a popular move.

Adapting your settings configuration to the way you work is a small amount
of work - Django does a good job at the moment of staying unopinionated on
this whilst giving you what you need to get going.

On the SECRET_KEY. It is true that many people commit their SECRET_KEY into
the repo. But in the same way that you often get people committing DB
credentials and API keys. It is not a frameworks job to inform you of every
security malpractice (although Django does a good job of this already), it
is up to the developer to understand what they are doing. Despite this
there is extensive documentation on the SECRET_KEY needing to be secret,
mentioned both in the settings documentation and the deployment checklist.
There is even a comment above this setting explicitly stating that it
should be kept secret in production.

Assuming Django's startproject command aims to have a fully functioning
project from the get go - which means it needs a SECRET_KEY - then I think
this is a pretty good compromise as is.

- Nick


On Fri, Oct 11, 2019 at 12:14 PM Christian González <
christian.gonza...@nerdocs.at> wrote:

> Hi, may I disagree - I set up projects very often (for testing a package),
> and I always feel a bit awkward because of that monolithic settings.py file.
>
> I can really support Bobby's idea, even if development/staging/production
> may be a bit overkill. Having a practical standard which ensures good
> practice from the start is a good thing. And OTOH, it won't hurt anyone if
> these files are there.
>
> As there was another discussion earlier about "declarative" settings -
> maybe it would be helpful to exclude some of the settings from settings.py
> which is code, not declaration. SECRET_KEY could be anywhere by default, it
> doesn't have to be in an executable .py file. But this would mean to change
> Django's code to read it before or after importing settings.py.
>
> +1 for a .gitignore file too.
>
> Christian
> Am 10.10.19 um 22:18 schrieb Ehigie Aito:
>
> Hello Bobby,
> I think this should be added to a best practises documentation and not
> codified in Django. As I feel that would be overkill.
>
> On Thu, 10 Oct 2019, 20:41 Bobby Mozumder,  wrote:
>
>> In particular, they include settings that shouldn’t be stored in a git
>> repo such as SECRET_KEY and database passwords. You’ll find these kinds of
>> settings in git repos all the time.
>>
>> Really the default django-admin startproject shouldn’t have a single
>> settings.py that people include in their git repos, but instead a python
>> settings module, with a base.py, development.py, staging.py, and
>> production.py. An __init__.py reads base.py and one of
>> development/staging/production based on ENV variables (defaulting to
>> development if no ENV variable).
>>
>> Additionally, startproject should add a .gitignore in the root directory
>> to not include development/staging/production settings files.
>>
>> I get that this might not be absolutely necessary but I think these are
>> the kinds of defaults that make practical real-world use more secure, as
>> well as standardizing workflow for more advanced production usage.
>>
>> Is this something agreeable? I can put together a solution if people like
>> this.
>>
>> -bobby
>>
>>
>> --
>> 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 view this discussion on the web visit
>&g

Re: Explore integrating django-docker-box in some way?

[Nick Sarbicki]

That makes sense.

Do we have a list of the versions required? I'm happy to try it out and see
if it makes a difference.

- Nick


On Tue, Oct 8, 2019 at 12:05 PM Tom Forbes  wrote:

> I did experiment with it. The main problem is that the image we use
> requires a bunch of system libraries (see
> https://github.com/django/django-docker-box/blob/master/Dockerfile#L4). I
> think a few where missing our outdated in Alpine, but if that's changed
> then I'm not against trying it again.
>
> Tom
>
> On 8 Oct 2019, at 11:58, Nick Sarbicki  wrote:
>
> Just out of interest, Tom, have you tried using Alpine as the base? Or is
> there a reason to avoid it?
>
> I usually find once you introduce all the dependencies for django it
> doesn't make a huge difference but it might shave some of the weight off if
> we're worried about image size.
>
>
> - Nick
>
>
> On Tue, Oct 8, 2019 at 11:52 AM Josh Smeaton 
> wrote:
>
>> I was going to archive the repo, but it seems I don't have the necessary
>> permissions. Carlton, do you?
>>
>> On Tuesday, 8 October 2019 21:45:22 UTC+11, Adam Johnson wrote:
>>>
>>> +1 to archiving django-box
>>>
>>> On Tue, 8 Oct 2019 at 11:01, Tom Forbes  wrote:
>>>
>>>> Thank you for the kind words Bruno! I'm glad it's helped you, if you
>>>> have any suggestions for improvements then please open an issue on the repo
>>>> or post a message here, I know it's not perfect. I would have replied
>>>> earlier but this message didn't get delivered to me.
>>>>
>>>> I'm biased, but I'd be +1 on archiving the old django-box. It's served
>>>> us well, but unless someone is willing to spend some time updating it then
>>>> it's going to confuse new users.
>>>>
>>>> On Friday, 4 October 2019 12:40:02 UTC+1, Bruno Alla wrote:
>>>>>
>>>>> Just a note that as a newish contributor to Django, this
>>>>> django-docker-box is fantastic, it makes things much easier to setup.
>>>>>
>>>>> Thank you to everyone involved!
>>>>>
>>>>> On Wednesday, 5 December 2018 00:02:27 UTC, Tom Forbes wrote:
>>>>>>
>>>>>> To have this completely working at sprints without having everyone
>>>>>> building their own local images we would need to have the Jenkins server
>>>>>> use docker in some capacity. This would also require an official
>>>>>> django account on Docker hub.
>>>>>>
>>>>>> The pattern I’m using right now is that on every build we pull the
>>>>>> django-ci:latest image (from my personal account). Docker uses this
>>>>>> image as a cache automatically (preventing rebuilds). On any successful
>>>>>> master build we push the new image to docker-hub, so subsequent builds 
>>>>>> can
>>>>>> utilise it.
>>>>>>
>>>>>> Then anyone wanting to speed up their bootstrapping can do docker-compose
>>>>>> pull and automatically have the latest image available for running
>>>>>> right away. We can make this smaller, for sure, but we can also suggest
>>>>>> people download this beforehand (i.e at their hotel).
>>>>>>
>>>>>> I don’t know how feasible this is but it’s also very easy to run a
>>>>>> caching docker mirror (docker run -p 5000:5000 registry). Organizers
>>>>>> could run this at large events and configuring docker to use a local 
>>>>>> mirror
>>>>>> on the network is a one-line change for atendees.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4 December 2018 at 23:52:42, Josh Smeaton (josh@gmail.com)
>>>>>> wrote:
>>>>>>
>>>>>> Size of the image could definitely be a concern, especially at
>>>>>> sprints where wifi speeds aren't always optimal. The django-box image is
>>>>>> significantly larger though so it'd still be a net win. There are also
>>>>>> optimisations that can be made to the image for reducing size over time, 
>>>>>> so
>>>>>> I'd fully expect it to come down. I've spent a little bit of time trying 
>>>>>> to
>>>>>> optimise a $work$ python docker file, I'll provide what I've got as an
>>>>>> issue to possibly look at.
>>>>>>
>>>>>> I 

Re: Explore integrating django-docker-box in some way?

[Nick Sarbicki]

Just out of interest, Tom, have you tried using Alpine as the base? Or is
there a reason to avoid it?

I usually find once you introduce all the dependencies for django it
doesn't make a huge difference but it might shave some of the weight off if
we're worried about image size.


- Nick


On Tue, Oct 8, 2019 at 11:52 AM Josh Smeaton  wrote:

> I was going to archive the repo, but it seems I don't have the necessary
> permissions. Carlton, do you?
>
> On Tuesday, 8 October 2019 21:45:22 UTC+11, Adam Johnson wrote:
>>
>> +1 to archiving django-box
>>
>> On Tue, 8 Oct 2019 at 11:01, Tom Forbes  wrote:
>>
>>> Thank you for the kind words Bruno! I'm glad it's helped you, if you
>>> have any suggestions for improvements then please open an issue on the repo
>>> or post a message here, I know it's not perfect. I would have replied
>>> earlier but this message didn't get delivered to me.
>>>
>>> I'm biased, but I'd be +1 on archiving the old django-box. It's served
>>> us well, but unless someone is willing to spend some time updating it then
>>> it's going to confuse new users.
>>>
>>> On Friday, 4 October 2019 12:40:02 UTC+1, Bruno Alla wrote:
>>>>
>>>> Just a note that as a newish contributor to Django, this
>>>> django-docker-box is fantastic, it makes things much easier to setup.
>>>>
>>>> Thank you to everyone involved!
>>>>
>>>> On Wednesday, 5 December 2018 00:02:27 UTC, Tom Forbes wrote:
>>>>>
>>>>> To have this completely working at sprints without having everyone
>>>>> building their own local images we would need to have the Jenkins server
>>>>> use docker in some capacity. This would also require an official
>>>>> django account on Docker hub.
>>>>>
>>>>> The pattern I’m using right now is that on every build we pull the
>>>>> django-ci:latest image (from my personal account). Docker uses this
>>>>> image as a cache automatically (preventing rebuilds). On any successful
>>>>> master build we push the new image to docker-hub, so subsequent builds can
>>>>> utilise it.
>>>>>
>>>>> Then anyone wanting to speed up their bootstrapping can do docker-compose
>>>>> pull and automatically have the latest image available for running
>>>>> right away. We can make this smaller, for sure, but we can also suggest
>>>>> people download this beforehand (i.e at their hotel).
>>>>>
>>>>> I don’t know how feasible this is but it’s also very easy to run a
>>>>> caching docker mirror (docker run -p 5000:5000 registry). Organizers
>>>>> could run this at large events and configuring docker to use a local 
>>>>> mirror
>>>>> on the network is a one-line change for atendees.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4 December 2018 at 23:52:42, Josh Smeaton (josh@gmail.com)
>>>>> wrote:
>>>>>
>>>>> Size of the image could definitely be a concern, especially at sprints
>>>>> where wifi speeds aren't always optimal. The django-box image is
>>>>> significantly larger though so it'd still be a net win. There are also
>>>>> optimisations that can be made to the image for reducing size over time, 
>>>>> so
>>>>> I'd fully expect it to come down. I've spent a little bit of time trying 
>>>>> to
>>>>> optimise a $work$ python docker file, I'll provide what I've got as an
>>>>> issue to possibly look at.
>>>>>
>>>>> I see that the ticket has been accepted and I think that's a great
>>>>> step forward. I'd also like to hear from the infrastructure team what 
>>>>> their
>>>>> thoughts on using docker over customised build environments would be.
>>>>>
>>>>> Florian, Tim, Markus .. any thoughts? (Apologies, I've missed some,
>>>>> this list of names is from memory).
>>>>>
>>>>> On Wednesday, 5 December 2018 10:39:16 UTC+11, Tom Forbes wrote:
>>>>>>
>>>>>> Thank you for the reply Josh. I didn’t anticipate any suggestions for
>>>>>> including this inside core but off the back of your suggestion I’ve made 
>>>>>> a
>>>>>> ticket here: https://code.djangoproject.com/ticket/30010.
>>>>>>
>>>>>&

Re: Proposal to format Django using black

[Nick Sarbicki]

>
>
> I'm just saying that if "As contributor, I can haz automatic code 
> formatter to lower the barrier" is precisely the story you want to solve, 
> then black may not be the only solution you want to consider deeply ;)
>
>
Jamie, sure, I wasn't responding directly to you about this, more to the 
general people arguing against blacks style choices. I would happily 
consider alternatives to black - although (without any formal research to 
back this claim) it does feel like black has the most community support.

My point is mostly that if there is a growing community consistency through 
black then I'd be hesitant to choose another tool that goes against this.

 

> > 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. 
> -- 
>

Thanks for the correction Melvyn, you're right - aside from readability and 
backwards compatibility consistency is important.

I'd also note the irony of using PEP8 to argue for consistency with a tool 
that is (at least on line length) inconsistent with PEP8. Although I really 
don't want to start a debate on line length.

-- 
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/3041089f-97dd-405e-98ff-e19d53575e1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Nick Sarbicki]

I'm still quite strongly in support of black. I find it's very nice to read
a codebase that has strong consistency (which is historically usually the
work of pedantic but very necessary reviews).

It's even nicer to go between multiple codebases which are all consistent
with each other. PEP8 and linters like flake8 go quite a long way in
achieving this but black goes even further.

There will always be arguments about what standards to use, it's an
unsolvable problem. Some people may think the current Django standards are
perfect, some will prefer blacks defaults, even more will have their own
preferences. I feel that it is arbitrary to make this a major point, it
will never be agreed upon.

Consistency in the end is the most important thing (even PEP8 agrees
there). If we can contribute towards a global consistency in the python
community that would be wonderful. If black is the way the community is
going for this, then that is where my vote is. Even moreso if it lowers the
barrier to entry (I don't think anyone is saying it raises it?).


On Mon, 22 Apr 2019, 07:44 Jamesie Pic,  wrote:

> Just note that the coala python package ( https://coala.io ) seems to be
> the alternative to black that will let you make some compromises, might be
> worth considering as well.
>
> --
> 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/CAC6Op18_ZPJS5pm%3DZ%2B%2B3z3O4NZJydEvF75v-FNkmhQw0xjThYw%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGuvt92iP_Z0niqWw%3D3T0j-BtTL-pyNmrcHPwcE0hHqhQWyMyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Nick Sarbicki]

Just going to say that one of the main frustration points I've had when
making a contribution is having to fix small formatting errors (often minor
things in docstrings which aren't _always_ consistent).

It produces a lot of inertia and can stop PRs from getting merged for
extended periods of time. So from a new contributor angle I think black is
an obvious choice.

>From a maintainers point of view, git blame is very nice to have and this
would add some complexity. But it's easy to see the full version history of
a file and, let's be honest, not enough people use git bisect.


On Sun, 14 Apr 2019, 00:04 Berker Peksağ,  wrote:

> On Sun, Apr 14, 2019 at 1:34 AM Carlton Gibson 
> wrote:
> >
> > We spend a lot of time spotting small formatting errors and then asking
> for those to be fixed and then waiting for an update. This wastes reviewer
> time and slows down the feedback cycle. Many pull requests drag out because
> of it.
>
> But you can now do final edits (cosmetic changes, tweak reST markup
> and documentation) via GitHub UI, right? I always do it to not bother
> contributors with these changes, especially if they are new to the
> project.
>
> --Berker
>
> --
> 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/CAF4280J%2B6J1BJAto1MHd8mo5X%2Bm4AohSqS2HQr3yNXh1WOUcRQ%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGuvt92sVXVAuTzLW7sQkpkJEdNuamfeQwjwcn2dvFokZDZ7CQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: database configuration error(django and mysql)

[Nick Perry (Souldeux)]

Desh, as Adam already mentioned to you once before:

> This mailing list is for the development of Django itself, not for support 
> using Django. Please use. the django-users mailing list for that, or IRC 
> #django on freenode, or a site like Stack Overflow.



___
Nick Perry
404.660.1020
nperr...@gmail.com



> On Jan 29, 2019, at 10:13 AM, Desh Deepak  wrote:
> 
> 
> Forbidden (403)
> CSRF verification failed. Request aborted.
> Help
> Reason given for failure:
> CSRF token missing or incorrect.
> 
> In general, this can occur when there is a genuine Cross Site Request 
> Forgery, or when Django's CSRF mechanism 
> <https://docs.djangoproject.com/en/2.1/ref/csrf/> has not been used 
> correctly. For POST forms, you need to ensure:
> Your browser is accepting cookies.
> The view function passes a request to the template's render 
> <https://docs.djangoproject.com/en/dev/topics/templates/#django.template.backends.base.Template.render>
>  method.
> In the template, there is a {% csrf_token %} template tag inside each POST 
> form that targets an internal URL.
> If you are not using CsrfViewMiddleware, then you must use csrf_protect on 
> any views that use the csrf_token template tag, as well as those that accept 
> the POST data.
> The form has a valid CSRF token. After logging in in another browser tab or 
> hitting the back button after a login, you may need to reload the page with 
> the form, because the token is rotated after a login.
> You're seeing the help section of this page because you have DEBUG = True in 
> your Django settings file. Change that to False, and only the initial error 
> message will be displayed.
> You can customize this page using the CSRF_FAILURE_VIEW setting.
> 
> -- 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers 
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJ0m4xj66-WXGviUkYhtJWgL--NCQ-QpDQEAULaVDYrzsYfaYQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CAJ0m4xj66-WXGviUkYhtJWgL--NCQ-QpDQEAULaVDYrzsYfaYQ%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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/721980F8-DE24-4057-AB3A-F15D25815B78%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug in utils.encoding producing invalid JSON for request body

[Nick Sarbicki]

There's been a longer discussion on the ticket about this. The point you
raise I agree with. I also think _encode_data should be left alone.

I still think this should be in framework instead of having to subclass
RequestFactory. Passing in a dict as data should not give invalid JSON.

Instead it would be better to implement an _encode_json. This would be
called if we have the correct content_type within the .post, .patch and
.delete methods. Question for me is how to pass the kwargs in for
json.dumps to allow custom encoders. Or do we not want this (I think we do)?

On Mon, Jan 29, 2018 at 4:50 PM Adam Johnson <m...@adamj.eu> wrote:

> the JSON it produces (it does try)
>>
>
> I wouldn't say it "tries", it just calls str on any object that is passed
> in, which for a simple dict with strings in, looks close to JSON.
> force_bytes definitely shouldn't be trying to JSON-coerce things.
>
> Thus I don't think it's a bug. Bugs are when behaviour doesn't match the
> documentation, and afaict coercing a dict to JSON isn't documented anywhere.
>
> It should be possible to make a subclass of RequestFactory or Client that
> does json.dumps inside _encode_data before calling super(). It's possible
> to swap the self.client on your TestCase subclasses easily by setting
> client_class so you could make it the default in your project.
>
> On 29 January 2018 at 14:14, Nick Sarbicki <nick.a.sarbi...@gmail.com>
> wrote:
>
>> I've just posted a ticket for this here:
>> https://code.djangoproject.com/ticket/29082#ticket
>>
>> The general point is that when I'm using RequestFactory and making a post
>> request with a JSON body, I'd expect to be able to pass in a dict for this
>> - but I can't as the JSON it produces (it does try) is invalid (single
>> instead of double quotes).
>>
>> The fix is three lines in the file but another isinstance call among many.
>>
>> I've been meaning to contribute for a long time and would like this to be
>> my first ticket if I can get confirmation that it _is_ a bug and not
>> intentional.
>>
>> Reproducible example and exact location of offending code are in the
>> ticket.
>>
>> - Nick.
>>
>> --
>> 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/77ab7248-3d6f-4cca-8ddc-27afc49c520c%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/77ab7248-3d6f-4cca-8ddc-27afc49c520c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM1biqF10RR9Ybm%3Dbs083PCSQbjwy1LCCM66nOS4B%3DW6rA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1biqF10RR9Ybm%3Dbs083PCSQbjwy1LCCM66nOS4B%3DW6rA%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 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/CAGuvt9216aoAbTSukC0a9VxGitxcx4zhmkqfS%2BFu0oVg%2BYNz4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Bug in utils.encoding producing invalid JSON for request body

[Nick Sarbicki]

I've just posted a ticket for this 
here: https://code.djangoproject.com/ticket/29082#ticket

The general point is that when I'm using RequestFactory and making a post 
request with a JSON body, I'd expect to be able to pass in a dict for this 
- but I can't as the JSON it produces (it does try) is invalid (single 
instead of double quotes).

The fix is three lines in the file but another isinstance call among many.

I've been meaning to contribute for a long time and would like this to be 
my first ticket if I can get confirmation that it _is_ a bug and not 
intentional.

Reproducible example and exact location of offending code are in the ticket.

- Nick.

-- 
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/77ab7248-3d6f-4cca-8ddc-27afc49c520c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Having an --include option for collectsstatic.

[Nick Sarbicki]

I recently found I needed to create a command to include specific files for 
collectstatic and ignore everything else (images and fonts). The opposite 
of the current --ignore functionality.

I've tried to do this with the current --ignore option using glob syntax 
but haven't managed to "ignore all but these file types".

I'm making this functionality now for my project but wondering if it would 
be a welcome addition to django itself?

Looking through the collectstatic code it should be doable by adding 
another if statement at 
https://github.com/django/django/blob/master/django/contrib/staticfiles/utils.py#L26

if include_patterns and not matches_patterns(fn, include_patterns):
continue

And some upstream changes to include "include_patterns" as an option for 
the file finders list methods and the collectstatic command itself.

Setting include_patterns to a default of None should make the addition 
backwards compatible for any third party finders.

Is there any interest in doing this? I accept my current use case is fairly 
niche but it may be useful for others.

Nick.

-- 
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/e0575126-d804-441c-b70a-945d5ffed189%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for database level on delete cascade 21961

[Nick Stefan]

My understanding of why you wouldn't want to support using both kwargs at 
the same time is that it would negate any performance gains from using the 
DB's delete.

DB_CASCADE has the advantage of not making django run extra queries against 
every model relation to determine which other tables need cascading delete 
queries. For example, pretend we've got an app with one particular "shard 
key", if you will, that relates to about 20 different tables. When I delete 
that record from the root shard key table, django will run a query against 
every one of those 20 related tables looking for that key. DB_CASCADE means 
the DB could just do that for me after deleting one record in the root 
shard key table with a single query between the server and the database.

If we use both, then we have to first run all of those extra queries 
against the other tables. Its true that they'd be SELECTs versus DELETE, 
but still queries. Then we'd delete that one record and let the DB do its 
thing.

It's possible that someone would want that, I guess, to allow DB 
constraints and signals to work together, but it seems rather inefficient. 
I guess it is possible though.

> I'm also curious why you wouldn't put the contraints directly on the DB 
table instead of injecting them into the SQL commands.

In the PR, I actually do use the existing SQL commands that define table 
columns, but add a little extra constraints (ON DELETE CASCADE). So I 
believe it is running against the DB table directly? Did I understand you 
correctly?

Nick


On Monday, December 11, 2017 at 10:56:31 AM UTC-8, Dylan Young wrote:
>
> There's also the added burden on explaining that we can only pass one of 
>> the two kwargs, and not use both at the same time. I think that favors 
>> overloading a single kwarg.
>>
>
> I'm not clear *why* you wouldn't be able to use both at the same time?  
>  In fact, this seems like the primary benefit of using two separate 
> kwargs.  Can you explain?
>
> I'm also curious why you wouldn't put the contraints directly on the DB 
> table instead of injecting them into the SQL commands.
>
> Can you explain the rationale behind these decisions/constraints?
>
>
> Best,
>
> Dylan
>
> On Monday, 24 July 2017 23:34:33 UTC-3, Nick Stefan wrote:
>>
>> Hi All,
>>
>> I've taken interest to implimenting built in django support of ON DELETE 
>> CASCADE. As a general concept, the ticket was accepted 3 years ago, and 
>> there was some discussion around that time: 
>> https://code.djangoproject.com/ticket/21961 . I've put together a small 
>> PR with some but not all of the proposed design decisions, 
>> https://github.com/django/django/pull/8661. The original ticket proposed 
>> adding something like models.DB_CASCADE in addition to models.CASCADE, 
>> models.SET_NULL. That is the tact that I took in the PR.
>>
>>
>> At the time of the ticket there were some concerns:
>>
>> 1. Q: What do we do with models.DB_CASCADE when using a DB that doesn't 
>> support it? 
>> A: MySQL, PostgreSQL, SQLite3 and Oracle all now support this 
>> functionality.
>>
>> 2. Q: Won't it be confusing that signals will not fire? 
>> A: We can document that the application code mimics models.DO_NOTHING, no 
>> signals will fire, and that all the deletion will be handled by SQL.
>>
>> 3. Q: Won't it be confusing that models.DB_CASCADE won't trigger a 
>> foreign model's models.CASCADE?
>> A: Is it any different than having a models.DO_NOTHING table pointing to 
>> a models.CASCADE table? We can document that on the application side, 
>> models.DB_CASCADE works like models.DO_NOTHING.
>>
>> 4. Q: generic foreign keys?
>> A: We could forbid models.DB_CASCADE on these types of relations?
>>
>> 5. Q: implicit foreign keys between child to parent in model inheritance?
>> A: We could forbid models.DB_CASCADE on these types of relations?
>>
>>
>> Additionally there was a proposal by Carl Meyer to split out database 
>> based delete into a separate kwarg. To summarize: 
>> ForeignKey(on_delete=models.CASCADE) versus 
>> ForeignKey(on_delete_db=models.DB_CASCADE). This would help avoid having to 
>> implement a magical fallback mode when the DB didn't support 
>> models.DB_CASCADE. It also would help eliminate two very different code 
>> paths overloading the same kwarg.
>>
>> My thoughts on the above splitting of the kwargs:
>> All of the django 2.0 databases can support ON DELETE CASCADE. So there's 
>> no longer any need for a magical fall back mode. There's also the added 
>> burden on explaining that we can only pass one of the two kwargs, and not 
>> use both at the same time. I th

Re: New Feature: Allow password reset token to expire in under a day

[Nick Zaccardi]

There are cases where corporate security policies require (regardless of 
the actual security they provide) which require a <24hr link. Here is a 
x/post from this ticket :

I do want to explain why this doesn't meet the 1% of use cases. When I 
> originally reported this I was working on a password reset feature in a 
> different app (a large corporate financial application) which has very 
> specific policies on passwords, password resets, and the validity time of 
> both. From a contractual perspective (regardless of user experience) >24hr 
> link would be a break in policy or worse a violation of contractual 
> obligation to implement a <24hr link. For most up to 2 days is fine, for 
> some, regardless of the real-life implications of the policy, it is a big 
> deal.
>

On Saturday, September 23, 2017 at 9:41:17 AM UTC-5, Luke Plant wrote:
>
> Hi Zach,
>
> To be clear, I'm not totally opposed to the change. There could certainly 
> be advantages to updating the code, especially if we move to 
> TimestampSigner.
>
> However, from a quick look, I'm not sure if TimestampSigner will be 
> possible - we want the hashed value to incorporate some internal data, but 
> don't want that internal data to be part of the signed message that Signer 
> produces (for various reasons, including the fact that we want to keep the 
> URL as short as possible for maximum compatibility). I think we should also 
> be careful not to change the public interface of 
> PasswordResetTokenGenerator, since people may have subclassed it, which 
> limits the amount of cleanup you can do here. 
>
> I imagine that changing the timestamp to support better precision will 
> also create work for people upgrading (the setting change, plus URLconf 
> changes). 
>
> What I am suggesting is that we should seriously consider whether all this 
> is worth it given the extremely marginal security benefits.
>
> Regards,
>
> Luke
>
> On 23/09/17 04:33, Zhiqiang Liu wrote:
>
> Luke, 
>
> thanks for the long explanation. I see your points here. I actually saw 
> the make token function and was thinking about it what is the best way to 
> do with that. I think most people here feel there's need to at least allow 
> some flexibility for the time out since there will be cases under a day is 
> needed.
> I will keep this discussion for a couple of more days to see if we can get 
> consensus and how we should implemented if needed.
>
> Zach
>
> On Friday, September 22, 2017 at 3:04:01 PM UTC-4, Luke Plant wrote: 
>>
>> I would be +1 to what Adam wrote from me i.e. just allow the value to 
>> accept floats.
>>
>> However, I don't think it will work due to the way that we round the 
>> precision of timestamps to days 
>> .
>>  
>> This was done partly to reduce the number of characters needed to express 
>> the timestamp, to keep URLs as short as possible. We would  have to change 
>> the mechanism to store more precision into the timestamp. This would result 
>> in an upgrade 'bump' for users (i.e. links generated before the upgrade 
>> would become invalid after upgrade).
>>
>> However, I really question whether we need any change here, and whether 
>> it would be a good idea.
>>
>> Having a short expiration time (less than 1 hour) could cause major 
>> problems for some people - plenty of systems introduce 5 or 10 minute 
>> delays in mail delivery, and with some people's internet connection it can 
>> take several minutes to open a web page. This also means that some people 
>> end up finishing the process of whatever they were doing the next day (I 
>> know I've done this several times on various sites), so a timeout of at 
>> least 1 or 2 days is a good default. If you want to come back after the 
>> weekend and carry on, 3 days makes more sense as a minimum.
>>
>> In terms of security, I don't think there is really any need for anyone 
>> to reduce below the default at all (see below). So I'm very unconvinced 
>> about the need for changing to PASSWORD_RESET_TIMEOUT - it is just 
>> unnecessary upgrade work for some existing projects (this is the biggest 
>> consideration for me), and it could encourage people to set the value to 
>> something low that would decrease usability.
>>
>> *Security:*
>>
>> The security of the password reset feature is almost entirely independent 
>> of the value of the timeout setting. There are 3 attack vectors I can see:
>>
>> 1) Someone's email account is compromised, and they then do a password 
>> reset on a Django site.
>>
>> We simply can't protect against this AFAICS.
>>
>> 2) Someone's email account is compromised, and they find/use a password 
>> reset email in the person's inbox.
>>
>> This is the only scenario for which having a shorter timeout makes a 
>> difference. It is somewhat unlikely, because in 99% of cases the attacker 
>> would be able to generate a password reset email 

Re: Support for database level on delete cascade 21961

[Nick Stefan]

Thanks for the feedback Anssi.

The original ticket talked about making DB_CASCADE work where it can, and 
adding warnings to most other places. I've updated the PR with checks 
warnings for the following cases (including tests for said checks cases):


   - GenericForeignKey + DB_CASCADE (#4 in the Original Post)
   - concrete model inheritance + DB_CASCADE (e.g. the example Anssi gave 
   above, and #5 in the OP)
   - model A DB_CASCADE --> model B CASCADE (wont get triggered) --> model 
   C (#3 in the OP)

If anyone wants to take a look: https://github.com/django/django/pull/8661

Nick

On Thursday, July 27, 2017 at 1:19:19 AM UTC-7, Anssi Kääriäinen wrote:
>
> On Tuesday, July 25, 2017 at 5:34:33 AM UTC+3, Nick Stefan wrote:
>>
>> 5. Q: implicit foreign keys between child to parent in model inheritance?
>> A: We could forbid models.DB_CASCADE on these types of relations?
>>
>
> There's actually a variation of this that seems a bit hairy to solve 
> properly. For models:
>
> class Category:
> pass
>
> class Child:
> pass
>
> class Parent(Child):
> category = models.ForeignKey(Category, on_delete=DB_CASCADE)
>
> Then, when you delete a category instance, the associated parent instance 
> will get deleted, but the child instance won't (as there's no foreign key 
> from child to parent, we can't make this work in the DB without using 
> triggers).
>
> Now, the problem here is that this actually leaves the database in an 
> inconsistent state. I guess the solution might be to document this, add a 
> warning to checks done on startup, and let users deal with the 
> inconsistency if they so decide.
>
> We could solve these problems by including an O2O from both parent to 
> child and from child to parent, and making them both DB_CASCADE. That's not 
> a good idea for other reasons (complexity of saving a new instance to the 
> database for one). If we want to make these cases work seamlessly directly 
> in the database, it's likely better to add in triggers. It wouldn't be 
> horribly complex code to write. The hardest part would be making sure the 
> triggers are kept in sync when doing migrations.
>
> For the other parts your proposal does make a lot of sense to me. Don't 
> fall in the trap of complexities in parent -> child cascade. Just add 
> warnings and that's it.
>
>  - Anssi
>

-- 
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/0119909c-2fa6-44c6-b0c5-5991c5c368ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Support for database level on delete cascade 21961

[Nick Stefan]

Hi All,

I've taken interest to implimenting built in django support of ON DELETE 
CASCADE. As a general concept, the ticket was accepted 3 years ago, and 
there was some discussion around that time: 
https://code.djangoproject.com/ticket/21961 . I've put together a small PR 
with some but not all of the proposed design decisions, 
https://github.com/django/django/pull/8661. The original ticket proposed 
adding something like models.DB_CASCADE in addition to models.CASCADE, 
models.SET_NULL. That is the tact that I took in the PR.


At the time of the ticket there were some concerns:

1. Q: What do we do with models.DB_CASCADE when using a DB that doesn't 
support it? 
A: MySQL, PostgreSQL, SQLite3 and Oracle all now support this functionality.

2. Q: Won't it be confusing that signals will not fire? 
A: We can document that the application code mimics models.DO_NOTHING, no 
signals will fire, and that all the deletion will be handled by SQL.

3. Q: Won't it be confusing that models.DB_CASCADE won't trigger a foreign 
model's models.CASCADE?
A: Is it any different than having a models.DO_NOTHING table pointing to a 
models.CASCADE table? We can document that on the application side, 
models.DB_CASCADE works like models.DO_NOTHING.

4. Q: generic foreign keys?
A: We could forbid models.DB_CASCADE on these types of relations?

5. Q: implicit foreign keys between child to parent in model inheritance?
A: We could forbid models.DB_CASCADE on these types of relations?


Additionally there was a proposal by Carl Meyer to split out database based 
delete into a separate kwarg. To summarize: 
ForeignKey(on_delete=models.CASCADE) versus 
ForeignKey(on_delete_db=models.DB_CASCADE). This would help avoid having to 
implement a magical fallback mode when the DB didn't support 
models.DB_CASCADE. It also would help eliminate two very different code 
paths overloading the same kwarg.

My thoughts on the above splitting of the kwargs:
All of the django 2.0 databases can support ON DELETE CASCADE. So there's 
no longer any need for a magical fall back mode. There's also the added 
burden on explaining that we can only pass one of the two kwargs, and not 
use both at the same time. I think that favors overloading a single kwarg.

Simon Charrette made a suggestion to make the models.CASCADE, 
models.SET_NULL, models.DB_CASCADE, etc all inherit from an OnDelete class. 
This allows the old application callables to still be simple callables, new 
SQL based operations such as DB_CASCADE to access an as_sql method, and yet 
both be instances of the same class for migration serialization. 


Seeking feedback,
Nick

-- 
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/20f67b4e-bf5b-4c55-bcc8-aac41cfae598%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Javascript Templating Package

[Nick Sarbicki]

Hi Daniel,

This is a separate idea. Instead of relying on JSON dumps, we actually
generate an entire JS script via the engine.

The flow is along the lines of:

> Client makes request

> Django receives request and renders an HTML page which it passes to the
client.

> The given HTML page has a script tag which requests a javascript file
from our server.

> Django receives this request and, instead of serving a static javascript
file, renders a javascript file via the templating engine which it then
passes to the client.

This allows us to have more control over the client side scripts based on
what is happening server side.

It's a bit niche - but it cleared up a lot of the legacy JS held in massive
script tags which were overly wasteful and required a lot of tampering
based on server side variables.

On Tue, Oct 11, 2016 at 3:11 PM Daniel Moisset <dmois...@machinalis.com>
wrote:

> Hi Nick, I'm not sure what kind of generation are you suggesting. What
> I've used a couple of times is creating a template tag to convert a
> json-like data structure in the context to a javascript object, so in the
> template I have something like this in a 

Javascript Templating Package

[Nick Sarbicki]

Hi Everyone,

We were tasked at work some time ago with tidying up a legacy Django 
project. Part of the projects JS relied heavily on Django variables and 
settings and we were seeing frequent large variable JSON dumps in the 
templates.

We cleaned this up and ended up designing a small package which allowed us 
to generate Javascript files through the Django templating engine when 
requested by the client.

Since then we've started finding ourselves thinking about using this 
package more and more.

So I was wondering, is this something that the community would be 
interested in? It's not open source yet but we're considering opening up 
the particular package (not least so its more available for us).

If it's not at all of interest, why? Is there a big disadvantage to 
generating Javascript through the templating engine? (assume you, and not 
the client, control the variables going in.

-- 
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/04d4d42d-3bfa-47c6-9ac7-e9d801de9286%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Looking for feedback on implementation of UserManager.with_perm()

[Nick Pope]

Hi Berker,

I just wanted to highlight my comment on the PR here for the benefit of 
those discussing this:

https://github.com/django/django/pull/7153#issuecomment-242672721

We currently horribly abuse the existing permission system to add 
additional global permissions in a hacky way by manually adding content 
types. (https://code.djangoproject.com/ticket/24754 would be awesome) 

My scenario is simply having an easy method to find users *and* groups with 
a particular permission or set of permissions. Doing so is rather clunky at 
the moment.
I also feel that any solution should have the ability to optionally 
include/exclude by is_superuser and is_active flags - we often want to know 
who has a permission whether implicit or explicit.

Thanks,

Nick

On Wednesday, 14 September 2016 05:10:41 UTC+1, Berker Peksag wrote:
>
> https://github.com/django/django/pull/7153/ implements 
> UserManager.with_perm() [1] as: 
>
> def with_perm(self, perm): 
> for backend in auth.get_backends(): 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> return self.get_queryset().none() 
>
> [1] "Shortcut to get users by permission": 
> https://code.djangoproject.com/ticket/18763 
>
> With this implementation, users of UserManager.with_perm() won't get 
> users with permissions for all backends. Also, result of 
> UserManager.with_perm() will depend on the order of 
> settings.AUTHENTICATION_BACKENDS. See also 
> https://code.djangoproject.com/ticket/18763#comment:9 for more 
> information about the current strategy. 
>
> I suggested an alternative approach at 
> https://github.com/django/django/pull/7153/files#r78226234 with the 
> following implementation: 
>
> def with_perm(self, perm, backend=None): 
> if backend is None: 
> backends = _get_backends(return_tuples=True) 
> if len(backends) != 1: 
> raise ValueError( 
> 'You have multiple authentication backends configured 
> and ' 
> 'therefore must provide the `backend` argument.' 
> ) 
> _, backend = backends[0] 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> else: 
> backend = load_backend(backend) 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> return self.get_queryset().none() 
>
> This also simulates what django.contrib.auth.login() does when 
> multiple authentication backends are defined: 
>
>
> https://github.com/django/django/blob/18c72d59e0807dae75ac2c34890d08c1e0972d0a/django/contrib/auth/__init__.py#L100
>  
>
> Tim suggested to get some feedback about possible use cases: 
>
> "I'm not sure about the use cases. For example, someone might want to 
> get users with permissions for all backends. It would be nice if we 
> had some feedback about what users are implementing on their own to 
> confirm we're targeting the largest use case." 
>
> Is there any other possible use cases? Which one of the suggested 
> approaches cover the largest use case? 
>
> Thanks! 
>
> --Berker 
>

-- 
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/c5249500-d576-44ab-b38a-78ac22866782%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Joining the "Python 3 Statement"

[Nick Timkovich]

Regarding "forcing", the statement has a similar sentiment: "Third parties 
may offer paid support for our projects on old Python versions for longer 
than we support them ourselves. We won’t obstruct this, and it is a core 
principle of free and open source software that this is possible." If Blue 
Hat has a market for and chooses to develop Django 1.12 to run on their 
Python 2.8, that's fantastic. Just that you can't expect *free* support by 
the community beyond 2020.

Yes, the statement is status-quo for Django, but my motivation is more for 
this to expand the scope of said statement beyond the SciPy stack. Because 
this doesn't alter policy, I'm hoping for this as a smooth segue towards 
broader awareness/adoption.

On Sunday, July 10, 2016 at 1:18:56 PM UTC-4, Florian Apolloner wrote:
>
> On Sunday, July 10, 2016 at 3:22:47 PM UTC+2, Nick Sarbicki wrote:
>>
>> The problem with announcing way back is people outside of the sphere 
>> forget.
>>
>
> But then again those will not bother if Django is on Python3 or not. For 
> those it might be way more important if the default python is python3 on 
> their machines, or if a recent python is even available (looking at you 
> RHEL ;)).
>  
>
>> Even then (warning, dumb analogy coming), if I was asked to sign a 
>> petition to my government, I wouldn't refuse just because I'd already 
>> written to my MP about it. Speaking together has more power.
>>
>
> Yeah, given the current political situation I'd rather not continue that 
> argument -- lets leave politics out ;)
>  
>
>> My last job as an example had a huge pure python programme that is core 
>> to the business. My manager would try to justify upgrading to 3.x but it 
>> never caught on with the seniors. They would look at the stats and see most 
>> people still using 2.7, most libraries still working in 2.7, and see the 
>> current code still running in 2.7. There's never been anything big enough 
>> to convince them.
>>
>
> And those people are not convinced by a pledge either, so whats the point. 
> Then again, the decisions on companies often depend on other factors (ie 
> support on their machines etc…), and using python3 should be evaluated on a 
> project per project basis (and if a [non-binding]pledge is enough to shift 
> your managers, you probably have something else to worry about :D). 
>
> Even more to the point (and far worse in my mind) are the teaching 
>> websites like codecademy and learn python the hard way. They all still use 
>> python 2! And to justify it they quote employability and lack of 3.x 
>> uptake. Again if they were to have something bigger put in front of them to 
>> show how much of a dead end 2.7 is, it could push them to change.
>>
>
> Those people are quite aware that python3 is out there and ready, such a 
> statement is not going to help. It is probably quite a bit of work to 
> upgrade all those tutorials and they maybe do not see the gain in time vs 
> money or whatever…
>  
>
>> If that changes 3.x can get a big push forward. And that in the future 
>> can help Django.
>>
>
> And how exactly can that help Django?
>  
>
>> Realistically though, what is stopping us from signing? What negative 
>> outcome can it have?
>>
>
> Probably nothing, but Django in the past has never tried to convince 
> anyone or force anyone to do something (aside from the decisions we make 
> within our framework), and we do not feel the urge to force our view on 
> others -- nor sign a pledge for that matter. Our stance on Python 3 is 
> clear, we made our point, but we do not need or have to convince anyone 
> else.
>
> Cheers,
> Florian
>
>>

-- 
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/968d26e0-d792-4e0d-8bc7-b2173e850f30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Joining the "Python 3 Statement"

[Nick Sarbicki]

>
> Not going to carry this on much more as I doubt I'll be convincing. And
while I, for the most part, agree that group pledges won't change the minds
of those locked to 2.7, I'm hopelessly optimistic about it :-).

And how exactly can that help Django?
>

I think anything which advances and promotes python3 will have direct knock
on effects for Django post 2.0. We all want to see the project thrive, and
if the language it's built on thrives as well that can only be a good thing.


Realistically though, what is stopping us from signing? What negative
>> outcome can it have?
>>
>
> Probably nothing, but Django in the past has never tried to convince
> anyone or force anyone to do something (aside from the decisions we make
> within our framework), and we do not feel the urge to force our view on
> others -- nor sign a pledge for that matter. Our stance on Python 3 is
> clear, we made our point, but we do not need or have to convince anyone
> else.
>

Again I think there's a difference in opinion here. I don't see it as
something we as a project need to convince people of. I see it as a
statement of intent. Django doesn't need to convince anyone, it just needs
to say "this is happening" (and if I had my way in this conversation,
publicly, more than once and in union with other projects...). The
convincing should be left to those using it.

Maybe it would have been better to not have an officially signed list. But
instead just a curated list of projects which have announced that they
won't support 2.7 at some date. Would have been easier and less political.

Nick.

>

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

Re: Joining the "Python 3 Statement"

[Nick Sarbicki]

On my phone so excuse typos.

On Sun, 10 Jul 2016, 13:28 Florian Apolloner, <f.apollo...@gmail.com> wrote:

>
>
> On Saturday, July 9, 2016 at 10:26:25 PM UTC+2, Nick Sarbicki wrote:
>>
>> I don't think this is a question of what it would do for Django. More
>> what Django could do for python.
>
>
> We already announced (way way back), that we are dropping support for
> Python 2 and outlined our plan. That is imo enough, being on a side like
> python3statement.github.io does not add any value to python.
>


The problem with announcing way back is people outside of the sphere
forget. Yes everyone working with Django should know. I know everyone in my
team is very aware of the deadline.

But those outside of Django forget how seriously this is being taken by the
community.

Even then (warning, dumb analogy coming), if I was asked to sign a petition
to my government, I wouldn't refuse just because I'd already written to my
MP about it. Speaking together has more power.

Again, no immediate benefit to Django, but there is one for python.



> The web and scientific communities are essentially the two biggest python
>> communities around. If they both joined together to say "2020 is the
>> deadline for us and everyone else" it could really push a lot of others to
>> see how serious the need to move is now.
>>
>
> Everyone seriously involved in Django (agencies, companies) etc are
> already aware of our plans and are hopefully preparing themselves, if not,
> there is little else we can do which would change their minds…
>

Again, in Django most definitely are. But outside of Django it's less clear.

My last job as an example had a huge pure python programme that is core to
the business. My manager would try to justify upgrading to 3.x but it never
caught on with the seniors. They would look at the stats and see most
people still using 2.7, most libraries still working in 2.7, and see the
current code still running in 2.7. There's never been anything big enough
to convince them.

It didn't run Django so Django announcing wouldn't have any impact. But if
all the major libraries announced then it might have.

Even more to the point (and far worse in my mind) are the teaching websites
like codecademy and learn python the hard way. They all still use python 2!
And to justify it they quote employability and lack of 3.x uptake. Again if
they were to have something bigger put in front of them to show how much of
a dead end 2.7 is, it could push them to change.

If that changes 3.x can get a big push forward. And that in the future can
help Django.

Realistically though, what is stopping us from signing? What negative
outcome can it have?

Nick.

>

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

Re: Joining the "Python 3 Statement"

[Nick Sarbicki]

Hi Aymeric,

I don't think this is a question of what it would do for Django. More what
Django could do for python.

The web and scientific communities are essentially the two biggest python
communities around. If they both joined together to say "2020 is the
deadline for us and everyone else" it could really push a lot of others to
see how serious the need to move is now.

Python could gain from the greater uptake of 3.x and further downstream
Django will benefit too. I don't find it smug. I think it's a reality check.

Nick.

On Sat, 9 Jul 2016, 07:51 Aymeric Augustin, <
aymeric.augus...@polytechnique.org> wrote:

> Hello Nick,
>
> This website was quickly discussed by a few team members some time ago. It
> wasn’t clear to us what joining this initiative would achieve for Django.
>
> At first sight, it would mostly allow those who run on Python 3 to feel a
> bit more smug and make those who are stuck on Python 2 a bit more
> frustrated.
>
> The web community seems to be ahead of the scientific community for moving
> to Python 3. By now most Django users should be aware that they have to
> figure out a plan to migrate to Python 3 (or JS, or Go, etc.) I don’t think
> the scientific community is there yet.
>
> (To be honest, I discovered recently that some high-profile members of the
> Django community are still advocating to start new projects on Python 2.
> I’m failing to rationalize why they give this advice, certainly because of
> my biais.)
>
> If we consider that we’ve reached a point where we no longer need to focus
> on raising awareness, I’d rather drive the migration to Python 3 with a
> stick than with a carrot. There’s plenty of cool stuff to advertise :-)
>
> --
> Aymeric.
>
> On 09 Jul 2016, at 04:03, Nick Timkovich <prometheus...@gmail.com> wrote:
>
> With the release of IPython 5.0 LTS, it was mentioned as also being the
> final Py2-compat release in the series with a reference to the "Python 3
> Statement" https://python3statement.github.io/ Some of the prose in it
> refers to just the Scientific Stack (Numpy, Scipy, MPL, et al.), but an
> issue popped up saying that it could be generalized if other projects were
> to join/"sign", e.g. Django.
> https://github.com/python3statement/python3statement.github.io/issues/21
>
> I'm not strongly advocating one way or the other, just thought I'd bring
> it up.
>
> Nick
>
> --
> 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/0460ab73-1059-49e9-be63-2716378fddca%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0460ab73-1059-49e9-be63-2716378fddca%40googlegroups.com?utm_medium=email_source=footer>
> .
> 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/7E8B9E8B-D60E-48E4-BDB5-969BC4479EDF%40polytechnique.org
> <https://groups.google.com/d/msgid/django-developers/7E8B9E8B-D60E-48E4-BDB5-969BC4479EDF%40polytechnique.org?utm_medium=email_source=footer>
> .
> 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/CAGuvt91Fw%2Bayc02jyW_-8hxj1_sekJvfkuUQsi0Ft566gyZ92w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Joining the "Python 3 Statement"

[Nick Timkovich]

With the release of IPython 5.0 LTS, it was mentioned as also being the 
final Py2-compat release in the series with a reference to the "Python 3 
Statement" https://python3statement.github.io/ Some of the prose in it 
refers to just the Scientific Stack (Numpy, Scipy, MPL, et al.), but an 
issue popped up saying that it could be generalized if other projects were 
to join/"sign", e.g. Django. 
https://github.com/python3statement/python3statement.github.io/issues/21

I'm not strongly advocating one way or the other, just thought I'd bring it 
up.

Nick

-- 
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/0460ab73-1059-49e9-be63-2716378fddca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Nick Sarbicki]

Same boat for me.

I constantly need the JSON field but can't always rely on postgres.

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

Re: Adding "bits of entropy" argument to crypto.get_random_string

[Nick Timkovich]

When get_random_string is being used in get_random_secret_key, or CSRF key 
generation, would it be advantageous to specify the strength 

On Monday, March 7, 2016 at 10:10:53 AM UTC-6, Tim Graham wrote:
>
> My opinion is that django.utils needn't grow features that Django itself 
> doesn't use.
>
> On Monday, March 7, 2016 at 11:04:48 AM UTC-5, Nick Timkovich wrote:
>>
>> By the presence of a "bits" measure in the documentation of the function 
>> it seems to be known that it's a measure of interest. The benefit of adding 
>> it into Django is that by review of others it can be assured to be correct 
>> and will reduce the likelihood of security-related bugs. A bit contrived, 
>> perhaps, but as adding such a parameter requires no external dependencies, 
>> the bar shouldn't be terribly high.
>>
>> On Saturday, March 5, 2016 at 2:51:58 AM UTC-6, Moritz S. wrote:
>>>
>>> Can't you just define your own function called 
>>> "get_random_string_entropy" that 
>>> calculates the length and then calls get_random_string? 
>>> What would be the benefit of doing that in Django directly? 
>>>
>>> Am 05.03.2016 um 00:15 schrieb Nick Timkovich: 
>>> > Rather than guess at the appropriate string length to get some level 
>>> of 
>>> > security, I'd like to add a (minimum) bits of entropy argument to 
>>> > get_random_string, so I could say something like 
>>> get_random_string(bits=256) and 
>>> > have it do the math for me: math.ceil(bits / 
>>> math.log2(len(allowed_chars))). 
>>> > 
>>> > Not sure what should happen if both bits and length are specified, let 
>>> bits 
>>> > override? ValueError? whichever is longer/more random/secure (maybe 
>>> then call it 
>>> > min_bits)? 
>>> > 
>>> > I seem to recycle that snippet in many of my projects, and I hope it 
>>> would be 
>>> > useful for others. 
>>>
>>>

-- 
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/3ee73edc-5b21-4e91-aa45-f4958cf21e21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding "bits of entropy" argument to crypto.get_random_string

[Nick Timkovich]

By the presence of a "bits" measure in the documentation of the function it 
seems to be known that it's a measure of interest. The benefit of adding it 
into Django is that by review of others it can be assured to be correct and 
will reduce the likelihood of security-related bugs. A bit contrived, 
perhaps, but as adding such a parameter requires no external dependencies, 
the bar shouldn't be terribly high.

On Saturday, March 5, 2016 at 2:51:58 AM UTC-6, Moritz S. wrote:
>
> Can't you just define your own function called "get_random_string_entropy" 
> that 
> calculates the length and then calls get_random_string? 
> What would be the benefit of doing that in Django directly? 
>
> Am 05.03.2016 um 00:15 schrieb Nick Timkovich: 
> > Rather than guess at the appropriate string length to get some level of 
> > security, I'd like to add a (minimum) bits of entropy argument to 
> > get_random_string, so I could say something like 
> get_random_string(bits=256) and 
> > have it do the math for me: math.ceil(bits / 
> math.log2(len(allowed_chars))). 
> > 
> > Not sure what should happen if both bits and length are specified, let 
> bits 
> > override? ValueError? whichever is longer/more random/secure (maybe then 
> call it 
> > min_bits)? 
> > 
> > I seem to recycle that snippet in many of my projects, and I hope it 
> would be 
> > useful for others. 
>
>

-- 
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/373c2b74-de84-4bb0-93b8-38f9f3365b2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding "bits of entropy" argument to crypto.get_random_string

[Nick Timkovich]

Rather than guess at the appropriate string length to get some level of 
security, I'd like to add a (minimum) bits of entropy argument to 
get_random_string, so I could say something like get_random_string(bits=256) 
and have it do the math for me: math.ceil(bits / 
math.log2(len(allowed_chars))).

Not sure what should happen if both bits and length are specified, let bits 
override? ValueError? whichever is longer/more random/secure (maybe then 
call it min_bits)?

I seem to recycle that snippet in many of my projects, and I hope it would 
be useful for others. 

-- 
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/bc93fd3e-4e8c-45e6-9ada-4fa595bf4479%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Nick Sarbicki]

>
> FWIW Jira seems to be an exception among bug trackers: some people really
> love it, others really hate it. It depends on who set it up and maintained
> it in the company where they used it.
>
> Since we don’t have a resident Jira expert, we run the risk that most of
> the Django community will fall into the “hate it” bucket. To me this is one
> of the riskier choices we could make.
>
> Anyway it’s unclear to me that the potential benefits of switching to any
> bug tracker could offset the transition costs, as long as Trac is
> serviceable.
>
> We’ll see what happens in 2020 if it doesn’t support Python 3 by then (
> http://trac.edgewall.org/ticket/10083,
> http://trac.edgewall.org/ticket/12130).
>

Could always look at Bloodhound (http://bloodhound.apache.org/) if after
something similar. Not that it supports Py3 yet.

But I'm with everyone else. It's not worth it.

-- 
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/CAGuvt93%2BabKpnA%2BFC2Ny5HYn3p_8mdS_%2BrPV3jg3NFoV%3DgHvyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

To make myself clear. I don't think we need to document this as it is not a 
django error. 

It is a Python error because the module was not installed correctly.

Maybe there should be a mention of the difference for installation on 
Ubuntu (and other linux distros?). But this would be unusual for anyone 
using Windows or Mac as they won't have a default Python install and will 
often only have 1 version, so 1 pip.

- Nick.

On Wednesday, September 9, 2015 at 3:05:15 PM UTC+1, Nick Sarbicki wrote:
>
> In which case you need to install it again with *pip3*.
>
> All the defaults in Ubuntu (Python, pip etc.) are focused on 2.7, you 
> always need to append 3 if you want it to be *python3 *specific.
>
> For earlier versions of ubuntu this was because some core processes 
> required python2.7 and would call it through *python*. I think they are 
> past that with the latest release, but from memory there is a *pep* somewhere 
> which states that this should remain the standard for now.
>
> - Nick.
>
> On Wednesday, September 9, 2015 at 2:58:36 PM UTC+1, Anjul Tyagi(geety) 
> wrote:
>>
>> yes, I installed django using *pip *and not* pip3.*
>>
>

-- 
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/507c7031-f5e6-46ca-b6e1-1811cc600e8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

In which case you need to install it again with *pip3*.

All the defaults in Ubuntu (Python, pip etc.) are focused on 2.7, you 
always need to append 3 if you want it to be *python3 *specific.

For earlier versions of ubuntu this was because some core processes 
required python2.7 and would call it through *python*. I think they are 
past that with the latest release, but from memory there is a *pep* somewhere 
which states that this should remain the standard for now.

- Nick.

On Wednesday, September 9, 2015 at 2:58:36 PM UTC+1, Anjul Tyagi(geety) 
wrote:
>
> yes, I installed django using *pip *and not* pip3.*
>

-- 
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/8e361d61-ee46-4b00-8536-a1ebc0a1ac65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

Can you show us how you installed django?

More specifically, did you do 

*pip install django*

and

*pip3 install django*

As it looks like you only install django for 2.7, and not for 3.4.

- Nick.

On Wednesday, September 9, 2015 at 2:51:07 PM UTC+1, Anjul Tyagi(geety) 
wrote:
>
> Hi everyone,
>
> I am new to django and wish to address the problem which I faced during 
> the installation of django on Ubuntu 14.04.
> I had two versions of python installed before I installed django: python 
> 2.7.6 and python 3.4. I installed django as per the steps given in the 
> documentation.
> Now, 
> If I type the following on the terminal:
>
>
> *python>>>import django*
>
> It works correctly, but
>
>
> *python3>>>import django*
>
> shows the module not found error 
> <http://stackoverflow.com/questions/26545436/unable-to-import-django-in-python3-4>.
>  
> I think we can document this inside the "verifying" section of the "Quick 
> Installation guide" part of documentation just to make sure that new users 
> don't panic seeing this error.
>

-- 
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/1eedff19-6212-4b49-8521-7889ce30dfec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django with Pycharm

[Nick Sarbicki]

Hi Prabhu,

Are you using the community or professional version?

The community version doesn't support specific Django projects (although it
is still good to use).

https://www.jetbrains.com/pycharm/features/editions_comparison_matrix.html

Nick.

On Fri, Sep 4, 2015 at 3:47 PM Prabhu <prabhusix...@gmail.com> wrote:

> Hi Team,
>
> I'm Prabhu new to django, i'm trying configure to debug django appication
> using pycharm.
>
> I could not locate/select project type as "Django"
>
> Please hep me out to resolve this issue to move forward to debug my
> project.
>
> Using Ubuntu 15.04, Django,Pycharm & Python installed
>
> Thanks and Regards,
>
> Prabhu
>
> --
> 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/62d50e77-ba53-4da5-bf07-326ee89fd75e%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/62d50e77-ba53-4da5-bf07-326ee89fd75e%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
 - Nick

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

Re: Django Admin New Look

[Nick Sarbicki]

This takes the conversation back a ways...

But I like the idea of being able to customise the admin scheme. Enforce a 
default of course, but maybe have some options (in admin.py? or as a 
separate script?) which can change the core colors of the scheme, either a 
set of predefined colours, or something completely customisable by the 
user. 

I don't think it's a huge amount of work (it's finding and replacing hex 
values in the css files). But I reckon it could add a lot of value for 
people who want the admin page to match the scheme of their website.

Obviously not a good idea to shove it in before the 1.9 release, but if the 
idea is liked I might (or any one else who is interested) be able to look 
into it.

/Nick.

On Monday, March 16, 2015 at 1:44:23 PM UTC, Tim Graham wrote:
>
> In some previous discussion, it was suggested to have a toggle between the 
> new and old designs to ease the transition. I guess this could be something 
> like a "theme" attribute on AdminSite. Do you think this is required? It 
> seems this could be a non-trivial maintenance burden if we have to test and 
> maintain two designs for some time.
>
> On Friday, March 13, 2015 at 7:42:35 AM UTC-4, elky wrote:
>>
>> Did you test RTL?
>>>
>>> I did. I tested Arabic and Hebrew - no issues detected for me. BUT. As 
>>> far as I understand Django admin has poor RTL support by itself.
>>>
>>
>> Sorry guys, I was wrong about it. Django has very good RTL support! Just 
>> didn't notice right setting to test it. But anyway I did few tweaks in my 
>> theme. 
>>
>

-- 
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/8499ebc7-c562-4e86-bb89-46a15ac7c906%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: does django-admin need a man page?

[Nick Phillips]

On Mon, 2014-11-24 at 16:44 -0800, Tim Graham wrote: 
> I raised the issue in #23903 and Aymeric mentioned that it may be
> useful for downstream packagers, e.g. Debian. I installed
> python-django via apt-get on Ubuntu 14.04 and confirmed the existence
> of the man page. I'd like to remove it though (or make it point people
> to 'django-admin --help') as it's out-of-date and 'django-admin
> --help' provides the same information in a much easier to maintain
> format. Does anyone else have input on this?
> 

As far as Debian is concerned, not having a manpage for an executable
installed in the standard path is a bug. So if you don't provide one,
one will probably be written for Debian anyway, albeit not a
particularly good one.

However, as Ben pointed out, "man foo" is the standard interface to
getting long-format information on the "foo" command, if not always the
full docs (g info gr). So I'd suggest considering implementing
something to generate a man page from whatever you wish the "canonical"
source of the information to be.


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

-- 
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/1416963109.6414.18.camel%40otago.ac.nz.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Write unit tests for JavaScript

[Nick Sandford]

So, I have been working a little on a PR for this (
https://github.com/django/django/pull/3003) and having spoken to Tim
briefly about getting this supported in jenkins I just wanted to check that
the approach was OK. The tests use node, grunt, qunit, istanbul and jshint.
Is this a reasonable approach? Some of the responses here are using a
similar stack.


On Mon, May 5, 2014 at 7:19 AM, Trey Hunner  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I started a rough draft of a DEP for adding unit tests for Django's
> JavaScript: https://github.com/django/deps/pull/4
>
> I am suggesting that a native JavaScript test framework be used
> *without* attempting to use an adapter to run the tests under the Django
> test framework.  I anticipate that this suggestion may require further
> explanation and debate, so I have submitted a pull request for
> discussion while I continue to extend the DEP.
>
> - --
> Trey Hunner
> http://treyhunner.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTZy2KAAoJEOpnfp/Nreona8oIAKBE0T05wmnCP0tq/nvmQIlC
> 0KWB0bX47FHn3TeOjEK8dHrxebP9UDL+wmdZ8F23iOQnW8OiJIO3dJjSjqLOAXxg
> dNh5imq02kY2rvjVB6ypZp0h+INkQoaQMae5xMdN4RozLnbNrgXln7vbuSrjIB/8
> z7h983vqiRp/ofa+2urTnUnC63730gg6vBbXE5EQ+5WeJxqx2yahdbeSmB3oCnhD
> 7TMRdHYY+Tx1bdsHF3KOniKoHXA0qoeV16RK+J7EWRHMo3eKlH1zOpcbNX8klwed
> qF2zZSKFqMIj0H/mBOVWy5uePXUOfIOP4iLTjEuSy+6sPDNPCiPAvCE5R9jyz/k=
> =/i9B
> -END PGP SIGNATURE-
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/53672D8A.2050005%40treyhunner.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" 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/CAMwcc5WuxZ5yVQQH8wVbX51VHyaXN-ZLyrK_oJeS3e4vo5kqvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overriding AppConfig.get_model(s)

[Nick Sandford]

Managed might be the ticket then. I don't think it's too surprising to the
user who configures a cache or file session backend that no database table
is created. I think that's slightly less surprising than the status quo --
they configured a file session backend and when they run migrate they
notice that a database table for sessions has been created, which might
lead them to question if the session backend is working as intended. I'll
pursue the meta option for now :).

If they start with the database backend, and switch at a later date to a
non-database backend, then I'm comfortable to make it the user's
responsibility to clean up the leftover database table, but were you
suggesting if they start with a non-database backend and at some later
stage decide to switch to a database backend it won't work?

Thanks for the help.

Nick




On Fri, Jul 25, 2014 at 9:24 PM, Andrew Godwin <and...@aeracode.org> wrote:

> Yeah, but if you change the value of the routers during a project's
> lifetime it's up to you to fix the resulting issues (same as if you switch
> AUTH_USER_MODEL - you _cannot_ change this after project start without
> serious pain).
>
> If you're happy saying the same thing about sessions, then go and tie the
> model's managed option to the setting - that should do what you want - but
> people are going to get real confused when they change the setting and the
> table isn't made for them.
>
> Andrew
>
>
> On Fri, Jul 25, 2014 at 1:17 PM, Nick Sandford <nick.sandf...@gmail.com>
> wrote:
>
>> Isn't that essentially what's happening by respecting
>> router.allow_migrate? Determining at runtime via a setting
>> (DATABASE_ROUTERS) whether to apply migrations. From the perspective of a
>> user, providing a custom database router makes sense for applications they
>> don't control, but from the perspective of an reusable app developer who
>> doesn't have access to the project's settings, using database routers seems
>> a bit more cumbersome.
>>
>> I guess I'm just thinking that having an alternative method would be
>> useful. I'm happy to help find a solution if you feel it's a worthwhile
>> pursuit.
>>
>> Cheers,
>> Nick
>>
>>
>> On Fri, Jul 25, 2014 at 9:02 PM, Andrew Godwin <and...@aeracode.org>
>> wrote:
>>
>>> I don't think there's a way you can do this with migrations. You're not
>>> supposed to be able to change them at runtime based on settings; that was
>>> the cause of most of our bugs with swappable models.
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford <nick.sandf...@gmail.com
>>> > wrote:
>>>
>>>> Ahh ok, that makes sense -- I guess there's no difference between
>>>> overriding get_model(s) and manually deleting the model out of the source
>>>> to the migrations.
>>>>
>>>> I can't think of any decent way to use router.allow_migrate in sessions
>>>> other than monkey patching it to do what I want. Any suggestions?
>>>>
>>>> Would it be possible to detect that the models are being manually
>>>> excluded rather than removed from the source and migrate them differently?
>>>>
>>>> Cheers,
>>>> Nick
>>>>
>>>>
>>>> On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin <and...@aeracode.org>
>>>> wrote:
>>>>
>>>>> Migrations instantiate their own copies of AppConfig and Apps and run
>>>>> from those, so you won't be able to affect them by overriding methods. If
>>>>> you want to exclude models from migrations use router.allow_migrate.
>>>>>
>>>>> Andrew
>>>>>
>>>>>
>>>>> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford <
>>>>> nick.sandf...@gmail.com> wrote:
>>>>>
>>>>>> I was just working on #22986 and it seems that if the
>>>>>> AppConfig.get_model(s) methods are overridden, migrations for models that
>>>>>> are excluded are still run.
>>>>>>
>>>>>> Is this a known issue? Am I abusing get_model(s) or should I file a
>>>>>> ticket for this?
>>>>>>
>>>>>> Cheers,
>>>>>> Nick
>>>>>>
>>>>>> https://code.djangoproject.com/ticket/22986#comment:5
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Django developers" group.
&g

Re: Overriding AppConfig.get_model(s)

[Nick Sandford]

Isn't that essentially what's happening by respecting router.allow_migrate?
Determining at runtime via a setting (DATABASE_ROUTERS) whether to apply
migrations. From the perspective of a user, providing a custom database
router makes sense for applications they don't control, but from the
perspective of an reusable app developer who doesn't have access to the
project's settings, using database routers seems a bit more cumbersome.

I guess I'm just thinking that having an alternative method would be
useful. I'm happy to help find a solution if you feel it's a worthwhile
pursuit.

Cheers,
Nick


On Fri, Jul 25, 2014 at 9:02 PM, Andrew Godwin <and...@aeracode.org> wrote:

> I don't think there's a way you can do this with migrations. You're not
> supposed to be able to change them at runtime based on settings; that was
> the cause of most of our bugs with swappable models.
>
> Andrew
>
>
> On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford <nick.sandf...@gmail.com>
> wrote:
>
>> Ahh ok, that makes sense -- I guess there's no difference between
>> overriding get_model(s) and manually deleting the model out of the source
>> to the migrations.
>>
>> I can't think of any decent way to use router.allow_migrate in sessions
>> other than monkey patching it to do what I want. Any suggestions?
>>
>> Would it be possible to detect that the models are being manually
>> excluded rather than removed from the source and migrate them differently?
>>
>> Cheers,
>> Nick
>>
>>
>> On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin <and...@aeracode.org>
>> wrote:
>>
>>> Migrations instantiate their own copies of AppConfig and Apps and run
>>> from those, so you won't be able to affect them by overriding methods. If
>>> you want to exclude models from migrations use router.allow_migrate.
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford <nick.sandf...@gmail.com
>>> > wrote:
>>>
>>>> I was just working on #22986 and it seems that if the
>>>> AppConfig.get_model(s) methods are overridden, migrations for models that
>>>> are excluded are still run.
>>>>
>>>> Is this a known issue? Am I abusing get_model(s) or should I file a
>>>> ticket for this?
>>>>
>>>> Cheers,
>>>> Nick
>>>>
>>>> https://code.djangoproject.com/ticket/22986#comment:5
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers" 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/django-developers/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" 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/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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

Re: Overriding AppConfig.get_model(s)

[Nick Sandford]

Ahh ok, that makes sense -- I guess there's no difference between
overriding get_model(s) and manually deleting the model out of the source
to the migrations.

I can't think of any decent way to use router.allow_migrate in sessions
other than monkey patching it to do what I want. Any suggestions?

Would it be possible to detect that the models are being manually excluded
rather than removed from the source and migrate them differently?

Cheers,
Nick


On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin <and...@aeracode.org> wrote:

> Migrations instantiate their own copies of AppConfig and Apps and run from
> those, so you won't be able to affect them by overriding methods. If you
> want to exclude models from migrations use router.allow_migrate.
>
> Andrew
>
>
> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford <nick.sandf...@gmail.com>
> wrote:
>
>> I was just working on #22986 and it seems that if the
>> AppConfig.get_model(s) methods are overridden, migrations for models that
>> are excluded are still run.
>>
>> Is this a known issue? Am I abusing get_model(s) or should I file a
>> ticket for this?
>>
>> Cheers,
>> Nick
>>
>> https://code.djangoproject.com/ticket/22986#comment:5
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAMwcc5WrEHhwA-U3h8R4qUa8mBvUd%2BXz%2BgSjwb0H8Yz6LAaVsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Overriding AppConfig.get_model(s)

[Nick Sandford]

I was just working on #22986 and it seems that if the
AppConfig.get_model(s) methods are overridden, migrations for models that
are excluded are still run.

Is this a known issue? Am I abusing get_model(s) or should I file a ticket
for this?

Cheers,
Nick

https://code.djangoproject.com/ticket/22986#comment:5

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Nick Phillips]

On Sun, 2013-09-15 at 18:23 +0200, Aymeric Augustin wrote: 
> On 15 sept. 2013, at 17:57, Simon Kern <sim...@gmail.com> wrote:
> 
> > Yes but management commands should be irrelevant for django-secure
> 
> Well, in this case, I have a backup argument :)
> 
> There's a non-negligible number of people serving websites in production with 
> ./manage.py runserver, in spite of all the warnings in the docs.

FWIW there is also a non-negligible number of people who believe in
doing development using the same stack that they're going to deploy to
for production use, and who therefore never use the runserver at all...

Cheers,

Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Nick Phillips]

On Sun, 2013-05-12 at 11:03 -0700, Jason Reethisma wrote: 
> @Russell
> 
> "can't compel anyone to do anything"... you can compel people to NOT do 
> something, such as, "don't close a ticket as won't-fix without giving a 
> detailed explanation of why it should be closed". 
> 
> Saying that people cannot be compelled is an excuse to not take action.
> 
> Ignoring the 3 outlined problems in the post you replied to while pretending 
> to ask for suggestions from the community is just a form of equivocation. 
> Politicians do it all the time...
> 

As someone who uses Django, and lurks (mostly) on this list, I have to
say that I think you have got completely the wrong end of the stick.

The tone of your mail is not constructive, and is provoking a negative
reaction even in me (and I am not one who has been putting massive
amounts of time into building Django, keeping the tracker in order, and
trying to keep the community running smoothly). I don't want to think
about how such posts must make the likes of Russell, Jacob & co react -
I can only say that in the years I've been here they've done a superb
job keeping the frustration in check.

This community, to me, is notable for the professional and courteous
manner in which people making demands are directed toward what they need
to do to have a chance of getting what they want. I'm not saying it's
perfect, but it deserves rather more credit than you appear to be
giving.

If there is little to no chance that a particular feature will be
implemented, it seems to me that is better for all concerned to close
down the discussion fairly sharplish - the submitter then doesn't waste
time thinking they're going to get something done about it, and the
developers don't waste time explaining again and again and again why the
submitter's latest rehash of the same argument is not going to make any
difference (submitter wrong, bad fit for Django, philosophical issues,
whatever - some people just don't seem to get the message).

I suggest you take Russell's post at face value, by the way. "Looking
for a positive outcome".

Well, perhaps face value plus a head of frustration that he's hiding
fairly well.

Thanks again to all of you who are making it happen.


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

[Nick Phillips]

On Tue, 2013-02-19 at 15:46 -0700, Carl Meyer wrote:
> Hi Nick,
> 
> On 02/19/2013 03:32 PM, Nick Phillips wrote:
> > I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
> > do, it seems rather problematic. In particular, that host verification
> > is apparently turned off while DEBUG is True or while testing.
> > 
> > Surely this makes it impossible to test, and makes it likely that
> > misconfigurations will not be picked up until deployed to a production
> > environment.
> >
> > Given that most setups require some customisation of settings for
> > dev/staging/production/whatever environments anyway, why not leave the
> > verification on at all times and allow us to ensure we get the right
> > hosts in the right environments?
> 
> There was extensive back-and-forth discussion of this in writing the
> patch. The issue is that in almost all cases the correct value of the
> setting in local development and under test are different from the
> correct value in production. So how much value is there in knowing the
> tests pass, and/or it works locally? That doesn't really increase the
> chances that you have it configured correctly in production.

It would at least ensure that you were aware of it and had attempted to
set it...

>  In the end,
> our estimation was that requiring it to be configured in local dev and
> testing would introduce quite a lot of hassle (and potentially a major
> roadblock for new users), with very little gain to offset that.

What would the implications of having "localhost" in there be?

> Note that it isn't impossible to test, if you want to; the check is
> "disabled" under test by means of setting ALLOWED_HOSTS to ['*'] for the
> duration of the test run, so if you want tests to exercise validation
> you can just use the override_settings decorator to temporarily change
> it for a test method or test case.

Ah, thanks - I was at least missing that.


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
Faculty of Medicine, University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.4.4 and contrib/sessions/management/__init__.pyc

[Nick Popoff]

Ah it looks like there's already a ticket on it:

https://code.djangoproject.com/ticket/19858

On Tuesday, February 19, 2013 7:12:52 PM UTC-8, Nick Popoff wrote:
>
> Hi folks,
>
> I downloaded Django 1.4.4 this evening and after switching to it started 
> getting the following error on my CentOS 6.3 / Python 2.6 based system:
>
> ImportError: Bad magic number in 
> /usr/lib/python2.6/site-packages/django/contrib/sessions/management/__init__.pyc
>
> After confirming my md5sum matches the published signature I noticed, 
> unlike the previous version, the Django 1.4.4 source tarball includes 
> several .pyc files:
>
> $ find . -name \*.pyc
> ./conf/locale/__init__.pyc
> ./conf/locale/en/__init__.pyc
> ./conf/locale/en/formats.pyc
> ./contrib/sessions/management/__init__.pyc
>
> In the case of ./contrib/sessions/management/__init__.pyc an __init__.py 
> is not provided.
>
> Is it possible compiled 2.7 .pyc files were included instead of .py files 
> by mistake?
>
> My apologies in advance if I've misunderstood some aspect of Django 
> packaging/installation and thanks for this awesome project...
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Django 1.4.4 and contrib/sessions/management/__init__.pyc

[Nick Popoff]

Hi folks,

I downloaded Django 1.4.4 this evening and after switching to it started 
getting the following error on my CentOS 6.3 / Python 2.6 based system:

ImportError: Bad magic number in 
/usr/lib/python2.6/site-packages/django/contrib/sessions/management/__init__.pyc

After confirming my md5sum matches the published signature I noticed, 
unlike the previous version, the Django 1.4.4 source tarball includes 
several .pyc files:

$ find . -name \*.pyc
./conf/locale/__init__.pyc
./conf/locale/en/__init__.pyc
./conf/locale/en/formats.pyc
./contrib/sessions/management/__init__.pyc

In the case of ./contrib/sessions/management/__init__.pyc an __init__.py is 
not provided.

Is it possible compiled 2.7 .pyc files were included instead of .py files 
by mistake?

My apologies in advance if I've misunderstood some aspect of Django 
packaging/installation and thanks for this awesome project...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

[Nick Phillips]

On Tue, 2013-02-19 at 14:50 -0600, James Bennett wrote:
> We've issued several security releases today. Details are in the blog
post:
> 
> https://www.djangoproject.com/weblog/2013/feb/19/security/
> 
> We recommend everyone carefully read this one, as it has an
> end-user-visible change requiring action beyond simply upgrading your
> Django package.
> 

I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
do, it seems rather problematic. In particular, that host verification
is apparently turned off while DEBUG is True or while testing.

Surely this makes it impossible to test, and makes it likely that
misconfigurations will not be picked up until deployed to a production
environment.

Given that most setups require some customisation of settings for
dev/staging/production/whatever environments anyway, why not leave the
verification on at all times and allow us to ensure we get the right
hosts in the right environments?

What am I missing?


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Docs aren't clear on purpose of signals' "providing_args"

[Nick]

Should I submit a ticket to have the docs updated?

On Thursday, December 27, 2012 2:57:55 PM UTC-7, Nick wrote:
>
> Thanks for the info. Maybe the docs should state this so others don't run 
> into the same confusion that I ran into?
>
> On Thursday, December 27, 2012 2:10:51 PM UTC-7, donarb wrote:
>>
>> On Thursday, December 27, 2012 10:39:23 AM UTC-8, Nick wrote:
>>>
>>> The bottom of the docs says:
>>>
>>> If you notice errors with this documentation, please open a ticket and 
>>>> let us know!
>>>
>>>
>>> Well, I don't know that I would call this an *error*, so I don't think 
>>> opening a ticket is the right thing to do. Please let me know if I'm wrong. 
>>> I would just like to suggest to the developers that the purpose of 
>>> "providing_args" be clarified in the docs:
>>>
>>> https://docs.djangoproject.com/en/dev/topics/signals/#defining-signals
>>>
>>> Do you *have* to define what the providing arguments are? In my quick 
>>> tests, the answer to that appears to be "no". Also, there doesn't appear to 
>>> be a problem with sending a signal without providing an argument listed 
>>> in "providing_args". So then what's the point of "providing_args"?
>>>
>>> Just to be clear, I realize that this group isn't a support group. I'm 
>>> not asking the question for my own personal benefit. Rather, I'm suggesting 
>>> that the docs be clarified.
>>>
>>> Thanks!
>>>
>>
>> This was discussed a few years ago. At the moment, it's purely 
>> documentation(al).
>>
>> https://groups.google.com/d/msg/django-developers/gV92rX6CPL8/gxj2fwpbbHoJ
>>  
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/UL9RxKlaOPYJ.
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: Docs aren't clear on purpose of signals' "providing_args"

[Nick]

Thanks for the info. Maybe the docs should state this so others don't run 
into the same confusion that I ran into?

On Thursday, December 27, 2012 2:10:51 PM UTC-7, donarb wrote:
>
> On Thursday, December 27, 2012 10:39:23 AM UTC-8, Nick wrote:
>>
>> The bottom of the docs says:
>>
>> If you notice errors with this documentation, please open a ticket and 
>>> let us know!
>>
>>
>> Well, I don't know that I would call this an *error*, so I don't think 
>> opening a ticket is the right thing to do. Please let me know if I'm wrong. 
>> I would just like to suggest to the developers that the purpose of 
>> "providing_args" be clarified in the docs:
>>
>> https://docs.djangoproject.com/en/dev/topics/signals/#defining-signals
>>
>> Do you *have* to define what the providing arguments are? In my quick 
>> tests, the answer to that appears to be "no". Also, there doesn't appear to 
>> be a problem with sending a signal without providing an argument listed 
>> in "providing_args". So then what's the point of "providing_args"?
>>
>> Just to be clear, I realize that this group isn't a support group. I'm 
>> not asking the question for my own personal benefit. Rather, I'm suggesting 
>> that the docs be clarified.
>>
>> Thanks!
>>
>
> This was discussed a few years ago. At the moment, it's purely 
> documentation(al).
>
> https://groups.google.com/d/msg/django-developers/gV92rX6CPL8/gxj2fwpbbHoJ
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/FR8qxK5wZ1UJ.
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.

Docs aren't clear on purpose of signals' "providing_args"

[Nick]

The bottom of the docs says:

If you notice errors with this documentation, please open a ticket and let 
> us know!


Well, I don't know that I would call this an *error*, so I don't think 
opening a ticket is the right thing to do. Please let me know if I'm wrong. 
I would just like to suggest to the developers that the purpose of 
"providing_args" be clarified in the docs:

https://docs.djangoproject.com/en/dev/topics/signals/#defining-signals

Do you *have* to define what the providing arguments are? In my quick 
tests, the answer to that appears to be "no". Also, there doesn't appear to 
be a problem with sending a signal without providing an argument listed 
in "providing_args". So then what's the point of "providing_args"?

Just to be clear, I realize that this group isn't a support group. I'm not 
asking the question for my own personal benefit. Rather, I'm suggesting 
that the docs be clarified.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/corHPFoihx4J.
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: ImageField's “Currently” and “Clear” Sometimes Doesn't Appear

[Nick]

Sure, here you go:

https://code.djangoproject.com/ticket/19215

On Tuesday, October 30, 2012 12:01:15 PM UTC-6, Carl Meyer wrote:
>
> Hi Nick, 
>
> On 10/30/2012 08:21 AM, Nick wrote: 
> > I posted this question to Stack Overflow a couple weeks ago (link 
> > <
> http://stackoverflow.com/questions/12902785/imagefields-currently-and-clear-sometimes-doesnt-appear>)
>  
>
> > but have had no responses. I'm guessing it's geared more towards the 
> > Django developers, so I'm going to post it here. 
> > 
> > Assume you have a model that has a required field of any type and also 
> > an optional ImageField. Let's say you used Django's built-in admin 
> > interface to insert a row into this database table and when you did so, 
> > you filled out both fields. Now let's say you go to edit the row that 
> > you just created. The ImageField will look like this: 
> > 
> > Currently: [url] | [checkbox] Clear 
> > 
> > Change: [file widget] 
> > 
> > If you upload a non-image (a PDF, for example), it will say "Upload a 
> > valid image. The file you uploaded was either not an image or a 
> > corrupted image." only now the "Currently: [url] | [checkbox] Clear" 
> > portion won't be there anymore. This can be misleading to users (causing 
> > them to think the original image is now gone). 
> > 
> > Another issue is let's say you were editing the row and you blanked out 
> > the required field and also replaced the image with another one. It 
> > will, of course, complain about the required field not being filled out. 
> > But, again, the "Currently: [url] | [checkbox] Clear" portion of the 
> > image field won't be there anymore. Again, this can mislead the user. 
> > 
> > Is this a bug or is this the intended behavior? Either way, how can I 
> > get around this? 
>
> I can reproduce this, and I'd call it a bug. I think the fix may involve 
> passing the "initial" value to the ClearableFileInput in preference to 
> the value from the form submission, in cases where a bound form is being 
> rendered (because the ClearableFileInput widget can't do anything useful 
> with an unsaved value anyway), but it's not immediately clear to me how 
> to do that without introducing some unsavory widget-type-checking into 
> BoundField. So I think the right fix here may take some thought. 
>
> I searched the bug-tracker at code.djangoproject.com and didn't find an 
> existing bug for this - do you mind filing a bug for it? 
>
> Thanks! 
>
> Carl 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/YH--EYtHydIJ.
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.

ImageField's “Currently” and “Clear” Sometimes Doesn't Appear

[Nick]

I posted this question to Stack Overflow a couple weeks ago 
(link)
 
but have had no responses. I'm guessing it's geared more towards the Django 
developers, so I'm going to post it here.

Assume you have a model that has a required field of any type and also an 
optional ImageField. Let's say you used Django's built-in admin interface 
to insert a row into this database table and when you did so, you filled 
out both fields. Now let's say you go to edit the row that you just 
created. The ImageField will look like this:

Currently: [url] | [checkbox] Clear

Change: [file widget]

If you upload a non-image (a PDF, for example), it will say "Upload a valid 
image. The file you uploaded was either not an image or a corrupted image." 
only now the "Currently: [url] | [checkbox] Clear" portion won't be there 
anymore. This can be misleading to users (causing them to think the 
original image is now gone).

Another issue is let's say you were editing the row and you blanked out the 
required field and also replaced the image with another one. It will, of 
course, complain about the required field not being filled out. But, again, 
the "Currently: [url] | [checkbox] Clear" portion of the image field won't 
be there anymore. Again, this can mislead the user.

Is this a bug or is this the intended behavior? Either way, how can I get 
around this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/rPuD3oL06jwJ.
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: Possible bug in django oracle backend - no way to map from model type to oracle NUMBER type.

[Nick Phillips]

On Wed, 2012-10-17 at 12:16 -0600, Ian Kelly wrote:

> > Do you know what type in model will map to NUMBER in oracle?
> 
> There is none.  The proper type would be a floating-point
> DecimalField, but Django doesn't allow that as the decimal_places
> attribute is required.  I'm not really sure why that is; maybe the
> requirement could be relaxed?
> 
> If you don't need a lot of precision, then you could probably get away
> with using a FloatField.  Otherwise you might want consider creating a
> custom field that looks like a FloatField but uses decimals instead of
> floats.
> 

Not if you have a "legacy" database which uses NUMBER, I'm guessing...
I'd have thought the inability to work with any particular common field
type should be a bug, as it could effectively prevent working with
non-managed models altogether.


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
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.

[1.4] SECRET_KEY deprecation is confusing...

[Nick Pope]

Hi,

There is a problem in 1.4rc2 where a missing SECRET_KEY causes Django to 
refuse to start.

According to the current version of the release notes on the website: *In 
Django 1.4, starting Django with an empty SECRET_KEY will raise a 
DeprecationWarning. In Django 1.5, it will raise an exception and Django 
will refuse to start.*
*
*
This doesn't make sense...  It currently raises DeprecationWarning which is 
an exception which causes Django to fail to start.  To trigger a 
deprecation warning while allowing execution to continue you need to use 
warnings.warn().

As things stand you are essentially implementing the behaviour for both 1.4 
*and* 1.5!

Cheers,

Nick

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/lYpYVlaGlZYJ.
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: Revisiting multiline tags

[Nick Phillips]

On Fri, 2012-02-24 at 08:27 -0700, Carl Meyer wrote: 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 02/23/2012 11:29 PM, Russell Keith-Magee wrote:
> > This thread contains 6 people expressing support for this change, and
> > 2 against (a BDFL, a core developer) -- and you can add me to the -0
> 
> FWIW, I'd forgotten how painful the single-line restriction was the last
> time I had to work on internationalized templates using blocktrans. The
> presented use cases have me thoroughly convinced that this is an
> unreasonable restriction on template authors, and I'd be +1 on lifting it.

If the translation tags are pretty much the only things that would
really benefit from multi-line tags (and they certainly seem to be the
focus here), surely that's an indication that they're the problem, not
the unavailability of multi-line tags?

Do all the arguments really have to be within the single tag?


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
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: incorrect check email with 'email_re' in 'django.core.validators'

[Nick Fitzsimons]

Strictly speaking that regex cannot determine that an email address is 
well-formed per the RFC as the grammar defining the form of email addresses is 
a Type 2 Chomsky Grammar and regular expressions are limited to Type 3 Chomsky 
Grammars.

Off topic weirdness: I did a quick Google to make sure I remembered this 
correctly, and the snippet on the second result confirmed what I was going to 
say, so I said it. Then I actually followed the link, and it turned out it was 
me saying it in a comment to an answer on Stack Overflow a couple of years ago: 
<http://stackoverflow.com/a/1874122/16782>. So if I was wrong then, I'm wrong 
now ;-)

Cheers,

Nick.
Sent from my iPad

On 19 Dec 2011, at 19:38, Andre Terra <andrete...@gmail.com> wrote:

> Useful/interesting read: "I knew how to validate an e-mail address until I 
> read the RFC" [1].
> 
> And a full regex for validating e-mails per the RFC is available here[2], not 
> that you'd want to use it.
> 
> 
> [1] 
> http://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx
> [2] http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
> 
> 
> Cheers,
> AT
> 
> On Mon, Dec 19, 2011 at 3:51 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Mon, Dec 19, 2011 at 9:36 AM, Maxim Badika <mibad...@gmail.com> wrote:
> > Hello all!
> >
> > i found that
> >
> > email_re.search(u'my...@mydomain.com.') # with dot at the end of
> > address
> >
> > returns true. I think that is incorrect.
> > Thanks.
> 
> That is actually correct, and it is equivalent to "my...@domain.com".
> See RFC 3696.
> 
> The root of the domain name tree is known as "." and the TLDs are
> technically "com.", "edu.", "uk.", etc.  When discussing domains below
> the TLDs, the trailing dot is normally omitted ("domain.com"), but
> applications are still required to accept it
> 
> Cheers,
> Ian.
> 
> --
> 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.
> 
> 
> -- 
> 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.

-- 
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: Wrong error message when user having is_staff=False tries to login to admin

[Nick Phillips]

On Mon, 2011-03-14 at 15:57 +, Tom Evans wrote:

> This is one of my bug-bears with the current authentication system -
> it has no concept of role. The current action when an identified user
> visits the admin site is to display a login form, which is totally
> wrong in my opinion. The user has already presented credentials, which
> we have accepted, so why should we expect them to have another
> different set of credentials?
> 
> Similarly, most restricted access views are currently protected by the
> login_required decorator. Again, this is pretty good, but it doesn't
> solve the authorization issue. With the vast majority of views I
> decorate with @login_required, I actually need three states:
> 
> Unidentified -> login page
> Identified, but no access -> homepage, with error message
> Identified, access -> allow through

Spot on, IMO - it's muddling authentication and authorization up
together. The user is authenticated, and shouldn't be arbitrarily given
the impression that they're not when they try to access a page to which
they don't have access. There's nothing "special" about the admin here,
except that it is provided as part of the "batteries included". How does
your site respond when a user tried to access any other URL to which
they are denied access? Whatever happens there is probably what should
happen when they try to access the admin. It could be a 403, a redirect
to homepage, a forced logout with disabling of account and email to
admin, could be all sorts of things, depending on the site.

The question should probably be "how can we allow the developer to
specify the desired behaviour when the user attempts to access a URL to
which they have no access?" - subject to the usual provision of sensible
defaults etc.


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
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: #14733: A vote in favor of no validation of .raw() queries

[Nick Phillips]

On Fri, 2011-03-11 at 23:20 -0500, Jacob Kaplan-Moss wrote:
> Hi Christophe --
> 
> Interesting; I didn't know about these constructs.
> 
> I'm not opposed to this change, but I am a bit concerned about opening
> up the ability to use raw() for stuff like UPDATE/DELETE where it'd be
> a nasty code smell. I'd be interested in your thoughts on that: is
> there a way we can prevent folks from shooting themselves in the foot
> this way, or do you think trying itself is futile?

If they're going to do it, they're going to do it - I can immediately
think of several people who, on finding that they can't do what they
want with raw(), would naturally progress to writing a postgres function
to do the dirty work (on the grounds that that can then be called using
"select").


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
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: Intermittent IOError exception raised and emailed to admins during file upload.

[Nick Phillips]

On Mon, 2011-02-14 at 11:10 -0800, Drew Volpe wrote:
> Did you ever track down what was happening ?
> 
> Was any more information discovered on this problem ?
> 
> I'm seeing a similar issue in a eb service written in Django which
> receives data from mobile apps as a POST.  Not infrequently, I'm
> seeing the same "IOError: request data read error" when I try to read
> request.raw_post_data.  It happens more than spotty connections would
> explain.

User double-clicks on submit button, second click killing the connection
created by the first press and starting another one?

Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago


-- 
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: Feedback required: #14799 -- Problem with setting up test databases

[Nick Phillips]

On Sat, 2010-12-04 at 11:56 +0800, Russell Keith-Magee wrote:

> Option 4: Introduce a per-database setting -- TEST_DEPENDENCIES --
> that allows the developer to explicitly encode the dependency between
> databases. This means the developer can explicitly encode the
> dependencies that exists in database creation order. We can default to
> assuming 'everything depends on default' (which is what the current
> trunk implements); but this gives end users the flexibility to define
> any dependency they need. The patch on #14799 implements this solution
> (although it needs some tests for the dependency resolution code and
> documentation for the setting itself)
> 
> My personal preference is for (4). I don't like the addition of a
> setting, but it's a setting that most users will be able to ignore
> (since there is a reasonably sensible default), and it is the most
> explicit and configurable option available.
> 
> Opinions? Alternatives?

pre-syncdb handler to check that it's valid to actually run a syncdb on
this database at this time?

Seems a lot more general than just test-related, anyway; I'd have
thought it would make more sense to see (and name, and document) it as a
general dependency of one database on the other - so
creation/updates/migrations should all always happen in an order which
takes any defined dependencies into account. I'm guessing that the test
setup just happens to be the only place (within Django itself) where any
of these processes are automated across multiple DBs at the moment?

FWIW I *always* forget that I have to explicitly call syncdb for each
database, and expect the one call with no db specified to have done the
lot.



Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: HMAC and timing based attacks - ticket #14445

[Nick Phillips]

On Tue, 2010-10-12 at 12:03 +0100, Luke Plant wrote:

> The fixed strings are used to make the keys unique per application - see
> below for what the keys are like that actually end up being used.

I realise that, I just couldn't remember exactly why that was
necessary... but you answered that below.


> AFAICS the HMAC module does all this.  From hmac:
> 
> class HMAC:  
> """RFC 2104 HMAC class.  Also complies with RFC 4231...
> """
> # ...
> 
> def __init__(self, key, msg=None, digestmod=None):
> # ...
> if len(key) > blocksize:   
> key = self.digest_cons(key).digest()   
> # ...
> 
> So it is explicit - the hmac module does RFC 2104 for us, that's what we
> are relying on it for. If this module *stops* doing this, then all the
> existing MACs generated will be broken, so backwards compatibility means
> it will carry on doing so. We should let this module do our crypto for
> us as much as possible.

Absolutely - I hadn't had a chance to check the hmac module, but given
the fact that it does pre-hash or pad as recommended (and assuming it
will continue to do so), that's fine.


> Since we are effectively using
> SHA1(different_fixed_string_for_each_application + SECRET_KEY) as the
> key, it isn't obvious to me that using
> SHA1(entirely_different_random_string_for_each_application) is really
> any different, or really that much superior.  Even if it was preferable
> to use the latter, we can't do that easily with backwards compatibility
> - we would need to generate new random strings for each key needed and
> insert them into settings.py.

Personally, I'd be looking for reassurance from a "crypto expert" at
this point. I'd agree that it would appear that any problem is not
obvious, but then neither would I expect it to be so. I would not be at
all surprised if the combination of being able to control the message,
and being able to get an HMAC of it with two different but related keys
enables an attack, and some googling for "related key attack on hmac"
would seem to support this possibility (although as I said, I'm no
expert, and I don't have time to look into it in detail).


> As for key rotating/refreshing - that would also (probably) be
> desirable, but it would be significantly more work. There is no way to
> change the key without invalidating existing HMACs (that's the whole
> point), so you would effectively have something like a list of
> SECRET_KEYS, where the first is the one used for generating HMACs, but
> each is tried for verifying them.  We had some discussion about this
> before. See the bottom of http://code.djangoproject.com/wiki/Signing

Yes, that's the kind of thing I was thinking of.


> However, I don't think we should delay this change for the sake of that
> ideal.

Makes sense. What you're doing is clearly an improvement, and one with
no cost to the user involved in making the change, so...


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: HMAC and timing based attacks - ticket #14445

[Nick Phillips]

On Mon, 2010-10-11 at 23:38 +0100, Luke Plant wrote:
> Hi all
> 
> For a while this has been on my TODO list, but I've finally got round to
> it:
> 
> * Use HMAC where appropriate in Django
> * Fix timing based attacks.

Cool. I'd been wondering about this for a while.

> - is the new method (using hmac.new etc.) actually correct and something
>   we are happy to stick with for a good while, to avoid having to do
>   this again quite soon? As far as I read it, I'm doing the same thing 
>   as keyczar:
> 
> http://code.google.com/p/keyczar/source/browse/trunk/python/src/keyczar/keys.py#300
> 
> (BTW, there are good reasons not to use keyczar - it would add a big
> dependency; it doesn't actually provide an API that is flexible enough
> for some of our use cases, like where we use a shortened HMAC to make a
> small URL; and it provides very little other value as a wrapper around
> hmac).

First of all I should say that I'm no crypto expert, but I'm worried
about the key. Inclusion of fixed strings in a key for this type of use
rings alarm bells, as does the use of an ASCII key (albeit 50 chars
rather than the 20 recommended for use with SHA1 in HMAC), and the fact
that in reality, it's never going to get refreshed.

On the key strength, I notice that RFC2104 recommends the hashing of the
key using the underlying hash function if the supplied key length is
greater than the hash output length. It would appear that this will
usually be the case, so Python's hmac module will probably be doing this
for us. However, there's rather a lot of "implicit" and "probably" in
that. And it would be perfectly possible that someone would update the
hash function used at some later date without realising the assumptions
that are being made. Might it not at least be a better idea to
explicitly ensure that the combination of fixed string and SECRET_KEY is
longer than the hash output length, and to hash the resulting string
before calling hmac.new?

I do seem to remember there being apparently good reasons for not using
the same secret key throughout, although I can't remember what they
were. Given the need for distinct keys for different purposes (I'm
assuming there really is still such a need, for now), it seems to me
that explicitly having separate keys in settings.py for each purpose
would be preferable (either as separate entries or by chopping a much
longer SECRET_KEY into substrings). That then makes me wonder whether
there's any real benefit to storing the key in settings anyway - perhaps
we could come up with an alternative that would both manage separate
keys for each requirement, and actually allow the keys to be refreshed
without invalidating existing otherwise-valid HMACs?


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12012 Logging: request for comments

[Nick Phillips]

On Wed, 2010-09-29 at 09:00 +0800, Russell Keith-Magee wrote:

> These all strike me as messages appropriate for a warning -- they're
> all slightly concerning indications that you're either under some sort
> of attack, or at the very least that your users are having a bad
> experience on your site.
> 
> This includes 404 -- manually entered URLs and annoying PHP hackbots
> notwithstanding, your site shouldn't be generating 404s. If it is, you
> should be investigating. The only argument I can see for 404 as an
> INFO message is the prevalence; given that a 404 is often generated
> without being a concern, it makes sense to make them easy to filter
> out. However, IMHO, unilaterally ignoring 404s would be just as bad as
> having too many. On top of that, any halfway decent log analysis tool
> can filter these messages on a per-status code or per-URL basis.

FWIW I agree with everything you say up to this point - it's just the
conclusion that I differ on; I'd prefer to have the ability to use the
logging config to send the 404s somewhere else. Not to ignore them, just
to be able to deal with them separately as simply as possible. Since
their issue is buried within the framework and can't easily be
overridden, I think their ubiquity does justify the the lower priority.

However, as Alex pointed out, this is essentially bikeshedding. So,
since you're the one doing the work, at this point I'll shut up and wish
you well with it :-)


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12012 Logging: request for comments

[Nick Phillips]

On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote:

> So - have at it. I'm really excited by this; so let me know everywhere
> I've messed up so that we can get this into trunk.


Sorry, missed this before. A couple of comments...

Logging config as last stage of settings loading is where is seems to
have ended up in our apps at the moment anyway; I'd agree with whoever
it was who said that it should be made possible/simple to force the
config to happen earlier in settings (and then not happen twice), as
depending on the complexity of the settings, it may be necessary to log
from it.

I'm worried by the use of "warning" for all 4xx statuses. I think it
still makes sense to use the "original" syslog level definitions[*] as a
guide, and on there I'd suggest that some 4xx statuses would merit
"Info", some "Notice", and maybe one or two "Warning". "Notice" not
being included in Python's default logging, I guess that means I'd split
them between "Info" and "Warning".

My view is that the main use of these logs to me is to help me see when
someone is doing Bad Things (or trying to) to my system. I would be
wanting anything that indicated a targeted exploration of my server to
show up as "Warning", and anything that's most likely a random script
kiddie to be "Info". That certainly puts 404 in as "Info"; I see so many
hits looking for e.g. poorly-configured phpmyadmin installations, that
404s would swamp anything that I really needed to be looking at.


[*] Which are, according to 'man syslog' on this box:

   LOG_EMERG  system is unusable
   LOG_ALERT  action must be taken immediately
   LOG_CRIT   critical conditions
   LOG_ERRerror conditions
   LOG_WARNINGwarning conditions
   LOG_NOTICE normal, but significant, condition
   LOG_INFO   informational message
   LOG_DEBUG  debug-level message


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Proposal: Revised form rendering

[Nick Phillips]

On Wed, 2010-07-14 at 00:11 +0800, Russell Keith-Magee wrote:

> What exactly is your use case for something that designers want to
> customize in the raw widget that widget.render() doesn't expose?

That reminds me of one thing I'd very much like to see in any
refactoring of form/widget handling.

I'd like to be able to get at the "rendered" data (I say rendered, what
I suppose I really mean is "transformed" either due to rendering needs
or conversion from a graphical representation in the widget to something
that could be resubmitted), without any of the surrounding chrome. There
are various cases in which this can be useful, the most obvious of which
is to tell whether the data in the form has been edited before
submission. It's currently not possible to work this out from the
"before" and "after" data, as you don't know how any particular field's
data might have been munged by the widget (e.g. how is empty data
rendered, any forcing to unicode, Python boolean to textual
representation, date format transformation etc.). 

This would make solving problems like those in #11303 simple. As another
example, changeset 10757 is heading down this path to fix #10288 in
adding the _format_value method. I'd suggest that this be generalised
and applied to all widgets (and the _format_value or whatever you want
to call it to lose the "_" and be documented as part of the widget API).

In one project here, I've had to write "duplicate" versions of all
widgets to add a "disable" method and enable them to disable themselves
in the UI while still submitting data (actually I'd like the standard
widgets to support this too, but... ;-) ); while doing so I took the
opportunity to refactor slightly more and ensure that all munging of
data took place in one method which could then be used for the purpose
described above - which worked just fine.


Cheers,


Nick

-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[Nick Fitzgerald]

>
> It's still possible in exactly the same way as you do it today:
> mydata = ...
> urlpatterns('', url('...', 'MyView', {'outside_of_lifecycle': mydata}))
>
> Alternatively, you can derive from MyView:
> class SubMyView(MyView):
>ouside_of_lifecycle = mydata
>
> However, I don't think that this is the use-case of class-based views
> (you can achieve the same with function-based views). The whole point
> is being able to reuse as much code as possible while allowing to
> flexibly modify the view's behavior at a rather fine-grained level.
> Take a look at the Feed view in Django (or look at ModelAdmin from the
> admin interface if you prefer):
> http://docs.djangoproject.com/en/dev/ref/contrib/syndication/
> You can customize the query that gets executed and you can customize
> every single field that gets displayed in the feed. It's very easy and
> flexible and in contrast to function-based views you don't need to
> rewrite the whole view from scratch to change a little detail.
>
>
Yes. I couldn't have put the use case for class based generic views in to
words better myself.

_Nick_

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[Nick Fitzgerald]

I have forked bfirsh's code as well on github:
http://github.com/fitzgen/django-class-based-views

I have changed the code
to use __new__ rather than copying self. I have also merged in daonb's
commit to make request implicit to all methods via self.request.

All feedback is very welcome! :)

_Nick_



On Wed, Jun 16, 2010 at 4:14 PM, daonb  wrote:

> On Jun 16, 4:45 pm, Ben Firshman  wrote:
> >
> > The request is passed round so methods look like views to decorators.
> Magically dropping it for decorators seems a bit scary. :/
> >
>
> The way I see it a good framework need to establish a clear contract
> with its user. In our case, Django publishes a contract ensuring the
> user that when he inherits from View and overrides any of: GET, POST,
> UPDATE, DELETE,get_response, get_content, get_resource, render_html,
> get_template, get_context and a few others, the request attribute of
> self is current.
>
> I agree stripping the request looks a bit scary, but at least it's
> only 5 lines of simple code:-). They way I see it,  decorators are
> global so they need the request and Django adds it for them. When the
> global decorators are done, Django can strip the request and get the
> user to trust our contract.
>
> Benny.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[Nick Fitzgerald]

Another option that hasn't come up is to just have a custom __setattr__ that
won't let users write to self (therefore providing primitive thread safety).
I don't think it is a /good/ option, but I am just throwing it out there for
completeness.

_Nick_



On Tue, Jun 15, 2010 at 7:10 AM, Patryk Zawadzki wrote:

> If you don't mind, I'll talk a bit more to myself.
>
> On Tue, Jun 15, 2010 at 3:38 PM, Patryk Zawadzki 
> wrote:
> > I really don't think we should add anti-moron filters at the framework
> > level past documenting "taking care to ensire immutability of view
> > instances".
>
> This came out a bit harsh. What I mean is: teach users how to write
> thread-safe views (classes or not) and ignore those who refuse to do
> it. They either know what they're doing or there is really no point in
> forcing the help upon them.
>
> --
> Patryk Zawadzki
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[Nick Fitzgerald]

Luke,

Good points, especially about wrapping decorators *after* instantiation to
avoid the whole nasty self issue.

While I personally don't mind meta classes at all, I understand why some
people do.

I think you are probably on the right track here.

_Nick_

On Thu, May 13, 2010 at 4:08 AM, Luke Plant  wrote:

> On Thursday 13 May 2010 01:14:35 fitzgen wrote:
>
> > * How to decorate the __call__ method without doing a pointless
> > override of __call__ that just calls super so that you have
> > something to @decorate on top of. Check out the meta class on line
> > 175. This allows you to specify 'decorators = [login_required,
> > permission_required("polls.can_vote")]' on your subclass. I showed
> > this to Jacob at DjangoSki, and he seemed positive.
>
> I personally don't like metaclasses if we can find another way.  Here
> are some alternatives which use Plain Old Python:
>
> 1) from Python 2.6 we could use class decorators, and we could use the
> 'old style' MyClass = some_class_decorator(MyClass) until we move to
> Python 2.6.
>
> 2)
>   class Foo(View):
>  __call__ = some_decorator(View.__call__)
>
>
> 3) Add the decorators when you call 'instantiator' (which, by the way,
> I would rather call 'make_view' or something more specific).  You
> would then have, *in views.py*:
>
> 3a) my_view = some_decorator(make_view(MyViewClass))
>
> or possibly (though I don't think this adds much):
>
> 3b) my_view = make_view(MyViewClass,
>decorators=[some_decorator])
>
> This has some significant advantages:
>
>  - you don't need to worry about method decorators
>
>  - you can re-use MyViewClass with different decorators
>
>  - it protects us from changing the URLconf.  The URLconf always
>   has a reference to the 'my_view' function, rather than
>   MyViewClass.  Class-based views then remain an implementation
>   detail, just as they ought to be.  It may well be that
>   a re-usable app provides some views and might switch
>   from class-based views to normal functions, and URLconfs
>   should be insulated from that change.
>
> I don't like the idea of special-casing class based views anywhere,
> whether to cope with state or anything else.  I think a view should
> still be 'a callable that takes a request and returns a response'.  If
> that means we have to add an extra line to create a view function from
> a view class, so be it.
>
> Given that it is going to be possible to use any/all of these whatever
> Django provides, I think I'm quite strongly in favour of 3a), and
> opposed to adding a metaclass which really doesn't add anything
> significant.  Metaclasses add complications for people attempting to
> understand code, and should be used only when you really need them.
>
> > * How to decorate methods, when the decorator expects the first
> > argument to be request, and not self. See line 8. Ideally though,
> > Django's decorators would handle this, rather than forcing the use
> > of decorate_method_with on to the end users.
>
> We already have 'django.utils.decorators.method_decorator' to cope
> with this.  All attempts to have decorators that automatically adapt
> to functions/methods have failed.  See my message here
> http://groups.google.com/group/django-developers/msg/f36976f5cfbcbeb3
> It has some attachments with test cases that show how our previous
> attempt to do this didn't work in some situations.
>
> One thing we could do to make it nicer for the end user is to create
> our own 'method' versions of all supplied decorators i.e:
>
>  cache_page_m = method_decorator(cache_page)
>
> for every decorator we provide, so that people don't need to do that
> themselves.
>
> However, this point may be moot given the discussion above.
>
> Luke
>
> --
> "Mistakes: It could be that the purpose of your life is only to
> serve as a warning to others." (despair.com)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django

[Nick Phillips]

On Sat, 2010-04-17 at 14:23 -0700, orokusaki wrote:

> 4) The attitude projected at developers gives the idea that Django is
> for the core team only, and that users are graced with the ability to
> use Django. While the contribution is much appreciated, the attitude
> is harmful to the core team and to the user base.


You might like to consider the fact that this is not at all the
"attitude" I see.

What I see is a group of people working very hard and holding themselves
to very high standards. In such a situation I would expect that I too
would have to meet those standards were I to wish any contribution I
might make to be included in their work ("work" in the sense of "a
work").

That is a challenge I would love to have the time for, but I don't. So
where I find that Django either has issues or fails to meet my needs, I
work around the problems in other ways. I might well file a ticket here
and there, and even a patch if I have one that might be useful, but
"inclusion straight into trunk" is not the only way a patch can be
useful. I'm certainly not going to try to tell them that they should be
doing things my way - and if I did want to, I wouldn't expect to get
anywhere with your current tactic.

This thread is distracting energy that could be better spent, so I'm
going to leave it at that, and would suggest that others do too.


Cheers,


Nick

-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: [GSoC] Application Loading

[Nick Sandford]

On Fri, Apr 9, 2010 at 2:59 PM, Russell Keith-Magee
<freakboy3...@gmail.com> wrote:
> On Fri, Apr 9, 2010 at 12:33 AM, Nick Sandford <nick.sandf...@gmail.com> 
> wrote:
>> An App Loading mechanism for Django
>> 
>>
>> About Me
>> --
>> Hi everyone,
>>
>> My name is Nick Sandford, I'm an electrical engineering student at the
>> University of Western Australia.
>>
>> Background
>> ---
>>
>> I haven't been a particularly active contributor to any open source project -
>> here is where I hope to change that. In my current work at Christ
>> Church Grammar School we use Django heavily for most of our internal
>> projects. I've
>> followed django-dev closely for a couple of years and I have poked around 
>> with
>> its internals on various occasions.
>
> Ok - I clearly need to get a Perth DjUG going...
>
>> Plan
>> -
>>
>> Implement an improved application loading mechanism into Django.
>>
>> Rationale
>> -
>>
>> Django current application loading code is inflexible in many cases. There
>> exists a need for a number of extra features to be added to the way
>> applications are handled such as:
>>
>>  * The ability to internationalise application names.
>>  * The ability to customise application names similar to ``verbose_name`` in
>>    ``model._meta``
>>  * Deploy the same application multiple times in a single project.
>>  * Deploy two different applications with the same name.
>>  * Manage settings within applications.
>>
>> Method
>> ---
>>
>> I don't intend to solve the third dot point of the previous list - it seems
>> like a difficult problem, possibly to be tackled post-GSoC. What I do intend
>> to do is to move towards 'application classes' more akin to
>> ``django.contrib.admin``.
>>
>> New syntax in ``settings.INSTALLED_APPS`` will be introduced to address the
>> previous issues. Some examples of accepted syntax:
>>
>> .. sourcecode:: python
>>
>>    INSTALLED_APPS = (
>>        'django.contrib.auth',
>>        app('blog.BlogApplication', 'blog_1', 'My blog', 'app1_'),
>>        app('blog.BlogApplication', 'blog_2', 'Some other blog', 'app2_'),
>>        app(path='tagging.Tagging', verbose_name='My tagging application'),
>>        app('categories', db_prefix='cat_'),
>>        app({'path': 'django.contrib.admin.AdminApplication',
>>             'label': 'admin',
>>             'verbose_name': 'Secret Admin'}),
>>    )
>>
>> The ``app`` function will take four arguments, three of which are optional.
>> These are ``path``, ``label``, ``verbose_name``, and ``db_prefix``. It will
>> return an instance of an ``Application`` object, which will contain all of an
>> installed application's information. ``path`` will be the dotted path to a
>> subclass of ``Application``. The downside is that ``settings.py`` requires
>> an import, which may be against style rules.
>>
>> .. sourcecode:: python
>>
>>    def app(path, label=None, verbose_name=None, db_prefix='')
>>        if not path or not isinstance(path, basestring):
>>            raise ImproperlyConfigured('Application path must be string.')
>>        application_class = import_module(path)
>>        return application_class(path, label, verbose_name, db_prefix)
>>
>> ``INSTALLED_APPS`` will then be a tuple containing strings or ``Application``
>> instances. The application loading code will iterate over ``INSTALLED_APPS``
>> and construct an internal cache of ``Application`` instances to be used with
>> ``get_models``, etc. For backwards compatibility, if an element of the tuple 
>> is
>> a string, an instance of a base ``Application`` class will be created with 
>> sane
>> defaults (similar to ``app_label`` at the moment).
>>
>> The ``Application`` class will be very similar to ``django.contrib.admin``'s
>> ``AdminSite`` and will hopefully simplify application settings. If you write
>> views and urls directly on the ``Application`` class itself, instead of an
>> ``from django.conf import settings`` and subsequent ``settings.API_KEY``, you
>> could just reference ``self.api_key`` for instance. This wouldn't be the
>> required, just an optional extra.
>>
>> Model classes will get a ``_meta.app`` attribute, which will be an instance
>> of the model's ``Application`` class. Models should only be associated with 
>> one
>> application.
>>
>> I agree with moving ``django.db.models

Re: [GSoC] Application Loading

[Nick Sandford]

An updated proposal:

An App Loading mechanism for Django


About Me
--
Hi everyone,

My name is Nick Sandford, I'm an electrical engineering student at the
University of Western Australia.

Background
---

I haven't been a particularly active contributor to any open source project -
here is where I hope to change that. In my current work at Christ Church
Grammar School we use Django heavily for most of our internal projects. I've
followed django-dev closely for a couple of years and I have poked around with
its internals on various occasions.

Plan
-

Implement an improved application loading mechanism into Django.

Rationale
-

Django current application loading code is inflexible in many cases. There
exists a need for a number of extra features to be added to the way
applications are handled such as:

 * The ability to internationalise application names.
 * The ability to customise application names similar to ``verbose_name`` in
   ``model._meta``
 * Deploy the same application multiple times in a single project.
 * Deploy two different applications with the same name.
 * Manage settings within applications.

Method
---

I don't intend to solve the third dot point of the previous list - it seems
like a difficult problem, possibly to be tackled post-GSoC. What I do intend
to do is to move towards 'application classes' more akin to
``django.contrib.admin``.

I plan to introduce a new file into the project structure - ``apps.py`` which
will be used to register installed applications with the ``AppCache``. I will
also move to introduce a new setting in ``settings.py``, ``APP_LOADER`` which
will be a string containing a dotted path to an application loading class. This
will serve to facilitate a move from ``settings.INSTALLED_APPS`` to the new
``apps.py``. ``APP_LOADER`` will take one of two values:
'django.core.apps.loader.legacy', which will use ``settings.INSTALLED_APPS`` or
'django.core.apps.loader.registry', which would use the new registry-based
approach. Only applications registered in ``apps.py`` in the project directory
will be registered with the ``AppCache``. The default APP_LOADER setting for
1.3 will be 'django.core.apps.loader.legacy'.

``apps.py`` will contain purely application-related setup. This should be handy
to manage application settings and to ensure ``settings.py`` doesn't get too
full of application-specific settings. This will allow us to register an app
in one of three ways something like:

.. sourcecode:: python

   from django.core import apps
   from blog import BlogApplication

   class MyBlogApplication(BlogApplication):
   api_key = 'testing'

   another_blog = BlogApplication(label='blog2',
  verbose_name=_('Another blog'),
  api_key='anothertest')

   # an application class.
   apps.register(MyBlogApplication, label='blog', verbose_name=_('My blog'))
   # an application instance.
   apps.register(another_blog)
   # old-style application.
   apps.register('django.contrib.auth')

This could allow us not to touch ``settings.INSTALLED_APPS`` at all. If people
need to iterate over ``settings.INSTALLED_APPS``, a move to ``get_apps`` will
be recommended.

The ``Application`` class will be very similar to ``django.contrib.admin``'s
``AdminSite`` and will hopefully simplify application settings. If you write
views and urls directly on the ``Application`` class itself, instead of an
``from django.conf import settings`` and subsequent ``settings.API_KEY``, you
could just reference ``self.api_key`` for instance. This wouldn't be the
required, just an optional extra.

In addition to providing application settings an ``Application`` will be
required to explicitly define their models. These models could live outside
the traditional application structure, provided they are included in the
``models`` list on ``Application``. The current structure promotes strictly
requiring models for an application to reside in that application's
``models.py``. I wouldn't be promoting changing the current status quo with
regard to this, but it would be possible to deviate from it and include models
defined outside of the applications ``models.py`` on an ``Application``.

An application class would have other benefits, as evidenced by a short look at
``django.contrib.admin.AdminSite``. It could concievably be used to define a
set of 'base' add/edit/delete views for each model on an ``Application``. It
could even be used to set up an application's urls. This could make an
``Application`` class unwieldy and large however, so it won't be forced and
people can continue using views.py and urls.py as before.

Model classes will get a ``_meta.app`` attribute, which will be an instance
of the model's ``Application`` class. Models should only be associated with one
application.

There are a number of places within Django that rely on ``app_label`` and
that will need

Re: Application Loading

[Nick Sandford]

On Fri, Apr 9, 2010 at 5:21 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>
>
> Have you looked at the patch on ticket 3591 which does some of this
> already? Would you be using it as a starting point?

It's a great place to start, and gives a good idea about where to look for
problems. I'm not sure about get_installed_app_paths, rather than modifying
settings.INSTALLED_APPS to contain a tuple of strings pointing to all
application paths. If we end up using get_installed_app_paths it would break
all of those using for app in settings.INSTALLED_APPS in third party code.

You've taken the route of assuming applications won't know their models
until runtime, I've expected that people explicitly assign models to apps.

Your loading code looks like a good starting point also.

Cheers,
Nick

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: [GSoC] Application Loading

[Nick Sandford]

On Fri, Apr 9, 2010 at 3:41 AM, burc...@gmail.com <burc...@gmail.com> wrote:
>
> Hi Nick,
>
> I don't like your application creation syntax (why using dict-based
> DSL instead of class-based?), but
> I like how you approach the overall problem.
> More than that, you have shown you do understand all the problems
> you're going to solve, and that you have design skills required for
> solution.
> But I believe you can do even further with your proposal.
>
> You said:
> >Model classes will get a ``_meta.app`` attribute, which will be an instance
> of the model's ``Application`` class. Models should only be associated with 
> one
> application.
> This is very nice idea, and I think, it allows to come with further
> design of how should multiple app copies work.
> I don't want to push on you, or suggest a working solution, so I'd
> like to see your ideas.

Multiple app copies is quite a bit more difficult, unless you assume
(like the admin)
that they use the same database table. Then I guess you could store multiple
application instances in Model._meta.app and use url namespacing to
differentiate
applications/views.

>
> I've got questions that might help:
>  * how will views know about their current application?

Views implemented in views.py wouldn't necessarily need to know about their
current application, but if they did, you could use get_app("my_app")
in the view itself.

Views implemented on the Application itself wouldn't have this problem.

>  * how will views get their app settings after your changes?

For settings still in settings.py, just the same as always.

For settings implemented in an Application itself maybe something like:

# views.py
def view(request):
api_key = get_app("my_app").options.api_key
# do stuff

and for views in an Application:

def view(self, request):
api_key = self.options.api_key
# do stuff

>  * is it a good idea to make urls properties (namespace, app_name)
> correspond with the same application properties?

That would help for the case of multiple application instances, but
for the time being
isn't strictly necessary. Probably not a bad idea to promote.

>
> Currently options are either "from django.conf import settings", and
> those settings are singleton with configuration options, or put into
> urls.
>
> Should we say "go away" to view-as-a-function and go to rails-like
> controllers like your Application class?

I don't think I necessarily want to force people to do that, but
rather make things
easier to be done like that. View-as-a-function still works well for
simple setups.

>
> (I'm for this option actually, all views other than "hello world"
> always take such a bloat of configuration options right now that needs
> to be put into controllers anyway -- look at django.contrib.auth.views
> for example!)
>
> (Completely unrelated note, but I'd rather see a url routing right
> near those views definition after update. because, 98% of times, you
> won't need urls at all!)

That would be pretty nice, you could do something like:

# urls.py
from django.conf.urls.defaults import *
from django.core.apps import get_app

urlpatterns = patterns('',
(r'^blog/', include(get_app("blog").urls)),
)

>
> Please also see the thread
> http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879?hl=en,
> there's a question you avoided delicately, about what to do with
> ForeignKey. It might also help.

As far as I see that, it's more about what to do when you have two
instances of the
same application, which I won't be attempting to solve. With just a
single instance,
models work just the same as they always have (save for the _meta.app) stuff.

Thanks for the feedback.

>
> On Thu, Apr 8, 2010 at 7:33 PM, Nick Sandford <nick.sandf...@gmail.com> wrote:
> > An App Loading mechanism for Django
> > 
> >
> > About Me
> > --
> > Hi everyone,
> >
> > My name is Nick Sandford, I'm an electrical engineering student at the
> > University of Western Australia.
> >
> > Background
> > ---
> >
> > I haven't been a particularly active contributor to any open source project 
> > -
> > here is where I hope to change that. In my current work at Christ
> > Church Grammar School we use Django heavily for most of our internal
> > projects. I've
> > followed django-dev closely for a couple of years and I have poked around 
> > with
> > its internals on various occasions.
> >
> > Plan
> > -
> >
> > Implement an improved application loading mechanism into Django.
> >

[GSoC] Application Loading

[Nick Sandford]

An App Loading mechanism for Django


About Me
--
Hi everyone,

My name is Nick Sandford, I'm an electrical engineering student at the
University of Western Australia.

Background
---

I haven't been a particularly active contributor to any open source project -
here is where I hope to change that. In my current work at Christ
Church Grammar School we use Django heavily for most of our internal
projects. I've
followed django-dev closely for a couple of years and I have poked around with
its internals on various occasions.

Plan
-

Implement an improved application loading mechanism into Django.

Rationale
-

Django current application loading code is inflexible in many cases. There
exists a need for a number of extra features to be added to the way
applications are handled such as:

  * The ability to internationalise application names.
  * The ability to customise application names similar to ``verbose_name`` in
``model._meta``
  * Deploy the same application multiple times in a single project.
  * Deploy two different applications with the same name.
  * Manage settings within applications.

Method
---

I don't intend to solve the third dot point of the previous list - it seems
like a difficult problem, possibly to be tackled post-GSoC. What I do intend
to do is to move towards 'application classes' more akin to
``django.contrib.admin``.

New syntax in ``settings.INSTALLED_APPS`` will be introduced to address the
previous issues. Some examples of accepted syntax:

.. sourcecode:: python

INSTALLED_APPS = (
'django.contrib.auth',
app('blog.BlogApplication', 'blog_1', 'My blog', 'app1_'),
app('blog.BlogApplication', 'blog_2', 'Some other blog', 'app2_'),
app(path='tagging.Tagging', verbose_name='My tagging application'),
app('categories', db_prefix='cat_'),
app({'path': 'django.contrib.admin.AdminApplication',
 'label': 'admin',
 'verbose_name': 'Secret Admin'}),
)

The ``app`` function will take four arguments, three of which are optional.
These are ``path``, ``label``, ``verbose_name``, and ``db_prefix``. It will
return an instance of an ``Application`` object, which will contain all of an
installed application's information. ``path`` will be the dotted path to a
subclass of ``Application``. The downside is that ``settings.py`` requires
an import, which may be against style rules.

.. sourcecode:: python

def app(path, label=None, verbose_name=None, db_prefix='')
if not path or not isinstance(path, basestring):
raise ImproperlyConfigured('Application path must be string.')
application_class = import_module(path)
return application_class(path, label, verbose_name, db_prefix)

``INSTALLED_APPS`` will then be a tuple containing strings or ``Application``
instances. The application loading code will iterate over ``INSTALLED_APPS``
and construct an internal cache of ``Application`` instances to be used with
``get_models``, etc. For backwards compatibility, if an element of the tuple is
a string, an instance of a base ``Application`` class will be created with sane
defaults (similar to ``app_label`` at the moment).

The ``Application`` class will be very similar to ``django.contrib.admin``'s
``AdminSite`` and will hopefully simplify application settings. If you write
views and urls directly on the ``Application`` class itself, instead of an
``from django.conf import settings`` and subsequent ``settings.API_KEY``, you
could just reference ``self.api_key`` for instance. This wouldn't be the
required, just an optional extra.

Model classes will get a ``_meta.app`` attribute, which will be an instance
of the model's ``Application`` class. Models should only be associated with one
application.

I agree with moving ``django.db.models.loading`` to ``core.apps``, since we'll
no longer require applications to have a ``models.py``. A reference to the
new functions in ``core.apps`` will still live in ``django.db.models.loading``
for backwards compatibility.

A subclass of ``Application`` might look like:

.. sourcecode:: python

from django.views.simple import direct_to_template
from djang.core.apps import Application
from blog.models import Entry, Category

class BlogApplication(Application):
models = [Entry, Category]
api_key = 'default'

def entry_detail(self, slug, request,
template_name='blog/entry_detail.html'):
entry = get_object_or_404(Entry, slug=slug)
context = {
'entry': entry,
'api_key': self.api_key,
}
return direct_to_template(request, template_name, context)

Hurdles


There are a list of possible technical issues:

 * Introducing the new ``app`` function requires an import in settings.py
   which might not be acceptable behaviour.
 * Two applications with the same label.
 * Worrying amounts

Re: What is the status of auto_now and auto_now_add?

[Nick Lo]

> I can't see the problem in that article.
> Also, the datetime objects have changed since then, taking a timezone
> as optional parameter:
> http://docs.python.org/library/datetime.html#datetime-objects
>
> I mean we are using date/time already with our pre-save way of doing
> things, why should auto_add act any different?

I don't understand what you mean by "changed since then" as that  
article was "Last edited Thu 25 Jun 2009". I was referring  
specifically to /db/models/fields/__init__.py line 888:

value = datetime.datetime.now()

As you say, datetime.now() takes timezone as an optional parameter,  
but it has done for years. From my reading of that article the  
statement "datetime.now() is never to be used. Always use  
datetime.utcnow()" means the above line would become:

value = datetime.datetime.utcnow()

I'm not and cannot argue for or against that idea due to my poor  
knowledge of Python, it's date libraries and the whole timezone issue  
in general so I'm really just wondering if that has any relevance?  
Thanks to the original poster I'm now also interested in whether and  
if so why, auto_now and auto_now_add are to be avoided.

Nick

> On Sep 10, 8:24 pm, Nick Lo <ingredients.com...@gmail.com> wrote:
>>> By the way drossy, I still don't know why it's evil, just that every
>>> respected Django dev (and BDFLs) were +1 on removing it (very +1).  
>>> But
>>> the reasons don't seem consistent. In one case James B. describe's
>>> some unexplained side effects of using it (which coincide with  
>>> another
>>> bloggers findings) which would make the two attributes unstable. I
>>> don't know if that is just older behavior from previous releases.
>>
>> Since auto_now uses datetime.datetime.now() I don't know if it's
>> tangential or relevant to point to another article that discusses  
>> some
>> unexpected behaviour of datetime. It says "datetime.now() is never to
>> be used. Always use datetime.utcnow()":
>>
>> http://www.enricozini.org/2009/debian/using-python-datetime/
>>
>> I've not investigated this to any degree so I'm just passing it on as
>> a potentially relevant sidenote.


--~--~-~--~~~---~--~~
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: What is the status of auto_now and auto_now_add?

[Nick Lo]

> By the way drossy, I still don't know why it's evil, just that every
> respected Django dev (and BDFLs) were +1 on removing it (very +1). But
> the reasons don't seem consistent. In one case James B. describe's
> some unexplained side effects of using it (which coincide with another
> bloggers findings) which would make the two attributes unstable. I
> don't know if that is just older behavior from previous releases.

Since auto_now uses datetime.datetime.now() I don't know if it's  
tangential or relevant to point to another article that discusses some  
unexpected behaviour of datetime. It says "datetime.now() is never to  
be used. Always use datetime.utcnow()":

http://www.enricozini.org/2009/debian/using-python-datetime/

I've not investigated this to any degree so I'm just passing it on as  
a potentially relevant sidenote.

Nick


--~--~-~--~~~---~--~~
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: append_slash alternative: remove_slash

[Nick Phillips]

Graham Dumpleton wrote:
> I was only commenting in relation to how Apache works and the
> conjecture that:
>
>   

Yep, I assumed so - just wanted to make sure that nobody read it in a
more general way.

> Take it as you will as being irrelevant to the main conversation about
> Django itself, but am just clarifying what is reality for Apache in
> relation to that sweeping statement about what happened back in the
> """days when all web pages were a collection of static html files""".
>   

For users, the original statement ( /foo, /foo/ and /foo/index.html
usually being equivalent )
was correct. I think you're probably just looking at it from a different
angle.

As someone else pointed out, it's very likely moot at this point anyway.


Cheers,


Nick

-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago


--~--~-~--~~~---~--~~
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: append_slash alternative: remove_slash

[Nick Phillips]

Graham Dumpleton wrote:

>>> It's better to see it this way: Every page is an individual piece of
>>> content for itself, and still every page can have subpages.
>>>   
>>> A directory, on the other hand, can have subpages, but is not that
>>> interesting for itself. Which we don't want to happen - we want all
>>> our pages to be interesting!
>>>   
>> Think back to the days when all web pages were a collection of static
>> html files. Every directory within the server root had an index page
>> (usually index.html). That page could be found at any of the three
>> urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`.
>> 
>
> My understanding is that the default behaviour of Apache has always
> been that when '/path/to/dir' was used, it would redirect the client
> to '/path/to/dir/'.
>
> It only became possible to override this from Apache 2.0 onwards. See:
>
>   http://httpd.apache.org/docs/2.2/mod/mod_dir.html#directoryslash
>
> Disabling need for trailing slash in Apache apparently has some
> security implications as documented in that page and so in some
> respects it is discouraged.
>   

Two points:

1) Slashes were only added to directories; we're not talking about
directories in this case;
2) Since we're not talking about that situation (i.e. a request for a
directory, which could be handled by generating an index in one of two
different ways), there are absolutely no security implications involved
in the decision (or lack of decision ;-) ) that is currently being
discussed.

FWIW, I personally dislike extraneous slashes. Django views seem to me
to be analogous to files, not directories, so I don't like seeing URLs
that make them look like directories.

Analogies can of course be taken too far.


Cheers,


Nick

-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago


--~--~-~--~~~---~--~~
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: Mysql query log causing django to lock up

[Nick Craig-Wood]

Following up to myself...

On Wed, Feb 25, 2009 at 09:16:09AM +, Nick Craig-Wood wrote:
> I've finally got to the bottom of why django locks up on our dev server.
> 
> Our dev server has mysql query logging turned on with this in 
> /etc/mysql/my.cnf
> 
> # Query logging
> log=/var/log/mysql/mysqld.log
> 
> However with that, then simple queries (like looking at the accounts
> table in the admin interface) lock up leaving this in the process
> list.
> 
> +---+-+-++-+---++--+
> | Id| User| Host| db | Command | Time  | State  | 
> Info  
>|
> +---+-+-++-+---++--+
> | 43726 | backend | localhost:59678 | memset | Query   | 62773 | statistics | 
> SELECT `account`.`id`, `account`.`admin_id`, `account`.`billing_id`, 
> `account`.`currency`, `account` |
> | 43880 | backend | localhost   | memset | Query   | 58289 | statistics | 
> SELECT `account`.`id`, `account`.`admin_id`, `account`.`billing_id`, 
> `account`.`currency`, `account` |
> | 43882 | backend | localhost   | memset | Query   | 58231 | statistics | 
> SELECT `account`.`id`, `account`.`admin_id`, `account`.`billing_id`, 
> `account`.`currency`, `account` |
> | 43883 | backend | localhost   | memset | Query   | 58136 | statistics | 
> SELECT `account`.`id`, `account`.`admin_id`, `account`.`billing_id`, 
> `account`.`currency`, `account` |
> | 44190 | root| localhost   || Query   | 0 || 
> show processlist  
>|
> +---+-+-++-+---++
> 
> As you can see the queries are not completing even after 17 hours!
> 
> Disabling the query log (commenting out the log= in my.cnf) fixes the
> problems and the queries become instant again.
> 
> This is with mysql 5.0.51a-17 and django 1.0

I should really check stuff more before posting :-(

It seems that the act of restarting mysql was enough to let those
queries run properly which is independent of the mysql query log.

So any clues gratefully received!

-- 
Nick Craig-Wood <n...@craig-wood.com> -- http://www.craig-wood.com/nick

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Mysql query log causing django to lock up

[Nick Craig-Wood]

I've finally got to the bottom of why django locks up on our dev server.

Our dev server has mysql query logging turned on with this in /etc/mysql/my.cnf

# Query logging
log=/var/log/mysql/mysqld.log

However with that, then simple queries (like looking at the accounts
table in the admin interface) lock up leaving this in the process
list.

+---+-+-++-+---++--+
| Id| User| Host| db | Command | Time  | State  | 
Info
 |
+---+-+-++-+---++--+
| 43726 | backend | localhost:59678 | memset | Query   | 62773 | statistics | 
SELECT `account`.`id`, `account`.`admin_id`, `account`.`billing_id`, 
`account`.`currency`, `account` |
| 43880 | backend | localhost   | memset | Query   | 58289 | statistics | 
SELECT `account`.`id`, `account`.`admin_id`, `account`.`billing_id`, 
`account`.`currency`, `account` |
| 43882 | backend | localhost   | memset | Query   | 58231 | statistics | 
SELECT `account`.`id`, `account`.`admin_id`, `account`.`billing_id`, 
`account`.`currency`, `account` |
| 43883 | backend | localhost   | memset | Query   | 58136 | statistics | 
SELECT `account`.`id`, `account`.`admin_id`, `account`.`billing_id`, 
`account`.`currency`, `account` |
| 44190 | root| localhost   || Query   | 0 || 
show processlist
 |
+---+-+-++-+---++

As you can see the queries are not completing even after 17 hours!

Disabling the query log (commenting out the log= in my.cnf) fixes the
problems and the queries become instant again.

This is with mysql 5.0.51a-17 and django 1.0

I'm not sure whether this is a bug in django or mysql, but hopefully
this message will act as a heads-up to anyone else having the same
problem!

-- 
Nick Craig-Wood <n...@craig-wood.com> -- http://www.craig-wood.com/nick

--~--~-~--~~~---~--~~
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: #7666: Default managers should not restrict access to single related objects

[Nick Lane]

On Jul 8, 3:34 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 7, 2008 at 8:29 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > Currently, ReverseSingleRelatedObjectDescriptor uses _default_manager,
> > which is the problem (line 239 in django/db/models/related/fields.py).
> > One clean solution would be to give each model a _pristine_manager
> > attribute, which would be *guaranteed* to be a simple Manager()
> > instance -- i.e., not a custom one. Then we could use
> > _pristine_manager here, in this case.
>
> Why bother with the overhead of creating and maintaining an entire
> Manager instance, when what's really wanted is a pristine QuerySet?
> That can be obtained by the simple expedient of
>
>     qs = QuerySet(whatever_model_this_should_be)
>
> and doesn't come with any baggage.

I forgot to note before, I've added a patch to #7666 which uses James'
suggestion of a pristine QuerySet.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[Nick]

On Jun 12, 12:46 pm, Ville Säävuori <[EMAIL PROTECTED]> wrote:
> And FWIW, I think the proposed roadmap is brilliant. Not too many
> features but still enough to make most of us very happy. Especially if
> we can get at least few of the maybes in.

Agreed.  It is great to see a concrete plan emerging for the coming
months.  Hopefully, this will reassure the worriers, as well as giving
everyone a real target to aim for.

The fact that a roadmap exists is the important thing, more than the
particular dates that have been chosen.  Early September does
sound ambitious,  but if there is a good level of participation in the
sprints, and if the output from those sprints can be reviewed and
checked in efficiently enough, it should be achievable.

I missed the last sprint and haven't contributed any patches for a
while now, but I'm certainly going to try and do my bit to get 1.0 out
the door...

N.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Refactoring the documentation

[Nick]

On Mar 31, 7:45 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> I'm embarking on a mission to refactor Django's documentation;

Great!  I'll be happy to help out with some of the grunt work as and
when
I can find a spare moment.

> * Beginner material: we've got a good amount if this in the tutorials,
>   overview, and installation guide. Some bits of those documents --
>   especially the installation guide -- ought to be broken out into
>   reference material.

+1 on breaking out the installation guide.

This is a good opportunity to think about those topics listed under
"Coming Soon" in Part 4 of the existing tutorial.  Are they still
needed?
Do they fall into the Topical Guides category rather than the Beginner
Material category? etc...

> The main goal in refactoring is to break everything up into manageable chunks.
> The model API document is over 30 printed pages -- finding anything useful
> there is rapidly becoming impossible. Even worse, it's hard to tell if
> something's gonna be found there or in the DB API -- quick, where are primary
> keys documented?

This will be good to see.  The quality of the docs has always been
high,
but usability is definitely an issue with the bigger documents.  My
mouse's
scroll wheel always gets a good workout at djangoproject.com :)


Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Recent test breakage on Windows

[Nick]

On Mar 23, 3:37 pm, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> That was my first instinct too, then I had to re-discover (for the
> umpteenth time!) that normpath does not normalize a path to make it the
> same across Python implementations: it normalizes the path to make it
> right for the platform.  From the docs: "On Windows, it converts forward
> slashes to backward slashes." D'oh, that just makes the problem worse...
>
> And it turns out changing ".../django/newforms" to "...newforms" in the
> expected data isn't enough.  Where the files are two levels deep, there
> are backslashes further in also:
>

Perhaps this can be fixed by changing the definition of the path
variable, earlier in the test code.

Then again, perhaps this is one instance where writing the
tests using PyUnit would be easier than doing it with doctest.


Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: newsform Addition

[Nick Lane]

On Feb 14, 7:10 am, Collin Grady <[EMAIL PROTECTED]> wrote:
> Rock said the following:
>
> > Some thoughts:
>
> > Inplementing form.as_items returning a list of form lines would be
> > nice.
> > This allows a variety of custom formatting options. Examples:
>
> > 
> > {% for item in forms.as_items }}{{ item }} , {% endfor %}
> > <...submit directive...>
> > 
>
> > 
> > {{ item[0] }} -- {{ item[1] }} -- {{ item[2] }}
> > {{ item[3] }}
> > {{ item[4] }}
> > 
>
> These can already be done, just loop over the form, or use the manual
> items like {{ form.fieldname }}, {{ form.fieldname.label_tag }},
> {{ form.fieldname.errors }}, etc

This is what I do, but it does get a bit messy if I only want to
change the formatting of one form element and leave the rest alone.  I
know I'm going to have to list out all the fields myself in this case,
but having to insert a bunch of variables for each field can get a bit
repetitive. To be honest I haven't really sat down to work out a
better way to do this, but Malcolm's filter idea sounds like a good
place to start for me.

Cheers,
Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Databrowse improvement

[Nick]

On Dec 17, 7:32 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I'd be -1 on introducing another setting for something so minor. The
> string view is just meant to be a snapshot, so maybe increase it by a
> little bit (100, maybe ... *shrug*). But it shouldn't need to be
> customisable by everybody.

Yeah, makes sense.  I was a little uneasy about introducing a new
setting, hence my query.

I'll get rid of the setting and submit a ticket and the simplified
patch.


N.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Databrowse improvement

[Nick]

Databrowse is cool, but one limitation is that the string
representation of model instances is limited in length to 30
characters - via a hard-coded value in the __unicode__ method of the
EasyInstance class.

I have a patch that fixes this by adding a new setting for the string
size limit in django.conf.global_settings.  Before I create the ticket
and submit the patch, have I gone about this the right way?  Is a
global setting a sensible approach, or would it be preferable to have
some kind of local settings file that is used by databrowse?  What, in
general, is the best approach to supporting customization of the apps
in django.contrib?

N.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Writing tests for #6191 (admin delete view not listing all items)

[Nick Lane]

On Dec 13, 1:42 pm, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote:
> Just testing _get_deleted_objects() is fine by me if you can. I think
> the AdminSite object might be intertwined with things in the
> newforms-admin branch, so there may still be a bunch of setup.

I've updated the patch to test this, and I think the example in the
test is much clearer now.  Unfortunately I haven't had a chance to
play with newforms-admin at all yet, so it might take a little while
till I have time to update the patch for that.

Cheers,
Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The book

[nick]

What's the name of the book? I am looking for 1 to buy.



On Dec 11, 2:00 pm, raminf <[EMAIL PROTECTED]> wrote:
> Printed copy of Django book arrived yesterday. Looks great. As much as
> I enjoyed reading the chapters online, it's nice to be able to take
> the hardcopy out to a coffee shop. Also makes for a good primer for
> colleagues.
>
> Congratulations to Adrian, Jacob, and the rest of the Django crew.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Writing tests for #6191 (admin delete view not listing all items)

[Nick Lane]

Hi,

I had a quick look at writing some tests for #6191[1], and have a few
queries.

Should I be testing the admin delete view to make sure the response
contains the expected items, or should I just test the "private"
_get_deleted_objects() method, to check the items are returned in that
list?

Testing the view means I have to add some extra test setup overhead,
like: adding an admin user to the fixture, logging in with the test
client, etc.

So far the test I wrote just covers the smallest possible situation
which reproduces the problem, but I didn't want to proceed with any
more tests before asking here.

I guess the reason I went with testing the view was because the end
result is that the user should be shown a list of items which should
be deleted, so that was what I tested.

P.S. I used Mercurial queues to do the patch, but not sure how to spit
out a diff in a way which is useful in trac.

Suggestions/critcisms?

Cheers,
Nick

[1] http://code.djangoproject.com/ticket/6191
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 features -- the definitive list

[Nick]

> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>

+0 from me.  I've never set much store by version numbers, but I
suppose
2.0 will suggest a bigger leap forward to most people - and there's
a lot of good stuff on that list.


Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Sprint IRC

[Nick]

On 14 Sep, 10:47, Michael Radziej <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, Nick wrote:
>
> > On Sep 14, 3:12 am, SmileyChris <[EMAIL PROTECTED]> wrote:
> > > So the sprint is ambling along right now. If you didn't get the memo,
> > > the place to be is irc://irc.freenode.net/django-sprint
>
> > Anyone having problems finding django-sprint?  On connecting to
> > irc.freenode.net all I can see is django-fr and django-br
>
> The channel is hidden, so just make a /join #django-sprint
>

Thanks from an IRC newbie :)


N.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Sprint IRC

[Nick]

On Sep 14, 3:12 am, SmileyChris <[EMAIL PROTECTED]> wrote:
> So the sprint is ambling along right now. If you didn't get the memo,
> the place to be is irc://irc.freenode.net/django-sprint

Anyone having problems finding django-sprint?  On connecting to
irc.freenode.net all I can see is django-fr and django-br


N.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Let's schedule a Django sprint

[Nick]

On Sep 6, 12:51 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:

> like that. Things that people who haven't done much before can do in
> small steps and contribute useful stuff. Given that we've had a few
> people interested who have admitted to just starting out, we can make it
> easier for them.

That would be good.  Although I've been using Django for a while,
I've only really been nibbling around the edges of the codebase.

If there's simple stuff that folk like me can help with, I'd
certainly be interested in joining in.


Nick


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Admin and Related Models/Fields

[Nick Lane]

On Aug 26, 9:44 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> > That being said if you could point me to the patch (if it exists) so
> > that I can try to help get it going again in or just lend another pair
> > of eyes that would be really useful. If not, and if the admin isn't in
> > too much turmoil I can start implementing something like what Tai Lee
> > illustrated.
>
> Sorry, frustrated because didn't found any suitable patches. It
> appears to be very challenging problem.
>
> Found only two related, but seemingly not complete 
> patches:http://code.djangoproject.com/ticket/2874http://code.djangoproject.com/ticket/2076
>
> Obvious there's some more related tickets without any patches, but
> they are worthless.

Did you look at #3400? It implements following related fields in the
admin 'list_filter' option.

I did look at updating this patch again to support 'list_display' but
at first glance it wasn't as trivial as I had hoped so I just ended up
using something like your 'city_state()' method.

That being said, a fresh approach to this might be worthwhile.

Cheers,
Nick


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---