Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

I'll drop it. Someone else can chime in if they want. Just to be clear, the 
work you all do on Django is much appreciated :) 

Thanks,
Dave
On Thursday, July 14, 2022 at 6:53:41 PM UTC-5 James Bennett wrote:

> On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert  wrote:
>
>> Yeah, I hope I'm not coming off as being too pushy, but I'm just curious 
>> why that is. Mariusz or Adam, did what I said about it being *more* than 
>> just an alias for `filter().first()` make sense or am I missing something? 
>> (Different behavior for multiple results — on accident or otherwise)
>>
>
> Speaking for myself:
>
> I’d be against it because we’re getting into combinatorial territory with 
> diminishing returns. Adding this one opens the door to equally long and 
> repetitive threads in the future asking for all the others, and with less 
> room to push back each time.
>
> Currently, Django covers the common cases of “if you didn’t find a match, 
> 404” and “if there’s not exactly one result for this, throw an exception 
> and let me catch it”. The fact that you can make other variants kinda work 
> if you use first() or similar methods doesn’t, to me, obligate Django to 
> also provide the full matrix of methods doing all the someone-might-want-it 
> combinations of DoesNotExist, MultipleObjectsReturned, and None. People who 
> want specific behaviors not covered by the built-in stuff should write 
> their own, or somebody should make a 
> django-all-the-get-single-object-methods package and everybody who wants 
> one of these methods can install and use it.
>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c9d2559-6904-42c8-a1bf-a49904a9e4dan%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

> I'm not the first to suggest adding an additional shortcut, e.g. 
django.shortcuts.get_object_or_none which would work similarly to 
get_object_or_404

Personally I'm not a fan of it being in "shortcuts". It makes sense to me 
that the 404 ones are there because they are only useful in a 
request/response lifecycle. Seems like a good call to keep that out of the 
standard queryset methods. But `get_or_none` could be used anywhere, and 
ergonomically (?) it makes more sense to me that people (especially people 
new to Django) would naturally find and use it if it were right next to 
`get` and `get_or_create` (in docs, autocomplete, search in your codebase, 
etc.).

> I believe the main objection is against adding additional API to 
querysets.

Yeah, I hope I'm not coming off as being too pushy, but I'm just curious 
why that is. Mariusz or Adam, did what I said about it being *more* than 
just an alias for `filter().first()` make sense or am I missing something? 
(Different behavior for multiple results — on accident or otherwise)

Dave
On Monday, July 11, 2022 at 1:06:04 AM UTC-5 m...@feinheit.ch wrote:

> Hi
>
> I believe the main objection is against adding additional API to 
> querysets. get_object_or_404 only converts DoesNotExist into a 404 
> exception and doesn't handle MultipleObjectsReturned. 
>
> I'm not the first to suggest adding an additional shortcut, e.g. 
> django.shortcuts.get_object_or_none which would work similarly to 
> get_object_or_404 (and get_list_or_404 for that matter). The existing 
> shortcuts use functionality from several parts of Django (the ORM and the 
> request/response handling) which get_object_or_none wouldn't do, but its 
> behavior would be so close to what get_object_or_404 is doing that it may 
> be alright.
>
> OTOH even the implementation of this shortcut is so simple that I just add 
> it to each project when I have a need for it (I had a hard time finding it 
> because it comes up much less often than I thought it did). So I am not 
> proposing this addition personally but I wouldn't be against it either (if 
> that counts for anything).
>
> Best regards,
> Matthias
>
>
>
> def get_object_or_none(klass, *args, **kwargs):
> queryset = _get_queryset(klass)
> if not hasattr(queryset, "get"):
> klass__name = (
> klass.__name__ if isinstance(klass, type) else 
> klass.__class__.__name__
> )
> raise ValueError(
> "First argument to get_object_or_404() must be a Model, 
> Manager, "
> "or QuerySet, not '%s'." % klass__name
> )
>     try:
> return queryset.get(*args, **kwargs)
> except queryset.model.DoesNotExist:
> return None
>
>
>
> On Sun, Jul 10, 2022 at 10:13 PM Dave Gaeddert  
> wrote:
>
>> Fair enough. To me, the `get_or_none` behavior with multiple results 
>> would still be to raise an exception (so it is just like `get` in that 
>> sense). And that’s the reason I personally don’t just see it as a shortcut 
>> for `filter().first()` — I have (as I’m sure others have) made the mistake 
>> before of *thinking* that I was using a unique query when that wasn’t 
>> necessarily true, so the multiple results exception has caught mistakes at 
>> runtime. I’d rather have that exception than use `filter().first()` and 
>> potentially show the wrong object to the wrong user, for example, and not 
>> figure out that I have a uniqueness/db problem. I like the fact that `get` 
>> raises those exceptions, I just think that try/except DoesNotExist/None is 
>> such a common behavior that a shortcut for *that* would actually be 
>> useful.
>>
>> Dave
>> On Sunday, July 10, 2022 at 3:24:32 AM UTC-5 Adam Johnson wrote:
>>
>>> I'm also against adding get_or_none(), for the same reasons. Adding a 
>>> method to shortcut something that can already be done doesn't seem worth it 
>>> to me.
>>>
>>> On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak  
>>> wrote:
>>>
>>>> I'm against it because it's already easily achievable and it's 
>>>> debatable how it should behave with many results. IMO any new method would 
>>>> be confusing and in the case of unique filtering 
>>>> `get_or_none(unique_filters)` would be an alias for 
>>>> `.filter(unique_filters).first()`. To me, this is duplication of an API.
>>>>
>>>> There are several -0 in the previous thread (Shai, Florian) and you can 
>>>> count -1 from me.
>>>>
>>>> Best,
>>>> Mariusz
>>>>
>>>> -- 
>>>> You received this messa

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

Fair enough. To me, the `get_or_none` behavior with multiple results would 
still be to raise an exception (so it is just like `get` in that sense). 
And that’s the reason I personally don’t just see it as a shortcut for 
`filter().first()` — I have (as I’m sure others have) made the mistake 
before of *thinking* that I was using a unique query when that wasn’t 
necessarily true, so the multiple results exception has caught mistakes at 
runtime. I’d rather have that exception than use `filter().first()` and 
potentially show the wrong object to the wrong user, for example, and not 
figure out that I have a uniqueness/db problem. I like the fact that `get` 
raises those exceptions, I just think that try/except DoesNotExist/None is 
such a common behavior that a shortcut for *that* would actually be useful.

Dave
On Sunday, July 10, 2022 at 3:24:32 AM UTC-5 Adam Johnson wrote:

> I'm also against adding get_or_none(), for the same reasons. Adding a 
> method to shortcut something that can already be done doesn't seem worth it 
> to me.
>
> On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak  
> wrote:
>
>> I'm against it because it's already easily achievable and it's debatable 
>> how it should behave with many results. IMO any new method would be 
>> confusing and in the case of unique filtering `get_or_none(unique_filters)` 
>> would be an alias for `.filter(unique_filters).first()`. To me, this is 
>> duplication of an API.
>>
>> There are several -0 in the previous thread (Shai, Florian) and you can 
>> count -1 from me.
>>
>> Best,
>> Mariusz
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dbee041d-4f80-4e61-bf0a-1d6f4e2e22e6n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

Hey Mariusz, thanks for the link — I found some other threads but not that 
one. Would you mind saying why you're personally against it (`get_or_none` 
specifically)?

