Re: Deferring "Sign the CLA"

2019-05-01 Thread Tobias McNulty
On Wed, May 1, 2019 at 8:56 AM Florian Apolloner 
wrote:

> On Saturday, April 27, 2019 at 7:26:58 PM UTC+2, Carlton Gibson wrote:
>>
>> Right now I just wanted to move it down the page.
>>
>
> By all means do so…
>

+1


> I vaguely remember talking to Jacob when I saw him last and his stance on
> it was that we either do not need the CLA at all anymore or something like
> docusign would be enough. For instance Ansible has this
> https://docs.ansible.com/ansible/latest/community/contributor_license_agreement.html
> and I am pretty sure Redhat had lawyers go over that…
>

This is great. Is there someone from the DSF on this list who would be
willing to consult with a DSF attorney to see if language like this (and no
signature requirement) would work?

Tobias

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


Re: Deferring "Sign the CLA"

2019-04-30 Thread Tobias McNulty
I'd be happy to try setting something up, but a quick search didn't turn up
any obvious choices.

In the absence of information to the contrary, I'd hazard a guess that we
still need the CLAs...

Tobias

On Sat, Apr 27, 2019, 1:26 PM Carlton Gibson 
wrote:

>
> On 27 Apr 2019, at 18:51, Florian Apolloner  wrote:
>
> I think the question is if we need those at all. This is something the DSF
> should be able to answer.
>
>
> Ah, you’ve preempted a later question. 
>
> Right now I just wanted to move it down the page.
>
> Maybe some online signing service would be good. (?)
> (Anyone think they could get us setup quickly?)
>
> I mentioned tying it into the Github workflow a while back, but that’s
> probably overkill.
> (We don’t have so many signings that an online service we link to wouldn’t
> be enough, is the thought.)
>
> I’ve asked Frank (DSF president) if the board can discuss whether we still
> need the CLA.
>
> C.
>
> --
> 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/F70B1E18-7FF7-4985-9906-46D5A4677C11%40gmail.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/CAMGFDKQh4Dtk43KWsYNgWP%3DespMw3X0%3Dod5he8%3D%3Ds9oPvP8X-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-19 Thread Tobias McNulty
FWIW, I like that we have high standards for concise and readable comments
with proper grammar, especially because I myself often need a little extra
push in that department. And I'm not easily convinced by the arguments that
sound a whole lot like "I've written the code and don't have time to clean
this up." In the thick of the moment it's easy to assume a solution will be
obvious to others reading the code, when in reality taking a few extra
minutes to clearly write down *why *something is the way it is (not to
mention making the code itself readable in the first place) will save
potentially hours of someone else's time later on. This is precisely what
code reviews are for; to make sure we're handing down well-written,
described, and documented code for those who come after us (including
perhaps ourselves, a year or two down the road). The benefit to us as
contributors is that it makes us stronger developers, and I think that
might get forgotten sometimes.

I've continued to follow along in this thread and remain fairly ambivalent
about Black. I see how it will simplify many things; on the other hand, I
like my multi-line lists formatted my way. (Not poking fun, I really do.)
That said, if Black will truly remove some significant hurdles, let's do
it, but we should remain clear-headed about the fact that it's not going to
remove from the equation what some may feel is nitpicking and others would
argue is a necessary part of maintaining our high standards.

