Re: Django Admin New Look

[Aymeric Augustin]

On 18 août 2015, at 01:28, Tim Graham  wrote:

> Unless someone can present an argument for keeping IE8 support, I wouldn't 
> worry about it considering it will be end of life about 1 month after the 
> release of Django 1.9.

Let’s just make sure the admin stays usable, even if it looks bad. Since we’re 
taking the SVG route, providing an alt text on icons should do.

We could be explicit about the lack of support for IE8 and lower by adding a 
conditional message in the template:



-- 
Aymeric.




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

Re: Django Admin New Look

[Tim Graham]

I also had the idea of upgrading jQuery to jQuery 2 which drops support for 
IE6/7/8, but I guess this will break all the JavaScript in the admin under 
those browsers. Do you think that's unacceptable at this time? If so, could 
you propose an alternate timetable for the upgrade?

On Tuesday, August 18, 2015 at 3:32:18 AM UTC-4, Aymeric Augustin wrote:
>
> On 18 août 2015, at 01:28, Tim Graham > 
> wrote: 
>
> > Unless someone can present an argument for keeping IE8 support, I 
> wouldn't worry about it considering it will be end of life about 1 month 
> after the release of Django 1.9. 
>
> Let’s just make sure the admin stays usable, even if it looks bad. Since 
> we’re taking the SVG route, providing an alt text on icons should do. 
>
> We could be explicit about the lack of support for IE8 and lower by adding 
> a conditional message in the template: 
>
>  
>
> -- 
> Aymeric. 
>
>
>
>
>

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

Re: Django Admin New Look

[Marc Tamlyn]

I don't know about schedule, but caniuse reports IE8 browser usage at 1.5%,
more than IE9 or IE10.

There's an argument we shouldn't be "enabling" people still using XP who
are stuck on IE8, and this is a decreasing problem, but I don't think we
can tie ourselves to Microsoft's support dates.

On 18 August 2015 at 12:13, Tim Graham  wrote:

> I also had the idea of upgrading jQuery to jQuery 2 which drops support
> for IE6/7/8, but I guess this will break all the JavaScript in the admin
> under those browsers. Do you think that's unacceptable at this time? If so,
> could you propose an alternate timetable for the upgrade?
>
> On Tuesday, August 18, 2015 at 3:32:18 AM UTC-4, Aymeric Augustin wrote:
>>
>> On 18 août 2015, at 01:28, Tim Graham  wrote:
>>
>> > Unless someone can present an argument for keeping IE8 support, I
>> wouldn't worry about it considering it will be end of life about 1 month
>> after the release of Django 1.9.
>>
>> Let’s just make sure the admin stays usable, even if it looks bad. Since
>> we’re taking the SVG route, providing an alt text on icons should do.
>>
>> We could be explicit about the lack of support for IE8 and lower by
>> adding a conditional message in the template:
>>
>> 
>>
>> --
>> Aymeric.
>>
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e541a69a-2ded-4af1-b049-f144878c0f83%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Django Admin New Look

[Markus Holtermann]

Hey,