At least how I read that thread, there was more debate about how to add it 
than whether to add it at all, and then Cal sort of "gave up" by suggesting 
a docs patch that I'm not sure ever happened anyway. I don't want to kick 
off a huge thing about it, but that one was 8 years ago and, like you said, 
it has come up a number of times over the years (maybe that's normal). 

Thanks!
Dave
On Wednesday, July 6, 2022 at 11:35:36 PM UTC-5 Mariusz Felisiak wrote:

> Hi,
>
> Adding `get_or_none()` was discussed several times and was always 
> rejected. This thread 
> <https://groups.google.com/g/django-developers/c/h50RLblVDU8/m/vuffkI2aylgJ> 
> has a nice summary. Personally, I'm still against it.
>
> Best,
> Mariusz
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/46daf75f-bb6b-457a-8889-47b148b20d61n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

I'm new to this... anybody know how the best way to push this forward? Or 
who can make a decision on whether something could/should be added to 
Django? I see some other tickets/discussions about basically the same thing:
https://code.djangoproject.com/ticket/17546

A lot has changed in 10+ years... seems like this could be reconsidered.

On Tuesday, June 28, 2022 at 9:27:52 AM UTC-5 Dave Gaeddert wrote:

> > To begin with - thats the place I dont like .get() at all. The fact that
> > it might end up with multiple objects is a nuisance, but we cannot do
> > much about it for API compat reasons
> > ...
>
> For what it's worth, I agree with what you're saying here too. Having a 
> `unique_or_none` (and maybe `unique`) with that field checking could be 
> cool, but in the interest of actually getting a change into Django, I 
> assume `get_or_none` without that behavior is a much easier place to start.
>
> On Sunday, June 26, 2022 at 2:07:34 PM UTC-5 j.bre...@netzkolchose.de 
> wrote:
>
>> Well from my own habits to use .get() only for unique filtering (>80% on 
>> pks only) I also see some benefit of a .get_or_none() variant - it would 
>> stop writing those exception handler wrappers over and over halfway 
>> during project realization. A ready-to-go official way would reduce that 
>> to a conditional expression from line one on.
>>
>> > .get_or_none() probably should allow to query only pks and
>> > unique_together fields, so there will be no third state?
>>
>> To begin with - thats the place I dont like .get() at all. The fact that 
>> it might end up with multiple objects is a nuisance, but we cannot do 
>> much about it for API compat reasons. Idea - if we want such a changed 
>> behavior - maybe call it "unique_or_none()" to make the difference 
>> clear? If its called .get_or_none() imho it is better to stick to .get() 
>> behavior regarding multiple objects (still raising).
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e21c2c22-5ba2-4421-8724-fa3f7e8f0b19n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

> To begin with - thats the place I dont like .get() at all. The fact that
> it might end up with multiple objects is a nuisance, but we cannot do
> much about it for API compat reasons
> ...

For what it's worth, I agree with what you're saying here too. Having a 
`unique_or_none` (and maybe `unique`) with that field checking could be 
cool, but in the interest of actually getting a change into Django, I 
assume `get_or_none` without that behavior is a much easier place to start.

On Sunday, June 26, 2022 at 2:07:34 PM UTC-5 j.bre...@netzkolchose.de wrote:

> Well from my own habits to use .get() only for unique filtering (>80% on 
> pks only) I also see some benefit of a .get_or_none() variant - it would 
> stop writing those exception handler wrappers over and over halfway 
> during project realization. A ready-to-go official way would reduce that 
> to a conditional expression from line one on.
>
> > .get_or_none() probably should allow to query only pks and
> > unique_together fields, so there will be no third state?
>
> To begin with - thats the place I dont like .get() at all. The fact that 
> it might end up with multiple objects is a nuisance, but we cannot do 
> much about it for API compat reasons. Idea - if we want such a changed 
> behavior - maybe call it "unique_or_none()" to make the difference 
> clear? If its called .get_or_none() imho it is better to stick to .get() 
> behavior regarding multiple objects (still raising).
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b630d7a0-d832-41d0-985b-a7ae7ac1f1b6n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

I'll lob in my 2 cents that I actually think `get_or_none` would be great 
to have, in the same way that I imagine people think `get_or_create` is 
useful. You can try/catch yourself in both cases (example is basically the 
exact same 
https://docs.djangoproject.com/en/4.0/ref/models/querysets/#get-or-create), 
but especially for people new to Django, having a method for it is a lot 
easier to grasp. The MultipleObjectsReturned exception is more of a 
modeling/uniqueness error in my experience (not sure I've ever written a 
catch for this...), but doing .get and knowing it may not exist is super 
common — much easier to have a method for that than force everyone to think 
through all the ramifications of using .get vs .filter (and/or .first) etc.

I'd also guess that people don't want to create a Manager if they don't 
have to (which I'd also consider an advanced topic).

https://stackoverflow.com/questions/3090302/how-do-i-get-the-object-if-it-exists-or-none-if-it-does-not-exist-in-django

Dave

On Wednesday, June 22, 2022 at 5:27:52 AM UTC-5 j.bre...@netzkolchose.de 
wrote:

> I somewhat second what Adrian wrote:
>
> - try-except handling seems to be the most idiomatic way to me
> - a flag altering API behavior as .get(..., raises=False) might come 
> handy, and to avoid naming collisions in arguments this could also be 
> shaped as a separate get_or_none() method - but: I somewhat doubt its 
> usefulness just cluttering the API further for low benefit, also nothing 
> stops you from wrapping the exception way into such a query helper (or a 
> more advanced resemblance of .get as Uri does). In fact the exception 
> will create a tiny runtime overhead on interpreter side, but thats 
> really tiny compared to the db roundtrip (thus against the whole .get + 
> helper runtime).
>
> Imho a chaining .checked() method on the manager/queryset is not a good 
> idea, as it might create more API ambiguity - What should .checked() do, 
> if it is not followed by .get()?
>
> Cheers, jerch
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c9833cf7-6113-4405-b5e6-8de2dda1fdb6n%40googlegroups.com.

Re: Auto-installation of 3rd party packges

[Dave R]

Thanks Kacper!

The Github README.md should be complete and up to date now.  I hope this 
project gets some traction.  I put a lot of time into it and could use help 
writing installation files for the most common 3rd party Django packages 
e.g., django-allauth, django-filter, etc.

If anyone here thinks my approach is misguided for any reason, I'm 
definitely interested in hearing about that perspective as well.

Thanks all!
Dave

On Monday, July 20, 2020 at 8:11:20 AM UTC-4 szmigie...@gmail.com wrote:

> Hey!
>
> Back in the day, like 2017 or something, I was using Ansible tool for such 
> things. As far as I know (unfortunately I don't work on Django projects on 
> daily basis today) now it's pretty standard to set up a project once, and 
> later just use Docker for a unified dev environment.
>
> I've starred your project, I keep my fingers crossed for its success and 
> development.
>
> Best wishes,
> Kacper Szmigiel
>
> pon., 20 lip 2020 o 11:58 Dave R  napisał(a):
>
>> Hello all,
>> I recently got done with v1 of this project:
>> https://github.com/pandichef/indjections
>>
>> It's an installation utility for 3rd party Django packages.
>>
>> But then I started thinking about the issue more generally...
>>
>> I'm writing here because I'm kind of amazed why Django package 
>> installation often requires so many steps e.g., various configurations in 
>> settings.py,  some kind URL support in urls.py, add some stuff to 
>> base.html.  See django-hijack 
>> <https://django-hijack.readthedocs.io/en/stable/#installation>and 
>> django-allauth 
>> <https://django-allauth.readthedocs.io/en/latest/installation.html> as 
>> examples.
>>
>> It's all reminiscent of Python package distribution before distutils.
>>
>> I think some kind of automated way to install packages should be part of 
>> the Django itself.  Just a thought...
>>
>> My solution is to insert bits of code in the "right" places.   I'm 
>> curious how others have solved this problem.
>>
>> Thanks,
>> Dave
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/7c10b710-7abf-42e6-b41d-3e856aad288an%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/7c10b710-7abf-42e6-b41d-3e856aad288an%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8425bcbd-f8aa-4e9a-adc1-0e048a0ca6e6n%40googlegroups.com.

Re: f-strings again.

[Dave Vernon]

Hi Shai,

If you used  '<{0} id="{1}"> {2} '.format(tag, id, content) in a
templatetag (for example), it could easily be used iteratively which would
increase the need for performance and at that point, you could argue that
f'<{tag} id="{id}"> {content} ' would be a preferable choice, even
though you are repeating the 'tag' argument.

More generally:

I understand the value of *not* doing a bulk change in a PR, but I was
wondering if it's OK to do a PR based purely on improved performance for a
specific element? (I don't have one in mind, the question is purely 'in
principle')

Thanks,

Dave


On Tue, 21 Jul 2020 at 12:08, Shai Berger  wrote:

> On Tue, 21 Jul 2020 01:28:31 -0700 (PDT)
> Carlton Gibson  wrote:
> >
> > Certainly 99% of cases can be handled as cleanly (or more so, because
> > I guess we fell `format()` is a little verbose) with %-formatting or
> > an f-string.
> > But if we say format() is not allowed, don't we then guarantee we hit
> > the one case in X where "Actually, this version with format() is much
> > cleaner"?
> >
> FWIW, it seems to me one case where this happens is when you want to
> use one argument multiple times, without naming:
>
> '<{0} id="{1}"> {2} '.format(tag, id, content)
>
> Arguably, this specific example would look better with named references,
> but, IMO, not with % formatting:
>
> '<%(tag)s id="%(id)s"> %(content)s ' % dict(
> tag=tag,id=id, content=content
> )
>
> and as noted, f-strings have their limitations.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20200721140822.47376bd8.shai%40platonix.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADqmmRygoVynBgrYp1NwpJj3XTmeWFWNCVWP5zznCrstPXQd2A%40mail.gmail.com.

Re: f-strings again.

[Dave Vernon]

+1, I'd happily help on any PR with this (it would be my first!).

Kind Regards,

Dave

Springbourne Tech Limited
M: +44(0) 79 2107 6483
W: www.springbourne-tech.com





*—This E-Mail and its contents are confidential, protected by law
and legally privileged.  Only access by the addressee is authorised.  Any
liability (in negligence, contract or otherwise) arising from any third
party taking any action or refraining from taking any action on the basis
of any of the information contained in this E-Mail is hereby excluded to
the fullest extent of the law.  In the event that you are not the
addressee, please notify the sender immediately.  Do not discuss, disclose
the contents to any person or store or copy the information in any medium
or use it for any purpose whatsoever.*




On Tue, 21 Jul 2020 at 09:43, Nick Pope  wrote:

> Hi,
>
> So I'm in favour of using f-strings, but agree that there are places where
> they are not appropriate.
>
> I am also against bulk updates in this case as mentioned in my previous
> comment
> <https://github.com/django/django/pull/12650#issuecomment-607707454>. I
> don't think we should exclude replacing .format() with f-strings on a
> case-by-case basis, however, where performance is a concern.
>
> Thanks for your initial documentation, Carlton. Am wondering whether we
> should be more explicit about the pros and cons of each to help people make
> the correct decision? Here are my thoughts:
>
> %-formatting:
>
> + Simple to use printf-style familiar to all.
> + Default (can be changed
> <https://docs.python.org/3/howto/logging-cookbook.html#formatting-styles>)
> style used internally by the logging module, e.g. logging.info('Message
> with %s.', value)
> − Much less flexibility for formatting, see pyformat.info.
>
> ``.format()``:
>
> + Useful for interpolating a stored template string, e.g. from a database,
> which isn't possible with f-strings.
> − Worst performance due to method call.
> − Much more verbose, makes code less readable.
>
> f-strings:
>
> + Better performance than other methods due to dedicated FORMAT_VALUE
> <https://bugs.python.org/issue25483> opcode.
> + Allows for embedding more complex expressions, e.g. f'Hello
> {user.get_full_name()}'
> + Much more concise, makes code more readable.
> − Cannot be used if string must be translated.
> − Complex expressions can get out of control. A sensible balance needs to
> be struck.
>
> Regarding performance, here are some simple numbers:
>
> python -m timeit -s 'x="test"' 'f"{x}"'
> 2000 loops, best of 5: 11.8 nsec per loop
> $ python -m timeit -s 'x="test"' '"%s" % x'
> 1000 loops, best of 5: 39.1 nsec per loop
> $ python -m timeit -s 'x="test"' '"{}".format(x)'
> 500 loops, best of 5: 76.1 nsec per loop
>
> I think it is probably also worth updating the documentation added in this
> commit
> <https://github.com/django/django/commit/c3437f734d03d93f798151f712064394652cabed>.
> It isn't that xgettext doesn't support f-strings... It does:
>
> $ echo "_('Hello %s') % user.username" | xgettext --language=python
> --omit-header --output=- -
> #: standard input:1
> #, python-format
> msgid "Hello %s"
> msgstr ""
> $ echo "_('Hello {}').format(user.username)" | xgettext --language=python
> --omit-header --output=- -
> #: standard input:1
> msgid "Hello {}"
> msgstr ""
> $ echo "_('Hello {name}').format(name=user.username)" | xgettext
> --language=python --omit-header --output=- -
> #: standard input:1
> #, python-brace-format
> msgid "Hello {name}"
> msgstr ""
> $ echo "_(f'Hello {user.username}')" | xgettext --language=python
> --omit-header --output=- -
> #: standard input:1
> #, python-brace-format
> msgid "Hello {user.username}"
> msgstr ""
> $ echo "_(f'Hello {user.get_full_name()}')" | xgettext --language=python
> --omit-header --output=- -
> #: standard input:1
> msgid "Hello {user.get_full_name()}"
> msgstr ""
>
> It is actually that Python doesn't support modifying the template string
> prior to interpolating the values which is the requirement for injecting
> the translated string. PEP 498 <https://www.python.org/dev/peps/pep-0498/>
> makes no explicit mention of this. PEP 501
> <https://www.python.org/dev/peps/pep-0501/> was initially looking at
> solving the problem but was deemed a poor fit and was also deferred.
>
> Kind regards,
>
> Nick
> On Tuesday, 21 July 2020 at 08:28:54 UTC+1 Mariusz Felisiak wrote:
>
>> Hi y'all,
>>
>> I will not stand 

Auto-installation of 3rd party packges

[Dave R]

Hello all,
I recently got done with v1 of this project:
https://github.com/pandichef/indjections

It's an installation utility for 3rd party Django packages.

But then I started thinking about the issue more generally...

I'm writing here because I'm kind of amazed why Django package installation 
often requires so many steps e.g., various configurations in settings.py,  
some kind URL support in urls.py, add some stuff to base.html.  See 
django-hijack <https://django-hijack.readthedocs.io/en/stable/#installation>
and django-allauth 
<https://django-allauth.readthedocs.io/en/latest/installation.html> as 
examples.

It's all reminiscent of Python package distribution before distutils.

I think some kind of automated way to install packages should be part of 
the Django itself.  Just a thought...

My solution is to insert bits of code in the "right" places.   I'm curious 
how others have solved this problem.

Thanks,
Dave

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7c10b710-7abf-42e6-b41d-3e856aad288an%40googlegroups.com.

Re: Deadlock bug in logging? Reproducible case

[Dave Vernon]

Sorry - that message was sent as a 'reply' in error - my colleague uses
ajax with Django a lot and I was trying to forward this to him.

Kind Regards,

Dave


On Wed, 22 Apr 2020 at 18:23, Brian Tiemann  wrote:

> Hi all,
>
> I was directed here after getting corroboration on #django and elsewhere.
>
> I have what appears to be a bug in which a Django app can deadlock if you
> hit it with a lot (>3) of AJAX requests within a short time (i.e. all
> triggered in parallel from a single HTML page). I have a reproducible case
> here:
>
> https://github.com/data-graham/wedge
>
> I'd really appreciate it if someone could take a look and let me know
> whether I'm doing something wrong, or if there's something systemic going
> on. Thanks much!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7fa1a28d-8f54-48cd-9c34-5d1c111ef136%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/7fa1a28d-8f54-48cd-9c34-5d1c111ef136%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

Re: Deadlock bug in logging? Reproducible case

[Dave Vernon]

FYI 

Sent from my iPhone

> On 22 Apr 2020, at 18:23, Brian Tiemann  wrote:
> 
> 
> Hi all,
> 
> I was directed here after getting corroboration on #django and elsewhere.
> 
> I have what appears to be a bug in which a Django app can deadlock if you hit 
> it with a lot (>3) of AJAX requests within a short time (i.e. all triggered 
> in parallel from a single HTML page). I have a reproducible case here:
> 
> https://github.com/data-graham/wedge
> 
> I'd really appreciate it if someone could take a look and let me know whether 
> I'm doing something wrong, or if there's something systemic going on. Thanks 
> much!
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7fa1a28d-8f54-48cd-9c34-5d1c111ef136%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6BEF80E7-AC03-46A3-91B0-686146F7C17F%40springbourne-tech.com.

Re: Improve migration conflict detection

[Dave Vernon]

+1 charettes too; to add to the factors to consider I suspect the issue of 
keeping it performant too (especially for unit tests) could become a 
challenge.

On Tuesday, February 18, 2020 at 7:08:51 PM UTC, charettes wrote:
>
> +1 to what Tim said.
>
> Also what about migration leaf migrations with models that refer to each 
> others? What about a model rename in a leaf node that a model in the other 
> leaf references to for some attribute names (e.g. m2m field intermediary 
> table name).
>
> I don't want to discourage you from trying because you'll likely learn a 
> ton of stuff trying but I'm worried this might be a dead end or cause the 
> migration framework code to be even more complex than it already is.
>
> Le mardi 18 février 2020 13:45:09 UTC-5, Tim Graham a écrit :
>>
>> Have you considered what would happen if a migration has a RunPython or 
>> RunSQL? They may require a certain model state.
>>
>> On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>>>
>>> I’m working on this as a standalone PoC app for now, I may be able to 
>>> share a repository with the code soon in order to get some feedback
>>>
>>> Here’s in simple words where I’m at:
>>>
>>> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
>>> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
>>> with this, you can have more than one person changing different models in 
>>> the same app, without introducing conflicts. Migrations referring to the 
>>> same app and model would still cause a conflict
>>>
>>> * I’m now trying to get the migration graph’s forwards/backwards plan to 
>>> handle cases where there are more than one leaf node in the graph.
>>>
>>> I may be doing the wrong assumption here, but it seems to me that 
>>> migrations changing different models shouldn’t introduce a real conflict? 
>>> If I have the following migration graph:
>>>
>>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
>>> 0004_auto ]
>>>
>>> Where 0003_abc and 0003_def don’t have any model changes in common: no 
>>> FK references, nothing related at all
>>>
>>> If this assumption is correct, I could have the two migrations in ANY 
>>> order in the graph, that it would still give me the same result, for 
>>> example:
>>>
>>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
>>> 0004_auto ]
>>>
>>>
>>> Please let me know if I’m missing something, ideas and thoughts are 
>>> really welcome :)
>>>
>>>
>>> [1] 
>>> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>>>
>>> --
>>> Caio Ariede
>>> caio@gmail.com
>>>
>>>
>>>
>>>
>>> On Feb 13, 2020, at 11:49, Dave Vernon  
>>> wrote:
>>>
>>> If I had to guess, it would be that with more than one leaf node, you 
>>> would end up a substantial challenge resolving dependancies which would 
>>> create an Order(N) problem (i.e. there's a chance of excessive time to 
>>> complete the resolution).
>>>
>>> I certainly worked on some migration logic that took a similar approach 
>>> to this.
>>>
>>>
>>> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>>>>
>>>> I don’t think many people can answer this off the top of their heads. I 
>>>> certainly can’t and I have contributed a couple things to migrations.
>>>>
>>>> It’s probably quite necessary there’s only one leaf node but I can’t 
>>>> say for sure.
>>>>
>>>> On Thu, 13 Feb 2020 at 13:58, caio  wrote:
>>>>
>>>>> Cool. If I'm understanding this correctly, it auto-resolves during 
>>>>> *makemigrations*?
>>>>>
>>>>> I'm looking for something that could handle conflicts during the 
>>>>> *migrate* command, but I'm not sure if that's really possible. I 
>>>>> guess it depends on how intrinsic the single-leaf-node restriction is to 
>>>>> the whole migration system
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>>>>> escreveu:
>>>>>>
>>>>>> Definitely a plus one on auto resolving mi

Re: Improve migration conflict detection

[Dave Vernon]

What if the migrations aren't merged before 0004 is created and you get:

[ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0004(a) ]

and 

[ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0004(b) ]

where 0004(a) != 0004(b) and 0004(a) modifies the model schema in a way 
that overwrites 0003_def's change but then 0004(b) relies on 0003_def.

To be sure, I think at that point you need to check for all conflicts 
downstream and their inter-dependancy not just down their own branch, but 
all migrations down each diverged branch; also it wouldn't be enough to 
compare each equivalent step number, e.g in our example above you now need 
to check 0004(a) against 0003_def as well as against 0004(b), etc...







On Tuesday, February 18, 2020 at 6:45:09 PM UTC, Tim Graham wrote:
>
> Have you considered what would happen if a migration has a RunPython or 
> RunSQL? They may require a certain model state.
>
> On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>>
>> I’m working on this as a standalone PoC app for now, I may be able to 
>> share a repository with the code soon in order to get some feedback
>>
>> Here’s in simple words where I’m at:
>>
>> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
>> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
>> with this, you can have more than one person changing different models in 
>> the same app, without introducing conflicts. Migrations referring to the 
>> same app and model would still cause a conflict
>>
>> * I’m now trying to get the migration graph’s forwards/backwards plan to 
>> handle cases where there are more than one leaf node in the graph.
>>
>> I may be doing the wrong assumption here, but it seems to me that 
>> migrations changing different models shouldn’t introduce a real conflict? 
>> If I have the following migration graph:
>>
>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
>> 0004_auto ]
>>
>> Where 0003_abc and 0003_def don’t have any model changes in common: no FK 
>> references, nothing related at all
>>
>> If this assumption is correct, I could have the two migrations in ANY 
>> order in the graph, that it would still give me the same result, for 
>> example:
>>
>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
>> 0004_auto ]
>>
>>
>> Please let me know if I’m missing something, ideas and thoughts are 
>> really welcome :)
>>
>>
>> [1] 
>> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>>
>> --
>> Caio Ariede
>> caio@gmail.com
>>
>>
>>
>>
>> On Feb 13, 2020, at 11:49, Dave Vernon  
>> wrote:
>>
>> If I had to guess, it would be that with more than one leaf node, you 
>> would end up a substantial challenge resolving dependancies which would 
>> create an Order(N) problem (i.e. there's a chance of excessive time to 
>> complete the resolution).
>>
>> I certainly worked on some migration logic that took a similar approach 
>> to this.
>>
>>
>> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>>>
>>> I don’t think many people can answer this off the top of their heads. I 
>>> certainly can’t and I have contributed a couple things to migrations.
>>>
>>> It’s probably quite necessary there’s only one leaf node but I can’t say 
>>> for sure.
>>>
>>> On Thu, 13 Feb 2020 at 13:58, caio  wrote:
>>>
>>>> Cool. If I'm understanding this correctly, it auto-resolves during 
>>>> *makemigrations*?
>>>>
>>>> I'm looking for something that could handle conflicts during the 
>>>> *migrate* command, but I'm not sure if that's really possible. I guess 
>>>> it depends on how intrinsic the single-leaf-node restriction is to the 
>>>> whole migration system
>>>>
>>>> Thanks!
>>>>
>>>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>>>> escreveu:
>>>>>
>>>>> Definitely a plus one on auto resolving migrations a test package 
>>>>> still in planning aims to solve this 
>>>>> https://github.com/jackton1/django-migration-resolver-hook
>>>>>
>>>>> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>>>>>
>>>>> Hey folks,
>>>>>
>>>>> I was looking 