Herman, if you haven't been scared away from this just yet, I might suggest
trying to summarize the discussion and your recommendation/proposal given
the reactions so far (could be a DEP <https://github.com/django/deps> but
doesn't have to be, IMO). I do feel there's a pragmatic solution in here
somewhere.

Best to all,
Tobias



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Fri, Apr 19, 2019 at 8:52 AM Tim Graham  wrote:

> I'm sorry for establishing some (foolish?) guidelines that discouraged
> some people from contributing. I didn't establish those guidelines merely
> to be pedantic, but perhaps I'm too much of a perfectionist at times.
>
> After GitHub allowed mergers to amend pull requests, I often made cosmetic
> adjustments myself to eliminate the trivial back and forth that some have
> lamented. I never blocked a merge merely for trivial cosmetic reasons.
>
> On Friday, April 19, 2019 at 3:25:24 AM UTC-4, Luke Plant wrote:
>>
>> Hi all,
>>
>> An alternative solution to the problem of nit-picky, formatting related
>> PR reviews is simple: *let's not do that*.
>>
>> We already have an automated code formatting enforcer, flake8. Let's
>> simply drop the requirement on fixing anything that flake8 doesn't pick up.
>> A committer can fix up style issues if they want to, but shouldn't make
>> anyone else do it. This would mean most of the stuff on our coding style
>> page
>> <https://docs.djangoproject.com/en/2.2/internals/contributing/writing-code/coding-style/>
>> should just be delete, or at least not enforced - by which I mean almost
>> anything that can't be enforced by a tool (such as isort, flake8, editors
>> via .editorconfig etc.), and has no non-local effects. (So consistent
>> naming of classes/functions *should* be enforced, because that affects
>> other people's ability to use the code).  Large parts of that page are just
>> duplicating of flake8/isort rules anyway. Honestly, does it kill us if
>> someone writes "we" in a code comment? And black couldn't help with some of
>> these things anyway. Let's just stop being code review jerks.
>>
>> I'm kind of ambivalent on black itself. Certainly there are cases where
>> it makes code less readable (a significant sin in my book) e.g. lists that
>> are better displayed vertically, as mentioned already, and there are cases
>> where it makes your diff larger than it needs to be (e.g. when it decides a
>> list is now too long and needs to be re-formatted vertically). If we adopt
>> black we'd have to live with those annoyances. Alternatively, we can live
>> with the annoyance that code formatting is not perfectly consistent and we
>> accept less than 'perfect' PR. But we should just live with those things:
>>
>>
>> *A* *foolish* *consistency* *is* *the* *hobgoblin** of little minds*
>>
>>
>> And if our consistency requirements are causing problems for people
>> attempting to contribute, they are foolish and should be dropped.
>>
>> My 2 ¢.
>>
>> Luke
>>
>>
>> On 18/04/2019 16:03, Jani Tiainen wrote:
>>
>> Well let me add my two cents here since I was also in the group in DCEU
>> that talked about the usage of black.
>>

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread Tobias McNulty
There are plenty of use cases when this behavior wouldn't be desired, such
as editing the same model object with 2+ different model forms. Such a
pattern might be more common when editing an existing object, but isn't out
of the question for creating new objects, either (think of a multi-step
form wizard).

Cheers,
Tobias

On Tue, Apr 16, 2019, 8:34 PM Will Gordon  wrote:

> In the same way that editable fields are forced to not be included in a
> ModelForm (
> https://github.com/django/django/blob/master/django/forms/models.py#L146),
> I would like to propose that "required" fields (`blank=False`) be forced to
> be included in a ModelForm.
>
> While I understand that a developer can force this inclusion themselves,
> but on a large project, it should not be necessary to always ensure that a
> Model and ModelForm are in sync.
>
> Since this is probably a non-trivial patch (
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#non-trivial-patches)
> I need to provide evidence that this has been discussed. As such, I'm open
> to any and all opinions!
>
> --
> 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/980d8112-d51c-4e88-a17f-5e9a4a3577d2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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


Re: Proposal to format Django using black

2019-04-14 Thread Tobias McNulty
On Sun, Apr 14, 2019 at 3:11 AM Nick Sarbicki 
wrote:

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

I constantly need to be reminded to shorten docstrings and comments (and
sometimes remove "We" from the beginning of such strings). Unfortunately
(though understandably), Black won't help with any of these issues, and
we'll still be left with the same back and forth about grammar, wrapping,
etc. in comments and docstrings. (Again, as of mid-2018 there is
the max-doc-length option for flake8 that could help with this somewhat,
but that change can be made independently.)

I'm not arguing against Black adoption, but I don't think it's going to
eliminate from the review process what may sometimes feel like inertia...

Tobias

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


Re: Proposal to format Django using black

2019-04-13 Thread Tobias McNulty
On Sat, Apr 13, 2019 at 11:35 AM Herman S  wrote:

> I've set up how this _could_ look depending on some configurables in Black:
>
> * Default config: https://github.com/hermansc/django/pull/1
> * Line length kept at 119: https://github.com/hermansc/django/pull/3
> * Line length kept at 119, no string normalization:
> https://github.com/hermansc/django/pull/2


Apologies, somehow I missed these links on the first read. Go here for an
overview of lines changed, don't use my numbers. :-)

Tobias

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


Re: Proposal to format Django using black

2019-04-13 Thread Tobias McNulty
On Sat, Apr 13, 2019 at 12:07 PM Florian Apolloner 
wrote:

> As expressed at Djangocon Europe, I am hugely in favor for adopting black.
>

A quick glance suggests this would result in ~20k lines changed (~27% of
non-whitespace, non-comment code lines) in django/ and ~58k lines changed
(~41%) in tests/ (with `--line-length=119`). After the initial pass to fix
everything `black -l 119 tests/ django/` takes only 2.3 seconds to run (!),
though I'm sure my OS had all the files cached at that point.

Without normalizing strings, the number of changed lines comes down to ~14k
(~19%) for django/ and ~23k (~16%) for tests/ (with
`--skip-string-normalization --line-length=119`).

I'm sure some people will see this as "a ton" and others "only that much?"
:-)

(My line counts are imperfect and approximate, and you'll likely get
somewhat different numbers if you try this yourself.)

If we choose to do this there are a few things to consider:
>
>  * Line-length, we probably want to stay at 119 I guess
>

Perhaps we could compromise and choose something in the middle, for the
reasons noted in the docs:
https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length

We should also consider adding max-doc-length for flake8 to our setup.cfg,
and/or forego the shorter requirement for comments/docstrings *if* we
shorten the maximum line length for code.

This section
<https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/>
in the docs will need updating if we hand this off to a 3rd-party formatter
(in particular the sentence, "Don’t limit lines of code to 79 characters if
it means the code looks significantly uglier or is harder to read." since
we'll no longer have the option of shortening lines to 79 characters
arbitrarily).

 * String normalization, I'd be in favor of following black defaults here,
> but I am open to be convinced otherwise
>

It'd be nice to minimize the diff, but I'd be fine either way. If we're
going to do it eventually, better to do so all at once.


>  * We will need to adjust the isort configuration (
> https://github.com/ambv/black/blob/master/README.md#how-black-wraps-lines
> )
>

+1

Overall, the main downside I see is the large, fairly useless changeset
this would create and the impact it would have, such as reduced utility of
`git blame` for some portion of the code for the foreseeable future and
interruption to all in-progress PRs. Problems that can be worked around,
sure, but it would be an interruption to ongoing work nonetheless.

One question: Would we want to update some/all code samples in the docs
with the same code style? I imagine that could be a fairly time-intensive
endeavor, unless someone's already found a way to automate the process. In
particular, Black's format for chaining method calls
<https://black.readthedocs.io/en/stable/the_black_code_style.html#call-chains>
differs from Django's preferred style
<https://docs.djangoproject.com/en/2.2/topics/db/queries/#chaining-filters>.
Applying this standard to the docs without discretion may lead to less
readable docs, IMO...on the other hand, it's odd to have code samples that
don't pass our own tests...

In any case, while this sounds like a non-trivial project with some
questions to work through yet, I too like not having to worry about code
formatting and don't have any real objections to this.

Cheers,



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: Use CDN for djangoproject.com

2019-04-12 Thread Tobias McNulty
Last week we had an average hit ratio of around 63%, including ~10 purges
that dropped the rate down temporarily before the cache rebuilt:
[image: Screenshot 2019-04-11 09.37.57.png]
In terms of bandwidth, we're averaging around 5 GB/day for docs and 10
GB/day for static. Giving static its own domain may actually be saving us a
good bit of bandwidth (previously each subdomain had its own /s/ prefix
from which an identical set of static files was served).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Sun, Mar 31, 2019 at 3:08 PM Tobias McNulty 
wrote:

> On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes  wrote:
>
>> I’m a stats nerd, and I think I’m not alone on this list in that respect,
>> would it be possible to share some more numbers after a week of usage? I
>> would be interested in the total bandwidth used/saved, the global
>> distribution of requests and the average requests per second. If I remember
>> correctly fastly has a fantastic live dashboard with all of this info.
>>
>
> For static, I think we'll end up using just under 300 GB a month, or about
> a quarter of the total bandwidth served by this particular server (which
> also handles most other djangoproject.com subdomains). I'll see if I can
> collect some slightly more interesting numbers after a week or two.
>
> I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate
>> these and forward on http 1.1 requests? Could you elaborate a bit?
>>
>
> HTTP/2 supports connection coalescing
> <https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/>,
> where the browser (with varying degrees of aggressiveness, depending on the
> manufacturer) may reuse existing connections for different subdomains. In
> our case, Fastly originally provisioned a wildcard SSL cert ('*.
> djangoproject.com'), so *we think* that some versions of Firefox were
> reusing HTTP/2 connections originally established for
> static.djangoproject.com for requests to www.djangoproject.com, *even
> though* there was no overlap in IPs for the two domains. In the browser
> (courtesy of Mariusz) it looked like this:
>
> [image: Screenshot_20190320_113825.png]
> Clicking on the cert icon showed the wildcard cert from Fastly, not our
> Let's Encrypt cert, as well. In other words, it appeared Firefox was
> ignoring DNS for www.djangoproject.com and assumed that it could send
> those requests to static.djangoproject.com instead, simply because the
> server responded with an SSL certificate that matched
> www.djangoproject.com. I.e., it appeared to be *even more aggressive* than
> described under "The Firefox way" in the link above.
>
> I find this explanation entirely dissatisfying (if not altogether
> frightening), so part of me hopes I've got it wrong. :-\
>
> In any case, after requesting that Fastly de-provision the wildcard cert
> and include only the specific domains we needed, the issue went away. There
> is an HTTP status code (421) that can be used to tell the browser it's made
> such an error, so I believe we also could have solved this by setting up a
> catchall service in Fastly to return HTTP 421 for any requests received on
> subdomains we weren't expecting. But avoiding the spurious requests to
> begin with seemed like a better solution, and provisioning certs only for
> the domains we need is cleaner to begin with and seems to have fixed the
> problem.
>
> I was never able to reproduce this in Firefox myself, but I did see
> evidence of it occurring insofar as we *also* started getting a very
> small number of requests to the '*docs*.djangoproject.com' service in
> Fastly after changing the DNS for '*static*.djangoproject.com.' Of
> course, no one would have noticed these because the requests returned
> successfully, but they should not have been going through Fastly (until the
> DNS was changed for 'docs', of course). Mariusz may be able to add
> something about the when/how he saw this; I do think it was fairly
> intermittent. Anyways, I'm pretty sure this would have gone undiagnosed for
> weeks if not months if he had not noticed and alerted us to the issue
> (causing all sorts of frustration and confusion in the meantime), so thank
> you again, Mariusz!
>
> Cheers,
> Tobias
>

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


Re: translation.E005 / Should LANGUAGES_BIDI be a strict subset of LANGUAGES?

2019-04-09 Thread Tobias McNulty
Having thought about this a little more, I may have found in answer to my
own question. :-)

The reasoning would seem to be that, by overriding LANGUAGES but not
LANGUAGES_BIDI, you risk introducing an inconsistency between the language
code *format* in these two settings (a la LANGUAGE_CODE and the original
ticket that got this started). If that's correct, that seems fair to me
(and worth keeping this check), along with an update to the docs to clarify
this dependency and why it exists.

Tobias

On Tue, Apr 9, 2019, 8:06 AM Adam Johnson  wrote:

> Other ideas:
>
>- Bypass the check in the case that LANGAUGES_BIDI is the same as the
>one in global_settings - probably not the best idea, but would stop all
>projects having to set LANGUAGES_BIDI = [] to avoid the check
>- Change startproject so that LANGUAGES_BIDI is set up as the empty
>list - removes some "included batteries" but helps users make a more
>informed choice?
>
>
> On Tue, 9 Apr 2019 at 12:27, Adam Johnson  wrote:
>
>> Hi Matthias,
>>
>> I can see why this is annoying. At least the resolution is easy by
>> setting LANGUAGES_BIDI = []. I do agree that it should be in the release
>> notes, although it's quite hard to miss a new system check's output when
>> upgrading.
>>
>> I see it was only at the last review of the PR (
>> https://github.com/django/django/pull/11060 ) that the check in question
>> was upgraded from warning W005 to E005. I can see why a warning would make
>> sense, but at the same time a warning is still a message to the user and
>> resolved the same way, either by setting LANGUAGES_BIDI or adding it to
>> SILENCED_SYSTEM_CHECKS.
>>
>> I think I'm against removing the check, but pro anything that can make it
>> easier for users such as yourself - perhaps something as simple as a
>> suggestion in the error message to set LANGUAGES_BIDI = [] if you're not
>> using RTL languages?
>>
>> Thanks,
>>
>> Adam
>>
>> On Tue, 9 Apr 2019 at 11:22, Matthias Kestenholz  wrote:
>>
>>> Hello everyone,
>>>
>>> The resolution of https://code.djangoproject.com/ticket/30241 in
>>> https://github.com/django/django/commit/4400d8296d268f5a8523cd02ddc33b12219b2535
>>> introduced a new and in my opinion backwards incompatible requirement
>>> through the system checks framework.
>>>
>>> Previously*, overriding LANGUAGES to restrict the list of available
>>> languages on a Django site worked. Now it's also necessary to override
>>> LANGUAGES_BIDI because there is a new system check (translation.E005) which
>>> verifies that there are no language codes in LANGUAGES_BIDI not in
>>> LANGUAGES as well.
>>>
>>> It is my strong opinion that enforcing this does not provide any
>>> benefits and has the downside of forcing almost everyone who overrides
>>> LANGUAGES to now add a new setting to their project to override
>>> LANGUAGES_BIDI as well with unclear benefits.
>>>
>>> Strictness is a good thing, but since LANGUAGES_BIDI is only ever used
>>> for membership checking (and never iterated over) I don't see the problem
>>> in keeping the default language codes from django/conf/global_settings.py
>>> in there even though some of those languages may not be available on a
>>> given installation anyway.
>>>
>>> The report in https://code.djangoproject.com/ticket/30342 was closed as
>>> wontfix that's why I'm writing to the list. Also, since system checks
>>> generally aren't mentioned in the release notes users will not be informed
>>> ahead of time about this change when reading the release notes.
>>>
>>> Anyone has any opinions to offer on this?
>>>
>>> Thanks,
>>> Matthias
>>>
>>> * At least as long as I'm using Django, probably for 11 years or
>>> something.
>>>
>>> --
>>> 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/CANvPqgAy_HytsvmnOpPtrCP_969QhoncJaPUe%3D6pN-VYWMVcjA%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Adam
>>
>
>
> --
> 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 

Re: translation.E005 / Should LANGUAGES_BIDI be a strict subset of LANGUAGES?

2019-04-09 Thread Tobias McNulty
I am curious, what is the reasoning behind disallowing LANGUAGES_BIDI from
containing languages not in LANGUAGES in the first place?

If as Matthias says it is never iterated over, I'm unclear what problems
this might cause, though I agree the fix is simple enough...

At least perhaps the last paragraph in the description for the
LANGUAGES_BIDI setting (that is currently identical to a paragraph in the
LANGUAGES description, "Generally, the default value should suffice. Only
set this setting if you want to restrict language selection to a subset of
the Django-provided languages.") could be modified to clarify this
reasoning and its relationship to LANGUAGES? (What exactly this would say
is not obvious to me at the moment...)

Tobias


On Tue, Apr 9, 2019, 7:28 AM Adam Johnson  wrote:

> Hi Matthias,
>
> I can see why this is annoying. At least the resolution is easy by setting
> LANGUAGES_BIDI = []. I do agree that it should be in the release notes,
> although it's quite hard to miss a new system check's output when upgrading.
>
> I see it was only at the last review of the PR (
> https://github.com/django/django/pull/11060 ) that the check in question
> was upgraded from warning W005 to E005. I can see why a warning would make
> sense, but at the same time a warning is still a message to the user and
> resolved the same way, either by setting LANGUAGES_BIDI or adding it to
> SILENCED_SYSTEM_CHECKS.
>
> I think I'm against removing the check, but pro anything that can make it
> easier for users such as yourself - perhaps something as simple as a
> suggestion in the error message to set LANGUAGES_BIDI = [] if you're not
> using RTL languages?
>
> Thanks,
>
> Adam
>
> On Tue, 9 Apr 2019 at 11:22, Matthias Kestenholz  wrote:
>
>> Hello everyone,
>>
>> The resolution of https://code.djangoproject.com/ticket/30241 in
>> https://github.com/django/django/commit/4400d8296d268f5a8523cd02ddc33b12219b2535
>> introduced a new and in my opinion backwards incompatible requirement
>> through the system checks framework.
>>
>> Previously*, overriding LANGUAGES to restrict the list of available
>> languages on a Django site worked. Now it's also necessary to override
>> LANGUAGES_BIDI because there is a new system check (translation.E005) which
>> verifies that there are no language codes in LANGUAGES_BIDI not in
>> LANGUAGES as well.
>>
>> It is my strong opinion that enforcing this does not provide any benefits
>> and has the downside of forcing almost everyone who overrides LANGUAGES to
>> now add a new setting to their project to override LANGUAGES_BIDI as well
>> with unclear benefits.
>>
>> Strictness is a good thing, but since LANGUAGES_BIDI is only ever used
>> for membership checking (and never iterated over) I don't see the problem
>> in keeping the default language codes from django/conf/global_settings.py
>> in there even though some of those languages may not be available on a
>> given installation anyway.
>>
>> The report in https://code.djangoproject.com/ticket/30342 was closed as
>> wontfix that's why I'm writing to the list. Also, since system checks
>> generally aren't mentioned in the release notes users will not be informed
>> ahead of time about this change when reading the release notes.
>>
>> Anyone has any opinions to offer on this?
>>
>> Thanks,
>> Matthias
>>
>> * At least as long as I'm using Django, probably for 11 years or
>> something.
>>
>> --
>> 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/CANvPqgAy_HytsvmnOpPtrCP_969QhoncJaPUe%3D6pN-VYWMVcjA%40mail.gmail.com
>> 
>> .
>> 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/CAMyDDM25B-y3D6iHuROz0rfDPzHp8qnHYhDw2inHNOawEDerGA%40mail.gmail.com
> 

Re: Use CDN for djangoproject.com

2019-03-31 Thread Tobias McNulty
On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes  wrote:

> I’m a stats nerd, and I think I’m not alone on this list in that respect,
> would it be possible to share some more numbers after a week of usage? I
> would be interested in the total bandwidth used/saved, the global
> distribution of requests and the average requests per second. If I remember
> correctly fastly has a fantastic live dashboard with all of this info.
>

For static, I think we'll end up using just under 300 GB a month, or about
a quarter of the total bandwidth served by this particular server (which
also handles most other djangoproject.com subdomains). I'll see if I can
collect some slightly more interesting numbers after a week or two.

I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate these
> and forward on http 1.1 requests? Could you elaborate a bit?
>

HTTP/2 supports connection coalescing
,
where the browser (with varying degrees of aggressiveness, depending on the
manufacturer) may reuse existing connections for different subdomains. In
our case, Fastly originally provisioned a wildcard SSL cert ('*.
djangoproject.com'), so *we think* that some versions of Firefox were
reusing HTTP/2 connections originally established for
static.djangoproject.com for requests to www.djangoproject.com, *even
though* there was no overlap in IPs for the two domains. In the browser
(courtesy of Mariusz) it looked like this:

[image: Screenshot_20190320_113825.png]
Clicking on the cert icon showed the wildcard cert from Fastly, not our
Let's Encrypt cert, as well. In other words, it appeared Firefox was
ignoring DNS for www.djangoproject.com and assumed that it could send those
requests to static.djangoproject.com instead, simply because the server
responded with an SSL certificate that matched www.djangoproject.com. I.e.,
it appeared to be *even more aggressive* than described under "The Firefox
way" in the link above.

I find this explanation entirely dissatisfying (if not altogether
frightening), so part of me hopes I've got it wrong. :-\

In any case, after requesting that Fastly de-provision the wildcard cert
and include only the specific domains we needed, the issue went away. There
is an HTTP status code (421) that can be used to tell the browser it's made
such an error, so I believe we also could have solved this by setting up a
catchall service in Fastly to return HTTP 421 for any requests received on
subdomains we weren't expecting. But avoiding the spurious requests to
begin with seemed like a better solution, and provisioning certs only for
the domains we need is cleaner to begin with and seems to have fixed the
problem.

I was never able to reproduce this in Firefox myself, but I did see
evidence of it occurring insofar as we *also* started getting a very small
number of requests to the '*docs*.djangoproject.com' service in Fastly
after changing the DNS for '*static*.djangoproject.com.' Of course, no one
would have noticed these because the requests returned successfully, but
they should not have been going through Fastly (until the DNS was changed
for 'docs', of course). Mariusz may be able to add something about the
when/how he saw this; I do think it was fairly intermittent. Anyways, I'm
pretty sure this would have gone undiagnosed for weeks if not months if he
had not noticed and alerted us to the issue (causing all sorts of
frustration and confusion in the meantime), so thank you again, Mariusz!

Cheers,
Tobias

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


Re: Proposal to re-open #27017 (updating only dirty fields in save())

2019-03-14 Thread Tobias McNulty
I want to qualify this by saying that personally I've always thought of
(and likely will continue to think of) model objects as a snapshot of
what's in the database, and use the more explicit queryset.update() when
that snapshot is NOT what I want to save back to the database. So I may be
somewhat biased against this idea to start with. :)

That said, as Simon mentioned, don't we already effectively support this?

>>> from django.db import connection
>>> from food.models import Food
>>> f = Food.objects.only('pk').first()
>>> f.name = 'foo'
>>> f.save()
>>> connection.queries
[{'sql': 'SELECT "food_food"."id" FROM "food_food" ORDER BY
"food_food"."food_code" ASC LIMIT 1', 'time': '0.003'}, {'sql': 'UPDATE
"food_food" SET "name" = \'foo\' WHERE "food_food"."id" = 5542', 'time':
'0.010'}]

(For the record, this model has many more fields.)

Of course, if you need other fields to calculate whatever needs to be saved
back to the DB, you should add them to .only(). But in any case it protects
you from silently losing data by forgetting to include them in
update_fields (at the risk of generating extra queries if you forget to
include them in .only(), but at least you can see those and optimize them
away).

Consider me relatively ambivalent about the idea...perhaps +0 on a Meta- or
save()-level implementation and -0 on a settings-based approach (given the
red flags already raised).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Thu, Mar 14, 2019 at 11:20 AM charettes  wrote:

> +1 to what Adam said. Turning this feature on by default would be
> certainly cause a lot of bugs in application
> expecting a "coherent state" to be persisted on .save().
>
> That would effectively make most of the Form.clean(), Model.clean() and
> DRF serializer logic in charge of
> validating a field value based on another field value useless as another
> process could race to update the
> row to another state unless you've defined database level constraints as
> well.
>
> > ... performance *benefits* of executing smaller UPDATE statements that
> write fewer columns.
>
> FWIW the current .save() logic ignores deferred fields so it's currently
> possible to work around the
> rare cases where updating a large column causes a slow UPDATE query.
>
> > I'm not sure if a global setting is a good idea. Code in third-party
> apps would need to work with both configurations?
>
> Agreed, it feels like a Meta or .save() option would be more appropriate,
> we already have a select_on_save
> option for example which is even more specific than this use case.
>
> At this point I'm not convinced that it's something Django should
> implement internally as it is possible to implement
> an abstract model in charge of tracking "dirty" fields and overriding
> `.save` to make `update_fields` default to it
> as demonstrated by the few existing third-party solutions.
>
> Simon
>
> Le jeudi 14 mars 2019 09:49:59 UTC-4, Tim Graham a écrit :
>>
>> I'm not sure if a global setting is a good idea. Code in third-party apps
>> would need to work with both configurations?
>>
>> On Thursday, March 14, 2019 at 8:39:05 AM UTC-4, Daniel Tao wrote:
>>>
>>> I agree with this:
>>>
>>> > Therefore it seems like it would be a breaking change which is hard to
>>> communicate to users, a complicated situation.
>>>
>>> This is why I'm recommending that this behavior be opt-in via a Django
>>> setting such as SAVE_UPDATE_DIRTY_FIELDS_ONLY. Application developers
>>> would then need to make a determination for themselves whether or not to
>>> enable it.
>>>
>>> Adam is right to point out an edge case where this behavior could lead
>>> to subtle bugs. Not surprisingly, it's related to concurrency (which is
>>> where subtle bugs tend to live)! In response, I would point out that the
>>> whole point of this proposal is to address a *different* edge case,
>>> also related to concurrency, which I personally believe is more common,
>>> though it's admittedly hard to know without a lot of empirical data.
>>> (Actually it's also present in the scenario Adam describes, and he
>>> addresses this: "Sure there's a race condition and the results of either
>>> process 1 or 2 can be lost.")
>>>
>>> From the perspective of an application developer, if this functionality
>>> were available to me, I'd want to look at the code and ask myself this
>>> question: which is more work?
>>>
>>>- Are there

Re: Support for unittest -k option

2019-03-11 Thread Tobias McNulty
Agreed it's probably better to make the switch now, and I'd be fine without
a replacement shorthand alternative for --keepdb.

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Mar 11, 2019 at 8:19 AM Carlton Gibson 
wrote:

> Thanks François,
>
> Just on this, my thought is that if we don't follow `unittest` in changing
> `-k` for this, we have a steady trickle of confusion forever-more.
> I'd rather avoid that.
>
> C.
>
> On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:
>>
>> Hi Django Devs,
>>
>> https://code.djangoproject.com/ticket/30245 suggests supporting Python
>> unittest `-k` option, to selectively run tests matching a keyword.
>>
>> Currently, `-k` is the shorthand for `--keepdb` in Django.
>> A `--filter` flag was suggested to preserve backward compatibility.
>> Carlton suggested removing the `-k` option from `--keepdb` and reusing
>> it for unittest `-k`. That would follow unittest more closely, reduce
>> user confusion and ease maintenance.
>>
>> What do you think is best? Do you see other options?
>>
>> If re-taking the `-k` option for unittest `-k`, should a new shorthand
>> be introduced for `--keepdb`?
>>
>> Thanks for your time,
>> François
>>
> --
> 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/c54e52d2-012a-4852-9375-be37add55945%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c54e52d2-012a-4852-9375-be37add55945%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/CAMGFDKS1GCE3U824FZxMnzJTdZrq_9uuT60jiVHv%2BM4JR1%3D5%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Use CDN for djangoproject.com

2019-03-11 Thread Tobias McNulty
Hi all,

These changes have been deployed (though we're not yet using a CDN for the
primary domain, docs.djangoproject.com, so you shouldn't notice a change).

The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/) will
now cache docs pages for up to a week, and the hourly docs rebuilds will
trigger a cache purge of (a) nothing if there have been no changes in the
last hour, (b) just the dev docs if that's all that's changed or (c) the
entire docs site if a release branch has changed. I've tested this a few
times and everything seems to be working as it should, but please let me
know if you see anything out of order.

Currently we're waiting on the DSF/Fastly contract to be executed. Once
that's done I think we'll be ready to move static.djangoproject.com and
docs.djangoproject.com to Fastly.

I did set up a CloudFront distribution for these domains as well, but given
Fastly will give us the bandwidth for free we're having a hard time
justifying using CloudFront instead. Of course, if anyone has a connection
to $2000+ a year or so in AWS credits for the foreseeable future, let me
know. :-)

Finally, in preparation for the switch, I set up a status page (
https://docs-status.djangoproject.com) that, at the time I wrote this
email, at least, shows the following average response times to the docs
site from around the world:

   - Mumbai: 1968 ms
   - Singapore: 1895 ms
   - Sydney: 2015 ms
   - Tokyo: 1490 ms
   - Canada (Central): 224 ms
   - Ireland: 705 ms
   - London: 525 ms
   - Sao Paulo: 911 ms
   - US East (N. Virginia): 149 ms
   - US West (Oregon): 721 ms

You can click on an individual region to see the variability over time. I'm
on the east coast in the US so I don't have a good way to confirm or deny
most of these. They are HTTPS checks, and I believe the numbers represent
the time to connect and retrieve the page content (for
https://docs.djangoproject.com/en/2.1/).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner 
wrote:

> Hi Tobias,
>
> I think a cache of something like a day will most certainly not hurt
> anyone. If the need arises we can still manually purge the cache as needed.
>
> Cheers,
> Florian
>
> On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
>>
>> Hi all,
>>
>> An implementation question has come up regarding cache lifetime (see this
>> PR <https://github.com/django/djangoproject.com/pull/870>). Right now,
>> the whole site (including docs) has the site-wide Django cache enabled
>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45>,
>> with a timeout of 5 minutes
>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27>.
>> A couple docs views (search_suggestions
>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250>
>> and search_description
>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274>)
>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>
>> Once released, the vast majority of Django docs won't change much, except
>> for the release notes section and any (likely minor) related updates to the
>> docs themselves. To get the most benefit out of a CDN, it would obviously
>> be desirable to set the timeout to something greater than 5 minutes.
>>
>> At the same time, there are moments when a quick update to the docs *is*
>> desired, and waiting an hour or more for any cached pages to expire may
>> cause significant confusion, for example, in conjunction with a security
>> release for which stubbed (non-final) release notes may have already been
>> pushed out and cached.
>>
>> I see two main options at this point (which could even be combined):
>>
>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>> any time there's a docs build that has changes. It would be pretty easy to
>> piggyback off of the existing business logic for avoiding a rebuild
>> <https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93>
>> if the git checkout hasn't changed (in the update_docs management command).
>> 2) Pick subsections of the docs (e.g., for anything matching
>> '///releases/*' and perhaps the development docs) that would
>> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
>> requiring this special treatment would get a longer timeout, perhaps
>> somewhere between 1 and 24 hours.
>>
>> So, some questions for the list:
>>
>> * Are there sections of the docs besides '///releases/'
>> 

Re: GSoC 2019 Update

2019-03-09 Thread Tobias McNulty
On Thu, Mar 7, 2019 at 6:22 AM Carlton Gibson 
wrote:

> For the *ORM*, I think the cross-DB JSONField would be a great project.
> Florian worried it was too small in scope, but if it existed by the end of
> the summer, I would call that a success.
>
+1 -- and I'd rather a project be too small than too large (and go
unfinished). If it goes that quickly I'm sure we/they can always find more
to do, as your open tickets graph suggests. :) Perhaps a good proposal
would be to start with the cross-DB JSONField and then move to ORM tickets
X, Y, Z *if* the first is merged in time?

Cheers,



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: De-assigning "Easy pickings" tickets

2019-03-08 Thread Tobias McNulty
Also generally in favor. Is there a bot for such a thing? It would be nice
to get a reminder a week or two *before* the unassign happens, either to
prompt an update OR an early self-unassign (if the person is not in fact
working on the ticket anymore and just didn't remember it was still
assigned to them).

Tobias

On Fri, Mar 8, 2019, 3:22 PM Markus Holtermann 
wrote:

> Hi Carlton,
>
> my only question would be why you picked 2 months over 1 or 3. Generally
> in favor. I think de-assigning somebody after $time of inactivity on a
> ticket is fair, regardless of the complexity of the ticket.
>
> /Markus
>
> On Fri, Mar 8, 2019, at 8:30 PM, Carlton Gibson wrote:
> > Hi all.
> >
> > We don't have many Easy Pickings tickets, they're all assigned, and get
> > assigned quickly, but don't often get closed.
> >
> > Looking at the current batch...
> >
> >
> https://code.djangoproject.com/query?status=assigned=new=1=id=status=changetime=1=changetime
> >
> > ... I'd like to suggest that after 2 months we de-assign them, so they
> > can get picked up by people looking, who are likely not
> > willing/able/whatever to take over an assigned ticket themselves.
> >
> > Any thoughts/objections to that as a policy?
> >
> > 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 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/7bb67aa2-c898-4b97-a43a-eba38c00e00e%40googlegroups.com
> <
> https://groups.google.com/d/msgid/django-developers/7bb67aa2-c898-4b97-a43a-eba38c00e00e%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/8c599482-9c8e-4335-a5ff-7ffac96e94f8%40www.fastmail.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/CAMGFDKQbnRa_gaNjEdGyHyjXpAe0%2BA1qFo_JNfWpjARh6X%2BPrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Use CDN for djangoproject.com

2019-02-24 Thread Tobias McNulty
Tom,

That's great! Thanks for the feedback.

I've updated the PR <https://github.com/django/djangoproject.com/pull/870>
with something along the lines of what you suggested (along with the
corresponding configuration in Fastly).

Take a look and let me know what you think.

Cheers,
Tobias



On Sun, Feb 24, 2019 at 10:40 AM Tom Forbes  wrote:

> Awesome work! For my location (Lisbon, Portugal) it takes about 130ms to
> retrieve the HTML for a docs page (
> https://django-docs.global.ssl.fastly.net/en/2.1/intro/reusable-apps/ to
> be specific). The same page on docs.djangoproject.com responds in
> 800–900ms.
>
>
>
>
> On 24 February 2019 at 14:35:55, Tobias McNulty (tob...@caktusgroup.com)
> wrote:
>
> Hi Tom,
>
> Thanks for your message. I think we'll end up with Fastly since it would
> be free, but I'm waiting to see their sponsorship contract. CloudFront
> would work too but I don't know of any such open source sponsorship options
> with AWS.
>
> I will say wildcard purging looks a bit simpler in CloudFront, but your
> idea purging the whole cache only for non-dev builds could work (provided
> we have a lower cache timeout or a single wildcard purge condition set up
> for the dev builds, I guess).
>
> Feel free to test and post any feedback about Fastly prior to the
> potential transition here:
> https://django-docs.global.ssl.fastly.net/en/2.1/ (this is set up on a
> free dev account, so no custom SSL)
>
> For the sake of comparison I'm working on getting a distribution set up
> for CloudFront too, but it won't be so simple to test (without a DNS or
> server configuration change) since I don't think CloudFront supports
> passing a custom Host header to the origin like Fastly does (i.e., you'll
> probably need to edit /etc/hosts).
>
> Cheers,
> Tobias
>
>
> On Sat, Feb 23, 2019, 7:15 PM Tom Forbes  wrote:
>
>> Sorry, I did not completely grok your message. I would be in favour of
>> just invalidating the whole cache if needed, it seems the simplest
>> solution. Invalidating most of the cache on every non-dev deploy would also
>> be OK I think.
>>
>> On Sun, 24 Feb 2019, 00:10 Tom Forbes,  wrote:
>>
>>> Which CDN are we going to use? Fastly has awesome sub 100ms global
>>> invalidation which we can trigger on every deploy, and cloudflare has
>>> something similar.
>>>
>>> On Sun, 24 Feb 2019, 00:00 Tobias McNulty, 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> An implementation question has come up regarding cache lifetime (see this
>>>> PR <https://github.com/django/djangoproject.com/pull/870>). Right now,
>>>> the whole site (including docs) has the site-wide Django cache enabled
>>>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45>,
>>>> with a timeout of 5 minutes
>>>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27>.
>>>> A couple docs views (search_suggestions
>>>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250>
>>>> and search_description
>>>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274>)
>>>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>>>
>>>> Once released, the vast majority of Django docs won't change much,
>>>> except for the release notes section and any (likely minor) related updates
>>>> to the docs themselves. To get the most benefit out of a CDN, it would
>>>> obviously be desirable to set the timeout to something greater than 5
>>>> minutes.
>>>>
>>>> At the same time, there are moments when a quick update to the docs
>>>> *is* desired, and waiting an hour or more for any cached pages to
>>>> expire may cause significant confusion, for example, in conjunction with a
>>>> security release for which stubbed (non-final) release notes may have
>>>> already been pushed out and cached.
>>>>
>>>> I see two main options at this point (which could even be combined):
>>>>
>>>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>>>> any time there's a docs build that has changes. It would be pretty easy to
>>>> piggyback off of the existing business logic for avoiding a rebuild
>>>> <https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93>
>>>> if the git checkout hasn't changed (in the update_do

Re: Use CDN for djangoproject.com

2019-02-24 Thread Tobias McNulty
Hi Tom,

Thanks for your message. I think we'll end up with Fastly since it would be
free, but I'm waiting to see their sponsorship contract. CloudFront would
work too but I don't know of any such open source sponsorship options with
AWS.

I will say wildcard purging looks a bit simpler in CloudFront, but your
idea purging the whole cache only for non-dev builds could work (provided
we have a lower cache timeout or a single wildcard purge condition set up
for the dev builds, I guess).

Feel free to test and post any feedback about Fastly prior to the potential
transition here: https://django-docs.global.ssl.fastly.net/en/2.1/ (this is
set up on a free dev account, so no custom SSL)

For the sake of comparison I'm working on getting a distribution set up for
CloudFront too, but it won't be so simple to test (without a DNS or server
configuration change) since I don't think CloudFront supports passing a
custom Host header to the origin like Fastly does (i.e., you'll probably
need to edit /etc/hosts).

Cheers,
Tobias


On Sat, Feb 23, 2019, 7:15 PM Tom Forbes  wrote:

> Sorry, I did not completely grok your message. I would be in favour of
> just invalidating the whole cache if needed, it seems the simplest
> solution. Invalidating most of the cache on every non-dev deploy would also
> be OK I think.
>
> On Sun, 24 Feb 2019, 00:10 Tom Forbes,  wrote:
>
>> Which CDN are we going to use? Fastly has awesome sub 100ms global
>> invalidation which we can trigger on every deploy, and cloudflare has
>> something similar.
>>
>> On Sun, 24 Feb 2019, 00:00 Tobias McNulty, 
>> wrote:
>>
>>> Hi all,
>>>
>>> An implementation question has come up regarding cache lifetime (see this
>>> PR <https://github.com/django/djangoproject.com/pull/870>). Right now,
>>> the whole site (including docs) has the site-wide Django cache enabled
>>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45>,
>>> with a timeout of 5 minutes
>>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27>.
>>> A couple docs views (search_suggestions
>>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250>
>>> and search_description
>>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274>)
>>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>>
>>> Once released, the vast majority of Django docs won't change much,
>>> except for the release notes section and any (likely minor) related updates
>>> to the docs themselves. To get the most benefit out of a CDN, it would
>>> obviously be desirable to set the timeout to something greater than 5
>>> minutes.
>>>
>>> At the same time, there are moments when a quick update to the docs *is*
>>> desired, and waiting an hour or more for any cached pages to expire may
>>> cause significant confusion, for example, in conjunction with a security
>>> release for which stubbed (non-final) release notes may have already been
>>> pushed out and cached.
>>>
>>> I see two main options at this point (which could even be combined):
>>>
>>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>>> any time there's a docs build that has changes. It would be pretty easy to
>>> piggyback off of the existing business logic for avoiding a rebuild
>>> <https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93>
>>> if the git checkout hasn't changed (in the update_docs management command).
>>> 2) Pick subsections of the docs (e.g., for anything matching
>>> '///releases/*' and perhaps the development docs) that would
>>> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
>>> requiring this special treatment would get a longer timeout, perhaps
>>> somewhere between 1 and 24 hours.
>>>
>>> So, some questions for the list:
>>>
>>> * Are there sections of the docs besides '///releases/'
>>> and '//dev/' that might update frequently and merit some combination
>>> of invalidation and/or a shorter cache time? And what's a good cache
>>> timeout for such pages?
>>> * How long are we comfortable waiting for *other* (not frequently
>>> updated) pages to timeout, in the event they do change?
>>>
>>> Tobias
>>>
>>> On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty 
>>> wrote:
>>>
>>>> Thanks for sharing the results.
>>>

Re: Use CDN for djangoproject.com

2019-02-23 Thread Tobias McNulty
Hi all,

An implementation question has come up regarding cache lifetime (see this PR
<https://github.com/django/djangoproject.com/pull/870>). Right now, the
whole site (including docs) has the site-wide Django cache enabled
<https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45>,
with a timeout of 5 minutes
<https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27>.
A couple docs views (search_suggestions
<https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250>
and search_description
<https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274>)
views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except
for the release notes section and any (likely minor) related updates to the
docs themselves. To get the most benefit out of a CDN, it would obviously
be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs *is*
desired, and waiting an hour or more for any cached pages to expire may
cause significant confusion, for example, in conjunction with a security
release for which stubbed (non-final) release notes may have already been
pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any
time there's a docs build that has changes. It would be pretty easy to
piggyback off of the existing business logic for avoiding a rebuild
<https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93>
if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching
'///releases/*' and perhaps the development docs) that would
keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
requiring this special treatment would get a longer timeout, perhaps
somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '///releases/' and
'//dev/' that might update frequently and merit some combination of
invalidation and/or a shorter cache time? And what's a good cache timeout
for such pages?
* How long are we comfortable waiting for *other* (not frequently updated)
pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty 
wrote:

> Thanks for sharing the results.
>
> I did manage to get a domain set up with working SSL, in case you want to
> use it: https://django-docs.global.ssl.fastly.net/en/2.1/
>
> Tobias
>
> On Thu, Feb 14, 2019, 11:49 PM Cheng C 
>> Thanks for the test site, Tobias.
>>
>> Tested from Melbourne, Australia:
>>
>> https://docs.djangoproject.com/en/2.1/
>> Average Ping: 268ms
>>  Browser: 22 requests, 238KB transferred, Finish: 2.72s,
>> DOMContentLoaded: 1.37s, Load: 1.68s
>>
>> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
>> Average Ping: 28ms
>>  Browser: 22 requests, 240KB transferred, Finish: 947ms,
>> DOMContentLoaded: 627ms, Load: 910ms
>>
>> Tested on Chrome with "Disable cache" checked, and no render issue was
>> found.
>>
>> On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
>>>
>>> Adam, is there another provider you would recommend instead, that does
>>> not require changing DNS providers? FWIW, python.org does in fact use
>>> Fastly:
>>>
>>> $ host www.python.org
>>> www.python.org is an alias for dualstack.python.map.fastly.net.
>>> dualstack.python.map.fastly.net has address 151.101.248.223
>>> dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223
>>>
>>> Fastly did write back to say they're happy to help, though there's a
>>> contract which I guess the DSF would need to review and sign, if it's
>>> acceptable.
>>>
>>> In the meantime, feel free to give this a try and let me know if you see
>>> any issues:
>>> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for
>>> permanent use, obviously; you'll get a cert warning, and some pages will
>>> redirect you back to https://docs.djangoproject.com.)
>>>
>>> To keep this thread from getting too noisy, you can find me (tobias1) in
>>> #django-dev on FreeNode.
>>>
>>> Cheers,
>>> Tobias
>>>
>>> On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:
>>>
>>>> I have not had great experience with Fastly in the past and would avoid
>>>&g

Re: Use CDN for djangoproject.com

2019-02-15 Thread Tobias McNulty
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to
use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C  Thanks for the test site, Tobias.
>
> Tested from Melbourne, Australia:
>
> https://docs.djangoproject.com/en/2.1/
> Average Ping: 268ms
>  Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded:
> 1.37s, Load: 1.68s
>
> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
> Average Ping: 28ms
>  Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded:
> 627ms, Load: 910ms
>
> Tested on Chrome with "Disable cache" checked, and no render issue was
> found.
>
> On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
>>
>> Adam, is there another provider you would recommend instead, that does
>> not require changing DNS providers? FWIW, python.org does in fact use
>> Fastly:
>>
>> $ host www.python.org
>> www.python.org is an alias for dualstack.python.map.fastly.net.
>> dualstack.python.map.fastly.net has address 151.101.248.223
>> dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223
>>
>> Fastly did write back to say they're happy to help, though there's a
>> contract which I guess the DSF would need to review and sign, if it's
>> acceptable.
>>
>> In the meantime, feel free to give this a try and let me know if you see
>> any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
>> (Not for permanent use, obviously; you'll get a cert warning, and some
>> pages will redirect you back to https://docs.djangoproject.com.)
>>
>> To keep this thread from getting too noisy, you can find me (tobias1) in
>> #django-dev on FreeNode.
>>
>> Cheers,
>> Tobias
>>
>> On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:
>>
>>> I have not had great experience with Fastly in the past and would avoid
>>> them. They run an old fork of Varnish which is not fun to configure.
>>>
>>> On Thu, 14 Feb 2019 at 11:16, Josh Smeaton  wrote:
>>>
>>>> Cloudflare have many SSL options, including fully encrypted and
>>>> authenticated comms all the way through (terminate and reconnect).
>>>> Typically done by having a “hidden” origin domain that also hosts a
>>>> certificate. I’m unsure if it’s possible to have both origin and front
>>>> hosting the same name so that DNS alone can decide to hit cdn or origin.
>>>>
>>>> Anyway, it seems weird to me to dismiss a CDN offhand “because
>>>> security”. Especially considering the size of the providers and the
>>>> expertise their teams have.
>>>>
>>>> Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS”
>>>> providers. I would probably go as far to say that putting a CDN in front of
>>>> both the docs and the release packages would likely be a net improvement in
>>>> security for users.
>>>>
>>>> On Thu, 14 Feb 2019 at 21:58, Tom Forbes  wrote:
>>>>
>>>>> That makes sense, but in this case we are only talking about
>>>>> potentially yielding control of the docs subdomain which is not used to
>>>>> serve sensitive build artefacts?
>>>>>
>>>>> Another option is fastly.com, who support other large open source
>>>>> projects for free. They essentially give you geographically distributed
>>>>> HAProxy instances and you have a lot more control over them. I believe
>>>>> several large Linux distributions use them to serve cached apt packages.
>>>>>
>>>>> Regarding TLS termination, unfortunately any CDN we use will likely
>>>>> need to do this for the whole domain to get any benefit. The Django docs
>>>>> are text/html heavy with very few, if any, images. So the real speed
>>>>> benefit will have to come from serving that, which requires TLS 
>>>>> termination
>>>>> (and therefore interception) at their end.
>>>>>
>>>>> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <
>>>>> in...@markusholtermann.eu> wrote:
>>>>>
>>>>>> Hi all
>>>>>>
>>>>>> to elaborate on what Tobias said: we deliberately have the
>>>>>> infrastructure spread across multiple service providers: DNS registry,
>>>>>> nameservers, hosting, TLS certificate authority, … None of them have 
&g

Re: Use CDN for djangoproject.com

2019-02-14 Thread Tobias McNulty
Adam, is there another provider you would recommend instead, that does not
require changing DNS providers? FWIW, python.org does in fact use Fastly:

$ host www.python.org
www.python.org is an alias for dualstack.python.map.fastly.net.
dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a
contract which I guess the DSF would need to review and sign, if it's
acceptable.

In the meantime, feel free to give this a try and let me know if you see
any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
(Not for permanent use, obviously; you'll get a cert warning, and some
pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in
#django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:

> I have not had great experience with Fastly in the past and would avoid
> them. They run an old fork of Varnish which is not fun to configure.
>
> On Thu, 14 Feb 2019 at 11:16, Josh Smeaton  wrote:
>
>> Cloudflare have many SSL options, including fully encrypted and
>> authenticated comms all the way through (terminate and reconnect).
>> Typically done by having a “hidden” origin domain that also hosts a
>> certificate. I’m unsure if it’s possible to have both origin and front
>> hosting the same name so that DNS alone can decide to hit cdn or origin.
>>
>> Anyway, it seems weird to me to dismiss a CDN offhand “because security”.
>> Especially considering the size of the providers and the expertise their
>> teams have.
>>
>> Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS”
>> providers. I would probably go as far to say that putting a CDN in front of
>> both the docs and the release packages would likely be a net improvement in
>> security for users.
>>
>> On Thu, 14 Feb 2019 at 21:58, Tom Forbes  wrote:
>>
>>> That makes sense, but in this case we are only talking about potentially
>>> yielding control of the docs subdomain which is not used to serve sensitive
>>> build artefacts?
>>>
>>> Another option is fastly.com, who support other large open source
>>> projects for free. They essentially give you geographically distributed
>>> HAProxy instances and you have a lot more control over them. I believe
>>> several large Linux distributions use them to serve cached apt packages.
>>>
>>> Regarding TLS termination, unfortunately any CDN we use will likely need
>>> to do this for the whole domain to get any benefit. The Django docs are
>>> text/html heavy with very few, if any, images. So the real speed benefit
>>> will have to come from serving that, which requires TLS termination (and
>>> therefore interception) at their end.
>>>
>>> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
>>> wrote:
>>>
>>>> Hi all
>>>>
>>>> to elaborate on what Tobias said: we deliberately have the
>>>> infrastructure spread across multiple service providers: DNS registry,
>>>> nameservers, hosting, TLS certificate authority, … None of them have access
>>>> to everything. The reason is that we offer the download of the release
>>>> artifacts from the djangoproject.com website. And we would like to
>>>> ensure that the TLS termination happens by us and not some random service
>>>> provider. After all, Django is used by enterprises that do have some
>>>> restrictions on where you're allowed to download software from.
>>>>
>>>> By handing over DNS to some CDN provider, we loose the ability to
>>>> ensure that happens.
>>>>
>>>> That said, if there's a CDN that works as a reverse proxy and doesn't
>>>> require us to hand over control of DNS, I guess we could be interested in
>>>> moving the docs behind that.
>>>>
>>>> /Markus
>>>>
>>>> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
>>>> > For me it's the trust factor (allowing someone else to decrypt and
>>>> > re-encrypt all our data). This may be less of an issue for the docs
>>>> > site, *if* we don't have to assign DNS authority for the whole domain
>>>> > to the CDN provider.
>>>> >
>>>> > Tobias
>>>> >
>>>> >
>>>> > On Wed, Feb 13, 2019, 7:47 PM Kye Russell >>> > > I’ve been hearing that there are other CDN providers that offer a
&g

Re: Use CDN for djangoproject.com

2019-02-14 Thread Tobias McNulty
Fastly could be a good fit. I've reached out to see if they'd be willing to
provide a free account. If anyone on this list works at Fastly or knows
someone who does, feel free to email/introduce me off list, too.

Tobias

On Thu, Feb 14, 2019, 5:58 AM Tom Forbes  That makes sense, but in this case we are only talking about potentially
> yielding control of the docs subdomain which is not used to serve sensitive
> build artefacts?
>
> Another option is fastly.com, who support other large open source
> projects for free. They essentially give you geographically distributed
> HAProxy instances and you have a lot more control over them. I believe
> several large Linux distributions use them to serve cached apt packages.
>
> Regarding TLS termination, unfortunately any CDN we use will likely need
> to do this for the whole domain to get any benefit. The Django docs are
> text/html heavy with very few, if any, images. So the real speed benefit
> will have to come from serving that, which requires TLS termination (and
> therefore interception) at their end.
>
> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
> wrote:
>
>> Hi all
>>
>> to elaborate on what Tobias said: we deliberately have the infrastructure
>> spread across multiple service providers: DNS registry, nameservers,
>> hosting, TLS certificate authority, … None of them have access to
>> everything. The reason is that we offer the download of the release
>> artifacts from the djangoproject.com website. And we would like to
>> ensure that the TLS termination happens by us and not some random service
>> provider. After all, Django is used by enterprises that do have some
>> restrictions on where you're allowed to download software from.
>>
>> By handing over DNS to some CDN provider, we loose the ability to ensure
>> that happens.
>>
>> That said, if there's a CDN that works as a reverse proxy and doesn't
>> require us to hand over control of DNS, I guess we could be interested in
>> moving the docs behind that.
>>
>> /Markus
>>
>> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
>> > For me it's the trust factor (allowing someone else to decrypt and
>> > re-encrypt all our data). This may be less of an issue for the docs
>> > site, *if* we don't have to assign DNS authority for the whole domain
>> > to the CDN provider.
>> >
>> > Tobias
>> >
>> >
>> > On Wed, Feb 13, 2019, 7:47 PM Kye Russell > > > I’ve been hearing that there are other CDN providers that offer a
>> very comparable service for a fraction of the cost of CloudFront.
>> > >
>> > > Anyways, at this stage let’s not get bogged down on provider
>> decisions. I’m curious if anyone has any general objections to a CDN of any
>> kind.
>> > >
>> > > It shouldn’t be that big a deal to automatically invalidate when the
>> docs are updated. But I’m sure there’s something I’m missing.
>> > >
>> > > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <
>> cristianocc...@gmail.com> wrote:
>> > >> Consider AWS's cloudfront then :)
>> > >>
>> > >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner
>> escribió:
>> > >>> Especially cloudflare is a service we do not want to use. as for
>> the docs only, does the mirror on rtd work better for you? They are
>> probably behind a CDN.
>> > >>>
>> > >>> Cheers,
>> > >>> Florian
>> > >>>
>> > >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
>> > >>>> Hi,
>> > >>>>
>> > >>>> Is it possible to utilize a CDN service for djangoproject.com, or
>> at least on docs.djangoproject.com? The site is actually quite fast for
>> me but I think there is still room for improvement. Cloudflare sponsored
>> dozens of open source projects <
>> https://developers.cloudflare.com/sponsorships/>, probably they can
>> provide free service for django as well.
>> > >>>>
>> > >>>> Tested from Melbourne, Australia:
>> > >>>>
>> > >>>> https://www.djangoproject.com/
>> > >>>>  Average Ping: 245ms
>> > >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s,
>> DOMContentLoaded: 1.16s, Load: 1.48s
>> > >>>>
>> > >>>> https://git-scm.com/
>> > >>>>  Average Ping: 5ms
>> > >>>>  Browser: 42 requests, 351K

Re: Use CDN for djangoproject.com

2019-02-13 Thread Tobias McNulty
For me it's the trust factor (allowing someone else to decrypt and
re-encrypt all our data). This may be less of an issue for the docs site,
*if* we don't have to assign DNS authority for the whole domain to the CDN
provider.