Looking at some browser market share stats
(http://www.sitepoint.com/browser-trends-august-2015-chrome-exceeds-50/
, disclaimer:
http://www.sitepoint.com/how-browser-market-share-is-calculated/) IE8
seems hardly be used anyway. Furthermore, with the dropped support for
IE8 (and 9+) on Jan 12th, 2016
(https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=internet%20explorer),
I don't really see any problem in removing IE8 support and notifying the
users that they have to update to a modern browser.

Therefore I find Aymeric's proposed solution "You are using an old web
browser ..." a reasonable choice over being stuck with ages old
technology that is long outdated.

/Markus

PS: I'd go with SVG solution

On Tue, Aug 18, 2015 at 04:13:11AM -0700, Tim Graham wrote:

I also had the idea of upgrading jQuery to jQuery 2 which drops support for
IE6/7/8, but I guess this will break all the JavaScript in the admin under
those browsers. Do you think that's unacceptable at this time? If so, could
you propose an alternate timetable for the upgrade?

On Tuesday, August 18, 2015 at 3:32:18 AM UTC-4, Aymeric Augustin wrote:


On 18 août 2015, at 01:28, Tim Graham >
wrote:

> Unless someone can present an argument for keeping IE8 support, I
wouldn't worry about it considering it will be end of life about 1 month
after the release of Django 1.9.

Let’s just make sure the admin stays usable, even if it looks bad. Since
we’re taking the SVG route, providing an alt text on icons should do.

We could be explicit about the lack of support for IE8 and lower by adding
a conditional message in the template:



--
Aymeric.







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



--

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


pgpgFEniLPuy7.pgp
Description: PGP signature

Re: Django ORM query syntax enhancement

[Alexey Zankevich]

Hi all,

Thanks for detailed response. I thought over the described expressions/
transforms patches and here are my thoughts about the best way to
implement simplified lookups.

Firstly, I want to describe which properties of the new syntax seem to be
important:

1. Using Python operators to do basic lookups as it's a natural way in 
Python
for that.

2. Syntax should be minimalistic for basic lookups, the use of that approach
will be more noticeable on multiple filter conditions. In other words, next
syntax is better:

>>> GameSession.objects.filter(Q.user.profile.last_login.date() == 
datetime.now().date)

than this one

>>> GameSession.objects.filter(E(F.user.profile.last_login).date() == 
datetime.now().date)

as it requires additional calls, which makes expressions less readable.

3. I definitely like the idea of having explicit classes for lookups and
transforms and think it's worth to bundle dotted query syntax with the 
patch.
Explicit classes will separate functionality and simplify functions 
signature
checks.

I suggest a mixed approach, with next properties.

1. We will have a separate class to define query paths (let's call it P, we
can still use F as "field", but having F as multipurpose class may confuse
users, as well as implementation may become more complicated). And it will 
be
the only purpose of the class. Below I'll reference it as "P" no matter we 
call
it in future.

2. Any transforms and lookups will take query string or P class, as well as
existing methods "select_related", "prefetch_related" and "order_by". The
simplest implementation will be overriding __str__ method of the path class
to generate related strings.

>>> path = P.user.last_login_date
>>> GameSession.objects.all().order_by(path)[:10]

>>> print(path)
user__last_login_date

3. Implement transforms and lookups as classes or functions (not bound to P 
class):

>>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote 
d'Ivoire")

It will simplify cases with parametrized transforms (ex. mentioned 
collate('fi')).
Also eliminate fields collision with util functions like "date", which may 
be a
so-called field.

4. Below is a table describing accepted passed and returned parameters:

+---+---+--+
|  Class/Function   |Allowed Param Types| Comparison Operators |
+---+---+--+
| Transform | str, P, Transform, Lookup | Return lookup|
| Lookup| str, P, Transform | Raise exception  |
| P |   | Return lookup|
| .order_by | str, P|  |
| .select_related   | str, P|  |
| .prefetch_related | str, P, Prefetch  |  |
+---+---+--+


Samples:

>>> P.user.name == 'Bob'
Equal('user__name', 'Bob')

>>> Unaccent(P.user.name)
Unaccent('user__name')

>>> Collate(P.user.name, 'fi')
Collate('user__name', 'fi')

>>> Unaccent(P.user.name) == 'Bob'
Equal(Unaccent('user__name'), 'Bob')

>>> Equal(P.user.name, 'Bob') == 'Bob'
Traceback (most recent call last):
  File "", line 1, in 
Exception: Lookups comparison is not allowed

>>> Contains(P.user.name, 'Bo')  # lookup
>>> Date(P.user.last_login_date, datetime.now().date)  # transform


Questions to discuss and possible pitfalls:

1. Handling descended ordering in order_by

>>> path = P.user.last_login_date
>>> -path
'-user__last_login_date'

or even

>>> -p
NegP('user__last_login_date')

Is it possible path subtraction is required in future by any reason? In that
case the given approach will be inconvenient. Or may be better to just let
users to format desc ordering themselves?

>>> '-{}'.format(path)

2. Don't think it's a big deal, but users might do next thing:

>>> path = P.user.last_login_date
>>> GameSession.objects.filter(path=today)
Traceback (most recent call last):
  File "", line 1, in 
FieldError: Cannot resolve keyword 'path' into field.

At least need to mention it in documentation

3. Classes vs factory functions:

>>> Equal(P.user.name, 'Bob')
Equal('user__name', 'Bob')

vs

>>> equal(P.user.name, 'Bob')
Equal('user__name', 'Bob')


If you are fine with described syntax I can start with DEP.

Regards,
Alexey

On Monday, August 17, 2015 at 12:26:45 PM UTC+3, Anssi Kääriäinen wrote:
>
> I like this idea, too. 
>
> The work I and Loic have been doing has been about transforms that can 
> accept arguments. I don't see why the two styles couldn't be mixed 
> directly. 
>
> .filter(Q.user.profile.last_login.date(timezone='Europe/Helsinki') < 
> '2015-01-01') 
> .filter(Q.user.last_name.collate('fi').unaccent() == 'Kaariainen') 
>
> OTOH if you want to use expressions directly, that should be OK, too 
> (if you don't mind the non-optimal readability): 
> .filter(Exact(unaccent(collate(Q.user.la

Re: Enhancement to the call_command function to allow the use of modules as arguments

[Mike Lissner]

I see. Could this concern be addressed by adding it to the checks
framework, so that it throws a warning if there are ever two commands with
the same name?

On Mon, Aug 17, 2015 at 11:16 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> 2015-08-17 16:54 GMT+02:00 Mike Lissner :
>
>>
>> I’m -1 on removing the Python API that’s equivalent to `django-admin
>>> my_command`. It’s needed for testing management commands that override
>>> other management commands.
>>>
>>
>> Not sure what you mean here, but I suspect you're making a good point.
>> Does seem pretty niche though. Can you explain?
>>
>
> Here's the scenario.
>
> 1. You write a do_stuff management command in your project. You write a
> test to ensure that call_command('do_stuff') does the right thing.
> 2. A co-worker adds a third-party app which also implements a do_stuff
> management command. Unfortunately, the order of INSTALLED_APPS means that
> your command is overridden by the third-party app. Fortunately, your test
> catches the problem.
>
> With the change you're proposing, the test wouldn't catch the problem
> anymore.
>
> That's why Django needs an API to emulate `django-admin do_stuff`.
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/8aNf-lZXSVg/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANE-7mVHu8cCw8dUDcA4ECnNqCGD%2BS4LAPBFRnBUAo3%2Bm65PcA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Enhancement to the call_command function to allow the use of modules as arguments

[Marc Tamlyn]

This is a deliberate approach you would use - South used it for years to
customise syncdb.

call_command is intended as a python API for testing `$ django-admin foo`.
Two of your arguments are based around IDE usage, which I don't think is a
valid argument, and the third is about reducing string magic. I don't feel
there is any magic at all here, we are modelling a string based API so
naturally we use strings to do so.

On 17 August 2015 at 16:20, Mike Lissner 
wrote:

> I see. Could this concern be addressed by adding it to the checks
> framework, so that it throws a warning if there are ever two commands with
> the same name?
>
> On Mon, Aug 17, 2015 at 11:16 AM Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> 2015-08-17 16:54 GMT+02:00 Mike Lissner :
>>
>>>
>>> I’m -1 on removing the Python API that’s equivalent to `django-admin
 my_command`. It’s needed for testing management commands that override
 other management commands.

>>>
>>> Not sure what you mean here, but I suspect you're making a good point.
>>> Does seem pretty niche though. Can you explain?
>>>
>>
>> Here's the scenario.
>>
>> 1. You write a do_stuff management command in your project. You write a
>> test to ensure that call_command('do_stuff') does the right thing.
>> 2. A co-worker adds a third-party app which also implements a do_stuff
>> management command. Unfortunately, the order of INSTALLED_APPS means that
>> your command is overridden by the third-party app. Fortunately, your test
>> catches the problem.
>>
>> With the change you're proposing, the test wouldn't catch the problem
>> anymore.
>>
>> That's why Django needs an API to emulate `django-admin do_stuff`.
>>
>> --
>> Aymeric.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/8aNf-lZXSVg/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CANE-7mVHu8cCw8dUDcA4ECnNqCGD%2BS4LAPBFRnBUAo3%2Bm65PcA%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMp9%3DEzBJSSyhc7F_recj4-8CUxghzXSG%3Drx9EBT6MtDm3AeaQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Django ORM query syntax enhancement

[Collin Anderson]

Just a quick thought: I could imagine some newbies could get confused by 
the python-like syntax and try to do:

Equal(P.user.get_full_name(), 'Bob Someone')

I don't think it's not a huge deal, but worth noting.

On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
>
> Hi all,
>
> Thanks for detailed response. I thought over the described expressions/
> transforms patches and here are my thoughts about the best way to
> implement simplified lookups.
>
> Firstly, I want to describe which properties of the new syntax seem to be
> important:
>
> 1. Using Python operators to do basic lookups as it's a natural way in 
> Python
> for that.
>
> 2. Syntax should be minimalistic for basic lookups, the use of that 
> approach
> will be more noticeable on multiple filter conditions. In other words, next
> syntax is better:
>
> >>> GameSession.objects.filter(Q.user.profile.last_login.date() == 
> datetime.now().date)
>
> than this one
>
> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() == 
> datetime.now().date)
>
> as it requires additional calls, which makes expressions less readable.
>
> 3. I definitely like the idea of having explicit classes for lookups and
> transforms and think it's worth to bundle dotted query syntax with the 
> patch.
> Explicit classes will separate functionality and simplify functions 
> signature
> checks.
>
> I suggest a mixed approach, with next properties.
>
> 1. We will have a separate class to define query paths (let's call it P, we
> can still use F as "field", but having F as multipurpose class may confuse
> users, as well as implementation may become more complicated). And it will 
> be
> the only purpose of the class. Below I'll reference it as "P" no matter we 
> call
> it in future.
>
> 2. Any transforms and lookups will take query string or P class, as well as
> existing methods "select_related", "prefetch_related" and "order_by". The
> simplest implementation will be overriding __str__ method of the path class
> to generate related strings.
>
> >>> path = P.user.last_login_date
> >>> GameSession.objects.all().order_by(path)[:10]
>
> >>> print(path)
> user__last_login_date
>
> 3. Implement transforms and lookups as classes or functions (not bound to 
> P class):
>
> >>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote 
> d'Ivoire")
>
> It will simplify cases with parametrized transforms (ex. mentioned 
> collate('fi')).
> Also eliminate fields collision with util functions like "date", which may 
> be a
> so-called field.
>
> 4. Below is a table describing accepted passed and returned parameters:
>
> +---+---+--+
> |  Class/Function   |Allowed Param Types| Comparison Operators |
> +---+---+--+
> | Transform | str, P, Transform, Lookup | Return lookup|
> | Lookup| str, P, Transform | Raise exception  |
> | P |   | Return lookup|
> | .order_by | str, P|  |
> | .select_related   | str, P|  |
> | .prefetch_related | str, P, Prefetch  |  |
> +---+---+--+
>
>
> Samples:
>
> >>> P.user.name == 'Bob'
> Equal('user__name', 'Bob')
>
> >>> Unaccent(P.user.name)
> Unaccent('user__name')
>
> >>> Collate(P.user.name, 'fi')
> Collate('user__name', 'fi')
>
> >>> Unaccent(P.user.name) == 'Bob'
> Equal(Unaccent('user__name'), 'Bob')
>
> >>> Equal(P.user.name, 'Bob') == 'Bob'
> Traceback (most recent call last):
>   File "", line 1, in 
> Exception: Lookups comparison is not allowed
>
> >>> Contains(P.user.name, 'Bo')  # lookup
> >>> Date(P.user.last_login_date, datetime.now().date)  # transform
>
>
> Questions to discuss and possible pitfalls:
>
> 1. Handling descended ordering in order_by
>
> >>> path = P.user.last_login_date
> >>> -path
> '-user__last_login_date'
>
> or even
>
> >>> -p
> NegP('user__last_login_date')
>
> Is it possible path subtraction is required in future by any reason? In 
> that
> case the given approach will be inconvenient. Or may be better to just let
> users to format desc ordering themselves?
>
> >>> '-{}'.format(path)
>
> 2. Don't think it's a big deal, but users might do next thing:
>
> >>> path = P.user.last_login_date
> >>> GameSession.objects.filter(path=today)
> Traceback (most recent call last):
>   File "", line 1, in 
> FieldError: Cannot resolve keyword 'path' into field.
>
> At least need to mention it in documentation
>
> 3. Classes vs factory functions:
>
> >>> Equal(P.user.name, 'Bob')
> Equal('user__name', 'Bob')
>
> vs
>
> >>> equal(P.user.name, 'Bob')
> Equal('user__name', 'Bob')
>
>
> If you are fine with described syntax I can start with DEP.
>
> Regards,
> Alexey
>
> On Monday, August 17, 2015 at 12:26:45 P

Re: Enhancement to the call_command function to allow the use of modules as arguments

[Carl Meyer]

Hi Marc, Mike, Aymeric,

On 08/18/2015 06:52 AM, Marc Tamlyn wrote:
> This is a deliberate approach you would use - South used it for years to
> customise syncdb.
> 
> call_command is intended as a python API for testing `$ django-admin
> foo`. Two of your arguments are based around IDE usage, which I don't
> think is a valid argument, and the third is about reducing string magic.
> I don't feel there is any magic at all here, we are modelling a string
> based API so naturally we use strings to do so.

I agree that the way Django maps string names to management commands is
reasonable and useful and not especially magical -- if you're building a
CLI you have to map strings to code in some way.

I also fully agree with Mike that usually in Python code it's preferable
to explicitly import and call the code you want, rather than going
through an extra string-to-code mapping (which only exists to support a
CLI). For this reason, I rarely use `call_command`. But I don't think it
should be changed. There needs to be some API (if only for testing,
which is the only place I ever use it) that exercises a management
command end-to-end, including the name-to-code mapping, the default CLI
arguments and options, etc. `call_command` is that API, and it does that
(necessary) job well, so there's no reason to change it.

The responsibilities of a management command class should be to parse
input (CLI args and options) and manage output (stdout/stderr).
Everything else (all business logic) should be extracted into
independently reusable functions or classes. If you need to exercise the
whole CLI-oriented shebang (including string-to-code mapping,
args/options parsing, and stdout/stderr), you use `call_command`. If you
just want the business logic, don't mess with the management commands
system at all; just import and use your regular Python functions and
classes.

(Doc patches to better reflect that principle in the management command
docs are welcome, IMO.)

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: Enhancement to the call_command function to allow the use of modules as arguments

[Mike Lissner]

On Tuesday, August 18, 2015 at 12:00:30 PM UTC-4, Carl Meyer wrote:

>
> (Doc patches to better reflect that principle in the management command 
> docs are welcome, IMO.) 
>
> Yeah, it's sounding like this is the change that's needed here. Probably 
the place to do that is here:

https://docs.djangoproject.com/en/1.8/topics/testing/tools/#management-commands

Perhaps should just point out that:

1. call_command should be used if you want to do end-to-end parsing.
2. business logic should be placed outside of the Command class in easy to 
grab functions.
3. only parsing logic should live in the command itself.

It'd also be good to update the management commands documentation to 
explain how business logic should live outside the command itself. That'd 
not how they're presently described. The current example has:

def handle(self, *args, **options):
for poll_id in options['poll_id']:
try:
poll = Poll.objects.get(pk=poll_id)
except Poll.DoesNotExist:
raise CommandError('Poll "%s" does not exist' % poll_id)

poll.opened = False
poll.save()

self.stdout.write('Successfully closed poll "%s"' % poll_id)

 

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

Re: Enhancement to the call_command function to allow the use of modules as arguments

[Carl Meyer]

On 08/18/2015 10:10 AM, Mike Lissner wrote:
> On Tuesday, August 18, 2015 at 12:00:30 PM UTC-4, Carl Meyer wrote:
> 
> 
> (Doc patches to better reflect that principle in the management command
> docs are welcome, IMO.)
> 
> Yeah, it's sounding like this is the change that's needed here. Probably
> the place to do that is here:
> 
> https://docs.djangoproject.com/en/1.8/topics/testing/tools/#management-commands
> 
> Perhaps should just point out that:
> 
> 1. call_command should be used if you want to do end-to-end parsing.
> 2. business logic should be placed outside of the Command class in easy
> to grab functions.
> 3. only parsing logic should live in the command itself.

Yep.

> It'd also be good to update the management commands documentation to
> explain how business logic should live outside the command itself.
> That'd not how they're presently described. The current example has:
> 
> def handle(self, *args, **options):
> for poll_id in options['poll_id']:
> try:
> poll = Poll.objects.get(pk=poll_id)
> except Poll.DoesNotExist:
> raise CommandError('Poll "%s" does not exist' % poll_id)
> 
> poll.opened = False
> poll.save()
> 
> self.stdout.write('Successfully closed poll "%s"' % poll_id)

IMO the first four lines there are arguably part of parsing CLI input --
they are validating the given poll ID and converting it a Poll model
instance. I would usually leave that code in the management command,
since my business logic API likely prefers to operate in terms of model
instances, not their IDs.

So the "business logic" in this toy example really boils down to just
one or two lines: marking a poll opened=False and then saving it. Hardly
worth extracting; that's the problem with toy examples. Perhaps just a
prose note could be added mentioning that as the business logic expands,
it should be extracted.

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: Django ORM query syntax enhancement

[Anssi Kääriäinen]

I'm still thinking we shouldn't integrate any new query syntax into
1.9. Instead lets make it easy to create 3rd party apps that offer
different querying syntax, and then lets see which solution (if any)
gets popular enough to be integrated into Django.

 - Anssi



On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson  wrote:
> Just a quick thought: I could imagine some newbies could get confused by the
> python-like syntax and try to do:
>
> Equal(P.user.get_full_name(), 'Bob Someone')
>
> I don't think it's not a huge deal, but worth noting.
>
> On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
>>
>> Hi all,
>>
>> Thanks for detailed response. I thought over the described expressions/
>> transforms patches and here are my thoughts about the best way to
>> implement simplified lookups.
>>
>> Firstly, I want to describe which properties of the new syntax seem to be
>> important:
>>
>> 1. Using Python operators to do basic lookups as it's a natural way in
>> Python
>> for that.
>>
>> 2. Syntax should be minimalistic for basic lookups, the use of that
>> approach
>> will be more noticeable on multiple filter conditions. In other words,
>> next
>> syntax is better:
>>
>> >>> GameSession.objects.filter(Q.user.profile.last_login.date() ==
>> >>> datetime.now().date)
>>
>> than this one
>>
>> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() ==
>> >>> datetime.now().date)
>>
>> as it requires additional calls, which makes expressions less readable.
>>
>> 3. I definitely like the idea of having explicit classes for lookups and
>> transforms and think it's worth to bundle dotted query syntax with the
>> patch.
>> Explicit classes will separate functionality and simplify functions
>> signature
>> checks.
>>
>> I suggest a mixed approach, with next properties.
>>
>> 1. We will have a separate class to define query paths (let's call it P,
>> we
>> can still use F as "field", but having F as multipurpose class may confuse
>> users, as well as implementation may become more complicated). And it will
>> be
>> the only purpose of the class. Below I'll reference it as "P" no matter we
>> call
>> it in future.
>>
>> 2. Any transforms and lookups will take query string or P class, as well
>> as
>> existing methods "select_related", "prefetch_related" and "order_by". The
>> simplest implementation will be overriding __str__ method of the path
>> class
>> to generate related strings.
>>
>> >>> path = P.user.last_login_date
>> >>> GameSession.objects.all().order_by(path)[:10]
>>
>> >>> print(path)
>> user__last_login_date
>>
>> 3. Implement transforms and lookups as classes or functions (not bound to
>> P class):
>>
>> >>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote
>> >>> d'Ivoire")
>>
>> It will simplify cases with parametrized transforms (ex. mentioned
>> collate('fi')).
>> Also eliminate fields collision with util functions like "date", which may
>> be a
>> so-called field.
>>
>> 4. Below is a table describing accepted passed and returned parameters:
>>
>> +---+---+--+
>> |  Class/Function   |Allowed Param Types| Comparison Operators |
>> +---+---+--+
>> | Transform | str, P, Transform, Lookup | Return lookup|
>> | Lookup| str, P, Transform | Raise exception  |
>> | P |   | Return lookup|
>> | .order_by | str, P|  |
>> | .select_related   | str, P|  |
>> | .prefetch_related | str, P, Prefetch  |  |
>> +---+---+--+
>>
>>
>> Samples:
>>
>> >>> P.user.name == 'Bob'
>> Equal('user__name', 'Bob')
>>
>> >>> Unaccent(P.user.name)
>> Unaccent('user__name')
>>
>> >>> Collate(P.user.name, 'fi')
>> Collate('user__name', 'fi')
>>
>> >>> Unaccent(P.user.name) == 'Bob'
>> Equal(Unaccent('user__name'), 'Bob')
>>
>> >>> Equal(P.user.name, 'Bob') == 'Bob'
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> Exception: Lookups comparison is not allowed
>>
>> >>> Contains(P.user.name, 'Bo')  # lookup
>> >>> Date(P.user.last_login_date, datetime.now().date)  # transform
>>
>>
>> Questions to discuss and possible pitfalls:
>>
>> 1. Handling descended ordering in order_by
>>
>> >>> path = P.user.last_login_date
>> >>> -path
>> '-user__last_login_date'
>>
>> or even
>>
>> >>> -p
>> NegP('user__last_login_date')
>>
>> Is it possible path subtraction is required in future by any reason? In
>> that
>> case the given approach will be inconvenient. Or may be better to just let
>> users to format desc ordering themselves?
>>
>> >>> '-{}'.format(path)
>>
>> 2. Don't think it's a big deal, but users might do next thing:
>>
>> >>> path = P.user.last_login_date
>> >>> GameSession.objects.filter(path

Re: Django ORM query syntax enhancement

[Marc Tamlyn]

I strongly agree with the third party approach.
On 18 Aug 2015 17:49, "Anssi Kääriäinen"  wrote:

> I'm still thinking we shouldn't integrate any new query syntax into
> 1.9. Instead lets make it easy to create 3rd party apps that offer
> different querying syntax, and then lets see which solution (if any)
> gets popular enough to be integrated into Django.
>
>  - Anssi
>
>
>
> On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson 
> wrote:
> > Just a quick thought: I could imagine some newbies could get confused by
> the
> > python-like syntax and try to do:
> >
> > Equal(P.user.get_full_name(), 'Bob Someone')
> >
> > I don't think it's not a huge deal, but worth noting.
> >
> > On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
> >>
> >> Hi all,
> >>
> >> Thanks for detailed response. I thought over the described expressions/
> >> transforms patches and here are my thoughts about the best way to
> >> implement simplified lookups.
> >>
> >> Firstly, I want to describe which properties of the new syntax seem to
> be
> >> important:
> >>
> >> 1. Using Python operators to do basic lookups as it's a natural way in
> >> Python
> >> for that.
> >>
> >> 2. Syntax should be minimalistic for basic lookups, the use of that
> >> approach
> >> will be more noticeable on multiple filter conditions. In other words,
> >> next
> >> syntax is better:
> >>
> >> >>> GameSession.objects.filter(Q.user.profile.last_login.date() ==
> >> >>> datetime.now().date)
> >>
> >> than this one
> >>
> >> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() ==
> >> >>> datetime.now().date)
> >>
> >> as it requires additional calls, which makes expressions less readable.
> >>
> >> 3. I definitely like the idea of having explicit classes for lookups and
> >> transforms and think it's worth to bundle dotted query syntax with the
> >> patch.
> >> Explicit classes will separate functionality and simplify functions
> >> signature
> >> checks.
> >>
> >> I suggest a mixed approach, with next properties.
> >>
> >> 1. We will have a separate class to define query paths (let's call it P,
> >> we
> >> can still use F as "field", but having F as multipurpose class may
> confuse
> >> users, as well as implementation may become more complicated). And it
> will
> >> be
> >> the only purpose of the class. Below I'll reference it as "P" no matter
> we
> >> call
> >> it in future.
> >>
> >> 2. Any transforms and lookups will take query string or P class, as well
> >> as
> >> existing methods "select_related", "prefetch_related" and "order_by".
> The
> >> simplest implementation will be overriding __str__ method of the path
> >> class
> >> to generate related strings.
> >>
> >> >>> path = P.user.last_login_date
> >> >>> GameSession.objects.all().order_by(path)[:10]
> >>
> >> >>> print(path)
> >> user__last_login_date
> >>
> >> 3. Implement transforms and lookups as classes or functions (not bound
> to
> >> P class):
> >>
> >> >>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote
> >> >>> d'Ivoire")
> >>
> >> It will simplify cases with parametrized transforms (ex. mentioned
> >> collate('fi')).
> >> Also eliminate fields collision with util functions like "date", which
> may
> >> be a
> >> so-called field.
> >>
> >> 4. Below is a table describing accepted passed and returned parameters:
> >>
> >> +---+---+--+
> >> |  Class/Function   |Allowed Param Types| Comparison Operators |
> >> +---+---+--+
> >> | Transform | str, P, Transform, Lookup | Return lookup|
> >> | Lookup| str, P, Transform | Raise exception  |
> >> | P |   | Return lookup|
> >> | .order_by | str, P|  |
> >> | .select_related   | str, P|  |
> >> | .prefetch_related | str, P, Prefetch  |  |
> >> +---+---+--+
> >>
> >>
> >> Samples:
> >>
> >> >>> P.user.name == 'Bob'
> >> Equal('user__name', 'Bob')
> >>
> >> >>> Unaccent(P.user.name)
> >> Unaccent('user__name')
> >>
> >> >>> Collate(P.user.name, 'fi')
> >> Collate('user__name', 'fi')
> >>
> >> >>> Unaccent(P.user.name) == 'Bob'
> >> Equal(Unaccent('user__name'), 'Bob')
> >>
> >> >>> Equal(P.user.name, 'Bob') == 'Bob'
> >> Traceback (most recent call last):
> >>   File "", line 1, in 
> >> Exception: Lookups comparison is not allowed
> >>
> >> >>> Contains(P.user.name, 'Bo')  # lookup
> >> >>> Date(P.user.last_login_date, datetime.now().date)  # transform
> >>
> >>
> >> Questions to discuss and possible pitfalls:
> >>
> >> 1. Handling descended ordering in order_by
> >>
> >> >>> path = P.user.last_login_date
> >> >>> -path
> >> '-user__last_login_date'
> >>
> >> or even
> >>
> >> >>> -p
> >> NegP('user__last_login_

Re: Django ORM query syntax enhancement

[Michael Manfre]

+1 for making it doable for 3rd party apps.

Regards,
Michael Manfre

On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen 
wrote:

> I'm still thinking we shouldn't integrate any new query syntax into
> 1.9. Instead lets make it easy to create 3rd party apps that offer
> different querying syntax, and then lets see which solution (if any)
> gets popular enough to be integrated into Django.
>
>  - Anssi
>
>
>
> On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson 
> wrote:
> > Just a quick thought: I could imagine some newbies could get confused by
> the
> > python-like syntax and try to do:
> >
> > Equal(P.user.get_full_name(), 'Bob Someone')
> >
> > I don't think it's not a huge deal, but worth noting.
> >
> > On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
> >>
> >> Hi all,
> >>
> >> Thanks for detailed response. I thought over the described expressions/
> >> transforms patches and here are my thoughts about the best way to
> >> implement simplified lookups.
> >>
> >> Firstly, I want to describe which properties of the new syntax seem to
> be
> >> important:
> >>
> >> 1. Using Python operators to do basic lookups as it's a natural way in
> >> Python
> >> for that.
> >>
> >> 2. Syntax should be minimalistic for basic lookups, the use of that
> >> approach
> >> will be more noticeable on multiple filter conditions. In other words,
> >> next
> >> syntax is better:
> >>
> >> >>> GameSession.objects.filter(Q.user.profile.last_login.date() ==
> >> >>> datetime.now().date)
> >>
> >> than this one
> >>
> >> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() ==
> >> >>> datetime.now().date)
> >>
> >> as it requires additional calls, which makes expressions less readable.
> >>
> >> 3. I definitely like the idea of having explicit classes for lookups and
> >> transforms and think it's worth to bundle dotted query syntax with the
> >> patch.
> >> Explicit classes will separate functionality and simplify functions
> >> signature
> >> checks.
> >>
> >> I suggest a mixed approach, with next properties.
> >>
> >> 1. We will have a separate class to define query paths (let's call it P,
> >> we
> >> can still use F as "field", but having F as multipurpose class may
> confuse
> >> users, as well as implementation may become more complicated). And it
> will
> >> be
> >> the only purpose of the class. Below I'll reference it as "P" no matter
> we
> >> call
> >> it in future.
> >>
> >> 2. Any transforms and lookups will take query string or P class, as well
> >> as
> >> existing methods "select_related", "prefetch_related" and "order_by".
> The
> >> simplest implementation will be overriding __str__ method of the path
> >> class
> >> to generate related strings.
> >>
> >> >>> path = P.user.last_login_date
> >> >>> GameSession.objects.all().order_by(path)[:10]
> >>
> >> >>> print(path)
> >> user__last_login_date
> >>
> >> 3. Implement transforms and lookups as classes or functions (not bound
> to
> >> P class):
> >>
> >> >>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote
> >> >>> d'Ivoire")
> >>
> >> It will simplify cases with parametrized transforms (ex. mentioned
> >> collate('fi')).
> >> Also eliminate fields collision with util functions like "date", which
> may
> >> be a
> >> so-called field.
> >>
> >> 4. Below is a table describing accepted passed and returned parameters:
> >>
> >> +---+---+--+
> >> |  Class/Function   |Allowed Param Types| Comparison Operators |
> >> +---+---+--+
> >> | Transform | str, P, Transform, Lookup | Return lookup|
> >> | Lookup| str, P, Transform | Raise exception  |
> >> | P |   | Return lookup|
> >> | .order_by | str, P|  |
> >> | .select_related   | str, P|  |
> >> | .prefetch_related | str, P, Prefetch  |  |
> >> +---+---+--+
> >>
> >>
> >> Samples:
> >>
> >> >>> P.user.name == 'Bob'
> >> Equal('user__name', 'Bob')
> >>
> >> >>> Unaccent(P.user.name)
> >> Unaccent('user__name')
> >>
> >> >>> Collate(P.user.name, 'fi')
> >> Collate('user__name', 'fi')
> >>
> >> >>> Unaccent(P.user.name) == 'Bob'
> >> Equal(Unaccent('user__name'), 'Bob')
> >>
> >> >>> Equal(P.user.name, 'Bob') == 'Bob'
> >> Traceback (most recent call last):
> >>   File "", line 1, in 
> >> Exception: Lookups comparison is not allowed
> >>
> >> >>> Contains(P.user.name, 'Bo')  # lookup
> >> >>> Date(P.user.last_login_date, datetime.now().date)  # transform
> >>
> >>
> >> Questions to discuss and possible pitfalls:
> >>
> >> 1. Handling descended ordering in order_by
> >>
> >> >>> path = P.user.last_login_date
> >> >>> -path
> >> '-user__last_login_date'
> >>
> >> or even
> >>
> >> >>>

[ANNOUNCE] Django security releases issued (1.4.22, 1.7.10, and 1.8.4)

[Tim Graham]

Today the Django team issued multiple releases -- Django 1.4.22, 1.7.10, 
and 1.8.4 -- as part of our security process. These releases address a 
security issue, and we encourage all users to upgrade as soon as possible.

More details can be found on our blog:

https://www.djangoproject.com/weblog/2015/aug/18/security-releases/

As a reminder, we ask that potential security issues be reported via 
private email to secur...@djangoproject.com, and not via Django's Trac 
instance or the django-developers list. Please see 
https://www.djangoproject.com/security for further information.

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

Re: Django ORM query syntax enhancement

[Alexey Zankevich]

Once Josh completes this patch https://github.com/django/django/pull/5090
(.filter method accepting class-based lookups and transforms), it will be
almost everything required by third-party apps. Is it going to be a part of
Django 1.9, by the way?

Additionally, for pure flexibility, next method and classes need to accept
either a callable or an object supporting special path interface (for 
example,
just a single method get_path() returning string path).
They listed below:

1. The current methods.select_related, .prefetch_related, .order_by
2. Annotation classes Min, Max, Count, Sum
3. Future transforms and lookups classes


Examples:

>>> path = lambda x: 'user__last_login_date'
>>> GameSession.objects.all().order_by(path)

or

>>> class LoginDatePath(object):
... def get_path(self):
... return 'user__last_login_date'
>>> path = LoginDatePath()
>>> GameSession.objects.all().order_by(path)

Path generation is a critical part of external query syntax as it used in
almost all aspects of the ORM, meanwhile each related method accepts either 
a
string or (in some cases) a specific kind of class - OrderBy for order_by
method, Prefetch for prefetch_related and etc.


On Tuesday, August 18, 2015 at 7:54:48 PM UTC+3, Michael Manfre wrote:
>
> +1 for making it doable for 3rd party apps.
>
> Regards,
> Michael Manfre
>
> On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen  > wrote:
>
>> I'm still thinking we shouldn't integrate any new query syntax into
>> 1.9. Instead lets make it easy to create 3rd party apps that offer
>> different querying syntax, and then lets see which solution (if any)
>> gets popular enough to be integrated into Django.
>>
>>  - Anssi
>>
>>
>>
>> On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson > > wrote:
>> > Just a quick thought: I could imagine some newbies could get confused 
>> by the
>> > python-like syntax and try to do:
>> >
>> > Equal(P.user.get_full_name(), 'Bob Someone')
>> >
>> > I don't think it's not a huge deal, but worth noting.
>> >
>> > On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
>> >>
>> >> Hi all,
>> >>
>> >> Thanks for detailed response. I thought over the described expressions/
>> >> transforms patches and here are my thoughts about the best way to
>> >> implement simplified lookups.
>> >>
>> >> Firstly, I want to describe which properties of the new syntax seem to 
>> be
>> >> important:
>> >>
>> >> 1. Using Python operators to do basic lookups as it's a natural way in
>> >> Python
>> >> for that.
>> >>
>> >> 2. Syntax should be minimalistic for basic lookups, the use of that
>> >> approach
>> >> will be more noticeable on multiple filter conditions. In other words,
>> >> next
>> >> syntax is better:
>> >>
>> >> >>> GameSession.objects.filter(Q.user.profile.last_login.date() ==
>> >> >>> datetime.now().date)
>> >>
>> >> than this one
>> >>
>> >> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() ==
>> >> >>> datetime.now().date)
>> >>
>> >> as it requires additional calls, which makes expressions less readable.
>> >>
>> >> 3. I definitely like the idea of having explicit classes for lookups 
>> and
>> >> transforms and think it's worth to bundle dotted query syntax with the
>> >> patch.
>> >> Explicit classes will separate functionality and simplify functions
>> >> signature
>> >> checks.
>> >>
>> >> I suggest a mixed approach, with next properties.
>> >>
>> >> 1. We will have a separate class to define query paths (let's call it 
>> P,
>> >> we
>> >> can still use F as "field", but having F as multipurpose class may 
>> confuse
>> >> users, as well as implementation may become more complicated). And it 
>> will
>> >> be
>> >> the only purpose of the class. Below I'll reference it as "P" no 
>> matter we
>> >> call
>> >> it in future.
>> >>
>> >> 2. Any transforms and lookups will take query string or P class, as 
>> well
>> >> as
>> >> existing methods "select_related", "prefetch_related" and "order_by". 
>> The
>> >> simplest implementation will be overriding __str__ method of the path
>> >> class
>> >> to generate related strings.
>> >>
>> >> >>> path = P.user.last_login_date
>> >> >>> GameSession.objects.all().order_by(path)[:10]
>> >>
>> >> >>> print(path)
>> >> user__last_login_date
>> >>
>> >> 3. Implement transforms and lookups as classes or functions (not bound 
>> to
>> >> P class):
>> >>
>> >> >>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote
>> >> >>> d'Ivoire")
>> >>
>> >> It will simplify cases with parametrized transforms (ex. mentioned
>> >> collate('fi')).
>> >> Also eliminate fields collision with util functions like "date", which 
>> may
>> >> be a
>> >> so-called field.
>> >>
>> >> 4. Below is a table describing accepted passed and returned parameters:
>> >>
>> >> 
>> +---+---+--+
>> >> |  Class/Function   |Allowed Param Types| Comparison Operators 
>> |
>> >> 
>> +---+-

request for API review of streaming responses additions

[Tim Graham]

I'd like to ask for a high-level API review of some proposed streaming API
additions (I have already given the patch a couple of detailed reviews, but 
other eyes would be welcome on the details as well).

Summary:

* django.views.generic.base.StreamingTemplateView to stream a template
  rather than render it.

* A Template.stream() method, a django.template.loader.stream() function,
  and django.shortcuts.stream_to_response() and
  django.shortcuts.stream() shortcuts.

* django.template.response.StreamingTemplateResponse and
  django.template.response.SimpleStreamingTemplateResponse classes to
  handle streaming of templates.

Pull request:
https://github.com/django/django/pull/4783

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/772cae79-1941-4a6a-94a8-b82d5e767aa1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Shai Berger]

On Tuesday 18 August 2015 14:29:15 Marc Tamlyn wrote:
> I don't know about schedule, but caniuse reports IE8 browser usage at 1.5%,
> more than IE9 or IE10.
> 
> There's an argument we shouldn't be "enabling" people still using XP who
> are stuck on IE8, and this is a decreasing problem, but I don't think we
> can tie ourselves to Microsoft's support dates.
> 

Sure we can, in the same sense that we "tie ourselves" to the support dates of 
PostgreSQL, MySQL and Oracle.

1.9 is the release following an LTS -- the perfect time for changes such as 
JQuery 2 and dropping support for old browsers. If developers need to support 
the legacy IE8, they can use Django 1.8.

The suggestion to add a notice for IE8 users seems reasonable to me, but I 
don't think we should hold back progress just to keep the admin usable on it.

Shai.

Re: Pre-DEP: community support of unmaintained versions of Django

[Christian Hammond]

Hi Carl,

I know it's been a while since we discussed this, but today's security 
release is the first one that's really affecting our product and we've 
finally got things in shape to be able to start distributing unofficial 
Django security releases (we've also just been swamped since our discussion 
earlier this year).

I wanted to dig into the versioning scheme just a bit. We tried going with 
local version identifiers, but it turns out these are fairly useless. When 
specifying a dependency with a local version identifier, your only option 
is direct equality (==1.6.11+extended.1). You can't use any form of range 
(>=1.6.11+extended.4), as these get interpreted as >=1.6.11. This is the 
case with both easy_install and pip, and is documented in the PEP.

That means consumers of the builds either need to specify an explicit 
version (preventing other packages or administrators from choosing a higher 
version when a new build is released), or need to depend on the official 
1.6.11 and rely on administrators to keep up-to-date with the latest 
releases and manually install them.

Not to mention that this all falls apart if using setuptools < 8, which 
doesn't support these identifiers.

Given that, what would your feelings be on allowing for 1.6.11.x releases? 
This way we wouldn't take up any possible future versioning slots (unlikely 
as they may be), while being compatible with all versions of setuptools, 
and compatible with specifying version ranges. This would still appear 
solely on our own downloads page and announcements, with an appropriate 
note on them being unofficial builds.

Also as a status update, we've started a fork and applied for the 
pre-notification list. I've backported all current security fixes to a 
branch, ensured the test suite passes with flying colors, and have added a 
README detailing everything you've requested. This is all up at 
https://github.com/beanbaginc/django. Let me know if there's anything you'd 
like changed.

Thanks,

Christian


On Friday, March 27, 2015 at 9:25:20 AM UTC-7, Carl Meyer wrote:
>
> Hi John and Christian, 
>
> On 03/27/2015 09:46 AM, John Paulett wrote: 
> > James, thanks for putting this together. 
> > 
> > Christian, I am in a similar position, supporting 2.6 for the next 6-12 
> > months.  I had planned to keep a personal fork of Django 1.6, 
> > backporting security patches as needed, but I would be happy to 
> > contribute to a common effort in this regard. 
> > 
> > As mentioned by others, keeping the effort unofficial may be ideal.  A 
> > planed end-of-life of this secondary support may also be helpful to 
> > still convince people to migrate forward. 
> > 
> > For a personal fork this wasn't going to be needed, but I wonder how 
> > package distribution should occur. I doubt that publishing unofficial 
> > distributable under Django's PyPI project is advisable. 
>
> I agree. 
>
> I'll outline my idea of how this could work; consider it an alternative 
> proposal (or proposed revision of) James' DEP. (I don't think a DEP is 
> needed for this, but if other core team members feel that it is, I am 
> willing to work this up into DEP format). 
>
> - The community support work happens in a third-party GitHub fork. If 
> you and Christian want to work together on it for 1.6, one of you can 
> create a repo and grant the other commit access. (This is of course 
> something that you have every right to do regardless of what the core 
> team thinks of it.) 
>
> - One of you applies for security pre-notifications (under the 
> "distributor of Django" category -- essentially you are applying to be 
> equivalent to e.g. a Debian or Fedora packager of Django, who 
> could/might provide the same kind of extended support you are planning 
> to.) 
>
> - I think from the core team's perspective, the ideal situation would be 
> that these releases not be on PyPI at all, but that your users would 
> download them directly from the "releases" section of your github repo, 
> or perhaps pip-install them from a PyPI-compatible index that you 
> publish somewhere on static file hosting. If this is acceptable, it 
> would allow you to use PEP 440 "local version identifiers" [1] in your 
> versions, which I think is the most semantically correct for this 
> situation. So your versions would look something like 
> "1.6.11+extended-1" (choice of actual local-version label up to you). 
> If not-on-PyPI is a total dealbreaker for your users, it might be an 
> option to release under a different PyPI project name, such as 
> "Django-16-Community-Support" or similar, but this is less than ideal. 
> For one, it would require the actual package to have a name other than 
> "Django", and it would require the use of something like "1.6.11.post1" 
> instead of the local version identifier, since PyPI does not accept 
> local version identifiers. 
>
> - A preamble should be added to the README of the project on GitHub to 
> indicate that this is unofficial community-based e