Re: Improve migration conflict detection

[Dave Vernon]

If I had to guess, it would be that with more than one leaf node, you would 
end up a substantial challenge resolving dependancies which would create an 
Order(N) problem (i.e. there's a chance of excessive time to complete the 
resolution).

I certainly worked on some migration logic that took a similar approach to 
this.


On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>
> I don’t think many people can answer this off the top of their heads. I 
> certainly can’t and I have contributed a couple things to migrations.
>
> It’s probably quite necessary there’s only one leaf node but I can’t say 
> for sure.
>
> On Thu, 13 Feb 2020 at 13:58, caio > 
> wrote:
>
>> Cool. If I'm understanding this correctly, it auto-resolves during 
>> *makemigrations*?
>>
>> I'm looking for something that could handle conflicts during the 
>> *migrate* command, but I'm not sure if that's really possible. I guess 
>> it depends on how intrinsic the single-leaf-node restriction is to the 
>> whole migration system
>>
>> Thanks!
>>
>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>> escreveu:
>>>
>>> Definitely a plus one on auto resolving migrations a test package still 
>>> in planning aims to solve this 
>>> https://github.com/jackton1/django-migration-resolver-hook
>>>
>>> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>>>
>>> Hey folks,
>>>
>>> I was looking at the code used to detect conflicts in migrations [1]. It 
>>> seems to use a very safe approach, by avoiding with multiple node leafs in 
>>> the migration graph.
>>>
>>> While this is safe, I’ve been having some problems when it comes to 
>>> scalability when having multiple migrations created in a short period of 
>>> time (for the same app).
>>>
>>> Questions:
>>>
>>> 1. Are there any obvious impediments on improving the conflicts 
>>> detection?
>>> 2. Does anyone have ideas on how to improve the conflict detection? (eg. 
>>> going down from app-level to model-level detection)
>>>
>>>
>>> Thanks!
>>>
>>>
>>> [1] 
>>> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
>>>  
>>> 
>>>
>>> --
>>> Caio Ariede
>>> caio@gmail.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-d...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/31d78cfc-05bc-4bee-897b-3d9e2e502a3d%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd688186-752b-4bf5-9340-5d9607d17038%40googlegroups.com.

Re: Adding support for SQL Server

[Dave Clevenger]

I would definitely get behind official support for SQL Server. The company
I work for is all about SQL Server and not willing to consider other
options. Right now we are using the django-mssql-backend:
https://github.com/ESSolutions/django-mssql-backend which works pretty well
for our use case, but official SQL Server support would be great.

Dave

On Wed, Feb 12, 2020 at 5:44 PM Adam Johnson  wrote:

> Microsoft posted in 2015 and there was an update last April about a
> working backend that claims support for 3.0:
> https://groups.google.com/d/msg/django-developers/FbBcUCzrSZo/EoFNbR2BDgAJ
>
> Any support in core would need clear evidence of widespread demand. I
> don't think there's much demand - e.g. that backend has only 38 stars on
> GitHub.
>
> On Wed, 12 Feb 2020 at 20:33, Martynas Puronas 
> wrote:
>
>> Hey, I've been working on adding support for SQL Server to Django, since
>> the package currently being linked recommended in Django's documentation
>> has been abandoned (as well as a few others seem to be either abandoned or
>> do not have the test suite passing), and I have made some significant
>> progress on it (all of admin tests are passing, as well as aggregates,
>> inserts, deletes, updates and a few other modules). I was wondering if you
>> would be open to adding support for SQL Server, provided I could make sure
>> that the entire test suite passes, and documentation is written? Or does
>> this go against Django's technical roadmap and you would rather keep
>> support for SQL Server outside of Django in a separate package?
>>
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/6d98459d-9616-4343-b4fe-3eabd9ef131f%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/6d98459d-9616-4343-b4fe-3eabd9ef131f%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2hna%2B%3D%3DPuHKjH0xzJmEGzReDP3DFyJwX2L2bt%3DtsR97Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2hna%2B%3D%3DPuHKjH0xzJmEGzReDP3DFyJwX2L2bt%3DtsR97Q%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

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

Re: Ideas for a new DEP on long-term Django API compatibility

[Dave Burkholder]

> I love where Django is headed. I love all of those breaking changes that 
have to happen so we're not perpetually stuck with decisions from 2005.

+100 to this!!

Django user since 1.6 running on python2.6. Upgraded to 1.7 and python3.4 
at the same time, and _that_ migration was hard. Everything since then has 
been a cakewalk. 

Mega-props to the caretakers of Django. Carry on...!



On Monday, August 19, 2019 at 11:51:33 AM UTC-4, Patryk Zawadzki wrote:
>
> As someone who has spent over 12 years working with Django, I'd like to 
> offer an opposite point of view:
>
> I love where Django is headed. I love all of those breaking changes that 
> have to happen so we're not perpetually stuck with decisions from 2005.
>
> What I truly miss is strong static typing support that would tell that 
> when my code is not going to work before I even begin to test it. With 
> static types and tools like mypy and pyright upgrading dependencies is 
> usually a matter of a single afternoon.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b6f6b14-c3cc-4ba9-9d77-92ecaab23e11%40googlegroups.com.