Tobias


On Wed, Feb 13, 2019, 7:47 PM Kye Russell  I’ve been hearing that there are other CDN providers that offer a very
> comparable service for a fraction of the cost of CloudFront.
>
> Anyways, at this stage let’s not get bogged down on provider decisions.
> I’m curious if anyone has any general objections to a CDN of any kind.
>
> It shouldn’t be that big a deal to automatically invalidate when the docs
> are updated. But I’m sure there’s something I’m missing.
>
> On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho 
> wrote:
>
>> Consider AWS's cloudfront then :)
>>
>> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner
>> escribió:
>>>
>>> Especially cloudflare is a service we do not want to use. as for the
>>> docs only, does the mirror on rtd work better for you? They are probably
>>> behind a CDN.
>>>
>>> Cheers,
>>> Florian
>>>
>>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:

 Hi,

 Is it possible to utilize a CDN service for djangoproject.com, or at
 least on docs.djangoproject.com? The site is actually quite fast for
 me but I think there is still room for improvement. Cloudflare
 sponsored dozens of open source projects
 , probably they can
 provide free service for django as well.

 Tested from Melbourne, Australia:

 https://www.djangoproject.com/
  Average Ping: 245ms
  Browser: 21 requests, 211KB transferred, Finish: 2.52s,
 DOMContentLoaded: 1.16s, Load: 1.48s

 https://git-scm.com/
  Average Ping: 5ms
  Browser: 42 requests, 351KB transferred, Finish: 717ms,
 DOMContentLoaded: 564ms, Load: 699ms

 Tested on Chrome with "Disable cache" checked (but not the first time
 visit, so DNS query time might not be included).

 Best regards and thanks for all your great work.

>>> --
>> 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/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%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/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: TestCase.setUpTestData in-memory data isolation.

2018-12-02 Thread Tobias McNulty
On Fri, Nov 30, 2018, 1:03 PM Adam Johnson  Tobias - using database updates isn't always viable. Also the system under
> test might need to take in the model instance, mutate it and execute its
> own save(), and then there's no way of rolling that back if the object
> wasn't deepcopy'd
>

Fair enough, but for those cases, one could just as easily deepcopy the
object in the test itself. Again, it's more explicit, gives the developer
control over exactly what they want to happen, and makes failures more
obvious.