Re: draft blog post for Oracle help

[Jani Tiainen]

Hi all,

I'm volunteering myself to maintain both Oracle and Oracle GIS backends.

I've been developing applications based on Oracle for almost 20 years now and 
I've been maintaining Oracle installations and databases.

I've been developing with Django and it's GIS parts with almost 10 years now. 
I've previously contributed few very trivial patches and I've regulary keep 
answering questions on #django and hanging around in #django-dev with nick 
"jtiai".


On Thu, 13 Aug 2015 09:12:17 -0700 (PDT)
Tim Graham  wrote:

> I've drafted a blog post to advertise our need for Oracle expertise. Please 
> take a look and give feedback before it's published. Thanks!
> 
> Django team seeks help maintaining Oracle and Oracle GIS backends
> ---
> 
> Several members of the Django team that have previously provided Oracle
> expertise no longer work with Oracle in their day jobs, and therefore, the 
> team
> is seeking new contributors who have an ongoing interest in the backend.
> 
> Ideally, the team seeks to move the Oracle backend from "built-in" status, 
> to a pip
> installable backend that would be maintained under the "django" GitHub 
> account.
> Your duties would include monitoring a build that runs with Django master 
> and the
> latest version of the Oracle backend and fixing any issues that arise. To 
> help with
> the continuous integration infrastructure, knowledge of maintaining Oracle 
> servers
> would also be a plus, but these duties could be split among several people. 
> Please
> introduce yourself on the `django-developers mailing list`_ if this is 
> something you
> are interested in.
> 
> Also, the Oracle GIS backend has been broken for several months and
> no one has answered `requests for help`_ on the django-developers and
> geodjango mailing lists. If no one helps out, this backend will be dropped 
> in
> Django 1.9. This is the least used backend according to the `Django 
> Developers
> Community Survey`_, receiving 5 votes out of more than 3,000 responses.
> 
> .. _django-developers mailing list: 
> https://groups.google.com/forum/#!forum/django-developers
> .. _requests for help: 
> https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion
> .. _Django Developers Community Survey: 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics#start=publishanalytics
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/68c78921-001d-4171-bdd7-541f048734bc%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
Jani Tiainen

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