Connecting to remote host like Twitch to monitor chat using websockets

[Dave Holly]

Greetings,

Is it possible to use Django Channels and websockets to monitor the chat in 
twitch rooms, or other sites with chat rooms?  I would like to display 
extra graphics for users who send cheers of high amounts, like 1000, 2000, 
etc.  I have the display worked out in Django where I'm monitoring a simple 
local chat.  This would be used as an overlay web page for OBS for the 
broadcaster.  When someone posts a specific cheer amount, the javascript 
displays a message or gif on the overlay web page with a short timeout.  
It's basically to say Thank You to the tipper.

I haven't found any documentation or tutorials on using Django Channels for 
anything but setting up my own chat program.  

In the consumers, is there a way to connect to a site like twitch and 
search the DOM for specific chat messages, like cheers?  


Thanks.

-- 
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/196c5d4c-6ced-400d-a953-53918980eca8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PatchHammer 40,000

[Dave McLain]

I have apologized on #django-dev as well, but I do feel like I ought to
throw my mea culpa up here as well for posterity. I misread Jacob's "I think
this is a great idea" to mean "Go ahead and set 'Patch needs Improvement'"
on 100 tickets rather than what I should have read "Some method of
automatically checking patches and giving some feedback, but without
spamming the world would be great".

I let my enthusiasm get the best of me and as penance I'll spend some hours
trying to get some of the patches that I just let a script say need
improvement to apply cleanly.


dave

On Thu, May 5, 2011 at 2:00 PM, Jannis Leidel <lei...@gmail.com> wrote:

> Hi all,
>
> After having gotten almost 100 emails from patchhammer via Trac in under a
> minute, I'd like to suggest to be a bit less hammer-y and let actual humans
> review the patches instead of doing the patch apply check.
>
> In my experience attached patches usually only need little modification to
> land in trunk (if otherwise in good shape), so I see not much usefulness
> with auto-adding info that the file needs to be updated to the latest state
> of trunk.
>
> In other words, using a bot on a ticket tracker seems rather counter
> productive to me.
>
> Jannis
>
> On 05.05.2011, at 13:21, Dave McLain wrote:
>
> > I've been trying to move along some tickets that are in the 'Patch Needs
> Review' category, in the hopes that I might accrue enough karma that
> somebody would promote #15900 to ready for commit.
> >
> > I got frustrated with the number of patches that wouldn't merge with
> trunk, so like any sane person would at 2 in the morning I started writing a
> script that would screen scrape the Ready For Commit report, download the
> patches for every ticket and automatically try to merge them with -p0, -p1
> and the -R for both of those. It's 6am now, so I'm going to bed before
> throwing the source up on github, but I'll post the results below and open
> source the script in the morning (or afternoon).
> >
> > The next step would be to automatically set the "Patch Needs Improvement"
> bit, but I figured I probably ought to get some more opinions than just a
> straw poll on #django-dev.
> >
> >
> > dave
> >
> > ps. I've got an improvement to #15900 to get rid of it's nasty abuse of
> **kwargs, so please don't promote it. Thanks julien.
> >
> > 2594 - FAIL
> > 3202 - SUCCESS
> > 4117 - FAIL
> > 4198 - FAIL (NO PATCH)
> > 4287 - SUCCESS
> > 4978 - FAIL (NO PATCH)
> > 5014 - SUCCESS
> > 5025 - SUCCESS
> > 5373 - SUCCESS
> > 5418 - FAIL
> > 5423 - SUCCESS
> > 5446 - FAIL
> > 5611 - FAIL
> > 5704 - FAIL
> > 5789 - FAIL
> > 5899 - FAIL
> > 6011 - SUCCESS
> > 6392 - FAIL
> > 6474 - FAIL
> > 6610 - FAIL
> > 6648 - FAIL
> > 8159 - FAIL
> > 8261 - FAIL
> > 8348 - FAIL
> > 8363 - FAIL
> > 8500 - FAIL
> > 8561 - FAIL
> > 8754 - FAIL
> > 8901 - FAIL
> > 9071 - FAIL
> > 9102 - SUCCESS
> > 9200 - FAIL
> > 9209 - FAIL
> > 9368 - FAIL
> > 9433 - SUCCESS
> > 9459 - FAIL
> > 9460 - FAIL
> > 9762 - FAIL
> > 9800 - SUCCESS
> > 9805 - SUCCESS
> > 10191 - SUCCESS
> > 10436 - FAIL
> > 10557 - FAIL
> > 10571 - FAIL
> > 10725 - SUCCESS
> > 10744 - FAIL
> > 10790 - FAIL
> > 10808 - FAIL
> > 10837 - FAIL
> > 10843 - FAIL
> > 10899 - SUCCESS
> > 10944 - SUCCESS
> > 10977 - FAIL
> > 11133 - FAIL
> > 11185 - SUCCESS
> > 11212 - SUCCESS
> > 11295 - FAIL
> > 11487 - FAIL
> > 11505 - SUCCESS
> > 11515 - FAIL
> > 11518 - FAIL (NO PATCH)
> > 11555 - SUCCESS
> > 11595 - SUCCESS
> > 11651 - FAIL
> > 11745 - SUCCESS
> > 11775 - FAIL
> > 11778 - FAIL
> > 11911 - SUCCESS
> > 11941 - FAIL
> > 12091 - FAIL
> > 12103 - SUCCESS
> > 12183 - FAIL (NO PATCH)
> > 12212 - FAIL
> > 12308 - FAIL
> > 12441 - SUCCESS
> > 12464 - FAIL
> > 12566 - FAIL
> > 12658 - FAIL
> > 12713 - SUCCESS
> > 12747 - FAIL
> > 12753 - SUCCESS
> > 12807 - FAIL
> > 12823 - FAIL
> > 12826 - FAIL
> > 12914 - FAIL
> > 12972 - FAIL
> > 12982 - SUCCESS
> > 13043 - FAIL
> > 13085 - SUCCESS
> > 13154 - FAIL
> > 13163 - FAIL
> > 13205 - FAIL
> > 13211 - FAIL
> > 13223 - SUCCESS
> > 13247 - FAIL
> > 13252 - FAIL
> > 13385 - FAIL
> > 13559 - FAIL
> > 13564 - FAIL
> > 13677 - FAIL
> > 13721 - FAIL
> > 13734 - FAIL
> > 13756 - SUC

PatchHammer 40,000

[Dave McLain]

I've been trying to move along some tickets that are in the 'Patch Needs
Review' category, in the hopes that I might accrue enough karma that
somebody would promote #15900 to ready for commit.

I got frustrated with the number of patches that wouldn't merge with trunk,
so like any sane person would at 2 in the morning I started writing a script
that would screen scrape the Ready For Commit report, download the patches
for every ticket and automatically try to merge them with -p0, -p1 and the
-R for both of those. It's 6am now, so I'm going to bed before throwing the
source up on github, but I'll post the results below and open source the
script in the morning (or afternoon).

The next step would be to automatically set the "Patch Needs Improvement"
bit, but I figured I probably ought to get some more opinions than just a
straw poll on #django-dev.


dave

ps. I've got an improvement to #15900 to get rid of it's nasty abuse of
**kwargs, so please don't promote it. Thanks julien.

2594 - FAIL
3202 - SUCCESS
4117 - FAIL
4198 - FAIL (NO PATCH)
4287 - SUCCESS
4978 - FAIL (NO PATCH)
5014 - SUCCESS
5025 - SUCCESS
5373 - SUCCESS
5418 - FAIL
5423 - SUCCESS
5446 - FAIL
5611 - FAIL
5704 - FAIL
5789 - FAIL
5899 - FAIL
6011 - SUCCESS
6392 - FAIL
6474 - FAIL
6610 - FAIL
6648 - FAIL
8159 - FAIL
8261 - FAIL
8348 - FAIL
8363 - FAIL
8500 - FAIL
8561 - FAIL
8754 - FAIL
8901 - FAIL
9071 - FAIL
9102 - SUCCESS
9200 - FAIL
9209 - FAIL
9368 - FAIL
9433 - SUCCESS
9459 - FAIL
9460 - FAIL
9762 - FAIL
9800 - SUCCESS
9805 - SUCCESS
10191 - SUCCESS
10436 - FAIL
10557 - FAIL
10571 - FAIL
10725 - SUCCESS
10744 - FAIL
10790 - FAIL
10808 - FAIL
10837 - FAIL
10843 - FAIL
10899 - SUCCESS
10944 - SUCCESS
10977 - FAIL
11133 - FAIL
11185 - SUCCESS
11212 - SUCCESS
11295 - FAIL
11487 - FAIL
11505 - SUCCESS
11515 - FAIL
11518 - FAIL (NO PATCH)
11555 - SUCCESS
11595 - SUCCESS
11651 - FAIL
11745 - SUCCESS
11775 - FAIL
11778 - FAIL
11911 - SUCCESS
11941 - FAIL
12091 - FAIL
12103 - SUCCESS
12183 - FAIL (NO PATCH)
12212 - FAIL
12308 - FAIL
12441 - SUCCESS
12464 - FAIL
12566 - FAIL
12658 - FAIL
12713 - SUCCESS
12747 - FAIL
12753 - SUCCESS
12807 - FAIL
12823 - FAIL
12826 - FAIL
12914 - FAIL
12972 - FAIL
12982 - SUCCESS
13043 - FAIL
13085 - SUCCESS
13154 - FAIL
13163 - FAIL
13205 - FAIL
13211 - FAIL
13223 - SUCCESS
13247 - FAIL
13252 - FAIL
13385 - FAIL
13559 - FAIL
13564 - FAIL
13677 - FAIL
13721 - FAIL
13734 - FAIL
13756 - SUCCESS
13794 - FAIL
13864 - FAIL
13875 - FAIL
13883 - FAIL
13896 - FAIL
13926 - FAIL
13956 - FAIL
14007 - FAIL
14045 - FAIL (NO PATCH)
14056 - SUCCESS
14093 - FAIL
14098 - FAIL
14129 - FAIL
14175 - SUCCESS
14202 - SUCCESS
14273 - SUCCESS
14315 - FAIL
14319 - FAIL
14390 - FAIL
14394 - SUCCESS
14396 - FAIL
14567 - SUCCESS
14571 - FAIL (NO PATCH)
14572 - SUCCESS
14618 - FAIL
14675 - FAIL
14678 - SUCCESS
14681 - FAIL
14757 - SUCCESS
14786 - SUCCESS
14903 - SUCCESS
14958 - FAIL
15064 - SUCCESS
15098 - SUCCESS
15126 - SUCCESS
15184 - SUCCESS
15206 - SUCCESS
15221 - FAIL
15231 - SUCCESS
15237 - SUCCESS
15255 - SUCCESS
15263 - FAIL
15266 - SUCCESS
15281 - FAIL
15305 - SUCCESS
15321 - SUCCESS
15354 - SUCCESS
15361 - SUCCESS
15499 - FAIL
15580 - SUCCESS
15595 - SUCCESS
15596 - SUCCESS
15675 - SUCCESS
15715 - SUCCESS
15768 - SUCCESS
15769 - SUCCESS
15782 - SUCCESS
15789 - SUCCESS
15790 - SUCCESS
15805 - SUCCESS
15829 - SUCCESS
15840 - FAIL
15869 - FAIL (NO PATCH)
15900 - SUCCESS
15907 - SUCCESS
15918 - FAIL
15935 - SUCCESS
15938 - SUCCESS
15954 - SUCCESS
15963 - FAIL

-- 
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: CsrfViewMiddleware and HTTPS

[Dave Peck]

Ah; now that I understand the purpose of the check, it all makes sense
to me. Thanks, Paul!

-Dave

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

CsrfViewMiddleware and HTTPS

[Dave Peck]

If you're using HTTPS, the CsrfViewMiddleware performs a same_origin
check on the domain.

Two questions:

1. What security issue does this prevent? (I assume some kind of MITM,
but I don't understand why would be important for HTTPS and not for
HTTP.)

2. Because the check uses request.get_host(), and get_host() honors
the X-Forwarded-Host header, isn't it possible to effectively thwart
the check by sending a bogus X-Forwarded-Host header as part of evil
requests?

Thanks,
Dave

-- 
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: Control json serialization

[Dave Dash]

Sasha,

At Mozilla we've found it incredibly useful to have a lot of control
on JSON serialization strictly for testing: 
https://github.com/davedash/django-fixture-magic

Take note of the fact that this is python, and Django doesn't need to
support all your desires, you can simply write your own apps that do
what you need.

Since you're thinking model-centric stuff, that would work well with
our Fixture Magic stuff, you might have some luck forking from us and
implementing what you need.

-d

On Feb 26, 3:44 pm, Alexander Bolotnov  wrote:
> Hiya,
>
> thanks a lot for your response. So, using my approach (the json generation
> templates) is somewhat more or less ok then? I'd like to get involved but
> I'm just not really good at python and django, so I guess I will be mixing
> rather than fixing I'm afraid :)
>
> By putting json serialization to models I mean being able to def something
> simple in it that will use a handy serializer and return json/xml
> presentation.
>
> Sasha Bolotnovwww.gorizont-zavalen.ru
>
> On Sun, Feb 27, 2011 at 2:37 AM, Russell Keith-Magee <
>
>
>
>
>
>
>
> russ...@keith-magee.com> wrote:
> > On Sun, Feb 27, 2011 at 5:23 AM, Alexander Bolotnov 
> > wrote:
> > > Is there a way to control json serialization in django? Simple code below
> > > will return serialized object in json:
> > ...
> > > You can see it's serializing it in a way that you are able to re-create
> > the
> > > whole model, shall you want to do this at some point - fair enough, but
> > not
> > > very handy for simple JS ajax in my case: I want bring the traffic to
> > > minimum and make the whole thing little clearer.
>
> > You're not the first to propose this. It's a long standing feature
> > request, and yes, we'd like to address it. However, nothing gets built
> > by magic -- someone needs to find the time to devise an API and
> > implement it.
>
> > There was a recent post on django-dev from someone expressing interest
> > in doing this for the Summer of Code. However, anyone else with an
> > interest is certainly welcome to get involved.
>
> > > I'm thinking json generating should be part of the model (correct me if
> > I'm
> > > wrong) and done with either native python-json and django implementation
> > but
> > > can't figure how to make it strip the bits that I don't want.
>
> > This isn't a good idea. Serialization isn't an activity that is unique
> > to models, and JSON isn't the only serialization format. For example,
> > you may want an XML serializer to interface with certain APIs, and you
> > may need an XML serializer and two different JSON serializers in the
> > same project in order to interface with various subsystems. Therefore,
> > serialization needs to be handled independent of the model definition.
>
> > The approach that we have historically discussed (but not implemented)
> > is to define serialization in two parts:
>
> >  1) a DSL that defines the rules for an output format -- e.g., which
> > fields will be included, what extra metadata will be included, how
> > deep relations will be traversed.
>
> >  2) an set of engines that implements the rules of the DSL for a each
> > serialization language.
>
> > What we have at present is a single implied definition of (1) encoded into
> > (2).
>
> > > One more thing - even when I restrict it to a set of fields to serialize,
> > it
> > > will keep the id always outside the element container and instead present
> > it
> > > as "pk" outside of it.
>
> > Yes - which is by design. Django's serializers were designed to allow
> > for dumping and reconstructing data in a database. That means that
> > being able to easily identify the primary key is important.
>
> > Yours,
> > Russ Magee %-)
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.

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

Re: Using asserts in test code

[Dave Smith]

My team has adopted the convention of prepending "Sanity:" to the message of
any assertion whose purpose is to verify that things are set up correctly
for the
'main act' assertions. This helps us cut through the 'something is broken,
but it's
not here' noise  when a change causes a bunch of tests to fail. This works
equally
well with 2-arg assert or assertEquals() et al.

Dave

On Thu, Dec 23, 2010 at 8:56 AM, Ian Clelland <clell...@gmail.com> wrote:

> On Thu, Dec 23, 2010 at 8:46 AM, Karen Tracey <kmtra...@gmail.com> wrote:
> > On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant <l.plant...@cantab.net>
> wrote:
> > Perhaps it is not a problem when using bare asserts for this purpose, but
> I
> > have grown to dislike asserts in testcases because they give so little
> > information. For example, I am working with test code that uses bare
> asserts
> > all over the place instead of the TestCase methods and when these tests
> fail
> > I get errors like this:
> >
> > Traceback (most recent call last):
> >   File [snipped]
> > assert res.status_code == 200
> > AssertionError
> >
> > Well, great, status wasn't 200 but what was it? That's information I'd
> > really rather get by default, so I much prefer assertEquals, which tells
> me:
> >
> > Traceback (most recent call last):
> >   File [snipped]
> > self.assertEqual(res.status_code, 202)
> > AssertionError: 302 != 200
> >
> > That actually gives me enough information that I might be able to fix the
> > problem straight off.
> >
> > Do you not find the paucity of information provided by bare assert to be
> > annoying?
>
> Test cases should probably be using the two-argument form of assert:
>
>assert (res.status_code == 200), "The status code returned was
> incorrect"
>
> or even
>
>assert (res.status_code == 200), ("%s != 200" % res.status_code)
>
> At least some of the examples that Luke pointed to are using that
> style, and it definitely makes more sense than just asserting a bare
> fact, with no explanation.
>
>
> Regards,
> Ian Clelland
> <clell...@gmail.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<django-developers%2bunsubscr...@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: managing javascript and css resources

[Dave Dash]

Gabriel,

For addons.mozilla.org we use this syntax:

http://github.com/jbalogh/zamboni/blob/master/settings.py#L268

In TEMPLATE_DEBUG=False, we use a minified version of these assets, in
TEMPLATE_DEBUG=True we just use the individual assets unbundled.

We have a management command which compresses/minifies the assets.  We
also write a number to a build.py file that we can import so our urls
for assets have build numbers associated with them.

This is done with:

http://github.com/jsocol/jingo-minify

This is perhaps similar to other tools out there, the only reason we
made our own is because we use Jinja2 (via Jingo), but the functions
in our helpers.py can easily be ported to Django's native templates.

Let me know if that's helpful, and I'm happy to merge in support for
Django templates as well.

Cheers,

d


On Apr 21, 12:57 pm, Gabriel Hurley  wrote:
> I like the idea of having these "bundles" or "stacks" for media. Just
> thinking out loud here, if there were a compression engine in play
> that could do concatenation as well as minification you could have a
> useful syntax for ordered combinations of scripts similar to how
> ModelAdmin's fieldsets work (using a dictionary of nested tuples).
>
> A quick example:
>
> scripts = {
>     "head": (
>         "media/js/script_to_be_loaded_first.js",
>     ),
>     "tail": (
>         "media/js/script_that_shouldn't_be_concatenated.js", ("media/
> js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
>     )
>
> }
>
> That would give you the benefit of automated concatenation while
> somewhat alleviating the problem Kevin Howerton pointed out about it
> best being done by hand.
>
> That's my thought for the moment.
>
>     - Gabriel
>
> On Apr 21, 9:18 am, Owen Nelson  wrote:
>
>
>
> > I've been thinking about this ever since I learned that django's admin
> > was going to be using jQuery, but I admit I didn't really consider it
> > that important until recently (building sites against 1.2-beta).
>
> > I know now is not a fantastic time to be talking about features, but
> > this is something I'd enjoy working on (personally), and I am just
> > hoping to get a little feedback regarding the design, and how it might
> > fit in with everything else going on in django's guts
> > (philosophically).  I also understand that this isn't something for near
> > versions of django, but rather the distant future.
>
> > Here's where the pin dropped:
> > * The jQuery used by the admin site is conjured using the no conflict
> > option and is relegated/isolated to it's own namespace (excellent).
> > * There are many projects/apps out there that also rely on jQuery - they
> > also "bundle" the framework, but may not be quite so quick to play nice.
>
> > In my case, I noticed that when I added a few jQuery-enhanced form
> > widgets to a form in my admin site, it resulted in 3 instances of the
> > framework being sourced in the document head.  Although, this is
> > actually ok for the most part in terms of operation (so long as the
> > scripted events that come with each widget are bound to the dom before
> > the plugin of origin gets wiped by the next sourcing of jQuery), it's
> > far from ideal.
>
> > There are a myriad of ways to skin this cat, be it a simple
> > recommendation to adopt  the use of  django's jQuery and a template tag
> > to provide access to the appropriate script tag, or something more
> > structured/engineered/formal 
>
> > My goal would be to provide app developers with scaffolding to add
> > javascript/css resources to the rendered view in a non-competitive way.
> > I'm thinking in terms of a template tag that works along the lines of {%
> > include %}, but for script and link tags, allowing folks to add scripts
> > with an optional way to influence the position in the "stack".  A
> > similar interface would also be provided for form media, and perhaps
> > some kind of helper or shortcut for ease the addition of these scripts
> > from our view functions.
>
> > I understand that Django has historically been
> > anti-javascript-framework-blessing, and I'm wondering if opening this
> > can of worms would mean having to incorporate some kind of a pluggable
> > backend system (for working with different frameworks, or multiple
> > frameworks at a time) - something I've briefly considered, but started
> > foaming at the mouth as a result.
> > I've also considered the fact that the reaction here might be, "just
> > don't - leave it all in the individual's hands".
>
> > In closing... don't hit me!
>
> > Regards,
> > Owen Nelson
>
> > --
> > 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 
> > 

Re: Refining Django admin look proposal

[Dave Jeffery]

On Sat, Feb 6, 2010 at 6:02 AM, Russell Keith-Magee
<freakboy3...@gmail.com> wrote:

>  * Do we need to do this in phases - e.g., phase one for design
> proposals, and then phase two for best execution of the design
> proposal we pick?
>
>  * Who judges? I'm predisposed to say that the winner should be picked
> in the same way that we do feature voting for releases -- binding
> votes by the core team, but with input from anyone else that wants to
> offer an opinion.
>
> If this works out well, it might turn in to a model we can reuse. The
> DSF has some plans that will require some design work. Semi-regular
> design competitions might be one way to draw attention to the awesome
> design talent in our community.
>

Not that anybody wants to hear my opinion but...

This contest idea is ridiculous! The admin is a core feature of Django
and is responsible for a lot of the initial buzz surrounding Django;
I'd be willing to wager that an awful lot of people came to Django
because they wanted to try out the admin. The admin is beginning to
show its age though and a thoughtful redesign is due, a
99designs-style competition does not lend itself to thoughtful design.
No disrespect intended but as Russell pointed out himself, the core
developers are not designers and I doubt they would be sufficiently
competent to judge a *design* competition.