I suppose if the API allowed one to mix and match approaches for different
tests and model objects (like Simon's testdata app does right now), that
would work, too.

Tobias

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


Re: TestCase.setUpTestData in-memory data isolation.

2018-11-30 Thread Tobias McNulty
Hi Simon,

Intriguing proposal! Thanks for bringing it up. This is certainly something
I've struggled with on older projects we've continued to maintain.

My first impression (and it may be only that) is that this seems a big
magical and potentially confusing, especially in the event the copy
operation fails. I would want some way to disable the behavior, or even
have "disabled" as the default, at least for a couple releases (e.g., by
keeping it as a decorator the way you have it now). Alternatively, is there
a reason this couldn't continue to live as an external package?

I'm also not sure I understand the argument about how the current
implementation doesn't help reduce round trips to the database. Is this
just a case of the docs offering a less-than-optimal recommendation? When
tests do need to modify a record in the database that was created in
setUpTestData(), it's easy enough to replace self.obj.foo = bar;
self.obj.save() with Model.objects.filter(pk=self.obj.pk).update(foo=bar),
which will avoid modifying the Python object and be *at least* as efficient
as the original code, without the need for any additional overhead. I'll
admit tracking down the offending code can be a pain, but it can be done.

Could we, for example, include something along these lines as the preferred
approach in the docs
,
and/or even find a way to raise an error or warning when a test does modify
an object that it shouldn't?

Tobias

On Wed, Nov 28, 2018 at 11:42 PM charettes  wrote:

> Hey Josh, glad the package can help in the mean time!
>
> > Is there anyway to determine the pickle-ability of something without
> just trying to pickle it? I wouldn't be keen on that overhead.
>
> Not that I'm aware off but unfortunately. There really shouldn't be much
> overhead though because the deepcopy is only performed on instance
> attribute access. That means that tests that are only creating test data
> without accessing attributes assigned during setUpTestData() are not going
> to be affected by this change at all. In other words, I suggest only doing
> the deep copy if required for the requested attributes so if you define a
> complex data set in setUpTestData() then only the few attributes and their
> related objects would get deepcopied on instance attribute accesses.
>
> > Could you just capture any copy exceptions, raise a deprecation warning,
> and abandon the copy for that attribute?
>
> Yeah that's the exact plan for the deprecation phase; warn and return the
> actual attribute. From Django 3.1 this would result in an AttributeError.
>
> I've updated the branch with the deprecation warnings[0] approach.
>
> I'll give it one or two more weeks to gather a bit more feedback but it
> looks like this could be a viable option so far.
>
> Cheers,
> Simon
>
> [0]
> https://github.com/django/django/compare/master...charettes:testdata#diff-5d7d8ead1a907fe91ffc121f830f2a49R1032
>
> Le mercredi 28 novembre 2018 21:40:53 UTC-5, Josh Smeaton a écrit :
>>
>> Our project also suffers extensively with mutating objects assigned from
>> setUp, preventing us from moving most of our tests to setUpTestData. I'll
>> likely begin using your pypi package right away, thanks Simon!
>>
>> Backward compat issues are probably likely - but they'd be in test cases
>> exclusively, making them extremely easy to find during an upgrade. That
>> said, a deprecation warning is probably the most sensible path forward to
>> prevent the need for immediate action.
>>
>> Is there anyway to determine the pickle-ability of something without just
>> trying to pickle it? I wouldn't be keen on that overhead. Could you just
>> capture any copy exceptions, raise a deprecation warning, and abandon the
>> copy for that attribute?
>>
>> On Saturday, 24 November 2018 14:29:33 UTC+11, charettes wrote:
>>>
>>> Dear developers,
>>>
>>> Django 1.8 introduced the `TestCase.setUpTestData()` class method as a
>>> mean to
>>> speed up test fixtures initialization as compared to using `setUp()`[0].
>>>
>>> As I've come to use this feature and review changes from peers using it
>>> in
>>> different projects the fact that test data assigned during its execution
>>> couldn't be safely altered by test methods without compromising test
>>> isolation
>>> has often be the source of confusion and frustration.
>>>
>>> While the `setUpTestData` documentation mentions this limitation[1] and
>>> ways to
>>> work around it by using `refresh_from_db()` in `setUp()` I believe it
>>> defeats
>>> the whole purpose of the feature; avoiding unnecessary roundtrips to the
>>> database to speed up execution. Given `TestCase` goes through great
>>> lengths to
>>> ensure database level data isolation I believe it should do the same
>>> with class
>>> level in-memory data assigned during `setUpTestData`.
>>>
>>> In order to get rid of this caveat of the feature I'd like to propose an
>>> adjustment to ensure such 

Re: Pluggable secret key backend

2018-11-18 Thread Tobias McNulty
Personally, I like the simplicity and elegance of a single SECRET_KEYS
setting. It's also a good way to raise awareness that rotation is A Good
Thing to be doing anyways.

In any case, I second all of those who've already endorsed this idea. If I
can help, let me know.

Tobias

On Sun, Nov 18, 2018, 6:25 PM Adam Johnson  Very good point. I'd prefer a second setting though, named like
> OLD_SECRET_KEYS or VERIFICATION_SECRET_KEYS. If we're going to add a new
> setting, we might as well not force users who aren't rotating their keys to
> the new one, especially if they are semantically different.
>
> On Sun, 11 Nov 2018 at 18:32, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Good point, I can think of at least two apps of mine that would break.
>> Transitioning to a new setting makes more sense.
>>
>> --
>> Aymeric.
>>
>>
>>
>> > On 11 Nov 2018, at 18:58, Tom Forbes  wrote:
>> >
>> > Is it going to be easy to adjust the semantics of SECRET_KEY to support
>> sequences like that? I’d imagine a lot of third party packages that expect
>> SECRET_KEY to be a string would break in weird ways (thanks to both strings
>> and tuples of strings being iterables that yield strings).
>> >
>> > Here’s a quick search on GitHub:
>> https://github.com/search?q=%22settings.SECRET_KEY%22=Code
>> >
>> > To ease the backward compatibility concerns we could use SECRET_KEYS,
>> then make SECRET_KEY (if it is not explicitly defined) map to
>> SECRET_KEYS[0]? Third party packages using would not necessarily work with
>> the backwards verification but they would at least not break and continue
>> to work as expected.
>> >
>> > Tom
>> >
>> >
>> >
>> >
>> >
>> > On 11 November 2018 at 07:38:15, Aymeric Augustin (
>> aymeric.augus...@polytechnique.org) wrote:
>> >
>> >> Hello,
>> >>
>> >> I think this is a great idea.
>> >>
>> >> As suggested by others, an even better default implementation would be:
>> >>
>> >> class SecretKeysBackend:
>> >>
>> >> def get_signing_key(self):
>> >> if isinstance(settings.SECRET_KEY, (list, tuple)):
>> >> return settings.SECRET_KEY[0]
>> >> else:
>> >> return settings.SECRET_KEY
>> >>
>> >> def get_verification_keys(self):
>> >> if isinstance(settings.SECRET_KEY, (list, tuple)):
>> >> return settings.SECRET_KEY
>> >> else:
>> >> return [settings.SECRET_KEY]
>> >>
>> >> Once Django is updated to take advantage of this feature, hat would
>> make key rotation practical for every Django user!
>> >>
>> >> (And it seems easier to adjust the semantics of SECRET_KEY than to
>> introduce a SECRET_KEYS settings.)
>> >>
>> >> Best regards,
>> >>
>> >> --
>> >> Aymeric.
>> >>
>> >>
>> >>
>> >>> On 10 Nov 2018, at 11:12, Andreas Pelme  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> settings.SECRET_KEY can be used for sessions, password resets, form
>> wizards and
>> >>> other cryptographic signatures via the signing APIs. Changing
>> SECRET_KEY means
>> >>> that all of those will be invalidated and the users will be affected
>> in weird
>> >>> ways without really knowing what happened. (Why am I logged out?
>> Where did my
>> >>> form submission go? Why does not this password reset link work?).
>> This is
>> >>> desirable in case the key is compromised and swift action must be
>> taken.
>> >>>
>> >>> There are other situations when it would be nice to change the
>> SECRET_KEY when
>> >>> this sudden invalidation is not desirable:
>> >>>
>> >>> - When someone leaves a project/company that had access to the
>> production
>> >>>  system. After SSH keys/login credentials is revoked the developer
>> could
>> >>>  potentially have a copy of the secret key. It is essentially a
>> backdoor with
>> >>>  full remote access. It would be wise to rotate the key in those
>> cases.
>> >>>
>> >>> - Periodic and automatic rotations of keys to make it less useful in
>> the
>> >>>  future.
>> >>>
>> >>> The current situation of a single SECRET_KEY makes key rotation
>> impractical. If
>> >>> you run a busy site with active users 24/7, there is never a nice
>> time to
>> >>> change the SECRET_KEY.
>> >>>
>> >>> A solution for this problem would be sign new secrets with a new key
>> while
>> >>> still allow signatures made with the old key to be considered valid
>> at the same
>> >>> time. Changing keys and having a couple of hours of overlap where
>> signatures
>> >>> from both keys are accepted would mitigate most of the user facing
>> problems
>> >>> with invalidating sessions, password reset links and form wizard
>> progress.
>> >>>
>> >>> You could do this today by implementing your own session backend,
>> message
>> >>> storage backend and password reset token generator but that is
>> cumbersome and
>> >>> does not work across reusable apps that directly use low level Django
>> signing
>> >>> APIs unless they too provide hooks to provide your own secret.
>> >>>
>> >>> I propose a pluggable project wide secret key backend
>> >>> 

Re: Question (potential feature request) on dropping database column in migration

2018-10-01 Thread Tobias McNulty
Hello,

I don't think this is something Django can or should handle. You need to
make your change in smaller increments so it doesn't break.

The proper forum for discussing this is the Django users list (or IRC or
Google...).

Good luck!

Tobias


On Mon, Oct 1, 2018, 8:47 PM martin_x  wrote:

> Hi there,
>
> Thanks for making Django a great framework for starters :D
>
> Recently my team have run into problems when trying to remove a database
> column from the model without stopping our Django server, below is the
> timeline:
>
> 1. Before migration happens, we have column_A we want to remove, and
> running on old release_1
> 2. Now we run migration to remove column_A, our webserver is still running
> on old release_1 and serving requests
> 3. After migration, we ship the new release_2
>
> However, between step 2 and 3, there are requests coming and referencing
> column_A we want to remove, and throws a exception of course.
>
> So is there anyway I can mark a database column a special state
> (deprecated, purged in memory, etc), so it has the following affect:
> 1. Won’t generate migration file, which means database wise, nothing has
> changed
> 2. However, when Django loads the model into memory, it will ignore
> column_A completely. So query, create, update, etc won’t try to access
> column_A.
>
> The reason we want to do it that way is so we can achieve no downtime,
> seamless migration for our application. I believe more people will benefit
> from this.
>
> Please let me know if more information is needed. Looking forward to
> hearing from you.
>
> Martin
>
> --
> 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/50dbe737-0b6c-42d2-9f76-99c188c916e7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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


Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

2018-01-03 Thread Tobias McNulty
1. I also could not find anything other than #26481 and a brief discussion
<https://groups.google.com/d/msg/django-developers/xQCGx6MOZ8M/l42MypOCBAAJ> of
it on the list.

2. I've often wished for something like this, but ended up resorting to
assertNumQueries() for lack of a better solution. So yes, it'd certainly be
useful to me/us, and I'd be curious to see how one might go about
implementing it.

3. My gut says that an API, in Django core, that builds off of #26481
(e.g., .only(strict=True) and .defer(strict=True)) is the right direction
(even for related fields), and my preference would be for a loud failure
(i.e., an exception rather than a log message) when this "strict" mode is
enabled. One can easily downgrade that to a log message when needed, less
so the other way around.



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Wed, Jan 3, 2018 at 12:33 PM, 'Bryan Helmig' via Django developers
(Contributions to Django itself) <django-developers@googlegroups.com> wrote:

> At Zapier we're working with some rather complex and performance sensitive
> QuerySet building (most currently around experimenting with GraphQL) and I
> am constantly worried that the laziness of the ORM will surprise us in
> production (after a few levels of related nesting, the math of a mistake
> starts to really, really hurt). While not difficult to prevent, it does get
> a bit tedious maintaining constant vigilance :tm:. I was curious if sealing
> or locking a QuerySet has ever been seriously discussed before.
>
> For example, you might do something like:
>
> class Tag(models.Model):
> name = models.CharField()
> slug = models.SlugField()
> # etc...
>
> def get_url(self):
> return reverse('tag_index', args=[self.slug])
>
> class Post(models.Model):
> title = models.CharField()
> tags = models.ManyToManyField(Tag)
> # etc...
>
> posts = Post.objects.only(
> 'id', 'title',
> ).prefetch_related(
> Prefetch('tags', queryset=Tag.objects.only('id', 'name')),
> )
>
> # we'd .seal() or .strict() and evaluate the queryset here:
> for post in posts.seal():
> # get_url() would normally execute the classic N+1 queries
> # but after qs.seal() would instead raise some exception
> print ', '.join(tag.get_url() for tag in post.tags.all())
>
> Traceback (most recent call last):
>   File "", line 1, in 
> SealedQuerySetException: Cannot load sealed deferred attribute 'slug' on
> prefetched Tag model.
>
> Of course the obvious solution is to just add 'slug' to only(), but in a
> sufficiently complex application with many engineers working across various
> app boundaries it is both difficult to predict and test against. It
> requires lots of explicit self.assertNumQueries() and in the worse case can
> cause "production surprise" as deeply nested QuerySets can potentially
> explode in queries.
>
> This doesn't apply only to deferred attributes, but also related
> OneToOne, ManyToOne, ManyToMany, etc. lazy resolution. FWIW, I would image
> the FK/M2M N+1 pattern is a much more common surprise than opting into
> .only() or .defer() as my example above outlines.
>
> I had a go at implementing it outside of Django core, but ended up having
> to go down a monkey patching rabbit hole so I thought I'd reach out to the
> mailing list. I'd imagine setting a flag when evaluating a QuerySet to
> disable the laziness of a Model's fields and relations would be sufficient
> (IE: if it isn't in cache, raise SealedQuerySetException). It also seems
> backwards compatible, if you don't use .seal() you are still lazy like
> before.
>
> So, I guess my questions are:
>
> 1. Are there any other past discussions around this topic I can look at? I
> did find https://code.djangoproject.com/ticket/26481 which seems similar,
> but doesn't mention relationships.
> 2. Does this seem useful to anyone else? Specifically opting to raise
> explicit exceptions instead of automatic (and sometimes surprising) queries.
> 3. Anyone have tips on implementing this as a library external to Django
> with lots of monkey patching?
>
> I'd be happy to take a swing at it if there was a >50% chance that it
> would be at least considered.
>
> -bryan, cto & cofounder @ zapier
>
> --
> 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-devel

Re: Automatic prefetching in querysets

2017-08-21 Thread Tobias McNulty
On Sat, Aug 19, 2017 at 1:10 PM, Luke Plant <l.plant...@cantab.net> wrote:

> This could work something like the way that ForeignKey `on_delete` works -
> you have options that are enumerated as constants, but in reality they are
> classes that embody the strategy to be used. We could have something
> similar - `on_missing_relation=FETCH | WARN | ERROR | IGNORE ... `
>
I like this a lot. It (1) caters (I think) to many if not all of the
behavior preferences expressed in this thread, (2) mimics an existing API
we support, (3) allows projects to gradually add/try the feature, and (4)
permits but does not require a deprecation path for changing the default
behavior in the future. I'm assuming `FETCH` represents the current
behavior and not auto-detection of a missing relation and modification of
the associated QuerySet.

One alternative thought: Could we define two `ForeignKey` options (again
using the `on_delete` analogy) which support adding the relation to
select_related()/prefetch_related() all the time (e.g.,
`ForeignKey(prefetch_related=ALWAYS | MANUALLY | WARN | ERROR)` and/or
`ForeignKey(select_related=ALWAYS | MANUALLY | WARN | ERROR)`, where
MANUALLY represents the current behavior)? One could then use `.only()` or
`.values*()` to avoid fetching the related model, if needed.


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: Make bool(AnonymousUser) evaluate to false

2017-05-31 Thread Tobias McNulty
I second the objections; my assumption when reading the line 'if
request.user:' is that it's shorthand for 'if request.user is None', which
is not the case.

Grepping a project's code for incorrect usage of 'request.user' is simple
enough, so hopefully that will suffice. I don't recommend this because I
think existing Django developers would find it confusing, but technically
it would be possible to change or swap out instances of AnonymousUser via
middleware, too.

Lastly, this related ticket might be of interest:
https://code.djangoproject.com/ticket/20313

Tobias


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Wed, May 31, 2017 at 12:56 PM, Tim Graham <timogra...@gmail.com> wrote:

> My thoughts from the ticket, "The Django test suite passes with the change
> but I feel like that could have some backwards compatibility concerns. Also
> "explicit is better than implicit"?
>
> On Wednesday, May 31, 2017 at 12:44:51 PM UTC-4, Linus Lewandowski wrote:
>>
>> I suggest adding __bool__() method returning False to the AnonymousUser
>> class.
>>
>> This way it'll be possible to check if the user is authenticated by
>> simply writing "if request.user:"
>>
>> It's a frequent source of bugs (at least for me, but probably I'm not
>> alone) that right now this code returns True for anonymous users. If
>> unnoticed, such bugs can also lead to security issues.
>>
>> Related ticket: https://code.djangoproject.com/ticket/28259
>>
> --
> 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/0c20c042-cc34-4707-a3e0-
> eed3ce2cf83d%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0c20c042-cc34-4707-a3e0-eed3ce2cf83d%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/CAMGFDKQCfScbHYA8JfLtb2cDqt9Nz%3DA%3D8Qg9wJRhkz0sGju6GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-05-08 Thread Tobias McNulty
I'm no FTS expert, but based just on the facts raised in this thread, if
using Postgres FTS

   1. would not break existing nor potential search needs (in fact it might
   expand the functionality available) and
   2. would allow eliminating an entire service from the infrastructure

that seems like a net win to me and as such at least worth exploring
further. That is not to say I think we should commit to switching, but if
we have volunteers who are excited to flesh out this proposal with some
code and understand there's no guarantee it will actually get merged, I
don't (yet) see a reason to say no.

Tobias


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Mon, May 8, 2017 at 10:07 AM, Marc Tamlyn <marc.tam...@gmail.com> wrote:

> Yes, don't need that sorry.
>
> On 8 May 2017 at 14:40, Adam Johnson <m...@adamj.eu> wrote:
>
>>  I'm pretty sure our search requirements on dp.com need that,
>>
>>
>> s/need/don't need/ ? 
>>
>> On 8 May 2017 at 13:59, Marc Tamlyn <marc.tam...@gmail.com> wrote:
>>
>>> I'm not sure I see the benefit here. The strength and purpose of
>>> postgres FTS is that you can combine some FTS behaviour with some
>>> relational queries easily at the same time. I'm pretty sure our search
>>> requirements on dp.com need that, so using a dedicated search provider
>>> is a better option.
>>>
>>> On 7 May 2017 at 13:22, Florian Apolloner <f.apollo...@gmail.com> wrote:
>>>
>>>> On Sunday, May 7, 2017 at 12:45:27 PM UTC+2, Adam Johnson wrote:
>>>>>
>>>>> I guess we'd also have the benefit of not having to keep elasticsearch
>>>>> running.
>>>>>
>>>>
>>>> On the contrary, putting it into postgres means we have to care about
>>>> it. Putting it into Elasticsearch means we can let our hoster take care
>>>> about that.
>>>>
>>>>
>>>>> But I'm afraid I'm not familiar with Postgres. Is the FTS in Postgres
>>>>> mostly equivalent to ES, or will some kinds of search queries be affected?
>>>>>
>>>>
>>>> For the queries we use I think we can get pretty much equivalent
>>>> results.
>>>>
>>>> --
>>>> 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/ms
>>>> gid/django-developers/ecd3a1ea-63d9-430c-af79-951022fec138%4
>>>> 0googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/ecd3a1ea-63d9-430c-af79-951022fec138%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/ms
>>> gid/django-developers/CAMwjO1GFKbXyebkqmok_RYv3Hywq%3DfwXrfz
>>> XcgFxtZU7-Ez5%3DA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAMwjO1GFKbXyebkqmok_RYv3Hywq%3DfwXrfzXcgFxtZU7-Ez5%3DA%40mail.gmail.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

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

2017-04-17 Thread Tobias McNulty
I'm surprised that (as far as I can see) this idea hasn't been discussed in
the ~11 year (!) history of this ticket. It was alluded to ~3 years go by
mkhalil28 <https://code.djangoproject.com/ticket/2273#comment:12>, but was
missing the backwards-compatible 'except' bit and didn't get any follow-up
discussion. To me this seems like an appropriate corresponding change to
#25617 <https://code.djangoproject.com/ticket/25617>.

If I'm thinking through this correctly, this would provide, for all intents
and purposes:

   - case-insensitive usernames for all new sites (and new users on
   existing sites)
   - indefinite backwards compatibility for sites that already have
   "duplicate" usernames in the database, when case is ignored
   - no feature flag that needs to be maintained
   - the added benefit of allowing sites that really want case-sensitive
   usernames to disable this behavior, if needed (by never adding unique=True
   to the username field)

If a change like this has been considered already, I am curious to know why
it was rejected.

I am not suggesting (yet) that we re-open #2273, but I think this would at
least be worth exploring further: What would a minimum-impact change for
case-insensitive usernames look like, both in terms of code and
documentation changes? #25617 + this change seem like a good start, but
more work will certainly be required to get this into a state that's ready
for formal review. I probably won't have time to do that myself in the near
future, but I would be happy to serve as a reviewer.

Tobias



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Sun, Apr 16, 2017 at 5:47 PM, Info-Screen <info-scr...@info-screen.me>
wrote:

> Wouldn't it be possible to implement case-insensitive usernames without
> loosing backwards compatibility, by checking the username iexact and only
> if there are multiple possibilities fall back to the old case-sensitive
> variant?
>
> So something like this:
>
> diff --git a/django/contrib/auth/base_user.py b/django/contrib/auth/base_
> user.py
> index 34dd6ac2f2..748db8bf89 100644
> --- a/django/contrib/auth/base_user.py
> +++ b/django/contrib/auth/base_user.py
> @@ -4,6 +4,7 @@ not in INSTALLED_APPS.
>  """
>  import unicodedata
>
> +from django.core.exceptions import MultipleObjectsReturned
>  from django.contrib.auth import password_validation
>  from django.contrib.auth.hashers import (
>  check_password, is_password_usable, make_password,
> @@ -41,7 +42,14 @@ class BaseUserManager(models.Manager):
>  return get_random_string(length, allowed_chars)
>
>  def get_by_natural_key(self, username):
> -return self.get(**{self.model.USERNAME_FIELD: username})
> +username_field = self.model.USERNAME_FIELD
> +
> +# Try case-insensitive match of username.
> +# If there are multiple possiblities fallback to case-sensitive
> lookup
> +try:
> +return self.get(**{username_field + '__iexac': username})
> +except MultipleObjectsReturned:
> +return self.get(**{username_field: username})
>
>
>  class AbstractBaseUser(models.Model):
>
> --
> 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/cc07fa69-06b3-4d24-aa2c-
> e5201ebe936a%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%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/CAMGFDKQaa4RX31yJqOapRvehH8GBPObybJmLCJ44JqT0OZpqFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: DJANGO_SETTINGS_FILE

2017-04-06 Thread Tobias McNulty
I don't see Django making a change like this. If it's really impossible to
get your production settings file on an already-importable Python path, you
*could* modify your PYTHONPATH
<https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH>
environment variable to add the directory containing your Django settings
file. That being said, I think you're better off keeping all your settings
files in version control where they belong, and changing the things you
need to change via environment variables.

On Thu, Apr 6, 2017 at 9:20 AM, James Pic <j...@yourlabs.org> wrote:

> Hi all!
>
> Life with DJANGO_SETTINGS_MODULE has been great. However, it requires the
> settings to be an importable module. In most cases, this is a straight
> forward "simple" python script.
>
> Sometimes it looks like it could make sense to add an environment variable
> that could use a file that is not importable as a python module, ie.:
>
> DJANGO_SETTINGS_FILE=/etc/yourapp/production.py
> DJANGO_SETTINGS_FILE=~/yourapp_production.py
> DJANGO_SETTINGS_FILE=settings.py  # relative to pwd
>
> Then, in this file, we could override the default project settings there
> without having to put the new file in an importable module, ie. in
> /etc/yourapp/production.py:
>
> from yourapp.settings import *
> DATABASES=...
> CACHES=...
> SECRET_KEY=...
>
> I'm sure this has been discussed before but didn't find anything by
> searching DJANGO_SETTINGS_FILE in the ML.
>
> What's your opinion on this ? Is it time to upgrade this ?
>
> Best,
>
> --
> 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/CAC6Op19-0JeL8Jdcq70-pvwz%
> 2Bi2hfKtopEvihca_rGfH1DrPww%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAC6Op19-0JeL8Jdcq70-pvwz%2Bi2hfKtopEvihca_rGfH1DrPww%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: Django versioning and breaking changes policy

2017-04-04 Thread Tobias McNulty
Hello Bernhard,

In my experience, Django strikes a good balance between adding new features
without moving so quickly that it's impossible to keep up. That being said,
third-party packages *can* vary widely in the speed with which they add
support for new Django versions after a new major release.

What are some changes in Django over the past few releases that you felt
were too significant or costly to address?

Tobias

On Tue, Apr 4, 2017 at 3:15 PM, Bernhard Posselt <nukeawh...@gmail.com>
wrote:

> Hi guys :)
>
> I'm maintaining a Django project that uses 6 apps:
>
> * djangorestframework,
>
> * django-parler (database translations),
>
> * django-allauth (openid & richer account settings)
>
> * django-recaptcha2 (simple recaptcha widget)
>
> * django-csp
>
> * django-cors-middleware
>
> Each time a new Django version is published it takes me at least a few
> weeks to upgrade. The reason is that each release breaks something in
> the apps that I use. Code that I wrote myself can usually be fixed
> pretty quickly.
>
> Personally I don't think that the number of dependencies is excessive.
> Furthermore I think that Django developers want to offload as much
> functionality as possible to thirdparty apps to improve maintainability
> so I doubt that I'm the only one with these issues.
>
> I know that deprecating and cleaning up things is *very* important to
> keep the framework alive however was it ever considered to tune down the
> frequency of breaking changes (like only remove features in a new LTS
> release)?
>
> Apart from that would it be possible to adopt semver? If you had
> followed semver closely, each 1.x release would have actually been a
> major release (e.g. 1.1 -> 2.0.0, 1.2 -> 3.0.0) and your point releases
> would need to contain three version numbers (e.g. 1.11.0 and not 1.11).
>
> I know that this versioning approach leads to very high version number
> in a short amount of time but that's essentially what Django does:
> breaking compat with each release :)
>
>
>
> --
> 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/ms
> gid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: RedirectView failing silently on NoReverseMatch is confusing

2017-01-19 Thread Tobias McNulty
On Thu, Jan 19, 2017 at 4:07 PM, Adam Johnson <m...@adamj.eu> wrote:
>
> I'm +1 on removing the try/except because I think broken things should
> fail obviously.
>

Another +1. I have little patience for except statements that hide errors I
might care about, and this seems like one of those cases.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

2017-01-15 Thread Tobias McNulty
On Thu, Jan 5, 2017 at 10:58 AM, Martin Koistinen <mkoisti...@gmail.com>
wrote:

> Slightly off-topic, this presents a really nice case for switching to
> Argon2 via argon2_cffi (supported in Django 1.10+). Its super fast (C-lib)
> and resistant to GPU/ASIC brute-forcing. So, where as an attacker's 8-GPU
> hashing machine would probably have something on the order of 24,000X more
> hashing capability for SHA256 than a typical Django server, I estimate that
> the same hardware (8 GPUs) would only have about 20-30X more hashing
> capability than a typical server. (Note, the anecdotal evidence across the
> internet supporting this is pretty thin).
>

This is an interesting point. Argon2 is recommended over PBKDF2 by OWASP
<https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Leverage_an_adaptive_one-way_function>
and
even Django itself
<https://docs.djangoproject.com/en/1.10/releases/1.10/#django-contrib-auth>.
From
what I understand, the only reason it's *not* the default now is the 3rd
party dependency, which does require a C compiler and the libffi library to
build, if a wheel isn't available for your OS. In a minimal Python
3.5-alpine Docker image, I needed the following packages before I could
`pip install argon2_cffi` (which themselves had a collective ~12 additional
dependencies):

   - gcc
   - musl-dev (libc headers)
   - libffi
   - libffi-dev

Could anyone familiar with the draft DEP 7: Dependency Policy
<https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst>
and/or the addition of the Argon2 hasher
<https://github.com/django/django/commit/b4250ea04a88f6c4fdf84dc8624baa1cf3e0f568>
comment on the suitability of argon2_cffi (or not) for consideration under
DEP 7? I think it meets most if not all of the "maturity" guidelines in the
policy, with the one exception being that it presents an interesting test
case for the footnote
<https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst#id2>
on the "dependencies that require C extensions are *probably* not
acceptable" statement. There are wheels available for argon2_cffi on a
large number of platforms, but I still had to compile it manually on Alpine
Linux (a popular OS for minimal Docker images) and for Python 3.6 on my Mac
(there is a wheel available when using Python 3.5 on a Mac).

I have trouble imagining that there are many production Django apps out
there that don't compile *something* in their requirements file (e.g.,
psycopg2 or Pillow), in which case argon2_cffi essentially requires no
extra lift. That said, it is pretty incredible that beginners can (still)
install Django just about anywhere they have Python without compiling
anything at all.

I wonder if there's an alternative to forcibly requiring it, where most
users would eventually do so for production use, but had greater
flexibility when running locally? Only the security-minded will go through
the trouble of changing the default password hasher currently, so ideally
users would get a stronger nudge than they do now when it comes time to
deploy to production. Making a switch here also has the added benefit of
circumventing some of the concerns around increasing PBKDF2 iterations
<https://groups.google.com/forum/#!topic/django-developers/Qab-hRG-SKs>
over time.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: Methodology for increasing the number of PBKDF2 iterations

2017-01-15 Thread Tobias McNulty
I'm not sure the DoS concern is really something that can be addressed
here. Regardless of the number of iterations we choose, POSTing to the
login form will always be a target, unless it's appropriately protected
(i.e., with some combination of rate limiting, recaptcha, and/or something
at the network level). A run-of-the-mill cloud server that doesn't limit
access to the Python app in some way is simply never going to be a match
for a malicious person with a laptop, let alone a more sophisticated attack.

I created a tox.ini
<https://github.com/tobiasmcnulty/hash_benchmark-ubuntu-12.04/blob/master/tox.ini>
to
run Martin's benchmark with multiple Django & Python versions. A couple
notes:

   - I ran this several times on Circle CI using Ubuntu 12.04
   <https://circleci.com/gh/tobiasmcnulty/hash_benchmark-ubuntu-12.04/13>
   with Python 2.7.7, 3.3.3, 3.4.3, and 3.5.0, and Ubuntu 14.04
   <https://circleci.com/gh/tobiasmcnulty/hash_benchmark-ubuntu-14.04/1>
   with 2.7.12, 3.3.6, 3.4.4, and 3.5.2. To view the results, expand the "tox"
   section under the "Test" header.
   - All results are what one would expect: Python 2.7.7 and Python 3.3.x
   are ~3-4x slower than Python 2.7.8+ and Python 3.4+, and there are no
   inexplicably slow outliers, like the official Python 3.5.2 installer for OS
   X.

My local results are as follows:

   - Ubuntu 16.04 w/a Core i5 @ 3.50GHz:
  - 62-65ms for 100,000 iterations
  - 100-106ms for 165,000 iterations
   - Mac OS 10.12, Core i5 @ 2.7GHz:
  - 117-120ms for 100,000 iterations
  - 195-203ms for 165,000 iterations

I really don't know how we can pick a number that'll work for everyone, but
I'm all for setting it high and allowing people to decrease the number of
iterations or, better yet, switch to the hasher that the docs recommend
everyone use anyway
<https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#using-argon2-with-django>
(Argon2). If we define 100-120ms as acceptable performance, 100k would seem
reasonable based on the results above and posted elsewhere in this thread.

Martin, FWIW, I can confirm that the Python 3.5.2 installer from python.org
demonstrates the same 3x slower behavior on my Mac that you saw. The Python
3.5.2 I installed from Homebrew does not, nor does the official python.org
installer for Python 3.6. Based on the absence of any similar outliers in
the above tests, however, I still think the conclusion here should be to
fix the underlying Python build (if it's really creating a performance
issue for you or anyone else), not hold back Django from bumping its
default number of PBKDF2 iterations. Dropping Python 2.7 support still
means we lose a large swath of definitely-slow PBKDF2 implementations:
24.4% of installs where the Python version was known were using 2.7.5
or 2.7.6 in the chart Alex posted.

The point about switching Django's default to Argon2 is an intriguing one.
In the event there are still a bunch of slow PBKDF2 implementations out
there with Python 3.5+, one benefit of dramatically increasing PBKDF2
iterations is that it might push more people to Argon2. :-D On a more
serious note, I'll reply separately to that thread to save this one for the
original topic.

Tobias

On Wed, Jan 11, 2017 at 10:39 AM, Tim Graham <timogra...@gmail.com> wrote:

> I agree. The question in my mind is how to pick an appropriate number of
> iterations that we don't risk causing a DoS on (at least most) existing
> sites due to increased CPU usage. Or at least, can we offer some
> suggestions about how to tell if your site receives sufficient traffic that
> you might be impacted? Did anyone notice increased CPU usage in past
> upgrades?
>
> On Tuesday, January 10, 2017 at 1:27:19 PM UTC-5, Tobias McNulty wrote:
>>
>> IMO this doesn't change the argument that it would be best to default to
>> the higher number of iterations (i.e., 100k or higher, given some time as
>> passed since 2013), while noting in the documentation that individual
>> projects have the ability to reduce it if need be (though perhaps
>> recommending that they try first to find a faster Python). Other thoughts?
>>
>> On Mon, Jan 9, 2017 at 10:44 PM, Martin Koistinen <mkois...@gmail.com>
>> wrote:
>>
>>> The Python3.5 on my system was installed by the official Python
>>> installer, and is almost 3X slower than the Apple-built 2.7 install. I use
>>> pip all day long.
>>>
>>> True, my MacBook is not a server, but it still serves to demonstrate the
>>> point that it is not a reasonable assumption that all 3.5 installs use
>>> OpenSSL libraries.
>>>
>>> On Monday, January 9, 2017 at 7:39:18 PM UTC-5, Tim Graham wrote:
>>>>
>>>> About "we cannot just assume that all Python 3 installs have a "f

Re: Methodology for increasing the number of PBKDF2 iterations

2017-01-10 Thread Tobias McNulty
IMO this doesn't change the argument that it would be best to default to
the higher number of iterations (i.e., 100k or higher, given some time as
passed since 2013), while noting in the documentation that individual
projects have the ability to reduce it if need be (though perhaps
recommending that they try first to find a faster Python). Other thoughts?

On Mon, Jan 9, 2017 at 10:44 PM, Martin Koistinen <mkoisti...@gmail.com>
wrote:

> The Python3.5 on my system was installed by the official Python installer,
> and is almost 3X slower than the Apple-built 2.7 install. I use pip all day
> long.
>
> True, my MacBook is not a server, but it still serves to demonstrate the
> point that it is not a reasonable assumption that all 3.5 installs use
> OpenSSL libraries.
>
> On Monday, January 9, 2017 at 7:39:18 PM UTC-5, Tim Graham wrote:
>>
>> About "we cannot just assume that all Python 3 installs have a "fast"
>> PBKDF2 implementation" -- I'd expect very few if any Django users to be
>> compiling their own Python and doing so without OpenSSL. I'm guessing that
>> any operating system Python will have the OpenSSL bindings. Or is that a
>> bad assumption?
>>
>> On Wednesday, January 4, 2017 at 2:13:09 PM UTC-5, Martin Koistinen wrote:
>>>
>>> I think this is a pretty solid guess. Bear in mind this was a direct
>>> install from Python.org.
>>>
>>> The important thing here is, this demonstrates that we cannot just
>>> assume that all Python 3 installs have a "fast" PBKDF2 implementation =/
>>>
>>> On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias McNulty wrote:
>>>
>>>> ...
>>>>
>>> Martin, is it possible your version of Python 3 is not linked against
>>>> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't had
>>>> a chance to try your benchmark yet, but in a quick test I don't see any
>>>> difference between Python 3.5.2 and Python 2.7.12 on a Mac.
>>>>
>>>> Tobias
>>>>
>>>
>>>
>>>
>> --
> 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/9261dcdc-f3b2-458c-a6e1-
> bde49642c56b%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/9261dcdc-f3b2-458c-a6e1-bde49642c56b%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

-- 
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/CAMGFDKRz1%2BBQXs%2BpQTSf%2BNds%3DjLx4QoPtfT1%3DywL0Gy%2Bzsk72w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Adding a middleware to match cookies

2017-01-07 Thread Tobias McNulty
On Jan 7, 2017 11:41 PM, "Jeff Willette"  wrote:

the specific case I am talking about deals with google analytics cookies,
which are different for every user and sent with the request. When
accessing request.user, I really only care about sessionid and csrftoken,
if present. So sending a vary by cookie header back will cause all the
unauthed/unsessioned users to miss the cache because of the GA cookies.

Since I have no use for these cookies in my code, and they are only used
for external requests to GA, eliminating them somewhere (earlier the
better) should improve cache hits, right?


Perhaps, but the place to do that is in your edge cache servers, not Django:

* http://www.varnish-cache.org/docs/3.0/tutorial/cookies.html
* https://web.archive.org/web/20151031024029/https://www.fastl
y.com/blog/how-to-cache-with-tracking-cookies

I'm unclear how feasible this is (I've never tried it). It's with noting
the last page isn't even on Fastly's public site anymore.

In any event, I'm not seeing the case for a change to Django proper here.
If Django's cache middleware is the only cache you're using, you might be
able to accomplish something like the above via middleware, as Carl
suggested.

If you're looking for assistance with the middleware implementation, I
recommend the django-users list. If you're using a another cache in front
of Django, you'll need to figure how to implement this there, or find a
simpler route such as never setting the tracking cookies in the first
place, or splitting the request in two.

Good luck!

Tobias

-- 
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/CAMGFDKQSHNzAKfQj7CEnxKWn7S%2B%2Bq3%2B5v%2BeiQOjJ-nPPA76CgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Methodology for increasing the number of PBKDF2 iterations

2017-01-04 Thread Tobias McNulty
r 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/15FEAB83-A9A4-4BC6-ABCB-
> D7BC04603E89%40polytechnique.org
> <https://groups.google.com/d/msgid/django-developers/15FEAB83-A9A4-4BC6-ABCB-D7BC04603E89%40polytechnique.org?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: Methodology for increasing the number of PBKDF2 iterations

2017-01-03 Thread Tobias McNulty
On Tue, Jan 3, 2017 at 1:14 PM, Adam Johnson <m...@adamj.eu> wrote:

> But, to be consistent with Django 1.x going forward, let's define 36,000
>> iterations as "acceptable performance" for a Python2 with Django 1.11
>> install on a typical piece of server hardware today (beginning of 2017). A
>> useful benchmark would be to determine how many iterations would yield the
>> same delay on a Py3 + Django 1.11 install on the same server.
>>
>
> That sounds like a sensible benchmark to see where we are at current. I
> think Django should be aiming for 100k+ as default at least to match the
> Python docs though. Let's not forget that users can tweak it down as well
> as up if they do have problems with the execution time.
>

I agree; this seems like a strong argument for setting it appropriately
high and documenting that it can be decreased if required, rather than
setting low enough that it won't cause an issue on any hardware and
documenting that developers should increase it (which seems less likely to
happen, IMO).

If the Python docs
<https://docs.python.org/3/library/hashlib.html#hashlib.pbkdf2_hmac> are
correct and the Python 3 pbkdf2_hmac implementation is 3x faster than the
version in Python 2, 100,000 would seem to be a fairly unobjectionable
(perhaps even a bare minimum) starting point, given we're starting with
around 30,000-36,000 in current Django. That said, that recommendation is
also ~4 years old at this point, so some benchmarks or at least further
research may be in order...

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

2016-11-28 Thread Tobias McNulty
There is a non-development use case here, which is being able to accept the
IP range for a subnet used in an EC2 VPC (used by load balancers for health
checks). Sure, I could iterate through all the potential IPs and add
them, divine
a way
<http://stackoverflow.com/questions/166506/finding-local-ip-addresses-using-pythons-stdlib>
to (maybe) discover it via the socket module, or make an HTTP request to
retrieve it from the EC2 meta data API, but this seems like another time
when being concise and explicit about the allowed IPs/subnets (without
requiring a network call from settings.py) would be helpful. Using the
established convention of subnets rather than wildcards would be preferred,
IMHO.

Tobias

On Wed, Nov 23, 2016 at 11:40 AM, 'Tom Evans' via Django developers
(Contributions to Django itself) <django-developers@googlegroups.com> wrote:

> On Sat, Nov 19, 2016 at 1:01 AM, Florian Apolloner
> <f.apollo...@gmail.com> wrote:
> > On Thursday, November 17, 2016 at 5:07:07 PM UTC+1, Tom Evans wrote:
> >>
> >> Or:
> >>   from socket import gethostname, gethostbyname
> >>   ALLOWED_HOSTS = [ gethostname(), gethostbyname(gethostname()), ]
> >
> >
> > That a) adds your hostname and b) (assuming you properly configured your
> > system) 127.0.0.1  -- so as long as they are using 192.* to access the
> site,
> > this does not help.
>
> Our servers are configured such that "localhost" resolves to
> 127.0.0.1, and the hostname resolves to the local IP of the server.
>
> I don't think our servers are in any way misconfigured, or configured
> in a "special" manner - my laptop is configured in precisely the same
> manner out of the box.
>
> The offered solution works correctly on all of our development and
> production servers, and also on our developers local machines running
> various versions of Linux.
>
> Cheers
>
> Tom
>
> --
> 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/CAFHbX1K_1dCLrMQm4cy0u1i1cnEzLJV%2Bb_1-
> p9n58ERV7%3Dghvg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

-- 
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/CAMGFDKRa3AkU18jCTtyO-XFmm%2BeQBWjTHuOQXegC%2ByNMPB%3D0Xg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: should blank POST data fallback to use model field defaults?

2016-08-15 Thread Tobias McNulty
On Fri, Aug 12, 2016 at 9:58 AM, Tim Graham <timogra...@gmail.com> wrote:

> A change in Django 1.10 inadvertently caused the following behavior change:
>
> class M(models.Model):
> f = models.CharField(max_length=255, default='default_value')
>
> class MF(forms.ModelForm):
> f = forms.CharField(required=False)
>
> class Meta:
> model = M
> fields = ['f']
>
> >>> mf = MF({})
> >>> m = mf.save()
> >>> m.f
> '' (Django 1.10+)
> 'default_value' (Django < 1.10)
>
>
> On Django < 1.10, {'f': ''} as the form data (rather than empty form
> data) also results in a model instance with the model field default rather
> than an empty string. Claude and I agree that for this latter case,
> transforming an empty POST value to a model field default doesn't seem
> correct (that is, the new behavior seems better).
>

That certainly sounds incorrect to me and I would not want to see pre-1.10
behavior restored for the blank ('') value case.


> However, the desired behavior in the empty POST data case isn't so clear.
> For example, I could imagine an API call where it would be useful for the
> model to use the default if a user doesn't submit any data for that field.
> An issue with the idea that values not present in POST data fallback to
> their default is for HTML widgets like checkboxes. If a checkbox isn't
> checked, the key won't appear in POST data. In such a case, it's
> inappropriate for an unchecked checkbox to fallback to the model field's
> default if it's True. A draft patch to restore the Django < 1.10 behavior
> [1] special cases this with isinstance(form[f.name].field.widget,
> CheckboxInput) to fix some test failures but that hardly seems ideal.
>
> Do you feel we should try to restore the Django < 1.10 behavior or keep
> the new behavior and document that model field defaults are used to
> populate initial blank forms but not to fill missing data from the form
> input?
>

I tend to prefer the more cautious approach, i.e., allow the application to
supply default values to the form if they're not included in the POST, but
it sounds like I might be in the minority.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: Improve queries on django admin

2016-07-22 Thread Tobias McNulty
I think the question was more about memory usage than speed, but the answer
is the same, in my opinion.

The only thing I'll add is that -- if returning a mere 100 rows of a table
is really causing memory issues -- there are alternatives to storing large
blobs of data directly in the DB (e.g., files).

Tobias

On Fri, Jul 22, 2016 at 6:22 PM, Shai Berger <s...@platonix.com> wrote:

> I tend to agree with Tim -- in particular, a query on the admin should only
> return a small (<100) number of records, due to paging; if, for that size
> of
> query, you see a significant difference between returning all the columns
> and
> returning just the ones you need, it is suspicious: Either you have a very
> special case (e.g. it just happens that all the fields you chose to list
> are in
> an index, and so are selected extremely fast), or you're doing something
> wrong
> (which causes your default query to be very slow).
>
> For most cases, this should not be a significant optimization IMO.
>
> On Friday 22 July 2016 20:38:40 Tim Graham wrote:
> > I'm a bit wary of the complexity this would add, especially given this
> > warning in the documentation:
> >
> > The defer() method (and its cousin, only()
> > <
> https://docs.djangoproject.com/en/1.9/ref/models/querysets/#django.db.mode
> > ls.query.QuerySet.only>, below) are only for advanced use-cases. They
> > provide an optimization for when you have analyzed your queries closely
> > and understand *exactly* what information you need and have measured that
> > the difference between returning the fields you need and the full set of
> > fields for the model will be significant.
> >
> > I think it's better if developers override ModelAdmin.get_queryset() as
> > needed, as you've done. In particular, I thought of the case where a
> method
> > is used in list_display. In that case, I believe it's impossible to do
> the
> > optimization automatically since Django can't automatically determine
> what
> > fields a method might use.
> >
> > On Friday, July 22, 2016 at 9:51:27 AM UTC-4, Rael Max wrote:
> > > Hi Lucas, thanks for reply
> > >
> > > I think that select_related gives a great improve on performance but we
> > > can improve his usage passing the columns that we want retrieve,
> avoiding
> > > getting most columns/data and allocate more memory than necessary.
> > >
> > > Em quinta-feira, 21 de julho de 2016 17:01:00 UTC-3, Lucas Magnum
> escreveu:
> > >> You can use `list_select_related` for Django Admin too.
> > >>
> > >>
> > >>
> > >>
> > >> []'s
> > >>
> > >> Lucas Magnum.
> > >>
> > >> 2016-07-21 15:52 GMT-03:00 Rael Max <ozkon...@gmail.com>:
> > >>> Hi everyone,
> > >>>
> > >>> I'm working in a project with a large mysql database and i've faced
> > >>> with problems generated on django admin list. Basically, the query
> > >>> executed to retrieve a list of items from a model uses a SQL SELECT
> > >>> passing a list of all attributes of model, but usually we only use a
> > >>> small set of them on *list_display* attribute.
> > >>>
> > >>> I solved this problem overriding the *queryset* method of
> *ModelAdmin*
> > >>> and using the method only of *QuerySet* using the fields listed on
> > >>> *list_display* attribute of *ModelAdmin*. With the limit of columns
> > >>> retrieved this queries should to consume less memory to be executed.
> > >>>
> > >>> Searching about this here and on django issue tracker i've not found
> > >>> nothing about. What you think about this optimization be the default
> > >>> behavior or use a *ModelAdmin* attribute to enable?
> > >>>
> > >>> Regards,
> > >>> Rael
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


GitHub PR status within Trac

2016-07-22 Thread Tobias McNulty
I spent some time during the DjangoCon sprint today looking into
dashboard.djangoproject.com and how it calculates metrics. I was hoping to
add some new metrics that mash up data from GitHub and Trac together. While
technically possible, this breaks down when you want to link out to a list
of the related tickets in Trac. For example:

   - A list of Accepted tickets with no open PR or an open PR that hasn't t
   been touched in X months
   - A list of Accepted tickets with no PR and no attached patch that
   haven't been touched in  months

This got me wondering: Is checking for GitHub PRs via JavaScript the Right
Way to do it? What if we had a cronjob update Trac periodically with PR
status from GitHub?

I think it would be valuable to be able to query on PR status from within
Trac, e.g., to help find in progress but stale/abandoned tickets. Cleaning
up the work of someone else who's lost interest in a patch is often a good
way to get into Django development.

I'm sure there are some holes in this idea, so I'm putting it out there for
comment. Was something like this considered before, and if so, why wasn't
it pursued?

If it hasn't been considered before, what are the obvious problems I might
encounter?

Rather than sync the data periodically, another approach might be to extend
the existing trac-github <https://github.com/trac-hacks/trac-github>
plugin, though that would still require sync'ing existing data up front and
substantial testing to make sure all the right events (e.g., renames and
closures) are caught appropriately. It's not as simple as adding a commit
hash to a ticket's history, esp. if we ever wanted to change the fields
that were brought over from GitHub.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: change commit message format to present tense?

2016-06-24 Thread Tobias McNulty
I'm in support of this as well. Is the suggestion to change the format to:

A) Fixes #12345 -- Add support for ... / Validate that  / etc.

OR

B) Fixes #12345 -- Adds support for ... / Validates that ... / etc.

OR

C) Something else?

I assume (A) but others may interpret this differently?

On Fri, Jun 24, 2016 at 1:25 PM, Markus Holtermann <i...@markusholtermann.eu
> wrote:

> I don't mind either way. If everybody seems to use present tense these
> days, yeah, let's do that as well. As long as the general style of the
> commit messages stays: Fixes|Refs #12345 -- Make it work
>
> My 2¢
>
> /Markus
>
>
> On Fri, Jun 24, 2016 at 11:04:39AM -0600, Jacob Kaplan-Moss wrote:
>
>> I'm not entirely sure because my memory sucks, but odds are that I started
>> the current standard of using past-tense.
>>
>> FWIW I no longer care even at all, I think as long as commit messages are
>> clear we I don't care what tense they are. Following the standard git way
>> seems totally OK to me.
>>
>> Jacob
>>
>> On Fri, Jun 24, 2016 at 10:59 AM, Carl Meyer <c...@oddbird.net> wrote:
>>
>> On 06/24/2016 10:55 AM, Tim Graham wrote:
>>> > A few contributors indicated in #django-dev that it could be beneficial
>>> > to change our commit message format to match git's guidelines of
>>> present
>>> > tense (instead of our current past tense convention) as it would be one
>>> > less thing to remember when contributing to Django. Besides consistency
>>> > with the current history, do you feel there are any benefits in
>>> > continuing to use past tense instead of present tense?
>>>
>>> I was one of those contributors in #django-dev. Not only are past-tense
>>> commit messages non-standard for git (meaning they are one more thing a
>>> new contributor is likely to trip over), I also personally find them
>>> harder to write and make clear. Sometimes in a commit message you need
>>> to reference past (pre-commit) behavior and make it clear how the commit
>>> changes that behavior. I occasionally find that harder to do clearly
>>> when the entire commit message is supposed to worded in the past tense.
>>>
>>> So I find all the advantages (except for consistency with past history)
>>> in favor of switching to the imperative mood.
>>>
>>> Carl
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers  (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>>
>>> https://groups.google.com/d/msgid/django-developers/576D6702.3080501%40oddbird.net
>>> .
>>> 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/CAK8PqJESDrr05-1jJeTbz8UQ%3D%2BJXYHU88w1iGBBnby5czwwVSA%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/20160624172521.GF12981%40inel.local
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: decorator_from_middleware changes

2016-06-21 Thread Tobias McNulty
On Tue, Jun 21, 2016 at 7:00 PM, Carl Meyer <c...@oddbird.net> wrote:

> Still halfway tempted to go with the original "make middleware authors
> responsible for this themselves, if they want to access
> response.content" approach.
>

I am curious to hear what others think, but I'm leaning this way too.
Having a permanent helper (perhaps MiddewareMixin as you suggested) for
dealing with TemplateResponses certainly sounds like a win, too.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

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


Re: decorator_from_middleware changes

2016-06-21 Thread Tobias McNulty
On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer <c...@oddbird.net> wrote
> Possible disadvantages of this approach:



> 3. The new behavior may surprise some people accustomed to the old
> behavior, since it means the effect of the middleware decorator won't
> occur immediately where the decorator is applied. E.g. if you apply a
> middleware decorator to a view, and then another custom view decorator
> outside that, the custom view decorator won't see the effects of the
> middleware decorator in the actual response (it would only see a new
> entry in view_func._extra_middleware).

This one seems like the gotcha to me. What if, for example, I have a view
decorator whose effects I specifically don't want to cache, but I do want
to cache the underlying view; is it fair to require that the person write a
middleware and then turn it into a decorator to be able to do that? Are we
effectively saying, "for view decorators to behave the way you might
expect, implement them as middleware"? It seems odd, to me at least, that I
should care what the underlying implementation of a decorator is before I
use it. It also violates the 'strict in/out layering' goal, albeit for
decorators instead of middleware. (A similar argument could be said of
exceptions -- what if I want to trap an exception raised by a
middleware-turned-decorator?)

It might be okay if the decorators themselves were explicit about what they
were doing, for example @cache_page(3600) might become:

@add_middleware(CacheMiddleware, cache_timeout=3600)

However, that's probably a bigger and unnecessary change.

Would it be possible to implement a combination of the approaches, i.e.,
make the delay in applying the middleware-turned-decorator the exception
rather than the rule, perhaps only for TemplateResponses and specifically
for the purpose of supporting a deprecation plan? And then, long-term,
leave it up to middleware/decorator authors & users to decide how best to
implement/layer them, being explicit about the implications of rendering
the response or perhaps more appropriately, "not rendering if you can avoid
it" (i.e., your first strategy)?

Tobias
-- 

Tobias McNulty
Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

Sent from my mobile.

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


Re: ERROR on document "request-response" , request.is_ajax()

2016-06-20 Thread Tobias McNulty
I think it's a fair point. The docs on HttpReqest.is_ajax() are
specifically discussing headers set from the client side, so I think
X-Requested-With would be more appropriate. This was discussed previously
and a more substantial change proposed:

https://groups.google.com/forum/#!searchin/django-developers/HTTP_X_REQUESTED_WITH/django-developers/Jvs3F79cY4Y/GW-S9GTYOKsJ

In fact, Collin Anderson submitted a proof of concept PR to this ticket
just ~2 days ago:

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

Vignesh, I would follow this ticket and see if your concern could be
addressed through this implementation. If for whatever reason it doesn't go
through, you might consider filing a ticket
<https://docs.djangoproject.com/en/1.9/internals/contributing/bugs-and-features/>
and pull request (if the ticket is accepted) for a small improvement to the
documentation -- to change the header name referenced as you suggested
and/or point people to the section of the docs that talks about how headers
and META keys are different (
https://docs.djangoproject.com/en/1.9/ref/request-response/#django.http.HttpRequest.META
).

Cheers,
Tobias

On Mon, Jun 20, 2016 at 9:32 AM, Paulo Gabriel Poiati <
paulogpoi...@gmail.com> wrote:

> That is because the documentation is referring to the WSGI envrion
> dictionary (and thus the CGI spec). This is how the translation from the
> client to the server works: X-My-Header becomes HTTP_X_MY_HEADER. It isn't
> wrong IMO.
>
> On Sun, Jun 5, 2016 at 8:52 AM Vignesh Tnj <vigneshtn...@gmail.com> wrote:
>
>> https://docs.djangoproject.com/en/1.9/ref/request-response/
>>
>> " HttpRequest.is_ajax()[source]
>> <https://docs.djangoproject.com/en/1.9/_modules/django/http/request/#HttpRequest.is_ajax>
>> ¶
>> <https://docs.djangoproject.com/en/1.9/ref/request-response/#django.http.HttpRequest.is_ajax>
>>
>> Returns True if the request was made via an XMLHttpRequest, by checking
>> the HTTP_X_REQUESTED_WITH header for the string'XMLHttpRequest'. Most
>> modern JavaScript libraries send this header. If you write your own
>> XMLHttpRequest call (on the browser side), you’ll have to set this header
>> manually if you want is_ajax() to work. "
>>
>>
>> if we set ,  xhttp.setRequestHeader('HTTP_X_REQUESTED_WITH',
>> 'XMLHttpRequest'); as said in doc
>>
>> request.is_ajax()   return False
>>
>> ---
>>
>> if we set , http.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
>>
>> request.is_ajax()   return true
>>
>> --
>> 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/7a88b8d8-b15f-4377-8264-e94130ad041e%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/7a88b8d8-b15f-4377-8264-e94130ad041e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> *[]'s*
> *Paulo Poiati*
> blog.paulopoiati.com
>
> --
> 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/CABqSV%3DJNiAPpR%3DW5kZa5-gm2Kmn%2BYJV2G1dxBoiBCGtJGN8-hQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABqSV%3DJNiAPpR%3DW5kZa5-gm2Kmn%2BYJV2G1dxBoiBCGtJGN8-hQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

-- 
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/CAMGFDKQ2eOxYW-21RZ%3Dfx%2BC%3DxWPm0gV9VByq49UHQVUxR-mNNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Ticket #14019: SQLInsertCompiler.as_sql() failure

2013-04-07 Thread Tobias McNulty
Hi all,

I'm starting this thread in response to the recent closure as wontfix of Ticket
#14019 <https://code.djangoproject.com/ticket/14019>,
"SQLInsertCompiler.as_sql() failure"

The original summary in the ticket from mlavin goes as follows: "I came
across a problem with SQLInsertCompiler.as_sql function while trying to get
a stacktrace printed on insert errors (using
django-db-log<http://github.com/dcramer/django-db-log>).
I found that the as_sql function has an implicit condition that execute_sql
must be called first because execute_sql sets the return_id attribute."

The two proposed fixes either (a) check to make sure return_id exists
before accessing it, or (b) initialize return_id in __init__ so as to avoid
any implicit conditions that it's already set.

While as stated in the ticket this is not a public API, Django does
publicly support writing 3rd party database backends, and implicit
conditions like this make it difficult to develop and debug 3rd party
backends as well as other 3rd party database logging packages when
something goes wrong.  As kmtracey stated in the most recent comment, it
would be a big help to the larger Django community if methods like this did
not completely blow up when used incorrectly, but instead allowed a more
useful traceback to be raised by the actual offending code.

On a more general level, initializing attributes in __init__() is not a bad
practice, and ensuring that calling str() on an object doesn't raise an
exception is generally helpful too.  Given these issues, I wouldn't be
surprised if applying this fix also avoided similar issues during the
future development of Django itself.  Internal or not, "as_sql" is a
relatively common method, so making it at least somewhat resilient would be
helpful both for Django itself and the broader community of 3rd party apps
and backends.

Thanks in advance for considering re-opening this ticket.

Best,
Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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 sprint in North Carolina, Nov. 12-13, 2011

2011-11-11 Thread Tobias McNulty
Hi All -

Just a quick reminder that the Django sprint in NC is being held tomorrow
and Sunday here in Carrboro.  For more information:

https://code.djangoproject.com/wiki/Sprint20TriangleNC

Join us on IRC in the #django-sprint channel if you can't make it in
person.  We'll be on from about 9am to 3:30pm EST (UTC-5) each day and
Karen Tracey will be here for most of that time to help review and commit
our patches (thanks Karen!).  :-)

Cheers,
Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

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



Re: Django sprint in North Carolina, Nov. 12-13, 2011

2011-11-04 Thread Tobias McNulty
Hi all,

Just wanted to send out a quick reminder that we're hosting a Django sprint
here in Chapel Hill / Carrboro, NC next weekend (November 12th and 13th).
 All the details and related links are below.

If you're not local to Raleigh/Durham/Chapel Hill, you might consider
organizing a parallel sprint in your area.  The DSF and/or PSF can help
reimburse for sprint expenses.

Thanks and I hope to see you here or in the #django-sprint channel on
Freenode!

Cheers,
Tobias

On Tue, Oct 4, 2011 at 3:57 PM, Tobias McNulty <tob...@caktusgroup.com>wrote:

> Hi All,
>
> We'd like to host another Django sprint here at Caktus the weekend of
> November 12 and 13, 2011.  A development sprint is an excuse to get
> together, write some code, and have a good time doing it.  The purpose of
> this sprint will be to help finish features and push out bug fixes in
> preparation for the Django 1.4 release.  If you're interested in coming to
> work on other open source Django-based projects, that's welcome too.
>
> We'll be meeting at the Caktus Group office and we'll be here to open the
> doors at 9am both days.
>
> For more information, please check out the corresponding wiki page and
> RSVP via Eventbrite if you're interested:
>
> https://code.djangoproject.com/wiki/Sprint20TriangleNC
>
> http://nc-django-sprint-2011-11.eventbrite.com/
>
> If you you can't make it to NC but would like to participate online, you
> can RSVP by adding your name to the following page:
>
> https://code.djangoproject.com/wiki/Sprint20
>
> We're still looking for a few sponsors to help out with lunch and snacks,
> so check out the sponsors section of the wiki and add yourself (or your
> company) if you'd like to bring something.  Feel free to drop me an email
> off-list if you have any questions about sponsoring.
>
> Hope to see you there!
>
> Cheers,
> Tobias
> --
> Tobias McNulty, Managing Member
> Caktus Consulting Group, LLC
> http://www.caktusgroup.com
>
>


-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

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



Django sprint in North Carolina, Nov. 12-13, 2011

2011-10-04 Thread Tobias McNulty
Hi All,

We'd like to host another Django sprint here at Caktus the weekend of
November 12 and 13, 2011.  A development sprint is an excuse to get
together, write some code, and have a good time doing it.  The purpose of
this sprint will be to help finish features and push out bug fixes in
preparation for the Django 1.4 release.  If you're interested in coming to
work on other open source Django-based projects, that's welcome too.

We'll be meeting at the Caktus Group office and we'll be here to open the
doors at 9am both days.

For more information, please check out the corresponding wiki page and RSVP
via Eventbrite if you're interested:

https://code.djangoproject.com/wiki/Sprint20TriangleNC

http://nc-django-sprint-2011-11.eventbrite.com/

If you you can't make it to NC but would like to participate online, you can
RSVP by adding your name to the following page:

https://code.djangoproject.com/wiki/Sprint20

We're still looking for a few sponsors to help out with lunch and snacks, so
check out the sponsors section of the wiki and add yourself (or your
company) if you'd like to bring something.  Feel free to drop me an email
off-list if you have any questions about sponsoring.

Hope to see you there!

Cheers,
Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: class based views: object instead of dictionary as context?

2011-09-13 Thread Tobias McNulty
On Mon, Sep 12, 2011 at 2:10 PM, Reinout van Rees <rein...@vanrees.org>wrote:

> On 12-09-11 18:25, Florian Apolloner wrote:
>
>> On Monday, September 12, 2011 5:39:03 PM UTC+2, Reinout van Rees wrote:
>>
>>Addition: disallow attributes/methods starting with an underscore?
>>
>>That's a handy way to stow away dangerous methods should you have them
>>in your view.
>>
>> That's already the case for resolving variables in templates, I don't
>> think we need any specialcasing here.
>>
>> > The only way I can see yourself shooting in the foot is
>>when you have a
>> > form view that reacts to get() and post(). Upon "get()",
>>the template
>>
>> > *could* call data-modifying methods on the class.
>>
>>
>> Not easily, since the templates can only call methods which don't
>> require extra params, get/post do take request at least.
>>
>
> I love it when problems solve themselves :-)


That's a good point.  Are there *any* methods in the CBVs that don't take
arguments, that also modify data?  The only one that I found in the list I'd
initially proposed that can be called without arguments is as_view(), and
I'm not sure that really even needs protection.  Maybe there's no need to
protect anything with alters_data / proxying?

That would certainly be the simplest, and would eliminate the possibility
that someone will later ask for us to expose a certain method or attribute
that we thought it best to hide now.

Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: FloatField will not handle infinity values (Ticket #4287)

2011-04-27 Thread Tobias McNulty
On Wed, Apr 27, 2011 at 9:31 AM, Luke Plant <l.plant...@cantab.net> wrote:

>  ... If you need to store
> infinity in a database column, it's better to know sooner that your
> database doesn't support it so you can find one that does.
>

+1
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: RFC: new backports policy

2011-04-20 Thread Tobias McNulty
On Wed, Apr 20, 2011 at 3:56 PM, Paul McMillan <p...@mcmillan.ws> wrote:

> +1, I agree with Carl and Luke. The issue here is that for
> non-showstopper bugs, users have probably found (or may even be
> relying on!) the existing behavior. Keeping the "stable" branch more
> stable by only changing things when there's a serious issue seems to
> be a positive improvement.
>

Okay, I do think the regression issue makes a much stronger argument than
the developer time issue.

I'd be more comfortable if the policy stated that any new bugs introduced by
the last release would be backported to that release.  It's possible
that "major
functionality bugs in newly-introduced features" will equate to virtually the
same thing, but I'm not clear what would constitute a major functionality
bug (it sounds big, and like it might be a difficult criterion to meet).

On the other hand, if we've all been living with a trivial bug since 1.0, we
can probably live with it for just a little longer, and backporting
certainly doesn't sound worth the potential risk of a regression.

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: RFC: new backports policy

2011-04-19 Thread Tobias McNulty
On Tue, Apr 19, 2011 at 3:22 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

> Hi folks --
>
> Over the past few weeks, the core development team have been
> discussing how we can streamline our process to get more work done
> quicker. It's pretty clear that the bulk of the community wishes
> Django could move forward a bit faster [1], and we'd like to be able
> to deliver more awesomeness in less time. Ultimately, the goal will be
> to put out releases quicker, hit our deadlines more accurately, and be
> able to respond to community suggestions and patches in a more timely
> manner.
>
>[1] This isn't unique to Django, of course; almost every open
> source project wishes they could release more features more quickly.
>
> One way that we'd like to improve our speed is by modifying our
> existing backport policy. To refresh your memories, right now we
> backport any non-feature-containing patches to the previous release.
> So if we fix a bug on trunk, we backport the bug fix to the 1.3.X
> branch, where it would become part of the 1.3.1 release. This is a
> fair bit of work: it basically means we have to fix each bug twice.
>
> The core team has come to a rough consensus and we're planning to drop
> this backport-everything policy. Instead, we'll only backport critical
> patches. That is, we'd only backport patches for:
>
> * Security issues.
> * Data-loss bugs.
> * Crashing bugs.
> * Major functionality bugs in newly-introduced features.
>
> In other words, we'd basically only backport bugs that would have
> prevented a release in the first place.
>
> Practically, this means that if there's a minor bug in 1.3 -- for
> example, #15795, a bug with the representation of RegexURLPattern --
> the fix *will not* be applied to the 1.3.X branch, and thus no 1.3.*
> release will contain the fix, even if it's fixed in trunk. To get the
> fix for these bugs, users will have to upgrade to 1.4.
>
> The upside, of course, is that bug fixes will be quicker to apply, so
> we can fix more bugs, so we can get that 1.4 release out sooner [2].
> Additionally, this'll give users more of an incentive to upgrade to
> the latest-and-greatest. This means that they get new features, and we
> (the development community) get to focus more clearly on moving
> forward, not maintaining older releases.
>
>[2] Look for a proposed release date soon. Spoiler alert: it's
> sooner than you think.
>
> We'd like to make this change effective immediately, but we also don't
> want to just issue this change by fiat. So we're requesting comments
> and feedback on this change. Do you like the idea? Why or why not?
> Will this policy make it more likely you'll contribute? Less likely?
>
> Thanks!
>
> Jacob


Hi All -

In general I prefer to think about this the other way around: If we have a
most current stable release of product X, it makes sense to fix any bugs
that come up in that product.  For the sake of the next release, assuming
the bug was not fixed or made obsolete by some other change, it then also
makes sense to /forward port/ that bug fix to the current (unstable)
development trunk.  Calling it "forward porting" rather than "back porting"
makes it sound better, too. :-)

This workflow fits quite well if you're using one of the DVCS mirrors of the
Django repository, as it can be as easy as merging the latest release branch
into default/master on a regular basis.  There is obviously more to the
story (running tests, dealing with the occasional merge conflict), but to
me, it seems like the majority of the work is in fixing the original bug in
the first place, not in applying that same fix to another branch of the
code.  If my assumption is true, we might as well apply the fix in both
places once it has been made.

Being a non-core-committer perhaps I don't fully understand the additional
work involved, but I do appreciate the focus on stability in Django's
releases and I'd rather be forced to upgrade due to new features that I
want, rather than some silly bug that'll never be fixed -- especially if a
stable release that includes the fix I need is not even available yet.  In
other words, if a bug in a product has been fixed, it seems odd to me that
no stable release of the product will include that fix.

What if the window for bug fixes was time boxed, so that bug fixes would be
back/forward ported as usual up until 1-2 months prior to a new stable
release (perhaps coinciding with the first release candidate)?  This way at
least we have some semblance of a stable release destined to include all bug
fixes at all points in time, and the actual window in which a bug fix might
not make it into the current official stable release is reduced.

Just my 2 cents - hope that helps!

Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Gr

Re: Urgent Requirement: - Python Developer // 9 months // San Jose, CA

2011-04-11 Thread Tobias McNulty
Amit,

Please make job postings to the django-users mailing list.  The
django-developers list is for discussion related to the development of
Django itself.

Thank you.

Tobias

On Mon, Apr 11, 2011 at 3:27 PM, Amit Reks <amit.r...@gmail.com> wrote:

> Hi,
>
>
>
> Greetings!!!
>
>
>
> We have an opening for a *Python Developer* in San Jose, CA.
>
>
>
> We would highly appreciate it if you could recommend someone for it, in
> case you are not interested...
>
>
>
> Please find the job description below.
>
>
>
> *Job Title: Python Developer*
>
> *Job Location: San Jose, CA*
>
> *Duration: 9 months (Extendible)
> Position Type: Contract*
>
>
>
> *Job Description*
>
>  - Experience with Python
>
> -  Experience with Django
>
> If this project does not match your exact skills perhaps you know of
> someone with the necessary experience and availability; if so, please feel
> free to forward this e-mail at your discretion.
>
> If you are available and interested, please do send me a word copy of
> resume along with following details:
>
> IT Experience: in years
>
> Python:
>
> Django:
> Billing Hourly Rate__
> Earliest availability for the assignment :
> Earliest availability for the Interview :
> Current location :
> Preferred contact number :
>
> Best time to reach you:
>
> Work Authorization: Citizen/Green Card/EAD/H1b/TN Visa
>
>
>
> Thanks & Regards,
>
>
>
> *Amit |* Intelliswift Software Inc * |*
> 2201 Walnut Avenue, #180, Fremont, CA 94538*|* Phone: 510 870 8644  *|*
> Fax: 510-578-7710  *| *www.intelliswift.com
>
> --
> 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.
>



-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: New messages API: regressions ?

2011-03-30 Thread Tobias McNulty
On Tue, Mar 29, 2011 at 11:08 AM, is_null <james...@gmail.com> wrote:

> Greetings hackers,
>
> Django offered a feature to add messages to offline users, or to add
> messages to users in slots (if that's the pythonic name for "functions
> connected to signals"). It is still possible before 1.4, to call
> myuser.message_set.create() which doesn't need the request object.
>
> In 1.4, it will only be possible to add messages to online users and
> only in code which has the request object in its scope. That means:
>
> - no more adding messages to offline users
> - no more adding messages to users in slots
>
> A django hacker insisted that I should post on the list about this
> change, in case you were not aware about the consequences which might
> be seen as a regression.
>

Thanks for your message.  We are aware that this functionality is slated to
be removed.

It is not clear to me that the requirements for such functionality are
uniform across different applications.  It is my recommendation, at least,
that messages for users when the request object is not in scope are best
implemented in a 3rd party app.  If needed, integration with the
contrib.messages framework can be accomplished by implementing a custom
storage, similar to the following:

http://code.djangoproject.com/browser/django/trunk/django/contrib/messages/storage/user_messages.py

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Ticket #15124: BooleanField should not use False as default (unless provided)

2011-02-03 Thread Tobias McNulty
On Thu, Feb 3, 2011 at 1:22 PM, anb <andrewbadr@gmail.com> wrote:

> On Feb 2, 3:08 pm, Chris Beaven <smileych...@gmail.com> wrote:
> > On Friday, January 21, 2011 12:35:58 PM UTC+13, Karen Tracey wrote:
> >
> > > Rather, a BooleanField that raises an error on an attempt to save an
> > > instance that has no value set is what's being asked for. The quiet
> always
> > > defaulting to False does seem rather odd to me as well.
> >
> > The current behaviour still seems in-line with the behaviour a
> non-nullable
> > charfield (if not self.null, default to '').
> > So, for consistency should we also make a not-null charfield fail loudly
> if
> > instanciated without a value ? :P
>
> My argument for that is on the ticket. "It's ok for CharFields with
> blank=True to default to the empty string, because that's semantically
> the lack of a value for the field. However, True and False are equals;
> False is not the lack of a value."


Whoops, looks like I should have refreshed this thread before hitting send.
 :-)

Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Ticket #15124: BooleanField should not use False as default (unless provided)

2011-02-03 Thread Tobias McNulty
On Wed, Feb 2, 2011 at 6:08 PM, Chris Beaven <smileych...@gmail.com> wrote:

> On Friday, January 21, 2011 12:35:58 PM UTC+13, Karen Tracey wrote:
>>
>> Rather, a BooleanField that raises an error on an attempt to save an
>> instance that has no value set is what's being asked for. The quiet always
>> defaulting to False does seem rather odd to me as well.
>>
>
> The current behaviour still seems in-line with the behaviour a non-nullable
> charfield (if not self.null, default to '').
> So, for consistency should we also make a not-null charfield fail loudly if
> instanciated without a value ? :P
>

Really?  Django makes the case[1] that "" means "no data" for char and text
fields, as does None for integers, dates, and booleans.  As far as I can
tell, the behavior of all fields, except for BooleanField, is to default to
the empty value supported by that field.  Personally I see nothing wrong
with that (though I suppose a case could be made against the "" default for
CharFields, if someone wanted to).  On the other hand, False is in no way an
"empty value."  The flip side of the question is, given the current behavior
of BooleanFields, should we also make all not-null IntegerFields default to
0?

Tobias

[1] http://docs.djangoproject.com/en/dev/ref/models/fields/#null
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: ForeignKey with null=True

2010-12-17 Thread Tobias McNulty
On Dec 16, 2010 7:20 PM, "Christophe Pettus"  wrote:
>
>
> On Dec 16, 2010, at 2:31 PM, Luke Plant wrote:
> > That being so, there is a case for arguing that
> > ForeignRelatedObjectsDescriptor should not retrieve objects where the
> > field pointed to is NULL - for consistency with the inverse operation.
>
> I agree with this.  If the FK field is NULL, it should never return
related objects; ditto for the reverse situation.

+1

Tobias

-- 
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: contrib.staticfiles app concerns

2010-10-21 Thread Tobias McNulty
On Thu, Oct 21, 2010 at 11:58 AM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

> On Thu, Oct 21, 2010 at 10:44 AM, Tobias McNulty <tob...@caktusgroup.com>
> wrote:
> > I think the issue is that the commit has already been made, and that
> doesn't
> > feel like the right time to anyone to submit an alternate proposal.
>
> Well, that's why we use revision control: if there's a rough consensus
> that a commit was a mistake, we can revert it. I'm hearing a few
> voices in this thread that I *think* would like to see the change
> backed out -- though nobody's actually suggested that explicit yet, so
> I'm not sure. OTOH, I'm hearing a lot of "whoohoos" from users, so,
> yes, we couldn't just pull the rug out: we'd need something better to
> replace it with.
>
> > As far as constructive feedback goes, something I would like to see is
> > making "compilestatic" more configurable:
>
> Yes, indeed -- my main concern pre-commit was configurability, and the
> main focus of my code review was in making sure that we didn't do
> anything that precluded adding better more powerful features later. I
> didn't, however, want to hold off adding the feature waiting for some
> ill-defined set of improvements. I wanted to see a minimalistic
> addition that we can grow on later. That's how we roll.
>

I like that.


> I think realistically "later" likely means 1.4, but I'd happily review
> patches adding more hooks at every time.
>
> I really don't want staticfiles to be the tool that tries to do
> everything, though. The idea is to provide the lowest common set of
> functionality needed to handle media in reusable apps successfully,
> and then to let other more complicated features (compression, etc.)
> build on top of that. So yes: more hooks!
>
> > One might prefer to serve media
> > directly from the app static directories (via Aliases in apache or
> locations
> > in nginx), instead of copying it manually every time during a deployment.
>
> Hm, I certainly wouldn't... but it would be nice to make something
> like that possible, yes. BTW, you can right now run `collectstatic
> --links` to use symlinks instead of actually copying the files. Not
> quite the same thing, but close right now.
>

What's the argument against serving the original files directly?  Symlinks
are pretty horrible; I'd raise a bigger fit if that was the recommended
approach. ;-)


> > Another concern I have is about naming conflicts: how does staticfiles
> > address the case where multiple apps supply files with the same names?
>
> Just like templates: last one wins. See
> http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic
> ,
> and also see the `findstatic` command that you can use to debug which
> file shows up on which name.
>

Ah, so realistically we should put all our media in 'static/', like
for templates, if we want to avoid conflicts with other apps.  Would that be
worth mentioning as a convention in the docs so we don't end up with a bunch
of reusable apps that aren't at all reusable?

> This
> > is something that might also be addressed by being more configurable: I
> can
> > see the case where it'd make more sense to expose app-specific URLs for
> > media to the browser, instead of consolidating everything under a single
> > global namespace.  This could be implemented by a template tag, like so:
> > {% staticfile 'appname' 'path/to/file.png' %}
>
> I'm not quite sure I get the use case here, but like I said above: I
> would be thrilled to see patches making this more configurable now.


Adding something to the docs about avoiding name conflicts would make my
concerns about such conflicts (and the template tag suggested above)
obsolete.

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: contrib.staticfiles app concerns

2010-10-21 Thread Tobias McNulty
On Thu, Oct 21, 2010 at 11:01 AM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

> On Thu, Oct 21, 2010 at 8:19 AM, Tobias McNulty <tob...@caktusgroup.com>
> wrote:
> > That thread's pretty old and doesn't really end on anything conclusive
> other
> > than "work has started".  I do see that the patch was updated numerous
> times
> > on the ticket [1] this month, but was there an associated review on the
> > mailing list?  Searching the group for "staticfiles" [2] or "12323" [3]
> > doesn't turn up much, but maybe I'm missing something.
>
> It looks like most of the review and discussion took place on the
> ticket tracker and on IRC. I'll take a mea culpa for that: I should
> have brought things back here.
>

No worries.  I certainly haven't been as involved as I could have been, so
it's quite likely I'd know more about what's going on if I'd been paying
more attention. :-)

I'd like to try again to actually move this forward: does anyone have
> an alternate proposal? I'm hearing a bit of complaining, but no
> alternate proposals.
>

I think the issue is that the commit has already been made, and that doesn't
feel like the right time to anyone to submit an alternate proposal.

That said, I'm not complaining, and I think having a standard way to bundle
static media with reusable apps is a Really Good Thing (tm).

As far as constructive feedback goes, something I would like to see is
making "compilestatic" more configurable: One might prefer to serve media
directly from the app static directories (via Aliases in apache or locations
in nginx), instead of copying it manually every time during a deployment.
 Some hooks that would let you generate a customized configuration, instead
of making copying the de facto standard implementation, would be great IMHO.

Another concern I have is about naming conflicts: how does staticfiles
address the case where multiple apps supply files with the same names?  This
is something that might also be addressed by being more configurable: I can
see the case where it'd make more sense to expose app-specific URLs for
media to the browser, instead of consolidating everything under a single
global namespace.  This could be implemented by a template tag, like so:

{% staticfile 'appname' 'path/to/file.png' %}

Just my two cents.

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: contrib.staticfiles app concerns

2010-10-21 Thread Tobias McNulty
On Thu, Oct 21, 2010 at 8:54 AM, Dougal Matthews <douga...@gmail.com> wrote:

> On 21 October 2010 13:41, Tobias McNulty <tob...@caktusgroup.com> wrote:
>
>>  is there another mailing list thread or wiki page somewhere that follows
>> or summarizes the decisions that went into django.contrib.staticfiles?  I
>> think pointing to the fact that such a process has already happened would
>> also resolve a lot of the concerns in this thread.
>>
>
> I think you are looking for this;
>
> http://groups.google.co.uk/group/django-developers/browse_thread/thread/b333c14f40acd22a/288a34cc41bb4395
>
> I'm not sure if its documented or summarised anywhere.
>

That thread's pretty old and doesn't really end on anything conclusive other
than "work has started".  I do see that the patch was updated numerous times
on the ticket [1] this month, but was there an associated review on the
mailing list?  Searching the group for "staticfiles" [2] or "12323" [3]
doesn't turn up much, but maybe I'm missing something.

Thanks, just trying to come up to speed.

Tobias

[1] http://code.djangoproject.com/ticket/12323
[2]
http://groups.google.com/group/django-developers/search?group=django-developers=staticfiles
 <http://code.djangoproject.com/ticket/12323>[3]
http://groups.google.com/group/django-developers/search?group=django-developers=12323

-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: contrib.staticfiles app concerns

2010-10-21 Thread Tobias McNulty
On Thu, Oct 21, 2010 at 5:27 AM, James Bennett <ubernost...@gmail.com>wrote:

> In the future, it may well turn out that people will commonly need
> much more than what the current iteration of staticfiles provides. But
> we can't cross that bridge until we come to it; for now, staticfiles
> solves the common version of the problem (let's face it: *very* few
> people are doing CDNs or offline HTML5 apps or any of the other stuff
> brought up in this thread, as compared to gathering a bunch of files
> and serving them up).
>

For the sake of posterity (including me since I seem to be arriving rather
late to the game), is there another mailing list thread or wiki page
somewhere that follows or summarizes the decisions that went into
django.contrib.staticfiles?  I think pointing to the fact that such a
process has already happened would also resolve a lot of the concerns in
this thread.

Thanks,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: #6735 -- Class based generic views: call for comment

2010-10-01 Thread Tobias McNulty
On Fri, Oct 1, 2010 at 9:55 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:

> On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk>
> wrote:
> > It seems better to stress thread-safety dos and don'ts in the
> > documentation.
>
> Without wanting to beat a dead horse, I concur.  Fundamentally we need
> to have a little faith in your users, the admin has the exact same
> pattern of a single instance, and we haven't done anything special
> there.
>

+1

The thread safety issues certainly aren't insignificant, but I think they
can be solved by a big fat warning in the documentation.  I do prefer this
to the potentially false sense of security that copying the object may
involve.

Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: making queryset.delete issue only a single SQL query

2010-09-19 Thread Tobias McNulty
On Sun, Sep 19, 2010 at 11:41 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:

> On Sun, Sep 19, 2010 at 10:28 AM, drakkan <drakkan1...@gmail.com> wrote:
> > in my opinion django should emulate "ON DELETE CASCADE" only on
> > database backends that doesn't support it, if you are using a database
> > such as postgres delete() on a queryset should issue a single sql
> > query and should be the database to care about the cascade/set null
> > etc.. behaviour
> >
> > http://code.djangoproject.com/ticket/7539
> >
> > I think this way django could archive the best performance,
> >
> > if one need to delete a lot of row and there are relations to other
> > tables a single raw SQL query is not enough, you need to modify the
> > database schema too to ensure the correct cascade behaviuor or you
> > need to issue an sql query for every related table
>
>
> We also support cascading generic relationships, which no database
> supports.
>

And currently the pre- and post-delete signals are called for each object,
even in a bulk delete, so changing that would be a backwards-incompatible
change.  I don't much like that it does this, but changing it would still
undoubtedly cause trouble for some people.

That said, queryset.update() does NOT iterate through all the objects in a
queryset and call save(), and nor does it call the pre- and post-save
signals. [1]

We have two bulk operations that behave differently; would it be worthwhile,
at least, to make the behavior configurable?

Tobias

[1]
http://docs.djangoproject.com/en/dev/topics/db/queries/#updating-multiple-objects-at-once
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: making queryset.delete issue only a single SQL query

2010-09-17 Thread Tobias McNulty
On Fri, Sep 17, 2010 at 8:27 AM, SmileyChris <smileych...@gmail.com> wrote:
>
>  On Sep 11, 1:12 pm, Tobias McNulty <tob...@caktusgroup.com> wrote:
> > I may be missing something, but queryset.delete() seems oddly implemented
> in
> > Django.  It does a select to get all the IDs to be deleted, and then
> deletes
> > them, in blocks of 100 I believe, by ID.
>
> It's because .delete() is emulating the behavior of the SQL constraint
> ON DELETE CASCADE
>
> A list of objects to be deleted is recursively populated, then this
> complete list of objects is iteratively deleted (also calling the
> pre_delete and post_delete signals in their respective places).


Hm, I see that now, and I suppose there's no sense in changing that
behavior.

To my credit, the docs are a little misleading, specifically the line
reading "Keep in mind that this will, whenever possible, be executed purely
in SQL, and so the delete() methods of individual object instances will not
necessarily be called during the process." [1]  Additionally, is ambiguous
whether the part about "ON DELETE CASCADE" applies just to single objection
deletion or to queryset deletion as well.  Admittedly what it says is not
wrong, but it does /suggest/ that delete() on a queryset doesn't do anything
per-object, which is not true at all.

Perhaps I'll work on clarifying the docs and adding a warning that Django's
delete() on a queryset will chunk the actual deletions--in addition to
calling signals and deleting related objects one by one--so raw SQL should
be used instead if one needs to delete a lot of rows and efficiency is a
concern?  Does that seem reasonable?

Tobias

[1] http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: CI server - IRC bot

2010-09-13 Thread Tobias McNulty
On Sun, Sep 12, 2010 at 11:55 PM, Tobias McNulty <tob...@caktusgroup.com>wrote:

> At the DjangoCon sprint this weekend I setup Django on our CI server for
> OSS and had it reporting on builds in the #django-sprint IRC channel.  Would
> that be useful to continue post-sprint, and should I have it report to the
> #django-dev channel as well?
>

I got an unsolicited +1 from Carl and Alex in IRC and lazy consensus is good
enough for me...so I'll go ahead and add it.  Feel free to object if it gets
out of hand.

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

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



CI server - IRC bot

2010-09-12 Thread Tobias McNulty
Hey all,

At the DjangoCon sprint this weekend I setup Django on our CI server for OSS
and had it reporting on builds in the #django-sprint IRC channel.  Would
that be useful to continue post-sprint, and should I have it report to the
#django-dev channel as well?

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

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



making queryset.delete issue only a single SQL query

2010-09-10 Thread Tobias McNulty
Hi All,

I may be missing something, but queryset.delete() seems oddly implemented in
Django.  It does a select to get all the IDs to be deleted, and then deletes
them, in blocks of 100 I believe, by ID.  Is there a reason it needs to do
this and/or is it overly complex to implement as a single query?  Issuing
multiple queries when you're trying to delete millions of rows can be very
expensive when done like this.

There's a ticket open about this, marked "Design decision needed":

http://code.djangoproject.com/ticket/9519

Does this seem like a valid change to others out there?  Should I move it to
"Accepted" and proceed with trying to fix it (though it may be harder than I
think)?

Thanks,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: #9459 forms.DateTimeField() looses microseconds

2010-09-09 Thread Tobias McNulty
On Thu, Sep 9, 2010 at 5:43 AM, Thomas Guettler <h...@tbz-pariv.de> wrote:

> Here is the patch:
>
> http://code.djangoproject.com/attachment/ticket/9459/datetime-microseconds-py25.patch
>
> If the python version is greater-equal than 2.6, it uses %f to parse the
> microseconds,
> for older versions it parses the last integer itself.
>

The patch looks reasonable enough to me and I'm excited about getting it in.
 Have you tested it on Python 2.4, 2.5, and 2.6?

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Any interest in adding a navigation helper to Django?

2010-08-28 Thread Tobias McNulty
On Sat, Aug 28, 2010 at 12:32 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:

> I think the thing that would be helpful to most django users is bit
> really a navigation helper per se. I think what I need could be solved
> with a more generic tool. Russell, tell me what you think about
> providing a way to make a view a "child" of another. I'm not speaking
> in the CMS sense (e.g. /accessories/hair/brushes/) as this is very
> proprietary and can be aconploshed using a number of different
> algorithms (Django TreeBeard for example). I'm speaking in terms of
> software views. (e.g. /configuration/settings/billing/), etc. I want
> to have a way to know that I should show "settings" tabs when I'm at /
> configuration/, and without having to create 2 new templates (one for
> list and one for forms) for "configuration" that just overrides the
> menu. This works until you have a lot of views and then it gets to the
> point where you have 50 templates just for menus. Imagine a theme
> update with that.  What's your thoughts on that?


django-treenav[1] accomplishes what you're looking for without proliferating
a huge mess of templates and lives a perfectly happy life outside the django
core.

Tobias

[1] http://code.google.com/p/django-treenav/
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Any interest in adding a navigation helper to Django?

2010-08-27 Thread Tobias McNulty
On Thu, Aug 26, 2010 at 8:59 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> Navigation menus strike me as something that:
>  * Can live happily outside the core - it doesn't need to integrate
> closely with any part of the Django stack.
>
>  * Isn't a problem that everyone has.
>
>  * Even if it is a common problem, is something where there are many
> possible ways to solve the problem
>

+1 leaving navigation outside the core.

Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: pre-object permission

2010-08-18 Thread Tobias McNulty
Andu,

I could be mistaken, but this looks like a question better asked on the
django-users list.  django-developers is for discussion related to the
development of Django itself.

Cheers,
Tobias

On Wed, Aug 18, 2010 at 2:50 AM, andu <alemf...@yahoo.com> wrote:

> Hello!
>
> I am developing some web-application. The application is expected to
> store data which is reported from different location. And the data
> needs to be accessible to different web administrators (in different
> location). In this case I want to display reported data to each
> administrator based on his location.
>
> I have tried to override the queryset(self, request) method in the
> admin.py file. i.e
>
>
> class ReporterAdmin(admin.ModelAdmin):
>list_display = ('first_name', 'last_name', 'alias', )
>search_fields = ('^first_name', '^last_name', '^alias')
>form = ReporterAdmin
>
>def queryset(self, request):
>qs = super(ReporterAdmin, self).queryset(request)
>webuser = WebUser.by_user(request.user)
>webuser_location = webuser.location
>child_locations =
> webuser_location.descendants(include_self = True)
>return qs.filter(location__in = child_locations)
>
> The above code works well (I have also applied the same thing for
> other models). But when I open the form, foreign key fields still get
> the whole data instead of filtering based on the web-users location. I
> can't event have request object as a parameter in forms.py file.
>
> Some my question is:
>1. Can I program the required feature in Django? i.e. Filter the
> data based on location in the change list, edit form and also in the
> filter list (which appears to the right side of change list view of
> admin page)
>
>2. Is there any other means?
>
> Please help me
>
> Thank you in advance
>
> Andu
>
> --
> 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: dev process [was: #11834: colorized debug page]

2010-08-15 Thread Tobias McNulty
On Mon, Aug 16, 2010 at 12:23 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> My apologies -- I haven't watched the video for a while, so I forgot
> that detail. I'm not sure adopting that policy would help Django,
> though; we have enough of a bottleneck with committers without
> exacerbating the problem.


Sure, I just happened to be watching it right then, so I thought I'd put it
in textual form where people can see it without spending 30 minutes listing
to the talk. :-)

I'm certainly not arguing that we should adopt such a policy, but it is a
neat idea.  Like you've been saying, Django trunk does a pretty good job of
staying stable as it is and things seem to get fairly well tested on an
ongoing basis, so I'm not sure it's an issue.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: dev process [was: #11834: colorized debug page]

2010-08-15 Thread Tobias McNulty
On Sun, Aug 15, 2010 at 10:31 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli <mkb...@gmail.com>
> wrote:
> >  - punish dev's who don't fix their bugs quickly after api lock
> >
> > (The presentation lacks specifics on the last point. ;)
>
> Which is a big omission. When you're not paying anyone, and you
> already have a problem getting contributions, you have limited options
> for punishment. I'd be very interested to hear what constitutes
> "punishment" in this approach.


For the record, it is mentioned.  The punishment they tried for a few
releases was denying commits from the developers who did not do their fair
share of testing for 2 weeks after the tree was unlocked for everyone else.

Cheers,
Tobias

-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: help

2010-08-03 Thread Tobias McNulty
André,

Welcome.  Please direct your questions to the python and/or django-users
mailing lists.  This list is for discussion related to the development of
Django itself.

Regards,
Tobias

On Tue, Aug 3, 2010 at 10:36 AM, André Asantos <ti.andreasan...@gmail.com>wrote:

> I am totaly new to Python world...
>
> I would like to konw:
>
> 1- py is Python class extension?
> 2-does django have any similar .jsp GUI? or is only use HTML for GUI?
> 3-is netbeans IDE the best IDE?
>
>
> André AS
>
> --
> 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: How to get patches from 'Accepted' to 'Committed'

2010-08-03 Thread Tobias McNulty
Steve,

In my experience the best approach is to open a thread on this list asking
for someone to review/commit each of your tickets individually.  Since all
involved in the project are volunteers, it may take some work (e.g., asking
a few times) on your part to raise awareness of the issue.  But if you're
persistent & your request is reasonable, you'll get it committed.

Cheers,
Tobias

On Tue, Aug 3, 2010 at 10:22 AM, Stephen Kelly <steve...@gmail.com> wrote:

> Hi,
>
> The diagram here shows the lifecycle of a ticket.
>
> http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage
>
> What I don't get is how a ticked goes from 'Accepted' to 'Ready for
> checkin'
>
> The context I ask in is in relation to patches I submitted a year ago and
> which were accepted:
>
>
> http://code.djangoproject.com/query?status=new=assigned=reopened=~steveire=priority
>
> Should I change the status to 'Ready for checkin' myself or is somebody
> else
> supposed to?
>
> I'd like to contribute more small patches to Django, but I must say it's
> demotivating that those haven't seen any action since being accepted, and I
> couldn't see what I need to do to get those committed. If someone can tell
> me what's missing that's something I can work with.
>
> All the best,
>
> Steve.
>
> --
> 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: Filebrowser functionality in contrib?

2010-07-30 Thread Tobias McNulty
On Fri, Jul 30, 2010 at 1:54 AM, shacker <shac...@birdhouse.org> wrote:

> ... except that it's not working just fine (because of this dependency
> on Grappelli).


That sounds like a problem with the 3rd party app, not something that would
be resolved by incorporating it in Django proper. That said, as Russell
suggests, it may be possible to enhance the admin in ways that make writing
third party apps like this easier.

Cheers,
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: memcached-based-cache - timeout=0 does not work as intended by memcached

2010-07-29 Thread Tobias McNulty
On Tue, Jul 27, 2010 at 4:04 PM, SmileyChris <smileych...@gmail.com> wrote:
>
> I agree with Carl.
> We have an abstracted api - having a property with different meanings
> for different backends makes things a lot less pluggable.


Sure.  Upon closer investigation, I think this is pretty much a non-issue.

My only point is that all cache backends should receive whatever timeout
they're passed, unmolested by Django.

Given that all the backends, besides memcache, are implemented in the Django
source, I see no reason why they couldn't be modified on a case by case
basis to support a "cache forever" option, indicated by timeout=0, while
leaving the common code intact and without really co-opting anything.
 Establishing this as a loose convention seems like a reasonable enough plan
to me.

I will say that the memcache issue seems more like a bug, while
special-casing timeout=0 for all the other backends seems more like a
feature (and one that may require a lot more discussion, code, and testing
relative to the 1-line memcache fix).

Cheers,
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: Filebrowser functionality in contrib?

2010-07-29 Thread Tobias McNulty
On Thu, Jul 29, 2010 at 3:32 PM, shacker <shac...@birdhouse.org> wrote:
>
> I've been thinking that it seems like solid file management would be a
> good candidate for inclusion in contrib, but wanted to put feeler out
> on this list to see whether others might agree. Would this make a good
> 1.3 feature?


-1

For whatever it's worth, my sense is that there are a number of these types
of third party apps out there, and no single one is a clear winner.
 Furthermore, I don't really see what adding file management to contrib
gives us (it seems to work just fine as a third party app), and I'd hate to
see innovation stifled at this stage by including one of the implementations
in contrib.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: memcached-based-cache - timeout=0 does not work as intended by memcached

2010-07-26 Thread Tobias McNulty
On Sat, Jul 24, 2010 at 4:07 PM, Carl Meyer <carl.j.me...@gmail.com> wrote:

> It's not obvious to me why .extra or .raw are the appropriate analogy
> here, instead of the rest of the ORM API, which does attempt to
> present the same semantics regardless of backend.
>

The issue is about values passed, not about semantics.  I admit, it wasn't a
great analogy to begin with, but it does hold for other aspects of the ORM
as well (e.g., you wouldn't want values that you set to 0 converted to None
on model.save()).

The argument that "you know what cache backend your project uses" does
> not apply to the significant ecosystem of caching-related reusable
> Django code: johnny-cache, cache-machine, cachebot, and more.
>

True, hence the proposed big note in the docs stating that the value 0
should be used with care.

If such reusable code needs to cache things forever, which sounds perfectly
reasonable to me, I'd still rather not co-opt "0" to mean "forever" in all
cases.  Each backend that supports caching with no timeout could easily
offer a class attribute, such as "TIMEOUT_FOREVER", that indicated how to
set the timeout in these cases.


> Last week I uploaded a patch to #6447 that maintains cross-backend
> parity of allowed cache keys (without any performance hit on
> memcached) by making sure the other backends will reject the same keys
> memcached will reject. You approved this approach on IRC, Jacob, so
> given the discrepancy I'm just curious whether it is in fact a design
> goal to have semantic parity between the backends shipped with Django.
>

Rejecting a particular subset of cache keys is also not the greatest analogy
to co-opting configuration values. :-)

Cheers,
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: Documenting new features: built-in obsolescence of the "versionadded" tag.

2010-07-23 Thread Tobias McNulty
I agree.  It's a little odd seeings things flagged "New" that have been
around since 1.0.  I also like your proposal of removing the notes for
unsupported versions.

Tobias

On Fri, Jul 23, 2010 at 12:06 PM, richardbarran <
richardbar...@googlemail.com> wrote:

> Hi everybody,
> The Django documentation places a strong emphasis on highlighting new/
> changed features with lines such as:
>
>"New in Django 1.0: Please, see  the release notes"
>
> Such comments are a useful mental reminder when scanning through the
> docs, they do however have one downside: built-in obsolescence. With
> the passage of time (and versions), they will end up referring to long-
> forgotten Django releases, and become just cruft.
> My question: how long should these "versionadded" tags remain in the
> documentation? My $0.02: seeing as only 1.1 and 1.2 are officially
> supported, and that *in theory* everyone should already be working
> with those - reminders for earlier versions e.g. 1.0 have become
> cruft.
> Any thoughts?
>
> --
> 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: memcached-based-cache - timeout=0 does not work as intended by memcached

2010-07-23 Thread Tobias McNulty
The only concern in that ticket seems to be that 0 means different things
for different cache backends.

There may have been some effort towards making them all behave the same when
0 is passed.

Personally I prefer the approach of not messing with the value at all, and
passing it straight to the configured cache backend.  You don't want Django
messing with your .extra() or .raw(), so why should it try to magically
alter the parameters you pass to your cache backend?

Furthermore, correct me if I'm wrong, but:
timeout = timeout or self.default_timeout
seems like an oversight on the part of whoever wrote that line originally,
not some intended functionality to prevent 0 from ever making it to the
actual backend.

Chances are, if you configured a cache backend for your Django project, you
chose one explicitly and have some cognition of how it works.  We could
could change line this to:
timeout = timeout is not None and timeout or self.default_timeout
and simply add a big fat warning to the docs stating that 0 means different
things on different backends.

Thoughts?

Tobias

On Thu, Jul 22, 2010 at 7:44 AM, Will Hardy <e.willha...@gmail.com> wrote:

> I thought this was familiar too: <
> http://code.djangoproject.com/ticket/6988>
>
> Is this the ticket you were thinking of? It seems to have been reopened.
>
> Cheers,
>
> Will Hardy
>
> --
> 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: Patch: Indefinite args for simpletags and inclusion tags

2010-07-16 Thread Tobias McNulty
On Fri, Jul 16, 2010 at 1:07 PM, Stephen Burrows <
stephen.r.burr...@gmail.com> wrote:

> Before posting the patch to django's ticketing system, I wanted to
> check whether this would be a non-trivial patch and whether there
> might be any good alternatives.
>

Hard to tell without seeing the patch. :-)

Could you stick it somewhere we can see it?  Personally I like to see them
in Trac, since it comes with pretty colors.  If there isn't a ticket already
out there for this I see no problem with creating one.  We can always close
it if it gets rejected.

Cheers
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
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: memcached-based-cache - timeout=0 does not work as intended by memcached

2010-07-16 Thread Tobias McNulty
+1

Sent from my mobile device.

On Jul 16, 2010 6:54 AM, "Carsten Reimer" 
wrote:

Hello,

I am not quite sure if this is the right mailinglist but as long as my
remarks are about a core-component of django I hopefully chose the right
list.

Dealing with cache-stuff in Django I realized that it seems to be impossible
to use a timeout=0 (which in terms of memcached meant that the item would
never expire unless it has to make way for new items due to memory
shortage). This is because even still in the most current trunk-version the
timeout is calculated (in
django.core.backends.memcached.CacheClass._get_memcache_timeout) as

timeout = timeout or self.default_timeout

where timeout is one of the parameters given to _get_memcache_timeout.

So as long as timeout=0 always the default_timeout will be used.
Maybe this behaviour is intended to prevent memcached being filled up with
items that never expire.
In my opinion it may be better to enable developers to use the
timeout-values as intended by memcached (where 0 means no expiration at
all).

So I would like to suggest to change the default value in all method
signatures of the memcached.CacheClass (and whereever it whould be
necessary) from 0 to None and to replace the line above by an if-clause as

if timeout is None:
   timeout = self.default_timeout

This is not as elegant as the original version but now it would be possible
to use 0 as a timeout.

If it would help I can try to open a ticket and provide a first path against
the current trunk.


With best regards

Carsten Reimer



-- 
Carsten Reimer
Web Developer
carsten.rei...@galileo-press.de
Phone +49.228.42150.73

Galileo Press GmbH
Rheinwerkallee 4 - 53227 Bonn - Germany
Phone +49.228.42150.0 (Zentrale) .77 (Fax)
http://www.galileo-press.de/

Managing Directors: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker
HRB 8363 Amtsgericht Bonn

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



Extra params + aggregation creates incorrect SQL - Ticket 11916 - Oracle issues

2010-03-20 Thread Tobias McNulty
I just created a test for http://code.djangoproject.com/ticket/11916

The test verifies that the code fix makes the query succeed on mysql, pgsql,
and sqlite.  On oracle, however, not only does the new test fail, but the
code fix also breaks other tests in aggregation_regress (thanks kmt for
testing!).

Could someone with oracle knowledge take a look at this ticket?  Given that
the "fix" introduces other issues in oracle backend, I hesitate to have this
committed before the oracle issues are resolved.

Thanks!
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

-- 
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: Call for sprinters for 1.2

2010-03-16 Thread Tobias McNulty
Hi all,

We're doing another Django sprint THIS WEEKEND at Carrboro Creative
Coworking in the NC Triangle, for anyone in the area:

http://code.djangoproject.com/wiki/Sprint201003TriangleNC

Again the sprint is this weekend, March 20 & 21, from 9am to 5pm both days.
 Caktus will be sponsoring again with lunch both days - but more sponsors
for drinks, snacks, etc. would be great.  Just add your name & what you want
to bring to the list on the wiki page.

Everyone's welcome - if you haven't worked on Django before, a sprint is the
best place to start out. Hope to see you there!

Cheers,
Tobias

On Tue, Mar 16, 2010 at 11:08 AM, James Bennett <ubernost...@gmail.com>wrote:

> Russ is about to put up a post on the Django weblog with the current
> state of 1.2. There's been quite a bit of progress since the last
> update, but there are still around 60 tickets which will need in-depth
> attention before we hit the point of releasing 1.2; the remainder of
> the tickets on the milestone are mostly trivial (documentation
> updates, translation fixes and other minor issues).
>
> To help get these tickets resolved (and 1.2 out the door), we'd like
> to organize a 1.2 sprint either this weekend (March 20/21) or the next
> (March 27/28), and put out a call for anyone who's willing and able to
> join in. The focus will be entirely on the 1.2 milestone tickets, with
> the goal of resolving as many as possible and getting to the 1.2
> release candidate. So if you're interested and would like to help out,
> please head over to the wiki page for the sprint:
>
> http://code.djangoproject.com/wiki/1.2ReleaseCandidateSprint
>
> and add your name and when you'll be able to sprint.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
> 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

-- 
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: Django's testing infrastructure

2010-02-25 Thread Tobias McNulty
I think this is a great move and will be an awesome resource for the
community.  I'm working on getting some CPU time at the OSU OSL and/or from
Caktus to contribute to the effort.

Cheers,
Tobias

On Thu, Feb 25, 2010 at 11:08 PM, Sean O'Connor <sean.b.ocon...@gmail.com>wrote:

> A platform we probably should get into the mix is a CentOS/RHEL 5 box.  I
> suspect a significant portion of the community is stuck on such boxes and
> given the ancient versions of everything available under RHEL I'm sure that
> there are things which will break there and not in a developer's standard
> environment.
>
> I personally don't have a suitable RHEL box laying around but this seems
> like a good candidate for either another volunteer or DSF funds.
>
> 
> Sean O'Connor
> http://seanoc.com
>
>
>
> On Thu, Feb 25, 2010 at 10:54 PM, Eric Holscher <e...@ericholscher.com>wrote:
>
>> Hey everyone,
>>
>> During the sprints, I worked to set up a hudson instance for Django. This
>> is hopefully going to be the way that we are going to go forward for now
>> with doing continuous integration for Django. I have a pretty good setup
>> going currently, and want make it really fantastic. At this point in time,
>> what we really need now is some more hardware to be able to run tests on.
>>
>> The current setup is hosted at: http://hudson.djangoproject.com/
>>
>> Currently, I have tests running on the following architectures:
>>
>> Django trunk:
>>
>> Solaris:
>> Python 2.4-2.5
>> Databases: sqlite, postgres, mysql
>>
>> Ubuntu:
>> Python 2.5-2.6
>> Databases: sqlite, postgres, mysql
>>
>> Django 1.1.X:
>>
>> Solaris:
>> Python 2.5
>> Databases: sqlite, postgres
>>
>> This gives us pretty good coverage currently, but the whole point of doing
>> CI is that we catch bugs on other platforms we wouldn't normally run on.
>>
>> What we need
>> ===
>>
>> So I'm looking for people who can offer other boxes that they would like
>> to see tested. Currently the big ones we aren't covering are Windows boxes,
>> and the Oracle backends. There are lots of other permutations that we could
>> be testing against (Different python runtimes being a good example).
>>
>> However, we don't want to get in a situation where boxes that people have
>> set up just disappear. So, I'm only currently looking for machines that
>> people would be able to dedicate to the effort. We would require a
>> django-testing user account on the box, with our SSH key on it. There would
>> also be a team of trusted users, who would have access to this key and thus
>> your machine.
>>
>> We want the build farm to be stable and useful, and in the past we have
>> had too much trouble having machines just disappear.
>>
>> Requirements
>> ===
>>
>> Currently the hudson requirements seem to be about <1GB of disk space,
>> with 512MB of ram. I'm also looking into some pony build/barn based
>> alternatives that would knock the memory requirements down pretty
>> substantially. However, for the current 1.2 release it looks like hudson is
>> how we're going to make it going forward.
>>
>> Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so
>> another way that we might be able to get this going is to be able to have
>> donations to the DSF, and have them get some dedicated rackspace boxes.
>> However, for now, I'm hoping that we can cobble together enough stuff to get
>> 1.2 tested really well.
>>
>> Feedback
>> ==
>>
>> If you have any thoughts on CI, or any advice, I would love to hear it.
>> I'm trying to make our Continuous Integration setup really kick ass, so
>> feedback is necessary to do this. I have some notes and ideas that I have
>> been recording while setting things up over at the pycon etherpad:
>>
>> http://pyconpads.net/django-testing
>>
>> Let me know if you have any thoughts, questions, or concerns.
>>
>> Cheers,
>> Eric
>>
>>  --
>> 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<django-developers%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>  --
> You received this

Re: 404 debug pages should show the name of the tried urlpattern - #9310

2010-02-24 Thread Tobias McNulty
What do we do with tickets like this?  Given that this has been ready for
commit since September, I emailed a reminder to the list in October, and
it's such a tiny request, I find it frustrating that this won't make it in
for 1.2.  Personally I have no motivation to maintain the patch going
forward and would rather see the ticket get marked as "wontfix" than be
pushed off indefinitely.  It is poor use of sprinters' time (and defeating,
both personally and to the project) to work on tickets that will never make
it in to trunk.

I'm hoping this will spark a discussion about how we can work more
efficiently and put donated time to better use.  I may be a bit biased,
because this is coming on the tail end of spending 2+ person hours trying to
reproduce a ticket in the PyCon sprint that, I later found out, two others
had done the same thing with a day earlier, but neither had indicated as
much in the ticket.

A couple ideas to get us started:

1) Reemphasize via documentation and/or training (and/or by reading this
message) the proper work flow for tickets (e.g., accept it when you start
working on it, post a comment when you're done, etc.):

http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets

2) For each release, assign several people (I'd be happy to take a turn) the
task of searching through all outstanding tickets in the milestone in
question a couple weeks before the feature freeze and assigning
"committable" ones to specific committers.  Maybe this ticket is an outlier,
but I expect there are others out there that are also getting missed.  I'm
not sure if this means that the current way ticket triage is outlined to
work is just not happening, or if there are changes we need to make so that
it works more effectively:

http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

Cheers,
Tobias

On Mon, Oct 12, 2009 at 7:30 AM, Tobias McNulty <tob...@caktusgroup.com>wrote:

> In case it's not already on someone's radar, the patch on this ticket
> could use a review at some point:
>
> http://code.djangoproject.com/ticket/9310
>
> Thanks -
> Tobias <http://www.caktusgroup.com>
>



-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

-- 
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: Possible bug in messages framework?

2010-01-23 Thread Tobias McNulty
On Fri, Jan 22, 2010 at 10:45 PM, Luke Plant <l.plant...@cantab.net> wrote:

> On Saturday 23 January 2010 02:44:39 Luke Plant wrote:
>
> >  BTW, further research shows that we are not really RFC 2109
> >  compliant at all, but then again no-one is.  It seems virtually
> >  everyone (server side and client side) is using 'Netscape style'
> >  cookies with some things adopted from RFC 2109 and RFC 2965,
> >  including 'max-age' and the use of quoted-string, but not the all
> >  important "Version" attribute which turns on RFC 2109 cookies.
> >  Hardly anyone is using Set-Cookie2 from RFC 2965.  So specs of any
> >  kind are fairly meaningless here, it's a matter of what everyone
> >  does.
>
> Actually, to add a bit more:
>
> http://www.ietf.org/mail-archive/web/http-state/current/msg00078.html
> http://codereview.chromium.org/17045
>
> It's all pretty horrific, it pushes me back towards adding a layer of
> quoting to our cookie handling just to try to avoid it all - but a
> robust encoding which definitely avoids all problems.  We should note
> that the presence of semi-colons is more likely to cause problems than
> commas - Internet Explorer splits on semi-colons, irrespective of
> quotation marks.
>

Technically I imagine it is possible to come up with a way to encode all new
cookies in a safe way, but still support "decoding" old-style cookies.  That
said, I have reservations about any kind of across-the-board encoding
because it makes it necessary, when/if the cookies need to be read by
JavaScript, to implement that same decode/encode on the client side.  My
personal preference would be to fix the messages implementation and add a
note to the cookies documentation saying that it's "recommended to encode
cookies to avoid potential browser bugs," and list off a few of those bugs.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

-- 
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: Possible bug in messages framework?

2010-01-22 Thread Tobias McNulty
Hi Jeff,

Could you try again without a comma in the message and see if the
CookieStorage starts working again?  Either way, that definitely sounds like
a bug to me.

Thanks,
Tobias

On Fri, Jan 22, 2010 at 12:13 AM, j...@jeffcroft.com <j...@jeffcroft.com>wrote:

> Sean-
>
> Can't say for sure it's related, but I can verify that I was using
> Safari (Mobile) and that my message had commas in them...so it
> definitely could be.
>
> Switching to session storage solved the problem for me, and that
> backend works fine for my needs. So, it's no longer  pressing issue
> for me, but there definitely seems to be something wrong in the cookie
> storage backend.
>
> Jeff
>
> On Jan 21, 9:07 pm, Sean Brant <brant.s...@gmail.com> wrote:
> > I wonder if this is related?
> http://groups.google.com/group/django-developers/browse_thread/thread...
> >
> > On Jan 21, 2010, at 10:55 PM, j...@jeffcroft.com wrote:
> >
> >
> >
> > > After a little more playing around, I've discovered that this is not
> > > an issue if I use the session storage -- so it seems to be related to
> > > cookie storage.
> >
> > > --
> > > 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> > > For more options, visit this group athttp://
> 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

-- 
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: Looking for full-time developer

2010-01-18 Thread Tobias McNulty
This is not the right forum for job postings.  This list is for discussion
related to the development of Django itself.

You might instead try the django-users list [1] or the Django Gigs web site
[2].  In all honestly you will find a much larger number of actual Django
developers at either of those two locations.

-Tobias

[1] http://groups.google.com/group/django-users
[2] http://djangogigs.com/


On Mon, Jan 18, 2010 at 3:40 PM, gnoze5 <david.lop...@gmail.com> wrote:

> Hey there,
>
> I am looking for a full-time Django developer(preferably someone with
> a solid python background) to work remotely or in Lisbon , Portugal.
> We are currently developing several web applications in Django and
> need someone to complete our team.
>
> I am sorry if this is inapropriate but it is not that easy to find a
> good Django developer via normal HR means.
>

-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
-- 

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: Per application default database?

2010-01-18 Thread Tobias McNulty
On Mon, Jan 18, 2010 at 11:04 AM, Bill Hubauer <bhuba...@gmail.com> wrote:

> One of the use cases that may be common for multiple database support is
> being able to combine multiple Django applications that require different
> databases into a single site.   This is exactly what I need to do for one
> project.   This can be done with the new multiple database support, but it
> feels heavy handed to me to require the "integrator" go through all of the
> application code and insert "using" specifiers.   I also get nervous to
> about missing some places where it would be required.
>
> I've reviewed the code related to the selection of the default database and
> think that it wouldn't be too hard to make it possible to do application
> specific defaults to database settings.   It would mostly be refactoring the
> django.db.DEFAULT_DB_ALIAS constant into a function, and then deciding the
> best way to allow the user to specify a default database per application in
> the settings file.
>
> Has there been any consideration or discussion of this type of
> functionality?
>

There has been.  See:

http://groups.google.com/group/django-developers/browse_thread/thread/7904c7da7cb0085f/eb5a359e30307e89?lnk=gst=multidb+tobias#eb5a359e30307e89

If I recall correctly, the resolution was basically "not in this phase,"
i.e., this is something to be worked out in a future release of Django.

Tobias


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
-- 

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: Porting Django to Python 3

2010-01-12 Thread Tobias McNulty
I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be the
case here as well?

Sent from a mobile phone, please excuse any typos.

On Jan 12, 2010 11:53 PM, "Joshua Partogi"  wrote:

On Jan 9, 1:02 pm, Russell Keith-Magee  wrote:

> On Sat, Jan 9, 2010 at 2:25 AM, Dave  wrote: > > Hello
everyone, > > > My name...
Russ,

Would it be possible if the django core developers to create a python3
branch in the django svn repository?

Kind regards,

--
http://jobs.scrum8.com | http://twitter.com/scrum8

--
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: Model validation incompatibility with existing Django idioms

2010-01-09 Thread Tobias McNulty
On Sat, Jan 9, 2010 at 7:46 AM, Ivan Sagalaev <man...@softwaremaniacs.org>wrote:

> I too would opt for an implementation that makes model validation optional,
>> i.e., a call that developers must explicitly make, if they choose, before
>> saving a model.
>>
>
> I'm +1 on some way of validating a form without *fully* validating a model.
> But for a bit different reason that I didn't see in this thread yet.
>

I don't see why model validation should be bound up with forms at all.  The
current release notes for model validation state that it won't be done
unless explicitly requested by the developer, and it seems that validating
the model inside a form (whether fully or partially) breaks that contract.

Again - pardon my ignorance if there's something that I'm missing.  I was
just alarmed to find a thread about forms + model validation given the
current state of the release notes.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
-- 

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: Model validation incompatibility with existing Django idioms

2010-01-08 Thread Tobias McNulty
On Fri, Jan 8, 2010 at 4:03 AM, James Bennett <ubernost...@gmail.com> wrote:

> On Thu, Jan 7, 2010 at 10:40 AM, Honza Král <honza.k...@gmail.com> wrote:
> > ModelForm has a save() method that saves the model. It is reasonable
> > to assume that if the form is valid, the save() method call should
> > succeed, that's why the entire model is validated.
>
> Actually, I can see a strong argument against this: if I've defined a
> form class that I think constructs valid instances, and it doesn't,
> that's a bug in my form and Django should be making this as clear as
> possible.
>
> Of course, the flip side is that the bug in my form may be something
> subtle which breaks a constraint specified at the Python level but not
> at the DB level, and so the additional automatic validation could be
> the only way to catch it.
>

For another alternative still, a constraint may exist at the database level
that Python doesn't know about (or may not be able to enforce efficiently).

I regret and apologize that I'm arriving to this thread rather late.  Is
there a document somewhere that discusses, or could someone describe, how
model validation fits between the existing form validation in Django and
constraints that are specified on the database side?

I too would opt for an implementation that makes model validation optional,
i.e., a call that developers must explicitly make, if they choose, before
saving a model.  I've always been and I continue to be wary of trying to
implement data constraints at the application level; that's something good
relational databases have been doing and improving upon for a long time and
I have little faith in my own capacity to reproduce or replace such
functionality.

Cheers,
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
-- 

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: Model validation incompatibility with existing Django idioms

2010-01-08 Thread Tobias McNulty
On Fri, Jan 8, 2010 at 8:36 AM, Honza Král <honza.k...@gmail.com> wrote:

> I just hate the name save(commit=False) when it has nothing to do with
> saving or committing, it just DOESN'T call save, it's imho misleading.
> I understand why that is and how it came to be, I just don't like it.
> I wasn't, however, proposing we get rid of this feature, just that we
> extract it to a separate method or just tell people to use
> form.instance (which is all what it does + creating save_m2m which can
> be put elsewhere).
>

There is /a lot/ of code that relies on this naming and, while it might not
be the greatest name choice in the world, it's one you get used to after
making use of it time and time again.  I'm fairly certain the 'commit'
argument is not the only instance of imperfect naming in the Django core,
and fixing all of these would leave Django users with a relatively
insurmountable quantity of deprecated code.  Frankly I'm not sure it's worth
it.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
-- 

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.



  1   2   >