Re: draft blog post for Oracle help

[Josh Smeaton]

I'll also stick my hand up to be involved with the Oracle backend, but not 
the Oracle GIS backend. I don't have a lot of time available at the moment, 
but I'll be able to support Jani and anyone else that's interested in 
maintaining the backend.

Cheers

On Wednesday, 19 August 2015 16:36:23 UTC+10, Jani Tiainen wrote:
>
> Hi all, 
>
> I'm volunteering myself to maintain both Oracle and Oracle GIS backends. 
>
> I've been developing applications based on Oracle for almost 20 years now 
> and I've been maintaining Oracle installations and databases. 
>
> I've been developing with Django and it's GIS parts with almost 10 years 
> now. I've previously contributed few very trivial patches and I've regulary 
> keep answering questions on #django and hanging around in #django-dev with 
> nick "jtiai". 
>
>
> On Thu, 13 Aug 2015 09:12:17 -0700 (PDT) 
> Tim Graham > wrote: 
>
> > I've drafted a blog post to advertise our need for Oracle expertise. 
> Please 
> > take a look and give feedback before it's published. Thanks! 
> > 
> > Django team seeks help maintaining Oracle and Oracle GIS backends 
> > 
> ---
>  
>
> > 
> > Several members of the Django team that have previously provided Oracle 
> > expertise no longer work with Oracle in their day jobs, and therefore, 
> the 
> > team 
> > is seeking new contributors who have an ongoing interest in the backend. 
> > 
> > Ideally, the team seeks to move the Oracle backend from "built-in" 
> status, 
> > to a pip 
> > installable backend that would be maintained under the "django" GitHub 
> > account. 
> > Your duties would include monitoring a build that runs with Django 
> master 
> > and the 
> > latest version of the Oracle backend and fixing any issues that arise. 
> To 
> > help with 
> > the continuous integration infrastructure, knowledge of maintaining 
> Oracle 
> > servers 
> > would also be a plus, but these duties could be split among several 
> people. 
> > Please 
> > introduce yourself on the `django-developers mailing list`_ if this is 
> > something you 
> > are interested in. 
> > 
> > Also, the Oracle GIS backend has been broken for several months and 
> > no one has answered `requests for help`_ on the django-developers and 
> > geodjango mailing lists. If no one helps out, this backend will be 
> dropped 
> > in 
> > Django 1.9. This is the least used backend according to the `Django 
> > Developers 
> > Community Survey`_, receiving 5 votes out of more than 3,000 responses. 
> > 
> > .. _django-developers mailing list: 
> > https://groups.google.com/forum/#!forum/django-developers 
> > .. _requests for help: 
> > 
> https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion 
> > .. _Django Developers Community Survey: 
> > 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics#start=publishanalytics
>  
> > 
> > -- 
> > 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 post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/68c78921-001d-4171-bdd7-541f048734bc%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> Jani Tiainen 
>

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