Jeff Croft, Bryan Veloso and Nathan Borror sounds like a pretty
amazing team to do a overhaul of the admin (I know they haven't
offered, I'm just saying). If these guys are genuinely interested in
doing the work then it would be a shame if a core dev didn't come
forward and tell them that they are behind the idea and give them the
help they need to get started.

Dave

-- 
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: Refining Django admin look proposal

[Dave Jeffery]

On Thu, Feb 4, 2010 at 1:44 AM, Russell Keith-Magee
<freakboy3...@gmail.com>wrote:

> On Thu, Feb 4, 2010 at 8:35 AM, tezro <tezro...@gmail.com> wrote:
> >
> > As the most obvious thing - here's the margin/padding problem on the
> > left/right side of the page. One of a hundreds...
> > http://farm5.static.flickr.com/4022/4329186446_212477b9e4_o.png
>
> I'm not necessarily convinced that the margin padding "problem" you
> identified is inherently a problem - variations in horizontal
> alignment can serve a useful design purpose.
>
>
Yes, in this particular instance it serves to highlight the visual
hierarchy, i.e. the container for the content is a child of (and therefore
indented from) the header.

The admin site still looks great considering it's age, I have noticed that
it doesn't scale very well at wider resolutions though.
Perhaps the best way to get something like this included in trunk would be
to create an external project like django-grappelli[1] or
django-mobileadmin[2] and bring up the issue again when you think that the
project is ready for consideration. I'm not involved with contributing to
Django so take what I've just said with a pinch of salt.

Sorry to completely hijack this thread but would django-mobileadmin be
considered for inclusion to trunk (during the 1.3 timeline)? iPhones and
other mobile devices are getting pretty prolific and I love having the
mobile admin site available when I login from my iPhone (which happens
surprisingly often).

Thanks,
Dave

[1] http://code.google.com/p/django-grappelli/
[2] http://code.google.com/p/django-mobileadmin/

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

hide_email template tag

[Dave Jeffery]

I know this is a bad time to bring up feature requests but I would most
likely have forgotten to bring it up at a later date.

Would a hide_email template tag be a good addition to the standard set of
template tags in django? There's a snippet[1] on django snippets which
serves as a good starting point. This seems like it could be a great
time-saver for those of us who want to beat the most common email address
harvesters.

[1] http://www.djangosnippets.org/snippets/1349/

Thanks,
Dave

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

Porting Django to Python 3

[Dave]

Hello everyone,

My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.

Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.

A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.

We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.

Best regards,

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

CRLF vs just LF in multipart parser

[Dave Peck]

Hello,

I notice that Django's multipart form parser expects CRLF-style line
endings. Specifically,
django.http.multipartparser::parse_boudary_stream has a hardcoded
expectation of '\r\n\r\n' to end a part header.

Is this line ending mandated by RFCs, or is this hardcoding a mistake?

I ask because I appear to have an external client that only sends LF-
only endings; this causes Django to miss the entire contents of the
form post.

Thanks,
Dave

--

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: What do people think about the get_absolute_url proposal?

[Dave Jeffery]

I brought this up during the 1.1 dev schedule and if I remember correctly
the response was "let's have it painted red" and it seemed like it wasn't
considered a practical problem.

The reason I think this is an issue is the same reason that I get frustrated
whenever I see a pull-style handle on a door that you need to push. I
understand that people will 'get it' eventually but I don't think it's
acceptable to ask the user to refer to documentation (or read the 'push'
label) when the function is so simple and *seems* obvious.

To me it seems like an obvious fix which has no obvious downsides. I'm
assuming that get_absolute_url will continue to be available through the
lifecycle of 1.x., so I can't think of a reason not to do it.

Dave


On Mon, Dec 7, 2009 at 10:43 PM, Simon Willison <si...@simonwillison.net>wrote:

> This made it to the 1.2 feature list:
>
> http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
>
> If we want this in 1.2, it could be as simple as merging the get_url /
> get_url_path methods in to the base Model class, rolling a few unit
> tests and writing some documentation. It feels like we should discuss
> it a bit first though - the proposal hasn't really seen much
> discussion since it was originally put together back in September last
> year.
>
> Cheers,
>
> Simon
>
> --
>
> 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 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: 1.2 Proposal: Add a few more tutorial steps

[Dave Jeffery]

On Fri, Aug 21, 2009 at 4:10 PM, Dave Jeffery <djeff...@gmail.com> wrote:

>
> Does anybody have a copy (or know where I could a copy) of the completed
> code for the Django tutorial?
>

Ok, I quickly ran through the tutorial steps, here is what the code was
looking like at the end of the current tutorials:
http://files.davejeffery.com/django/polls.zip

Hope this helps anybody else who wants to add more steps to the tutorial.

--~--~-~--~~~---~--~~
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: 1.2 Proposal: Add a few more tutorial steps

[Dave Jeffery]

On Fri, Aug 7, 2009 at 5:19 PM, Rob Hudson <treborhud...@gmail.com> wrote:

>
> The tutorial ends here for the time being. Future installments of the
> tutorial
> will cover:
>
>* Advanced form processing
>* Using the RSS framework
>* Using the cache framework
>* Using the comments framework
>* Advanced admin features: Permissions
>* Advanced admin features: Custom JavaScript
>
>
I'm going to work on adding an instalment to the tutorial this weekend. Does
anybody have a copy (or know where I could a copy) of the completed code for
the Django tutorial? I know that it wouldn't take long to complete it myself
but it would save me a bit of time to start off where the current tutorial
ends.

Dave

--~--~-~--~~~---~--~~
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: 1.2 Proposal: django debug toolbar in contrib

[Dave Jeffery]

On Mon, Aug 17, 2009 at 2:28 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

>
> The reasoning was that we wanted the error pages to be somewhat
> framework-agnostic;
> we didn't want to impose our branding onto parts of *your* site. I'd
> say a similar ethos should be expressed in the debug toolbar branding.
> If you wanted to be extra special, some UI similarity between the
> error pages and the debug toolbar would probably be a good idea.
>

I like Jacob's idea of taking design hints from the debug page when styling
the toolbar. The information presentation on the debug page is very clear;
the sans-serif font and generous padding make it easy to read and scan
through; and the pastel colours make the page light.

(Sticking my nose in where it isn't wanted...) The toolbar looks really
great but it feels a bit over-designed and too heavy for a functional
interface which will sit atop of existing websites. I'm especially referring
to the typography, the uppercase serif lettering seems inappropriate for
this type of interface. Just my opinion, obviously discard it at will.

Dave

--~--~-~--~~~---~--~~
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: Proposal for contrib feature (DictionaryField in models)

[Dave Jeffery]

On Tue, Aug 11, 2009 at 11:58 PM, Mark Ferrer  wrote:

>
> You're right. I forgot about JSON. I guess it can be encoded and
> stored as a JSON string and then decoded afterward.
>

See django-jsonfield:
http://github.com/bradjasper/django-jsonfield/tree/master
Personally I use JSONField often and I find it quite handy, so I would be a
+1 but a quick search will bring you to #5965 [1] where it was rejected for
being "too specialised for core".

[1] http://code.djangoproject.com/ticket/5965

--~--~-~--~~~---~--~~
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: 1.2 Proposal: Add a few more tutorial steps

[Dave Jeffery]

On Fri, Aug 7, 2009 at 5:19 PM, Rob Hudson  wrote:
>
>
> If someone already had an idea on these wanted to add some more
> details of what to cover under one of those topics, I (and others?)
> can try to flesh one out during the 1.2 phase.
>
>
Just a quick note that I would be happy to help out with this area of the
docs too.

--~--~-~--~~~---~--~~
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: Posting to the wrong list (was: Re: Need Django Developer urgent)

[Dave Smith]

On Fri, May 8, 2009 at 4:49 AM, Ned Batchelder <n...@nedbatchelder.com>wrote:

>  Add the word "core" to make the first sentence, "Discussion group for
> Django core developers".
>

Good idea, but I'd take it step farther. "Core" is just ambiguous enough
outside the bubble that some people will still stop reading at the first
sentence, satisfied that they've found the list they're looking for.

How about:

  "You're found the wrong list. You're probably looking for django-users
unless you're interested in the development of the Django framework itself."

Dave

--~--~-~--~~~---~--~~
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: Killing reloaders when parent receives TERM signals

[Dave Benjamin]

On Mar 24, 5:04 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> Use Apache/mod_wsgi and the documented method of running a WSGI
> application in a specific daemon process in a autoreloading
> development mode. You could even have both the production and
> development instances under same Apache under different hosts, with
> only development instance having autoreload enabled. Would be much
> simpler as you don't have to muck around with the supervisor software.
> Also basically otherwise the same set up as your production
> environment and so better test as far as making sure everything works
> properly. See:
>
>  http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode
>
>  http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django...
>  http://blog.dscpl.com.au/2009/02/source-code-reloading-with-modwsgi-o...

I like mucking around with supervisor software. But this is clearly a
superior approach. Thanks for the links!

Dave
--~--~-~--~~~---~--~~
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: Killing reloaders when parent receives TERM signals

[Dave Benjamin]

On Mar 24, 4:13 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Tue, 2009-03-24 at 15:27 -0700, Dave Benjamin wrote:
> > In any case, sending a TERM signal to the parent process should cause
> > the child to die. There is no reasonable justification for the current
> > behavior, IMHO.
>
> There's a lot of justification for the current behaviour: it's a *lot*
> simpler than the change you are proposing we make and maintain forever.

Well, it's simple enough for me to hack around it, so I withdraw my
proposal. =)

> The development server is intended for single user, simple development
> stuff. It runs as a foreground process and ^C stops it very nicely.

I admit I am a bit of a daemontools addict. I use it even for single
user, simple development. The ability to easily start and stop
processes, and the built-in, auto-rotating logs that record output
even when apps crash hard are totally worth the effort for me.

> If you want anything more than that, use a real webserver. It's easy to
> set up mod_wsgi so that it reloads (see [1]). Or use --noreload and
> restart if/when you make changes to something (if other people are
> viewing it at the same time, random restarts aren't generally going to
> be a good idea).
>
> The goal is, intentionally, to keep the development server simple since
> there are numerous options for more functional setups when required.

I didn't realize that it was possible to do auto-reloading with WSGI.
I was under the assumption that the choice was between mod_python,
which reloads unpredictably (unless you use the MaxRequestsPerChild
trick), and the standalone server, which reloads reliably but
sometimes crashes. I really want the best of both worlds: a reliable,
auto-reloading, shared development environment. I now understand that
there are many more options than those I've considered.

Thanks,
Dave

--~--~-~--~~~---~--~~
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: Killing reloaders when parent receives TERM signals

[Dave Benjamin]

No, I'm trying to run it as a dev server. I use mod_python in
production. However, I use the dev server in a shared environment so
that a few other programmers and testers in the office can view the
site.

In any case, sending a TERM signal to the parent process should cause
the child to die. There is no reasonable justification for the current
behavior, IMHO.

On Mar 24, 2:45 pm, graham_king <gra...@gkgk.org> wrote:
>  It looks like you're trying to run the dev server as a real web
> server, which is a very bad idea (it's only serves one request at a
> time, for starters). As it says here:
>
> http://docs.djangoproject.com/en/dev/ref/django-admin/#runserver-opti...
>
> "DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone
> through security audits or performance tests. (And that's how it's
> gonna stay. We're in the business of making Web frameworks, not Web
> servers, so improving this server to be able to handle a production
> environment is outside the scope of Django.)"
>
> Is there a reason you can't use Apache, or a different server with a
> WSGI or FCGI setup? If you're not running it in production, why do you
> need daemontools?
>
>  Best regards,
>  Graham
>
> On Mar 24, 11:13 am, Dave Benjamin <dave.benja...@gmail.com> wrote:
>
> > Hello,
>
> > I run the Django development server (manage.py runserver) under
> > Daemontools on Linux. Daemontools is a server management framework
> > that runs a foreground process as a daemon and automates the tasks of
> > starting, restarting, signal handling, and logging. I use a run script
> > that looks like the following:
>
> > #!/bin/sh
> > exec 2>&1
> > exec setuidgid www-data envdir ./env myapp/manage.py runserver --
> > adminmedia=/usr/local/myapp/media/ 0.0.0.0:8000
>
> > This has been working well for me for awhile except for one problem.
> > The usual way of causing a Daemontools service to exit, either to
> > terminate the service or to do a full restart, is to type the
> > following:
>
> > svc -t /service/myapp
>
> > This sends a TERM signal to the parent process. Due to the way that
> > Django's autoreloader module (django.utils.autoreload) is written,
> > there are actually two processes, a monitoring parent process and a
> > child process exits whenever a reload is necessary. Sending a TERM
> > signal to the parent process leaves the child process running, and
> > this causes an orphan process that never exits and hogs the socket.
>
> > If the --noreload argument is passed to manage.py runserver, this
> > problem goes away because there is only one process running.
> > Unfortunately, this disables the autoreload functionality.
>
> > I have written a modification to my manage.py script that
> > monkeypatches the autoreload module so that it keeps a set of child
> > PIDs and sends them TERM signals when the parent process receives one.
> > I changed the call to spawnve so that it sends P_NOWAIT instead of
> > P_WAIT, causing the call to return a PID instead of an exit code. I
> > then stash this code in the set and do the os.waitpid() call myself.
> > The code is a modified version of the spawn* wrappers in os.py, and
> > handles the exit code processing and removal of exited/signalled PIDs
> > from the set.
>
> > I haven't tested this change on anything besides Linux, so at the very
> > least I'd imagine it causes some problems under Windows. I'm posting
> > it here in hope that it will be useful to someone else, and possibly
> > with some tweaking be integrated into the autoreload module.
>
> > The following is what my manage.py script looks like now:
>
> > #!/usr/bin/python
> > from django.core.management import execute_manager
> > try:
> >     import settings # Assumed to be in the same directory.
> > except ImportError:
> >     import sys
> >     sys.stderr.write("Error: Can't find the file 'settings.py' in the
> > directory containing %r. It appears you've customized things.\nYou'll
> > have to run django-admin.py, passing it your settings module.\n(If the
> > file settings.py does indeed exist, it's causing an ImportError
> > somehow.)\n" % __file__)
> >     sys.exit(1)
>
> > import os, sys, signal
> > from django.utils import autoreload
>
> > def restart_with_reloader():
> >     reloader_pids = set()
>
> >     def kill_reloaders(signum, frame):
> >         try:
> >             while True:
> >                 pid = reloader_pids.pop()
> >                 os.kill(pid, signal.SIGTERM)
> >         except KeyError:
> >         

Killing reloaders when parent receives TERM signals

[Dave Benjamin]

Hello,

I run the Django development server (manage.py runserver) under
Daemontools on Linux. Daemontools is a server management framework
that runs a foreground process as a daemon and automates the tasks of
starting, restarting, signal handling, and logging. I use a run script
that looks like the following:

#!/bin/sh
exec 2>&1
exec setuidgid www-data envdir ./env myapp/manage.py runserver --
adminmedia=/usr/local/myapp/media/ 0.0.0.0:8000

This has been working well for me for awhile except for one problem.
The usual way of causing a Daemontools service to exit, either to
terminate the service or to do a full restart, is to type the
following:

svc -t /service/myapp

This sends a TERM signal to the parent process. Due to the way that
Django's autoreloader module (django.utils.autoreload) is written,
there are actually two processes, a monitoring parent process and a
child process exits whenever a reload is necessary. Sending a TERM
signal to the parent process leaves the child process running, and
this causes an orphan process that never exits and hogs the socket.

If the --noreload argument is passed to manage.py runserver, this
problem goes away because there is only one process running.
Unfortunately, this disables the autoreload functionality.

I have written a modification to my manage.py script that
monkeypatches the autoreload module so that it keeps a set of child
PIDs and sends them TERM signals when the parent process receives one.
I changed the call to spawnve so that it sends P_NOWAIT instead of
P_WAIT, causing the call to return a PID instead of an exit code. I
then stash this code in the set and do the os.waitpid() call myself.
The code is a modified version of the spawn* wrappers in os.py, and
handles the exit code processing and removal of exited/signalled PIDs
from the set.

I haven't tested this change on anything besides Linux, so at the very
least I'd imagine it causes some problems under Windows. I'm posting
it here in hope that it will be useful to someone else, and possibly
with some tweaking be integrated into the autoreload module.

The following is what my manage.py script looks like now:



#!/usr/bin/python
from django.core.management import execute_manager
try:
import settings # Assumed to be in the same directory.
except ImportError:
import sys
sys.stderr.write("Error: Can't find the file 'settings.py' in the
directory containing %r. It appears you've customized things.\nYou'll
have to run django-admin.py, passing it your settings module.\n(If the
file settings.py does indeed exist, it's causing an ImportError
somehow.)\n" % __file__)
sys.exit(1)

import os, sys, signal
from django.utils import autoreload

def restart_with_reloader():
reloader_pids = set()

def kill_reloaders(signum, frame):
try:
while True:
pid = reloader_pids.pop()
os.kill(pid, signal.SIGTERM)
except KeyError:
pass

signal.signal(signal.SIGTERM, kill_reloaders)

while True:
args = [sys.executable] + sys.argv
if sys.platform == "win32":
args = ['"%s"' % arg for arg in args]
new_environ = os.environ.copy()
new_environ["RUN_MAIN"] = 'true'
pid = os.spawnve(os.P_NOWAIT, sys.executable, args,
new_environ)
reloader_pids.add(pid)
while True:
try:
wpid, sts = os.waitpid(pid, 0)
except OSError:
continue
if os.WIFSTOPPED(sts):
continue
elif os.WIFSIGNALED(sts):
exit_code = -os.WTERMSIG(sts)
if wpid in reloader_pids: reloader_pids.remove(wpid)
break
elif os.WIFEXITED(sts):
exit_code = os.WEXITSTATUS(sts)
if wpid in reloader_pids: reloader_pids.remove(wpid)
break
else:
raise error, "Not stopped, signaled or exited???"
if exit_code != 3:
return exit_code

autoreload.restart_with_reloader = restart_with_reloader

if __name__ == "__main__":
execute_manager(settings)



Thanks,
Dave

--~--~-~--~~~---~--~~
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: get_url() and get_url_path() for 1.1?

[Dave Jeffery]

On Sat, Jan 10, 2009 at 1:11 AM, Malcolm Tredinnick <
malc...@pointy-stick.com> wrote:

>
> There's no reason to mark it deprecated. It still works fine for what it
> does. It just doesn't do what the name suggests, but, historically, that
> hasn't been a real show-stopper for understanding purposes.


Hmmm, I wonder what makes you think that it's not a "show-stopper for
understanding purposes"? Sure, it's pretty easy to figure out once you read
the documentation on it but get_absolute_url is such an explicit name that
you would expect to know what it does without reading the docs. This is
especially important because it is used in templates where semantically
named methods are more important because they may be authored by people who
are not aware of the intricacies and kinks of django.


> Get your ducks in a row and have code ready for the start of the 1.2
> development period and we'll have 6 or 9 or 12 months of time to work out
> all the kinks.


That's a fair enough comment. I didn't really expect it to get into 1.1 at
this late stage.

Cheers,
Dave

--~--~-~--~~~---~--~~
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: get_url() and get_url_path() for 1.1?

[Dave Jeffery]

I should have explained more clearly, get_absolute_url() would still
be available in 1.1 (this is required for backwards compatibility
anyway).
get_url() and get_url_path() would simply be the preffered way to do
it, I would expect that get_absolute_url() would remain in django
(albeit deprecated) until 2.0.

As for the "Let's have it painted red" reaction… When I first started
using django this confused the heck out of me, when it returned a
relative url I presumed that I was doing something wrong. I don't
think this is one of those pedantic issues, this is a legitimate issue
that causes practical problems.

Cheers,
Dave

On Jan 9, 8:40 pm, Ludvig Ericson <ludvig.eric...@gmail.com> wrote:
> On Jan 9, 2009, at 20:26, Dave Jeffery wrote:
>
>
>
> > Back in August of last year, there was a discussion about the
> > confusing name of get_absolute_url and it led to this doument by Simon
> > Willison:
> >http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
>
> > After looking through the version 1.1 feature list (and rejected
> > features)[1], this seems to have flown under the radar. Is it too late
> > to have this feature looked at for 1.1? As was the case with the
> > initial feature proposal (just before 1.0), I realise that the timing
> > is very bad.
>
> > [1]http://code.djangoproject.com/wiki/Version1.1Features
>
> At best I would think there'd be a deprecation plan until 2.0, as this
> kind of BC is what I expect of Django for 1.x.
>
> Also, is this really worth it as this point? My initial reaction to
> that thread was, honestly, "Let's have it painted red."
>
> - Ludvig Ericson <ludvig.eric...@gmail.com>
> Note: E-mails to and from Sweden, or via servers in Sweden, are  
> monitored by the Swedish National Defence Radio Establishment, FRA.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

get_url() and get_url_path() for 1.1?

[Dave Jeffery]

Back in August of last year, there was a discussion about the
confusing name of get_absolute_url and it led to this doument by Simon
Willison:
http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl

After looking through the version 1.1 feature list (and rejected
features)[1], this seems to have flown under the radar. Is it too late
to have this feature looked at for 1.1? As was the case with the
initial feature proposal (just before 1.0), I realise that the timing
is very bad.

[1] http://code.djangoproject.com/wiki/Version1.1Features

Cheers,
Dave

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

[Dave Protasowski]

Lets get this into 1.1 ;)

-dave

On Sat, Jan 3, 2009 at 7:02 PM, Brantley Harris <deadwis...@gmail.com>wrote:

>
> On Sat, Jan 3, 2009 at 5:25 PM, Russell Keith-Magee
> <freakboy3...@gmail.com> wrote:
> >
> > On Sun, Jan 4, 2009 at 4:28 AM, Brantley Harris <deadwis...@gmail.com>
> wrote:
> >> Ah yes, this is definitely a problem.  See, I had to be able to import
> >> based on a string (database backend), and I was having problems doing
> >> so without an absolute import.  I defaulted to this, and didn't think
> >> much of it.  I'll get on this.
> >
> > It doesn't sound like this should be as big a problem as you describe.
> > Also, keep in mind that database backends are allowed to live outside
> > django.db.backends - this is how we support external development of
> > backends. The backend import code from Evolution and from Django
> > itself should give you a few pointers on how to do this in a location
> > independent fashion.
> >
>
> It's not a big problem, I'll figure it out.  I took the easy way out,
> and will be punished :)
>
> >>> 2) Performance on very large databases. "for obj in
> >>> Model.objects.all(): change(obj); obj.save()" is very Pythonic and
> >>> very easy to read, but will not perform very well on large databases.
> >>> Having an easy way to drop to raw SQL is essential for these cases.
> >>
> >> Yes, my solution to that, although undocumented I realize, is to allow
> >> migrations to also be completely sql.  So they would live right next
> >> to regular migrations, but have a .sql on them.  I was also going to
> >> make an option to ./mananage.py migrate that is --sql, so it would
> >> build the migration for you just the same, but as sql.
> >
> > The 'put the sql in a file' option is the same thing that Evolution
> > does. Better still would be to be able to 'compile' a python migration
> > into SQL - this would keep all the auditing DB admins happy - but I
> > acknowledge that this is a pretty hard ask.
>
> Not so hard, there is actually an undocumented command "python
> manage.py migratesql" that will pop out the sql that the next
> migration would do.  It's not documented so far because if you use it
> on an edited migration that has custom api commands, they will still
> run when popping out the sql, which is a problem.  Theoretically if I
> could put it into an uncommitted transaction, everything would work
> out, but I'm not sure if that works for each backend?  So I have to
> figure that one out.
>
> >
>

