cx_Oracle 5.2.1 released

[Shai Berger]

Hi all,

A new version of the Oracle driver library was released. Highlights, as far as 
we're concerned, are support for Python 3.5 and for binding Booleans with 
Oracle 12.

http://cx-oracle.readthedocs.org/en/latest/releasenotes.html

Have fun,
Shai.

Re: re-thinking middleware

[Carl Meyer]

I've updated DEP 5 with a new round of clarifications and tweaks based on 
the most recent feedback: 
https://github.com/django/deps/compare/62b0...master

Carl 

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

Re: re-thinking middleware

[Carl Meyer]

On 01/10/2016 04:54 PM, Raphaël Barrois wrote:
> I've got only one minor suggestion to the "backwards compatibility"
> section of the DEP.
> 
>> It currently states that "If the ``MIDDLEWARE`` setting is provided
>> [...], the old ``MIDDLEWARE_CLASSES`` setting will be ignored.
> 
> I suggest that, instead, this fails loudly if both ``MIDDLEWARE`` and
> ``MIDDLEWARE_CLASSES`` are set.
> This would prevent projects from keeping the two versions around and
> having to remember which one is currently in use.

Great suggestion, thanks. I've added it to the todo checklist on the PR:
https://github.com/django/django/pull/5949

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: re-thinking middleware

[Carl Meyer]

On 01/11/2016 04:52 PM, Shai Berger wrote:
> On Monday 11 January 2016 01:54:58 Raphaël Barrois wrote:
>> I've got only one minor suggestion to the "backwards compatibility"
>> section of the DEP.
>>
>>> It currently states that "If the ``MIDDLEWARE`` setting is provided
>>> [...], the old ``MIDDLEWARE_CLASSES`` setting will be ignored.
>>
>> I suggest that, instead, this fails loudly if both ``MIDDLEWARE`` and
>> ``MIDDLEWARE_CLASSES`` are set.
>> This would prevent projects from keeping the two versions around and
>> having to remember which one is currently in use.
>>
> 
> If the failure is too loud, it makes it hard to use the same settings file 
> for 
> testing with multiple versions of Django -- a practice used by Django itself, 
> and I think also by some reusable apps. We've run into this issue with the 
> change of the database test settings.

Yes; I think a checks-framework warning (like what we do for
`TEMPLATE_*` vs `TEMPLATES`) is the appropriate level; likely to catch
an unintentional usage, but silence-able if the duplication is intentional.

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: re-thinking middleware

[Carl Meyer]

Hi Mat,

On 01/12/2016 04:23 PM, Mat Clayton wrote:
> +1 as well, this is really great work, on both patches!
> 
> Modifying the middleware stack mid request would be very useful for us.
> 
> We currently run 3 copies of the same code, with essentially different
> urls.py and middlewares loaded, each one is used to run a variation of
> the site, for example www/mobile web and api, and have slightly
> different requirements, which are handled in middlewares, for example
> api calls are authenticated by access tokens and www/mobile use cookies.
> 
> Ideally we'd love to consolidate our deployment into a single set of
> python web workers, but to date its been a little too complex to be
> worth it. We could however use the url dispatching patch and PR1 to
> write a middleware which could load in the necessary middleware stack
> based on the requirements of each request.
> 
> So my preference therefore would be for PR1 as I can see a few edge
> cases it would enable solutions for.

I don't think it's worth penalizing the performance of the common case
in order to enable these edge cases. I think it should be possible to
add a "per-request middleware" feature atop PR #2 in a fully
backwards-compatible way without compromising performance in the common
case (essentially by compiling multiple alternative request-paths in the
handler instead of just one), but this should be handled as a separate
feature, built in a separate pull request; it's out of scope for DEP 5.
It solves a completely different problem from the one DEP 5 is aiming to
solve.

I also think there are fairly easy ways to solve your problem in the
meantime without the per-request middleware feature, for instance with
hybrid middleware that conditionally does something-vs-nothing (or
one-thing-vs-another) depending on some attribute attached to the request.

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: db.models.options help with a piece of code analysis.

[Elton Pereira de Lima]

Really, it's true!

Thanks for help!

-- 
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/bc30deff-2f95-4769-9195-ab74ab03b1c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: db.models.options help with a piece of code analysis.

[charettes]

FWIW, as Marteen pointed out, the `Meta` attribute is only available on
abstract classes because of these lines 

.

Simon

Le lundi 18 janvier 2016 13:09:16 UTC-5, charettes a écrit :
>
> Hi Elton,
>
> From what I understand the line you pointed at doesn't delete the model 
> `Meta`
> attribute but the `_meta.meta` attribute which makes it possible for 
> `Bar.Meta`
> to subclass `Foo.Meta` even if `Foo.Meta.abstract is not True`.
>
> Simon
>
> Le lundi 18 janvier 2016 12:34:29 UTC-5, Elton Pereira de Lima a écrit :
>>
>> Hello charettes!
>>
>> Analyzing the code further, I saw that it was impossible for the Bar Meta 
>> class inherits from Foo.Meta because when this code 
>>  
>> is executed, the Meta class ceases to exist because of this line 
>> 
>> .
>>
>

-- 
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/0cdc4202-c2f1-43f5-9efe-5d765843c65b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: db.models.options help with a piece of code analysis.

[charettes]

Hi Elton,

>From what I understand the line you pointed at doesn't delete the model 
`Meta`
attribute but the `_meta.meta` attribute which makes it possible for 
`Bar.Meta`
to subclass `Foo.Meta` even if `Foo.Meta.abstract is not True`.

Simon

Le lundi 18 janvier 2016 12:34:29 UTC-5, Elton Pereira de Lima a écrit :
>
> Hello charettes!
>
> Analyzing the code further, I saw that it was impossible for the Bar Meta 
> class inherits from Foo.Meta because when this code 
>  
> is executed, the Meta class ceases to exist because of this line 
> 
> .
>

-- 
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/ecab49d8-7b78-45ed-b5eb-fc378792058b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: db.models.options help with a piece of code analysis.

[Marten Kenbeek]

Hi Elton,

Django makes the Meta class of abstract models available as Foo.Meta. This 
allows you to define common Meta options on the abstract base class, and 
inherit the base Meta in your concrete child models. So the above example 
won't work as you noted, but this will:

class Foo(models.Model):
class Meta:
app_label = 'app'
abstract = True

class Bar(models.Model):
class Meta(Foo.Meta):
pass

assert 'app_label' not in Bar.Meta.__dict__
assert Bar.Meta.app_label == 'app'


On Monday, January 18, 2016 at 6:34:29 PM UTC+1, Elton Pereira de Lima 
wrote:
>
> Hello charettes!
>
> Analyzing the code further, I saw that it was impossible for the Bar Meta 
> class inherits from Foo.Meta because when this code 
>  
> is executed, the Meta class ceases to exist because of this line 
> 
> .
>

-- 
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/411c9ca0-f718-4ae5-835c-fcaa6edd4cf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: db.models.options help with a piece of code analysis.

[Elton Pereira de Lima]

Hello charettes!

Analyzing the code further, I saw that it was impossible for the Bar Meta 
class inherits from Foo.Meta because when this code 
 
is executed, the Meta class ceases to exist because of this line 

.

-- 
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/8254ecd9-0182-450c-a6f0-074ad5bd49da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: db.models.options help with a piece of code analysis.

[Elton Pereira de Lima]

Thanks for help!

-- 
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/2f95e42a-b869-4abf-88cd-6675f8db0d1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.