--~--~-~--~~~---~--~~
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: Perl port of the django template system.

[Dave Smith]

On Fri, Dec 26, 2008 at 9:54 AM, James Bennett <ubernost...@gmail.com>wrote:

>
> On Fri, Dec 26, 2008 at 11:36 AM, Maluku <marc.luck...@googlemail.com>
> wrote:
> > Kind of different question: Why is there no {% else %} in {% ifchanged
> > %}, I think it might be a help to some people.
>
> Because it wouldn't make any sense; the point of 'ifchanged' is to say
> "I have a special thing which only needs to happen when this other
> thing changes", not to set up complex chains of conditionals.


There are several use cases that an 'else' simplifies. See
http://code.djangoproject.com/ticket/4534
and http://code.djangoproject.com/changeset/8095 for the patch.

Dave

--~--~-~--~~~---~--~~
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: Proposal: Optional {% default %} clause for the {% for %} template tag

[Dave Smith]

I'm wondering who that's going to confuse. It's very clear that the template
language
isn't Python, so I'd think it'd make the most sense to use a keyword that
makes sense
within the context of the template language. I'd think that either 'else' or
'ifnone' are the
most memorable/readable. 'default' connotes "unless we override ...", which
isn't what's
going on here.

+1 for else

On Wed, Oct 29, 2008 at 5:44 PM, Calvin Spealman <[EMAIL PROTECTED]>wrote:

> The else clause executes unless a loop is broken (that is, with the break
> or obviously by raising an exception), and executes after a loop ends
> normally.
>
> >>> for i in "abc": ...   pass
> ... else:
> ...   print "else"
> else
> >>>
>
> On Wed, Oct 29, 2008 at 8:32 PM, Ned Batchelder <[EMAIL PROTECTED]>wrote:
>
>>  But this does operate the same as the Python for/else, no?
>>
>> >>> for i in []:
>> ...  print "boo"
>> ... else:
>> ...  print "foo"
>> ...
>> foo
>> >>>
>>
>> --Ned.
>> http://nedbatchelder.com
>>
>>
>> Calvin Spealman wrote:
>>
>> On Tue, Oct 28, 2008 at 8:18 PM, oggie rob <[EMAIL PROTECTED]>wrote:
>>
>>>
>>> > {% for item in grocery_list %}
>>> >   {{ item }}
>>> > {% default %}
>>> >   Nothing to buy.
>>> > {% endfor %}
>>>
>>
>>>  Please, though - use {% else %}. Its totally clear what its referring
>>> to and else doesn't mean squat unless you see what the if (and in this
>>> case, for) test is anyway, so I don't think this would be confusing
>>> (after all, this isn't python).
>>> (Also, if you want to avoid confusion don't use a keyword that is
>>> located within another language's looping construct :)
>>>
>>
>>  Please dont use else, because {%for%} matches python's for loop and that
>> supports an else clause which does not operate like this. If the same
>> keyword is used, it should behave the same.
>>
>>
>> --
>> Read my blog! I depend on your acceptance of my opinion! I am interesting!
>> http://techblog.ironfroggy.com/
>> Follow me if you're into that sort of thing:
>> http://www.twitter.com/ironfroggy
>>
>>
>>
>> --
>> Ned Batchelder, http://nedbatchelder.com
>>
>>
>>
>>
>
>
> --
> Read my blog! I depend on your acceptance of my opinion! I am interesting!
> http://techblog.ironfroggy.com/
> Follow me if you're into that sort of thing:
> http://www.twitter.com/ironfroggy
>
> >
>

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

Pushing along the idea of adding an 'else' to 'ifchanged'

[Dave Smith]

I'd like to put in a good word for #4534 and its patch.

I know this has been discussed before, and that is *is* possible to write
view code to pass along extra data to a template to get the same effect as
ifchanged/else, but it's a lot cleaner, IMHO, to support this in templates
and to avoid cluttering up views with extra code that's there only to
support presentation.

I've found having an 'else' for 'ifchanged' useful in three cases:
- Using different css styles for first and subsequent
- Displaying " below duplicates in a list of numbers (representing money),
simulating what you see on financial lists.
- Dropping in images in place of duplicates

The patch installs cleanly into r7997,  and the tests pass. The code is
straightforward. I had worked up a nearly identical patch before discovering
that SmileyChris had gotten there first.

Dave

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

Re: Tables params in extra()

[Dave Lowe]

I can't tell you how grateful I am that you posted this workaround,
Barry! Just in time for a site launch.

Like you said, I wonder if the multiple calls to to_tsquery() are
acceptable or if there's a more graceful solution here for the long-
term.



On May 13, 9:01 pm, Barry Pederson <[EMAIL PROTECTED]> wrote:
> Dave Lowe wrote:
> > It worked prior to qsrf-merge. I have tried adding the quotes though,
> > without success.
>
> > On May 13, 9:59 am, David Cramer <[EMAIL PROTECTED]> wrote:
> >> The database engine usually can't fill that in anyways, you should
> >> probably quote it yourself (correct me if I'm wrong).
>
> >> On May 13, 9:15 am, Dave Lowe <[EMAIL PROTECTED]> wrote:
>
> >>> Ever since the querset-refactor merge, params in the 'tables' argument
> >>> don't seem to be filled. The documentation describes the arguments
> >>> 'params' and 'select_params' as being for where and select statements,
> >>> respectively. Do we need a "tables_params" argument as well?
> >>> Here's a code sample of where I'm using tables params (it's for full-
> >>> text searching in postgres):
> >>> results = Product.objects.extra(
> >>>                             select={
> >>>                                 'rank': "rank_cd(textsearchable,
> >>> query, 32)",
> >>>                                 },
> >>>                             tables=["to_tsquery(%s) as query"],
> >>>                             where=["textsearchable @@ query"],
> >>>                             params=[terms],
> >>>                             order_by=('-rank',)
> >>>                     )
> >>> The error message by the way is: ProgrammingError: relation
> >>> "to_tsquery(2) as query" does not exist.
>
> I've seen this too, also trying to do PgSQL FTS, and posted about it in
> django-users
>
> http://groups.google.com/group/django-users/browse_thread/thread/ef17...
>
> it seems that two things are changed from pre-QSRF:  params aren't
> processed for the 'tables=' argument, and the tables= arguments are
> quoted now, so you end up with something like
>
>    SELECT ... FROM "to_tsquery(%s) as query" ...
>
> where before QSRF it would have executed
>
>    SELECT ... FROM to_tsquery('value of terms') as query ...
>
> as a workaround, you can repeat the call to to_tsquery() and use
> select_params=, as in:
>
> 
>
>    results = Product.objects.extra(
>       select={
>              'rank': "rank_cd(textsearchable,to_tsquery(%s), 32)",
>              },
>       where=["textsearchable @@ to_tsquery(%s)"],
>       params=[terms],
>       select_params=[terms],
>       order_by=('-rank',)
>       )
>
> -
>
> Don't know how big of a hit it is to have to call to_tsquery() multiple
> times even with the same args.  But this isn't really just a fulltext
> search issue, it could come up with other PgSQL functions that are more
> heavyweight.
>
>         Barry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Tables params in extra()

[Dave Lowe]

It worked prior to qsrf-merge. I have tried adding the quotes though,
without success.

On May 13, 9:59 am, David Cramer <[EMAIL PROTECTED]> wrote:
> The database engine usually can't fill that in anyways, you should
> probably quote it yourself (correct me if I'm wrong).
>
> On May 13, 9:15 am, Dave Lowe <[EMAIL PROTECTED]> wrote:
>
> > Ever since the querset-refactor merge, params in the 'tables' argument
> > don't seem to be filled. The documentation describes the arguments
> > 'params' and 'select_params' as being for where and select statements,
> > respectively. Do we need a "tables_params" argument as well?
>
> > Here's a code sample of where I'm using tables params (it's for full-
> > text searching in postgres):
>
> > results = Product.objects.extra(
> >                             select={
> >                                 'rank': "rank_cd(textsearchable,
> > query, 32)",
> >                                 },
> >                             tables=["to_tsquery(%s) as query"],
> >                             where=["textsearchable @@ query"],
> >                             params=[terms],
> >                             order_by=('-rank',)
> >                     )
>
> > The error message by the way is: ProgrammingError: relation
> > "to_tsquery(2) as query" does not exist.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Tables params in extra()

[Dave Lowe]

Ever since the querset-refactor merge, params in the 'tables' argument
don't seem to be filled. The documentation describes the arguments
'params' and 'select_params' as being for where and select statements,
respectively. Do we need a "tables_params" argument as well?

Here's a code sample of where I'm using tables params (it's for full-
text searching in postgres):

results = Product.objects.extra(
select={
'rank': "rank_cd(textsearchable,
query, 32)",
},
tables=["to_tsquery(%s) as query"],
where=["textsearchable @@ query"],
params=[terms],
order_by=('-rank',)
)

The error message by the way is: ProgrammingError: relation
"to_tsquery(2) as query" does not exist.


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

Re: Generic ManyToMany Functionality

[Dave]

On Oct 12, 5:59 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:

> It's not really a big deal -- should only be a small amount of code
> (but writing the *right* code is the trick). I'd just do it as a patch
> against django.contrib.contettpyes.

Yeah, I suppose it would be relatively small. The way I had in mind
was to create a GenericManyToManyField and a
GenericManyRelationManager. I think that's all that would be
required...


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

Re: Generic ManyToMany Functionality

[Dave]

On Oct 12, 5:09 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 10/12/07, Dave Sullivan <[EMAIL PROTECTED]> wrote:
>
> > Google and trac both show nothing on this kind of functionality. I see that
> > contenttypes work like a Generic ForeignKey (many-to-one) but I don't see
> > anything about ManyToMany.
>
> > Is there any work being done by anyone on this kind of feature? I have some 
> > of
> > the details in mind, and if it isn't being worked on by anyone else, I had
> > planned on starting work on it.
>
> It's on my todo list -- I'm gonna need it for a project coming up in a
> couple of months, at least -- but of course if you wanna take a crack
> at it I'd love to let someone else do the work :)
>
> Jacob

Thanks, I'd love to take a crack at it. I'll keep you posted about my
progress. Is there anything I need to do in terms of setting up a
project like this?
Post details on DjangoBranches and set up a branch on my own server,
or...?


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

Generic ManyToMany Functionality

[Dave Sullivan]

Hey All,

Google and trac both show nothing on this kind of functionality. I see that 
contenttypes work like a Generic ForeignKey (many-to-one) but I don't see 
anything about ManyToMany.

Is there any work being done by anyone on this kind of feature? I have some of 
the details in mind, and if it isn't being worked on by anyone else, I had 
planned on starting work on it.

Basically, the concept is that generic m2m relations would be no more 
difficult than standard m2m relations:

class MyModel(models.Model):
content = models.GenericManyToManyField()

The content field would work like any other m2m field:

>>> m = MyModel()
>>> m2 = MyOtherModel()
>>> m3 = MyThirdModel()

>>> m.content.add(m2)
>>> m.content.add(m3)
>>> m.content
[, ]

Is anyone else working on something like this? Thoughts?

-- 
Dave Sullivan
[EMAIL PROTECTED]
647-235-0328

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

Re: Visual recogintion of Django website

[Dave]

On Sep 15, 10:22 pm, Mikkel Høgh <[EMAIL PROTECTED]> wrote:

> To illustrate my point, take a look at this image, a screenshot of a
> very normal Firefox tab bar of 
> mine:http://mikkel.hoegh.org/galleries/odd_stuff/i_3_favicons?size=_original
> It's much easier for me to find what I need by help of favicons - and
> yes, most of the time, I have so many tabs open that I cannot see the
> title of the web pages.

Easy, Django is the one without a favicon... oh wait, there's lots of
them in there.. I presume you're complaining to all of the other sites
that don't have them too?


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

Re: Adding SVN revision identifier to version

[Dave Rowe]

On Fri, 17 Aug 2007 14:45:01 -0500, "Deryck Hodge" <[EMAIL PROTECTED]> wrote:
> 
> Hi, all.
> 
> Reading the Django users list, I saw someone mention not knowing what
> the "pre" meant in the version string returned by django-admin.py.
> This made me think of version numbers more generally, and I wondered
> if others saw value in appending an SVN revision identifier on the
> version string.
> 
> So instead of 0.97-pre the version would be 0.97-pre-SVN-5919.  This
> might help make it easier to track down what revision people are
> running since so many of us run off trunk.  This, of course, would
> have no impact on official releases.
> 
> I worked up a quick patch, which I can add to a ticket, if others see
> any value in this.
> 
> http://dpaste.com/17141/
> 

Are these people always pulling from SVN?  Otherwise, it'd always show 
SVN-Unknown, right?  Especially if 'svn' isn't in the path.


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

Re: Ticket #3700: XhtmlDegraderMiddleware

[Dave Hodder]

Jacob Kaplan-Moss wrote:
> 
> Nice stuff -- think I'll be using this a few times.
> 
> However, I'd say that it's a *bit* too specialized for direct
> inclusion; while I personally find it useful, I'm just suspicious of
> including anything in Django that doesn't have obvious wide appeal.
> 
> I'd say this is a *perfect* candidate for djangosnippets.org, though;
> put it there and people will quickly be able to find it.  That or a
> Google Code project if you plan to add more stuff onto it...
> 
> Of course, what we really need is a CPAN-for-Django-bits-thingie... I
> wish there was a middle ground between "included" and "not."

Thanks for looking at it Jacob.  I've followed your advice and placed it 
on djangosnippets.org.

Regards,

Dave

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