Re: #28560 - distinct() on ordered queryset with restricted list of columns returns incorrect result

[Michael Manfre]

Having run in to this issue in the past, automatically changing the meaning 
and/or breaking the query can turn in to a debug time sink. Option 3 could 
save people a bit of time.

Cheers,
Michael Manfre

On Wednesday, October 28, 2020 at 8:46:46 PM UTC-4 charettes wrote:

> I'm also a fan of option 3. to require an explicit opt-in or raise an 
> error.
>
> Not a lot of folks are familiar with this requirement imposed by the usage 
> of DISTINCT and even if Model.Meta.ordering is the most common reason but 
> unexpected ordering it can also be caused by the dynamic creation of a 
> queryset through multiple abstractions (e.g. A DRF API filter backend that 
> applies ordering).
>
> I think this is a similar problem to 
> https://code.djangoproject.com/ticket/14357#comment:11
>
> Cheers,
> Simon
>
> Le mercredi 28 octobre 2020 à 18:09:10 UTC-4, Tobias McNulty a écrit :
>
>> I tend to agree, though I'll note that was also a bug at one point: 
>> https://code.djangoproject.com/ticket/5321
>>
>> On Wed, Oct 28, 2020 at 5:38 PM Fran Hrženjak  
>> wrote:
>>
>>> Personally I would prefer to get a ProgrammingError, so option 3. 
>>>
>>> Explicit is better then implicit  
>>>
>>> Here is a great explanation of this exact issue, cleared it up for me:
>>>
>>> https://blog.jooq.org/2018/07/13/how-sql-distinct-and-order-by-are-related/
>>>
>>>
>>>
>>> On 28.10.2020., at 20:04, Tobias McNulty  wrote:
>>>
>>> 
>>> Hi all,
>>>
>>> Starting a thread on ticket #28560 
>>> <https://code.djangoproject.com/ticket/28560>, "distinct() on ordered 
>>> queryset with restricted list of columns returns incorrect result." In a 
>>> nutshell:
>>>
>>> $ cat testapp/models.py 
>>>
>>> from django.db import models
>>>
>>>
>>>
>>> class School(models.Model):
>>>
>>> name = models.CharField(max_length=255)
>>>
>>> county = models.CharField(max_length=255)
>>>
>>>
>>> class Meta:
>>>
>>> ordering = ("name",)
>>>
>>> $ python manage.py shell
>>>
>>> ...
>>>
>>> >>> from testapp.models import School
>>>
>>> >>> str(School.objects.values("county").distinct().query)
>>>
>>> 'SELECT DISTINCT "testapp_school"."county", *"testapp_school"."name"* 
>>> FROM "testapp_school" ORDER BY "testapp_school"."name" ASC'
>>>
>>> Note the "name" column is added implicitly to the SELECT clause due to 
>>> the default ordering on the model (I believe with good reason, since 
>>> #7070 <https://code.djangoproject.com/ticket/7070>). This is not 
>>> specific to a default ordering; it's also possible to generate 
>>> unintended results with a mismatching list of columns between an explicit 
>>> order_by() and values().
>>>
>>> It's possible to fix with an empty order_by():
>>>
>>> >>> str(School.objects.values("county").order_by().distinct().query)
>>>
>>> 'SELECT DISTINCT "testapp_school"."county" FROM "testapp_school"'
>>>
>>>
>>> But, this still feels like a case where we could do better. Some 
>>> potential options:
>>>
>>>1. It looks like there was an initial attempt to fix the issue with 
>>>a subquery, but from what I can tell it was not possible to preserve 
>>>ordering 
>>><https://github.com/django/django/pull/9055#issuecomment-338276279> 
>>>in the outer query.
>>>2. My colleague Dmitriy pointed out that there may be a precedent 
>>>for excluding the default ordering 
>>><https://github.com/django/django/pull/10005> for queries like this.
>>>3. An option I suggested on the ticket 
>>><https://code.djangoproject.com/ticket/28560#comment:13> is to raise 
>>>an error if the list of columns in values() is insufficient to run the 
>>>requested query (i.e., never add a column implicitly if the user 
>>> specified 
>>>a list of columns via values() or values_list()).
>>>
>>> What do others think? What are other potential fixes I'm not thinking of?
>>>
>>> Cheers,
>>>
>>>
>>> *Tobias McNulty*Chief Executive Officer
>>>
>>&g

Re: Moving database backends out of the core

[Michael Manfre]

On Mon, Nov 26, 2018 at 10:49 AM Tom Forbes  wrote:

> On your point about non-standard backends, maybe we should focus on making
> it easier to add third party backends and standardize some of the
> internals? We could treat the backend as external (i.e no special hacks for
> them) but keep them in the Django package. If we make the interfaces a bit
> more abstract it would be a lot easier for these backends to exist without
> hacks perhaps.
>

Over the past several years when I first started this thread, the API has
improved and these types of improvements reduced the need to monkey patch
or completely rewrite bits of the ORM in django-mssql. Continuing to
move/keep any DB specific hacks out of the ORM and in to their respective
backend makes Django friendlier for 3rd party database backends. The API is
still deemed internal and if you push for a more official database backend
API, I suggest clearly stating that it will still be exempt from the
standard deprecation policy. There was a lot of strong opposition to
changing that policy in the past.

Regards,
Michael Manfre
-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Updating date field using signals

[Michael Manfre]

This mailing list is for the development of the Django Framework. Questions
related to its usage should be posted to the django-users mailing list.

Regards,
Michael Manfre

On Fri, Nov 9, 2018 at 6:51 AM  wrote:

> Hi all,
>
> I have a very simple Profile class:
>
> class Profile(models.Model):
>   user = models.OneToOneField(User, on_delete=models.CASCADE)
>   location = models.CharField(max_length=30, blank=True)
>   birth_date = models.DateTimeField(null=True, blank=True)
>   date_activation = models.DateTimeField(null=True, blank=True)
>
>
> I want to set date_activation = datetime.now the first time the user login.
> I tried using "user_logged_id" signal, without success:
>
> @receiver(user_logged_in, sender=User)
>   def user_logged_in_callback(sender, user, request, **kwargs):
>
> Profile.objects.filter(get_user(request)).update(date_activation=datetime.now)
>
>
>
> Testing it I get this errore message below.
> Any help or suggestions would be greatly appreciated!
>
>
> TypeError at /admin/login/
>
> int() argument must be a string, a bytes-like object or a number, not 
> 'ModelBase'
>
> Request Method: POST
> Request URL: http://localhost:4000/admin/login/?next=/admin/
> Django Version: 1.11.16
> Exception Type: TypeError
> Exception Value:
>
> int() argument must be a string, a bytes-like object or a number, not 
> 'ModelBase'
>
> Exception Location: 
> /usr/local/lib/python3.6/site-packages/django/db/models/fields/__init__.py
> in get_prep_value, line 966
> Python Executable: /usr/sbin/uwsgi
> Python Version: 3.6.5
> Python Path:
>
> ['.',
>  '',
>  '/code',
>  '/usr/local/lib/python3.6/site-packages',
>  '/usr/lib/python3.6/site-packages',
>  '/usr/lib/python36.zip',
>  '/usr/lib/python3.6',
>  '/usr/lib/python3.6/lib-dynload']
>
>
>
>
>
> --
> 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/fd7793b7-305a-4916-bae8-e8de687be346%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/fd7793b7-305a-4916-bae8-e8de687be346%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: seat selecting page .

[Michael Manfre]

This mailing list is for the development of Django itself, not how to use
Django. The mailing list django-users is where you can ask this type of
question, but you will need to make your question a bit more detailed, if
you'd like to get a helpful response.

Regards,
Michael Manfre

On Wed, Oct 31, 2018 at 7:46 AM mainga miyanda 
wrote:

> i'm creating a online movie booking website, and i want to add a seat
> selection site before it records the seats chosen and the bill is
> calculated.
>
> --
> 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/CAPbPLkQVAwe%2BdJ-90VnnnshGHGA8K1VgsRkUpa0f1CDQ-PO%2Bfg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAPbPLkQVAwe%2BdJ-90VnnnshGHGA8K1VgsRkUpa0f1CDQ-PO%2Bfg%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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/CAGdCwBsr_%3DWfrcupXTEv-9DVE8v8Ji13A-RP-BWivTCgUR5O6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GDPR and parent domain cookies

[Michael Manfre]

It's possible to entirely control the emails that are sent out by defining
your own AdminEmailHandler and overriding the LOGGING configuration to use
it. I described how on the ticket. The process is a bit cumbersome if all
you want to do is replace the usage of ExceptionReporter and I think we
should improve that. I'm +1 on reopening the ticket to make it easier to
swap in a custom ExceptionReporter for AdminEmailHandler.

Regards,
Michael Manfre

On Mon, Aug 27, 2018 at 9:41 AM  wrote:

> Email error reports sent from Django (when DEBUG=False) include
> information about parent domain cookies, which may contain personal data.
> This may create issues related to the GDPR (the European General Data
> Protection Regulation), as one can't control the cookies from services
> hosted on parent domain(s), while it is necessary to provide full
> information about personal data handling to the user with the possibility
> to delete the data on request.
>
> In short words, to be GDPR-compliant, we should be able to exclude
> potentially risky data from the error reports.
>
> I created a ticket <https://code.djangoproject.com/ticket/29714> in the
> Django bugtracker about introducing an option to hide cookies in error
> reports. It was pointed out to me, that it's possible to implement a custom
> "SafeExceptionReporterFilter", but i still think that the situation with
> the cookies should be clarified somehow explicitly in the "HowTo" section
> dedicated to error reporting.
>
> There is already a topic related to GDPR:
> https://groups.google.com/forum/#!topic/django-developers/Xhg-0JeDN50/discussion,
> but so far there hasn't been any discussion going on there.
>
> --
> 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/ef2ed833-2512-4105-9de4-77d33bc6c823%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ef2ed833-2512-4105-9de4-77d33bc6c823%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Deprecate PickleSerializer for session serialization?

[Michael Manfre]

I have no strong opinion about keeping it verse moving it. The docs already
provide a sufficient warning about the risks of using it. Anyone who uses
it after reading the warning would likely still use it if it were in
another package. A separate package is another "Are you sure?" step that
they would likely ignore.

Regards,
Michael Manfre

On Sat, Aug 25, 2018 at 9:12 AM Tim Graham  wrote:

> Alex proposed:
>
> ---
>
> Pickle serializer has long been known to be dangerous. This is mitigated
> by requiring MAC on pickle in cookies, but nevertheless, RCEs continue to
> happen: ​
> https://blog.scrt.ch/2018/08/24/remote-code-execution-on-a-facebook-server/
>
>
> To further discourage it's use, we should consider deprecating
> PickleSerializer and moving it into a third party package.
>
> https://code.djangoproject.com/ticket/29708
> ---
>
> I don't see much advantage to a separate package for 10 lines of code:
>
> import pickle
>
> class PickleSerializer:
> """
> Simple wrapper around pickle to be used in signing.dumps and
> signing.loads.
> """
> protocol = pickle.HIGHEST_PROTOCOL
>
> def dumps(self, obj):
> return pickle.dumps(obj, self.protocol)
>
> def loads(self, data):
> return pickle.loads(data)
>
> I'm not sure that removing it from Django would improve security (since
> Django 1.6, JSONSerializer is the default session serializer). Thoughts?
>
> --
> 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/37fe5ab5-6d30-45bd-8bdd-a11f0170209c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/37fe5ab5-6d30-45bd-8bdd-a11f0170209c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: App static files (#29586)

[Michael Manfre]

On Mon, Jul 23, 2018 at 12:12 PM Florian Apolloner 
wrote:

>  * Any thoughts on asset pipelines?
>

This seems like it would be critical functionality. It might also help
users to avoid potential asset ordering issues without needing to create
more apps to resolve conflicts.

Regards,
Michael Manfre

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

Re: Adding a tutorial for Channels

[Michael Manfre]

Any improvements to documentation are greatly appreciated. Thank you for
taking the initiative.

Regards,
Michael Manfre

On Mon, Feb 5, 2018, 7:05 AM David Foster <davidf...@gmail.com> wrote:

> This weekend I spent several hours getting Channels configured to run a
> simple chat server <https://github.com/davidfstr/channels-chat-example>.
> This was an experiment I wanted to do before trying to integrate Channels
> into a much larger project.
>
> It would have taken me a lot less time if there had been a tutorial in the 
> official
> Channels docs <https://channels.readthedocs.io/en/latest/index.html> similar
> in style to the Django tutorial
> <https://docs.djangoproject.com/en/2.0/intro/tutorial01/> that showed how
> to configure Channels and use it to work with WebSockets while also
> touching on the important Channels concepts and linking to reference
> documentation where appropriate. So I'd like to offer to write such a
> tutorial.
>
> Would this be a welcome contribution?
>
> - David
>
> --
> 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/9b68e3cf-76de-4506-9733-00b2d640b1e2%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/9b68e3cf-76de-4506-9733-00b2d640b1e2%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Integrate dj-database-url into Django

[Michael Manfre]

On Sun, Feb 4, 2018 at 12:59 PM Tom Forbes <t...@tomforb.es> wrote:

> I had one question that I’m not sure the answer to: for databases I added
> the config_from_url to the .base.DatabaseWrapper class inside each built
> in adapter. I’ve kind of assumed each third party database would have the
> same structure, how much of a safe assumption is this?
>
Every 3rd party database backend adheres to the internal API and must
provide its own or an inherited DatabaseWrapper. Adding config_from_url
seems like the best place to me.

Regards,
Michael Manfre

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

Re: Having a MongoDB connector for Django

[Michael Manfre]

Another voice piling on to the "this is not a good idea" train. I inherited
a Mongo backed project at my day job that is filled with data that should
have been put in a relational database. Mongo is the wrong tool for the job
(and we're migrating off it). I tried putting an ORM in front of it to make
things a bit easier, but I gave up.  My many years of supporting a 3rd
party database backend for Django gave me the insight to realize that it
would take a lot of effort and ultimately would probably never work as well
as migrating the data to a more appropriate database. It was definitely a
lot of fun to tinker on it, but not something I'd ever want to support in
production.

Regards,
Michael Manfre

On Fri, Sep 8, 2017 at 12:57 PM Adam Johnson <m...@adamj.eu> wrote:

> I agree, I think forcing Django's ORM to work on MongoDB is not a great
> idea. Django relies heavily on transactions and other relational goodness.
>
> Have you tried storing JSON in your Postgres/MySQL database? Django can
> work with that with contrib.postgres/django-mysql 
>
> On 8 September 2017 at 16:51, 'Tom Evans' via Django developers
> (Contributions to Django itself) <django-developers@googlegroups.com>
> wrote:
>
>> Short answer: always use the appropriate tool
>>
>> Relational databases and document stores have different uses and
>> purposes. Using a document store like a relational database (eg, with
>> an ORM (emphasis on the R)) is a bad idea, and using a relational
>> database as a document store is similarly foolish.
>>
>> Work out what questions you want to ask of your data, then structure
>> the data in a way that allows you to query it efficiently.
>>
>> If the format desired is a document store, I wouldn't attempt to
>> shoehorn that in to an ORM wrapper, I'd use something like mongothon.
>>
>> Cheers
>>
>> Tom
>>
>> On Fri, Sep 8, 2017 at 8:50 AM, Nes Dis <nes...@gmail.com> wrote:
>> > Hello
>> >
>> > I am wondering what is the state of the art on Django having a backend
>> > connector for MongoDB database backend. There are a few solutions out
>> there
>> > but they don't work as expected.
>> >
>> > A possible solution for this is to have a connector which translates SQL
>> > queries created in Django, into MongoDB queries.
>> >
>> > I would like to hear the expert opinion from the esteemed members of
>> this
>> > group on this concept.
>> >
>> > A working solution for this can be found here: djongo. (Django + Mongo =
>> > Djongo) The project is hosted on github.
>> >
>> > Regards
>> > Nes Dis
>> >
>> > --
>> > 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/b0ce04d1-62cb-4765-b850-06c4a5b0607f%40googlegroups.com
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAFHbX1%2BNpZuWrAgcMwkcJQ4Xg4TrM700JRsYV_AnW05_9L3joA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on th

Re: Custom Join Conditions

[Michael Manfre]

On Tue, Sep 5, 2017 at 5:10 AM Adam Johnson  wrote:

> from django.db.models import FilteredRelation is what I'd expect
>

This is what I'd expect too.


> On 5 September 2017 at 09:44, Nicolas Delaby  wrote:
>
>> It seems we have a consensus.
>> I'll be glad to push that change.
>>
>> I just have a question, from where do you want users importing the class
>> FilteredRelation ?
>> From its current location ?
>>
>>   from django.db.models.query import FilteredRelation
>>
>> or from its parent module ?
>>
>>   from django.db.models import FilteredRelation
>>
>> as it seems to be the django way.
>>
>> Best,
>> Nicolas
>>
>> On 04/09/2017 13:30, Adam Johnson wrote:
>> > The annotate(foo=FilteredRelation(...)) API LGTM too, and yes I agree
>> on the rationale on alias over to_attr.
>> >
>> > On 4 September 2017 at 10:25, Anssi Kääriäinen > > wrote:
>> >
>> > I really like the .annotate() version. The way this feature works
>> with .annotate() is easy to understand if you understand how existing
>> > .annotate() functions work. But, if we go with this approach, it
>> might look a bit strange if we don't do an automatic select_related(). On
>> the
>> > other hand, there are cases where you definitely don't want to do a
>> select_related(), like if the relation annotation is only used in further
>> > aggregation. So, maybe there should be opt-out, or maybe we just
>> don't do any automatic select_related for this case.
>> >
>> > I do like the .annotate() version for other reasons, too. There are
>> variants of this feature which would work nicely with the annotate style,
>> that
>> > is either annotation querysets for objects that do *not* have a
>> relation to the original queryset, or annotation raw SQL directly.
>> >
>> >  - Anssi
>> > PS. It seems the Google Groups UI acts a bit strange for me today.
>> I hope this post does arrive to the group in a readable format...
>> >
>> > --
>> > 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 > django-developers@googlegroups.com>.
>> > Visit this group at
>> https://groups.google.com/group/django-developers <
>> https://groups.google.com/group/django-developers>.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/django-developers/4ceb0715-bd6b-4860-a6e6-77dc9ecabae6%40googlegroups.com
>> > <
>> https://groups.google.com/d/msgid/django-developers/4ceb0715-bd6b-4860-a6e6-77dc9ecabae6%40googlegroups.com
>> >.
>> > For more options, visit https://groups.google.com/d/optout <
>> https://groups.google.com/d/optout>.
>> >
>> >
>> >
>> >
>> > --
>> > Adam
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Django developers (Contributions to Django itself)" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-developers+unsubscr...@googlegroups.com
>> > .
>> > To post to this group, send email to django-developers@googlegroups.com
>> .
>> > Visit this group at https://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM0n5K9nLz1V1kWgEiHnRiOX4V6ai_TpFp0ahoXV5GDbVQ%40mail.gmail.com
>> > <
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM0n5K9nLz1V1kWgEiHnRiOX4V6ai_TpFp0ahoXV5GDbVQ%40mail.gmail.com?utm_medium=email_source=footer
>> >.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/a85c8823-4d17-97f6-5543-3a15f8147880%40free.fr
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: Are there use cases for storing null bytes in CharField/TextField?

[Michael Manfre]

I imagine we won't hear of a use case until after the change happens and
I'm some what strongly opposed to stripping potentially valid data from all
databases because of a limitation of one. I'd be in favor of loaddata
checking for null bytes and complaining when the backend doesn't support
that feature.

Regards,
Michael Manfre

On Mon, May 15, 2017 at 11:54 AM Tim Graham <timogra...@gmail.com> wrote:

> Does anyone know of a use case for using null bytes in CharField/TextField?
>
> psycopg2 2.7+ raises ValueError("A string literal cannot contain NUL
> (0x00) characters.") when trying to save null bytes [0] and this
> exception is unhandled in Django which allow malicious form submissions to
> crash [1]. With psycopg2 < 2.7, there is no exception and null bytes are
> silently truncated by PostgreSQL. Other databases that I tested (SQLite,
> MySQL, Oracle) allow saving null bytes. This creates possible
> cross-database compatibility problems when moving data from those databases
> to PostgreSQL, e.g.[2].
>
> I propose to have CharField and TextField strip null bytes from the value
> either a) only on PostgreSQL or b) on all databases. Please indicate your
> preference or suggest another solution.
>
> [0] https://github.com/psycopg/psycopg2/issues/420
> [1] https://code.djangoproject.com/ticket/28201 - Saving a Char/TextField
> with psycopg2 2.7+ raises ValueError: A string literal cannot contain NUL
> (0x00) characters is unhandled
> [2] https://code.djangoproject.com/ticket/28117 - loaddata raises
> ValueError with psycopg2 backend when data contains null bytes
>
> --
> 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/9897126d-b6ef-48f1-9f19-96ed98ce10e5%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/9897126d-b6ef-48f1-9f19-96ed98ce10e5%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Improving MSSQL and Azure SQL support on Django

[Michael Manfre]

Quick update of the current status of things related to MSSQL. The most
actively maintained MSSQL backend that I'm aware of is django-pyodbc-azure
(also works with standalone SQL Server). Michiya has been doing an amazing
job supporting that backend. There has been no real movement toward there
being an officially supported MSSQL backend for Django. Microsoft has
continued to be involved with Django and myself related to making a better
MSSQL experience for us.

Regards,
Michael Manfre

On Fri, Apr 28, 2017 at 3:55 PM <uri...@gmail.com> wrote:

> I wonder if there have been any updates on MS support for a
> official/supported MS SQL Django driver? Did the offered engineering effort
> from MS ever come through? Given the availability of of MS SQL on Linux, as
> well as support for Django in Visual Studio, it would be great if this came
> to fruition.
> Explicit support for Django with IronPython would also be nice, if MS
> would really want to take their Django support to the next level...
>
>
> On Monday, March 7, 2016 at 5:37:06 PM UTC-5, Meet Bhagdev wrote:
>>
>> Hi all,
>>
>> On interacting with several Django developers and committers, one of the
>> questions often came up, can I use SQL Server on non Window OS's? I wanted
>> to share that today Microsoft announced SQL Server availibility on Linux -
>> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
>> .
>>
>> While there is still work needed to strengthen the MSSQL-Django story, we
>> hope this aids more Linux developers to give SQL Server a shot. Let me know
>> of your thoughts and questions :)
>>
>> Cheers,
>> Meet
>>
>> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>>>
>>> Hey Folks,
>>>
>>> My name is Vin and I work with Meet in the Microsoft SQL Server team.
>>> Just wanted to let you all know we are still looking into how we can better
>>> improve and support MSSQL for the Django framework. We’ll continue to sync
>>> with Michael and let you know of any updates soon.
>>>
>>> Christiano and Tim - thanks for sharing your interest and sharing how
>>> you are using Django with MSSQL. It's great to learn from your scenarios.
>>>
>>> If you have any concerns, questions or comments feel free to reach out
>>> to me at vinsonyu[at]microsoft.com
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8258f170-8f10-45fc-a1d3-9551efca6d1c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/8258f170-8f10-45fc-a1d3-9551efca6d1c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: About secure-auth

[Michael Manfre]

Hi,

This mailing list is for the discussion of developing Django itself.
Questions related to using Django are meant for the django-users mailing
list.

I'm not familiar enough with the MySQLdb python package, but if it supports
that as a connection option, you'd need to provide it under the DATABASES
"OPTIONS" dict in your settings. If it doesn't accept a connection param
that matches --skip-secure-auth, then you'll need to look in to something
to proxy the connection or perhaps extending the mysql database backend.

If you find yourself needing to work on a database backend, check out the
Custom Database Backends talk given at DUTH last year.

Regards,
Michael Manfre

On Sun, Feb 19, 2017 at 8:11 PM <aca...@adrianahoyos.com> wrote:

How do I tell django to use --skip-secure-auth when connecting to mysql?

049, "Connection using old (pre-4.1.1) authentication protocol refused
(client option 'secure_auth' enabled)")

-- 
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/9ae435f7-d934-47fb-9522-452ae135207e%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/9ae435f7-d934-47fb-9522-452ae135207e%40googlegroups.com?utm_medium=email_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

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

Re: Add custom autoreload file tracking options setting

[Michael Manfre]

On Thu, Jan 5, 2017 at 8:06 AM Florian Apolloner <f.apollo...@gmail.com>
wrote:

>
>
> On Thursday, January 5, 2017 at 1:38:44 PM UTC+1, Sam Willis wrote:
>
> Could one options be to replace the current devserver with the one from
> Werkzeug? It already uses watchdog (similar to watchman) for monitoring
> file system events and is well maintained. With Django now allowing
> dependancies, this seems like something that doesn't necessarily need to be
> developed internally.
>
>
> Watchdog seems to require a .c extension file on MacOSX at least, so as
> long as there are no wheels, that does not seem to be an option.
>
> The Werkzeug devserver also has some niceties like an interactive debugger
> and ssl hosting with an automatically issued self signed certificate. It
> could be implemented behind the current management command
>
>
> Self-Signed SSL sounds somewhat nice, I am -0 to -1 for the debugger --
> I've seen to many sites out there running with DEBUG=True, enabling RCE
> ootb seems to be pretty horrible.
>

I think anyone running devserver in prod deserves a breakpoint induced
outage.

Regards,
Michael Manfre

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

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Michael Manfre]

On Tue, Dec 27, 2016 at 3:52 PM Tim Graham <timogra...@gmail.com> wrote:

> Collin raised a fair point in #django-dev that Ubuntu 16.04 bundles Python
> 3.5. I guess 16.10 will include Python 3.6 -- that will be released before
> Django 2.0 in December 2017.
>
> Presumably any Python's we don't drop for 2.0 we will have to support
> until the next LTS (which means 2 more years where we can't use any Python
> 3.6+ features without extra work to support them on 3.4, 3.5), or else we
> risk stranding Django users on some Django version like 2.0 or 2.1 where
> they could have received security updates for longer if they stayed on on
> 1.11 LTS. I don't like that situation.
>
> How would you revise our Python support policy?
>

I don't think Django should support versions of Python longer than Python
is willing to support them. If this means dropping support for a version of
Python in a non-LTS, then we should do that. As long as it is sufficiently
documented, users will be able to make an informed decision about whether
to stay on the previous LTS for longer Python version support, or move on
to our non-LTS releases to reap the rewards of the newer Django version.
Regardless what they choose, when they end up on the next LTS, they would
have likely updated Django and Python independently along the way.


> In my mind, the purpose of LTS is for conservative organizations that
> don't want to use the latest Python, Django, etc. Are Red Hat users on
> Python 3.4 demanding the latest Django? Maybe if Django is more aggressive
> about dropping old Pythons, those users will demand newer Pythons.
>

At the organizations I've worked at, the purpose of LTS was to allow them
to defer migrating versions for a few years, and not to avoid using the
latest version now. They would jump on to an LTS release immediately if it
lined up with their planning.

If Red Hat users will be stuck on 3.4, then I feel the burden for
supporting it (backporting security fixes) should fall on Red Hat, not
Django. We should make it as easy as possible for them to do so (e.g.
pre-notification), but not by adding more support burden (conditional code,
build matricies, etc.) to Django or preventing us from using newer features
from Python.

Regards,
Michael Manfre

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

Re: Guidelines to name python modules of Django applications?

[Michael Manfre]

As some one who maintains django packages, I wouldn't use "django_" and
don't think it should be an official recommendation. I do support
documenting the potential collisions to let package maintainers make a more
informed decision.

On Thu, Dec 8, 2016 at 7:17 AM Adam Johnson  wrote:

> +1 (to what Aymeric and Florian said)
>
> On 7 December 2016 at 19:54, Robert Roskam  wrote:
>
> +1
>
> On Wednesday, December 7, 2016 at 11:25:05 AM UTC-5, Marc Tamlyn wrote:
>
> What Aymeric and Florian sayid.
>
> On 7 December 2016 at 15:58, Florian Apolloner  wrote:
>
> On Wednesday, December 7, 2016 at 1:10:48 PM UTC+1, Aymeric Augustin wrote:
>
> I still think I wouldn't use a django_ prefix when I create new apps
> because
> it adds a small but pervasive overhead to prevent conflicts that aren't
> common
> in practice.
>
>
> Same here, I am certainly against making that a recommendation from/in
> Django itself.
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/ba0114d9-0baa-4662-8fff-f7c9b03b90d3%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b6258a98-2f7e-4617-bb44-e7bc14952327%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM1jBb50Rw74sEP8Ot7ykTDop7pn8Xr6kZw4uqgJmzot3Q%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Query on Third party DB integration with DJango

[Michael Manfre]

Hi Reetika,

This mailing list is for the development of Django. Questions and
discussions related to the use of Django belong on the django-users mailing
list. To spare you the double post, the version of django-mssql you're
using doesn't support the version of Django.

https://docs.djangoproject.com/en/dev/internals/mailing-lists/#django-users

Regards,
Michael Manfre

On Wed, Nov 30, 2016 at 8:14 AM Reetika Aggarwal <
reetika.aggarwa...@gmail.com> wrote:

> Hi,
> Getting below exception while makingMigrations
>
> django.core.exceptions.ImproperlyConfigured: 'sqlserver_ado' isn't an
> available database backend.
> Try using 'django.db.backends.XXX', where XXX is one of:
> 'mysql', 'oracle', 'postgresql', 'sqlite3'
> Error was: No module named 'django.db.backends.util'
>
> Please help me fixing this.
>
> Thanks,Reetika
>
> --
> 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/3bfe4bcf-7e29-4c37-839a-47efea16a099%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/3bfe4bcf-7e29-4c37-839a-47efea16a099%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Window expressions, #26608

[Michael Manfre]

On Tue, Nov 29, 2016 at 6:37 PM Adam Johnson <m...@adamj.eu> wrote:

> I'm not sure about that detail atm, I need to review the patch. I just
> think we shouldn't be putting anything in postgres-only land.
>
> On 29 November 2016 at 22:04, Josh Smeaton <josh.smea...@gmail.com> wrote:
>
> Adam, are you thinking we should be adding something like
> Model.objects.window(), or just allowing Window-type expressions on
> backends that have a specific feature flag? Does the compiler need to get
> involved at all, or can we handle the full range of window expressions with
> the expressions API?
>
>
I agree that this should be behind a database feature and not locked away
in contrib.postgres or with a vendor check. Regarding the specifics, I
haven't had time to dig in to see how difficult it would be to add window
expressions to the expressions API, but that would be the way I'd like to
see it happen. Doing something like Model.objects.window() seems like it
would require getting the compiler involved and be more of a pain trying to
implement the various window expressions for each backend.


> Mads, there's nothing that currently handles a list of expressions, and
> certainly nothing specific to OrderBy. Your proposed syntax is basically
> what would be required `order_by=[ .. ]`.
>
>
We (or anyone) could make an ExpressionList class that is essentially an
Expression that is a list of expressions. It would basically be a
Combinable with comma as the connector.

Regards,
Michael Manfre

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

Re: Built-in router link generator in Django

[Michael Manfre]

Speaking generically about Django supporting community apps, which one
should get the golden ticket and be supported? There are usually many
similar options with groups of developers who support each for their own
reasons. Trying to pick one is a non-trivial task.

With regards to a menu generator, I don't think this is something Django
should officially support for the same reasons mentioned by Marc.

Regards,
Michael Manfre

On Mon, Oct 3, 2016 at 9:44 AM James Pic <james...@gmail.com> wrote:

> True, this is a feature that's been invented a countless number of times.
> Perhaps one implementation could be supported by the organization ?
>
> --
> 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/CALC3Kacd2DJxG%2BfcACre5z%2Bp%2BnO%3DmhuM6RRHRT4DOV4k%2BBd%2B%2BQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CALC3Kacd2DJxG%2BfcACre5z%2Bp%2BnO%3DmhuM6RRHRT4DOV4k%2BBd%2B%2BQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Django Channels Load Testing Results

[Michael Manfre]

Hi Robert,

Thanks for doing this load testing. More context would be useful to help us
outside observers to understand the potentially different variables. Is
redis running locally or are you using elasticache?

Regards,
Michael Manfre

On Mon, Sep 12, 2016 at 9:41 PM Robert Roskam <raiderrob...@gmail.com>
wrote:

> Hey Chris,
>
> The goal of these tests is to see how channels performs with normal HTTP
> traffic under heavy load with a control. In order to compare accurately, I
> tried to eliminate variances as much as possible.
>
> So yes, there was one worker for both Redis and IPC setups. I provided the
> supervisor configs, as I figured those would be helpful in describing
> exactly what commands were run on each system.
>
> Does that help bring some context? Or would you like for me to elaborate
> further on some point?
>
> Thanks,
> Robert
>
>
>
> On Monday, September 12, 2016 at 2:38:59 PM UTC-4, Chris Foresman wrote:
>>
>> Is this one worker each? I also don't really understand the implication
>> of the results. There's no context to explain the numbers nor if one result
>> is better than another.
>>
>> On Sunday, September 11, 2016 at 7:46:52 AM UTC-5, Robert Roskam wrote:
>>>
>>> Hello All,
>>>
>>> The following is an initial report of Django Channels performance. While
>>> this is being shared in other media channels at this time, I fully expect
>>> to get some questions or clarifications from this group in particular, and
>>> I'll be happy to add to that README anything to help describe the results.
>>>
>>>
>>> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>>>
>>>
>>> Robert Roskam
>>>
>> --
> 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/7fdb4db1-7458-409f-94f5-d1dad3973616%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/7fdb4db1-7458-409f-94f5-d1dad3973616%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Extend support for long surnames in Django Auth

[Michael Manfre]

I agree with Aymeric. Short of actual stats stating otherwise, I think we
should use max_length=60 and accommodate most people on the planet out of
the box without a non-trivial amount of time/effort. For those who want to
go above an beyond for a handful of potential users, they can create a
custom User model; bonus points if they make it a reusable app or even a
gist.

Regards,
Michael Manfre

On Mon, Aug 1, 2016 at 9:03 AM James Pic <james...@gmail.com> wrote:

> Aymeric, it doesn't matter if tens of milions of names fit into your
> model, it only takes one to have a issue that's going to require the
> project developers to invest time in it. So I'm a bit lost about
> what's the most practical approach here.
>
> --
> 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/CALC3KaeTBeRU-S2Kk_639ikFP7Z7rxc7LAV17qcDfHM63ATh%3Dw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: django-mssql present and future

[Michael Manfre]

Aymeric wrote:

> However I’m wary of deciding that a non-existent-yet library is the
> endorsed solution for using SQL Server from Django. It may be best to wait
> until it has reached feature parity with django-mssql and received some
> amount of real-world testing to move it there.
>

Regarding feature parity, the initial commit of this non-existent-yet
library will have as many supported features as django-mssql on Django 1.9
and 1.10. :P

The pre-release code will need to be hosted publicly to allow the Microsoft
engineers to contribute (and anyone else willing to do so). Having to host
elsewhere and then move it relatively soon afterwards will likely cause
confusion and unnecessary overhead. When I moved django-mssql from google
code to bitbucket, I was fixing links across the internet for the next ~12
months.

Do we want Django to only ever endorse established/mature projects? Or
should there be flexibility to endorse people (and companies) willing to
implement a solution.

The current case for the SQL Server backend might be non-standard in that
it's really a continuation of the django-mssql project, albeit as a rewrite
with backing by Microsoft. I can't imagine the Microsoft supported backend
not being the Django endorsed one.

Marc wrote:

> I'm definitely a fan of doing things under the /django banner. I think so
> long as we make it clear that this is in development then it shouldn't
> matter about feature parity - especially as django-mssql won't have a
> version supporting 1.9 or 1.10 anyway.
>

I like to think that I do a good job of documenting whether or not I intend
a specific bit of code to be ready for production. This would obviously
carry over for the initial build up and future pre-release branches.

On Fri, May 27, 2016 at 10:37 AM charettes <charett...@gmail.com> wrote:

> I agree, such documentation is definitely lacking and even if it wont be
> commonly used it's invaluable for the rare developers needing it.
>
> Are you planning to include it in the official Django documentation?
>

I have no strong feelings either for or against it being in the official
Django documentation. I've been wanting to put together a talk about
creating a database backend and that will likely be the first pass at the
documentation.

Regards,
Michael Manfre

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

Re: Should we require pytz for timezone support in Django?

[Michael Manfre]

I can't recall the last Django project I worked on that didn't require
pytz. It makes sense to me to require it.

Regards,
Michael Manfre

On Tue, May 17, 2016 at 6:07 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> The reasoning was based on:
>
> - our reluctance to add dependencies back then (Django 1.4)
> - sqlite3 not being strictly needed in all circumstances (and probably
> being needed in fewer circumstances originally)
>
> I’ll try to find time to make a more detailed answer later.
>
> --
> Aymeric.
>
> On 17 May 2016, at 12:01, Marc Tamlyn <marc.tam...@gmail.com> wrote:
>
> It would seem reasonable to me to require it. I wonder whether the
> reasoning is based on distro packaging or similar?
>
> On 17 May 2016 at 01:21, Josh Smeaton <josh.smea...@gmail.com> wrote:
>
>> While writing timezone tests for
>> https://github.com/django/django/pull/6243 I ran into some issues where
>> pytz seemed to be required for just about every database and platform
>> combination except postgres on linux. The docs for timezone support (
>> https://docs.djangoproject.com/en/dev/topics/i18n/timezones/) say:
>>
>> Installing pytz <http://pytz.sourceforge.net/> is highly recommended,
>>> but may not be mandatory depending on your particular database backend,
>>> operating system and time zone. If you encounter an exception querying
>>> dates or times, please try installing it before filing a bug.
>>
>>
>> I tried to find some documentation on the broader internet that would
>> more accurately describe when and for what platforms pytz is actually
>> required for timezone support, but was unable to find anything. I've opened
>> a new ticket https://code.djangoproject.com/ticket/26622 to clarify more
>> explicitly when pytz is required.
>>
>> However, I'm wondering if we should just go all-in on pytz and require it
>> for timezone support. I've not run a Django site with timezone support
>> without pytz, so I'm not sure what exact limitations exist or why you'd
>> want to use timezone support without pytz. I'd be interested in hearing use
>> cases for not requiring pytz if there are any. Explicitly requiring pytz
>> will make test writing a lot easier, and will remove any doubt about
>> whether or not pytz is required for users.
>>
>> Josh
>>
>> --
>> 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/cb513e96-e75f-462f-a8ca-b5d916ad8eef%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/cb513e96-e75f-462f-a8ca-b5d916ad8eef%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1H_n%3DGzAFZ%2BR07Qf2qnbmY8_dpy5FhdaBEXrQRB0gJ9sQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMwjO1H_n%3DGzAFZ%2BR07Qf2qnbmY8_dpy5FhdaBEXrQRB0gJ9sQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/E0E058F8-7842-4F57-B7C2-A5BA2C2FD4D4%40polytechnique.org
> <https://groups.google.com/d/msgid

Re: Feedback on Django Channels

[Michael Manfre]

On Tue, Mar 22, 2016 at 1:44 PM, Andrew Godwin <and...@aeracode.org> wrote:

> Indeed, we run Redis over TLS tunnels at work to fulfill this requirement,
> so I know transport security is required, but at the same time reinventing
> it might be more work than we need - would you trust our internal symmetric
> encryption system, or go for TLS tunnels instead?
>

If not provided out of the box, there needs to be a supported way of wiring
in encryption. The security/compliance person at my job stated that only
securing the transport was not good enough for our compliance requirements
when I was dealing with HIPAA (and some other compliance regulations) a few
months ago.

Regards,
Michael Manfre

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

Re: Value of tightening URLValidator/EmailValidator regular expressions?

[Michael Manfre]

Simple is better. Anyone who needs/wants something more complex is not
prevented by Django from doing so.

Regards,
Michael Manfre

On Mon, Mar 14, 2016 at 2:31 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Indeed, for some reason, the URL and email validators get anywhere from 2
> to 8 changes in every Django version, and there’s no end in sight. (I
> contributed to this. Sorry.)
>
> Like James, I’m in favor of making the validation much more simple and
> documenting it. This seems better than perpetually modifying it at the risk
> of introducing regressions.
>
> --
> Aymeric.
>
> On 14 Mar 2016, at 19:17, James Bennett <ubernost...@gmail.com> wrote:
>
> Personally I've long been in favor of drastically simplifying the email
> regex and essentially telling people that if they want to support
> triply-nested comments in a bang-path address they can write their own :)
>
> Is there an actual compelling reason to not just pare it down to "word
> characters and/or some punctuation, followed by an @, followed by some more
> word characters and/or punctuation"?
>
> On Mon, Mar 14, 2016 at 11:09 AM, Tim Graham <timogra...@gmail.com> wrote:
>
>> On a pull request that proposes to tighten the validation of
>> EmailValidator [0], Ned Batchelder questioned the usefulness of this:
>>
>> "Can I respectfully suggest that continuing to tweak this complex regex
>> to get asymptotically closer to perfection is not worth it? Especially to
>> fix false positives. What real-world problem is happening because
>> "gmail.-com" is accepted? "gmail.ccomm" is also accepted, but is just as
>> useless as an email address."
>>
>> Collin Anderson proposed:
>>
>> "I think we should try to just match the standard html > type="email"> validation. I'd imagine that most uses cases would want to
>> match that. We might be able to use the regex verbatim from the standard
>> itself:
>>
>> ​
>> https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email
>> )
>> If people want to allow things outside of that they could use a custom
>> regex.
>> Though it gets more complicated when considering Unicode. Unicode needs
>> to get normalized to ascii before running through the official regex."
>>
>> (Of course, this may be somewhat backwards-incompatible.)
>>
>> What are your thoughts on this? I don't mind putting a halt to
>> enhancements to the validation as long as we can articulate a sensible
>> policy in the documentation.
>>
>> [0] https://github.com/django/django/pull/5612
>>
>> --
>> 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/eb04034e-ea07-489f-aaf9-a08a5d241c4b%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/eb04034e-ea07-489f-aaf9-a08a5d241c4b%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg8L6Gduwv4n%2BD68YqjEOmE1KWCKPPGnXjQr%2BR6a1HSSsA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAL13Cg8L6Gduwv4n%2BD68YqjEOmE1KWCKPPGnXjQr%2BR6a1HSSsA%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send ema

Re: Improving MSSQL and Azure SQL support on Django

[Michael Manfre]

There has not been much direct progress with regards to an SQL Server
database backend. My personal life keeps getting in the way and the test
suite takes a disturbingly long time on my computer against MSSQL. Despite
me being busy, others have helped move things forward. Some have
contributed code to django-mssql and others have put effort towards
optimizing the Django test suite so that it doesn't take so long when
connecting to a MS SQL Server.

My goal for the next MSSQL database backend will be to support running
Django on Windows, Linux, and Mac. Support for Windows is one of my primary
concerns because there are existing production sites that run Django on
Windows.

Regards,
Michael Manfre

On Wed, Jan 27, 2016 at 12:15 AM, Cristiano Coelho <cristianocc...@gmail.com
> wrote:

> I'm interested in the progress of this as well :)
>
> Sorry I didn't read through all the posts, mostly the first ones about the
> idea.
>
> I would like to know, have you guys decided on which adapter to use? I
> have had a project where we needed to connect to SQL Server from a linux
> machine (actually amazon lambda) and even worse, we couldn't install any
> library with dependencies on C code, so we used one that was implemented in
> pure python that worked very well (pytds if I'm not wrong), with ofcourse,
> not the best performance.
> Why do I tell this? Because even if you want django to run on SQL Server,
> it doesn't really mean you want to run it on a Windows machine, actually,
> that would probably be a terrible idea (no ofense), since apache works
> horribly bad on Windows, and Linux is atually the best OS to run a web
> server with python code (either nginx or apache). So please keep this in
> mind when chosing a connector, since if it has C dependencies (which it
> will probably have, since the pure python ones are quite slow).
>
> About if you need different connectors for Azure or SQLServer, I'm
> 'almost' sure you don't, we use azure or other cloud based sqlserver
> deployments with no problem with standard sqlserver connectors.
>
> So basically, do not aim this towards making django more Windows friendly,
> but rather the actual SQL Server backend.
>
>
> El lunes, 25 de enero de 2016, 22:59:07 (UTC-3), Fabio Caritas Barrionuevo
> da Luz escribió:
>>
>> is there any update about the progress of this?
>>
>> --
>> Fábio C. Barrionuevo da Luz
>> Palmas - Tocantins - Brasil - América do Sul
>>
>>
>>
>> Em terça-feira, 13 de outubro de 2015 18:12:55 UTC-3, Tim Graham escreveu:
>>>
>>> If anyone is interested in listening in on the meetings with Microsoft
>>> engineers (Wednesday and Thursday 9am-5pm Pacific), let me know and I'll
>>> send you the Skype link.
>>>
>>> On Friday, October 2, 2015 at 11:53:17 AM UTC-7, Meet Bhagdev wrote:
>>>>
>>>>
>>>>
>>>> On Thursday, October 1, 2015 at 12:32:25 PM UTC-7, Tim Graham wrote:
>>>>>
>>>>> Hi Meet,
>>>>>
>>>>> I was wondering
>>>>>
>>>>> 1. If you have any progress updates since your last message?
>>>>>
>>>>
>>>>
>>>> * Yes, engineers on my team I are currently ramping up on the three
>>>> Django-SQL Server adapters*
>>>>
>>>>
>>>>- *  Django-pymssql*
>>>>- * Django-pyodbc-azure*
>>>>-
>>>> * Django-mssql *
>>>>
>>>> * The goal is to have a thorough understanding of what’s good and
>>>> what’s bad with these adapters before the event. *
>>>>
>>>>>
>>>>> 2. If you have any further details on the schedule for the time in
>>>>> Seattle in a week and a half? (including video conference details for 
>>>>> those
>>>>> unable to attend in person)
>>>>>
>>>>
>>>>- *We will have a video conference link for Day 2 and Day 3.
>>>>Participants interested can join the conference stream from their 
>>>> browser.
>>>>The conference room mics are only capable to a certain extent. Thus the
>>>>quality might be a little poor. *
>>>>
>>>>
>>>>- *We are finalizing the detailed schedule this week and will post
>>>>it on this thread by next Friday.  *
>>>>
>>>>
>>>> 3. If myself or the other attendees should do anything to prepare for
>>>>> the meetings?
>>>>>
>>>>> *Here are some things that you should prepare

Re: Extending JSONField serialization

[Michael Manfre]

On Wed, Jan 6, 2016 at 9:58 AM, Tom Christie <christie@gmail.com> wrote:

> Customizing the encoder (or even using DjangoJSONEncoder by default) isn't
> so bad.
>
> I'm less convinced about the usefulness of customizing the decoder - once
> you've encoded the data into JSON any additional type information is lost,
> so casting back to python primitives is always going to need to be handled
> explicitly.
>

Whether or not a configurable decoder seems useful for the situations we
can think of, only allowing users to configure half of the encode/decode
cycle seems odd to me. Allowing both to be configurable requires a trivial
amount of extra effort to implement and maintain.

Regards,
Michael Manfre

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

Re: Vote on Jira as bugtracker

[Michael Manfre]

Agreed with the above for the same reasons.

On Wed, Jan 6, 2016 at 9:17 AM, Shai Berger  wrote:

> What Marc and James said, and in particular what Daniele said : I get to
> use Jira on a daily basis and find it cumbersome and confusing.
>
> Shai see
>
>
> On 6 בינואר 2016 15:43:02 GMT+02:00, Marc Tamlyn 
> wrote:
>>
>> Yeah, this is a non-starter for me. All bug trackers are bad, we should
>> stick with the bad one we are used to.
>>
>> Marc
>>
>> On 6 January 2016 at 13:26, Victor Sosa  wrote:
>>
>>> To answer you question:
>>> There is a plug-in to migrate all the data to Jira and similar to
>>> integrate with any it with any in you infrastructure. (I just don't know it
>>> all you infrastructure)
>>>
>>>
>>> https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html
>>>
>>> On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida wrote:

 On Wed, Jan 6, 2016, Victor Sosa  wrote:

 >I felt like lost using trac; it is kind of messy. I just don't feel
 >comfortable
 >with it.
 >I see so many open source project using Jira that is just natural.
 Search
 >is easy, categorize is easy, look through the all issues and task is
 quick.
 >
 >I would like to propose a vote on Jira as the bugtracker for this
 project.
 >Just vote + or - to see how many people agree on this.

 Hi Victor. It's a reasonable proposition, but it's not simply a case of
 choosing what would be nicer: we also have to make it work in our
 infrastructure - and that's a huge effort.

 How, for example, would we migrate the many thousands of tickets from
 Trac to JIRA?

 How would JIRA be integrated into our current deployment
 infrastructure?

 By all means it's useful to get votes on something like this, even
 before we consider those questions, because if enough people want something
 it's always possible - but be aware that simply getting lots of votes for
 it would only ever be the first and easiest step.

 Having said that: I prefer Trac to JIRA. It's simpler, and faster.

 Daniele

 --
>>> 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/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> --
> 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/CDE1F163-5500-446F-B8A4-FE512F944C57%40platonix.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Extending JSONField serialization

[Michael Manfre]

It should be configurable and I like the kwargs idea. I've also had to
monkey patch JSONField in this way for datetimes.

Regards,
Michael Manfre

On Tue, Jan 5, 2016 at 12:48 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> > On 5 janv. 2016, at 18:37, Tom Christie <christie@gmail.com> wrote:
> >
> >> Should JSONField accept additional kwargs to customize the encoder and
> the decoder?
> >
> > Quick take here:
> >
> > That sounds like a bit too much "cleverness" to me. The most obvious
> issue it'd cause is putting values of one type into the field, but getting
> objects of a different type back. (eg datetime getting coerced into a
> string on the way in, and left as a string on the way out).
>
> Yes, I understand how that could surprise a developer.
>
> A smart deserializer that would attempt to convert some strings back to
> their original type, based on their content, would create the opposite
> risk: a string that matches the format of a date could be accidentally
> returned as a date.
>
> I wouldn’t do this for mission-critical data — but then I wouldn’t store
> it in a JSON field either. Django projects should only use a JSON field for
> data that isn’t worth normalizing into actual fields. Writing a schema to
> map keys to types defeats the point; if you’re writing a schema, just
> express it with traditional model fields.
>
> I don’t think Django should (de)serialize non-native JSON types by
> default, but it should make it possible through public APIs, as this is a
> common requirement. For my use case, logging, the convenience of being able
> to store dates, datetimes and decimals without resorting the heavy guns
> (DRF serializers) helps a lot.
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/B995F2B7-E1D1-4F82-8032-E502EA11680A%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Backwards-compatibility import shims

[Michael Manfre]

On Wed, Dec 30, 2015 at 11:52 AM, Tim Graham <timogra...@gmail.com> wrote:

> For that reason, I think we should reconsider making Django's deprecation
> warnings loud by default (at least in LTS versions) [1]. Otherwise, users
> will pester library authors to fix those warnings and we haven't really
> made things easier.
>
> Instead, the idea would be for library authors to continue using the
> deprecated APIs while supporting the LTS in which they are deprecated and
> the previous LTS. When the version of Django following the LTS is released,
> library authors can then drop support for all Django versions before the
> LTS, check their package with the LTS using python -Wall and make the
> deprecation warning fixes, then seamlessly add support for the next version
> of Django.
>
> Does that make sense?
>

This makes sense to me. +1

Regards,
Michael Manfre

-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Fellow Report - October 17, 2015

[Michael Manfre]

On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> 2015-10-20 5:04 GMT+02:00 Michael Manfre <mman...@gmail.com>:
>
>> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS.
>> This may follow the current pattern Aymeric started when he created
>> django-pymssql, or have them both in django-mssql.
>
>
> For the record, django-sqlserver did that as well. In django-pymssql, I
> chose to wrap django-mssql instead of forking it to avoid the having to
> maintain a fork until a better solution is available.
>

Thanks for the reminder. I forgot about django-sqlserver. I'll also
evaluate that backend.

Regards,
Michael

-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Fellow Report - October 17, 2015

[Michael Manfre]

Tim gave a good overview of the week. I'll focus my response on the MSSQL
roadmap.

On Sat, Oct 17, 2015 at 8:36 PM, Tim Graham <timogra...@gmail.com> wrote:

> * Discussed the long-term roadmap for MSSQL support in Django. I'll let
> Michael speak to the details of this.
>

I had the opportunity to speak with several engineers that had intimate
knowledge of Microsoft's various SQL Server drivers; past, current, and
future. The ADO based drivers used by django-mssql will not receive any
future love from Microsoft. They don't have plans on removing them from
Windows, but the advice was to use either ODBC or FreeTDS. The fastest and
most feature rich drivers for connecting to SQL Server from Windows are the
ODBC drivers. Microsoft is actively working on updating the ODBC drivers
for Linux and expect them to be released this year. ODBC drivers for Mac
are planned for sometime next year. The next best way of connecting to SQL
Server is to use FreeTDS (without the ODBC interface), which has the
benefit of having drivers available for all OSes right now.

The short-term plan for django-mssql is to get it to pass the Django 1.8
test suite, without making any substantial changes. This will allow any
existing django-mssql users to upgrade to the Django 1.8 LTS. My long term
plan is to switch out ADO for replaceable ODBC and FreeTDS. This may follow
the current pattern Aymeric started when he created django-pymssql, or have
them both in django-mssql. After 1.8 is fully supported, I need to think,
discuss, and investigate more before making a decision.

ODBC seems to be the most performant and best option, but I have concerns
about the current lack of good drivers for Linux and Mac. If Microsoft
follows through with their commitment, then it should be a non-issue, but
I'd rather hedge my bets and ensure an easier time with drivers in the long
run. Supporting both also provides for a good way of comparing the
performance of the underlying drivers.

I plan on evaluating django-mssql, django-pyodbc-azure, and starting from
scratch to see which would be the best route for this new mssql database
backend. There are pros and cons to each. Django-mssql has a lot of legacy
cruft. Django-pyodbc-azure targets Azure SQL Server, which has some subtle
differences with Microsoft's non-cloud version of the database server.
Starting from scratch is potentially more work. Regardless of the decision,
the repo will be hosted on github.

Regards,
Michael Manfre

-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Static typing for python methods

[Michael Manfre]

Django can't include the inline type hinting syntax for many years, but we
can add stub files. Keeping the stubs in sync with the code will be more
effort and we'd want some sort of automated tooling to help with that, but
I'm not opposed to adding stub files for the public APIs. Assuming no core
devs chime in with a -1, I'd say create a ticket and you and/or others can
start working on a pull request.

Regards,
Michael Manfre

On Sun, Oct 11, 2015 at 5:00 AM, John Michael Lafayette <
johnmichaelreed...@gmail.com> wrote:

> Python now has static type checking. All you do is follow function
> parameters with ": paramType" and add "-> returnType" before the colon at
> the end of the function declaration and auto-complete will work on the
> return value in IntelliJ. Can you add the function parameter types and
> return types to all the functions in the public API?
>
> > > So like change this...
> > > def func(param):
> > >
> > > To this...
> > > def func(param: int) -> str:
>
> --
> 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/CACxkjvZUnbR1zXzAQnqdRS4vQ1Y_mJ%3DQ%3D-2Z-st5KDve48SBOA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CACxkjvZUnbR1zXzAQnqdRS4vQ1Y_mJ%3DQ%3D-2Z-st5KDve48SBOA%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Making max_length argument optional

[Michael Manfre]

I'm -1 on having a default max_length on CharField. We should encourage
developers to be more explicit when defining their models, not less. I've
inherited way too many databases that suffered from "VARCHAR(255)" being
chosen as the arbitrary "any field storing even a few characters will be
this length".

Instead of adding a default (and encouraging bad database schemas), what
are thoughts about adding a helper function to allow people to define their
own new CharField as a one liner? E.g. ShortCharField =
make_max_length_char_field(255)

I agree that the Postgresql specific field should exist in
django.contrib.postgres.

Regards,
Michael Manfre

On Tue, Sep 22, 2015 at 8:40 AM, Collin Anderson <cmawebs...@gmail.com>
wrote:

> If anyone's curious, the mysql situation is as crazy as you might expect.
> :)
>
> The max is only determined only by the total row size (65,535 bytes) and
> the index size (767 bytes default).
>
> Mysql defaults to only allowing 3-byte (no emoji) unicode characters, so
> 65,535/3=21,845 max across the entire row (the sum of all of the maxes of
> all char/varchar columns), and each indexed field only gets 767/3=255
> characters by default.
>
> If you change to 4-byte unicode characters, (which you should, but django
> doesn't really help you out #18392), your max_lengths can add up to
> 65,535/4=16,383 characters, and if you want the field to be indexed, you
> only get 191 characters (using the default index size). It's possible to
> only index the first 767/4=191 characters of the field, but django doesn't
> really support that.
>
> Basically, 255 works pretty well by default, allowing 65,535/3/255=85
> 3-byte fields per row, and indexes just work if you stick to the default
> settings.
>
> https://dev.mysql.com/doc/refman/5.0/en/char.html
> https://code.djangoproject.com/ticket/18392
>
>
> On Tue, Sep 22, 2015 at 1:56 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hi Shai,
>>
>> On 22 sept. 2015, at 04:22, Shai Berger <s...@platonix.com> wrote:
>>
>> > I'd solve the "need to specify" issue by setting a default that is
>> > intentionally smaller than the smallest (core) backend limitation, say
>> 128.
>>
>> I would pick the highest value supported by all core backends (probably
>> 255
>> for MySQL, unless there’s something about indexes and multi-byte encodings
>> that I forget) in order to minimize the need to increase it.
>>
>> If we go for a lower value, I suggest to pick something totally arbitrary
>> like
>> 100 to make it clear that it isn't a technical limitation.
>>
>> > I"d make an "unlimited length text field" a new type of field,
>> explicitly not
>> > supported on MySql and Oracle; and I'd suggest that it can live outside
>> core
>> > for a while. so we may get an impression of how popular it really is.
>>
>> The main use case seems to be “VARCHAR() on PostgreSQL”. What about
>> defining a
>> slight variant of CharField in django.contrib.postgres that merely makes
>> the
>> max_length argument default to None?
>>
>> --
>> 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/17C37814-E6A8-4E27-B590-BF9FFF42CB20%40polytechnique.org
>> .
>> 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/CAFO84S5TUwLPf%3DRrGXL4%3Dvf3647CufOsijiznttVQF%2BxYHaBFg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAFO84S5TUwLPf%3DRrGXL4%3Dvf3647CufOsijiznttVQF%2BxYHaBFg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options,

Re: Making the test suite run faster

[Michael Manfre]

I agree with Shai. The database backend needs to be able to control this
feature.

Regards,
Michael Manfre

On Sun, Sep 6, 2015 at 12:48 PM, Shai Berger <s...@platonix.com> wrote:

> Hi,
>
> On Sunday 06 September 2015 13:06:18 Aymeric Augustin wrote:
> >
> > This will require ./runtests.py --no-parallel or ./runtests.py
> > --parallel-num=1 to run tests under Oracle. I think it’s a good tradeoff
> > because the defaults should be optimized for occasional contributors.
> >
>
> Can we somehow make this default controlled by the database backend, so
> that
> it only defaults to --parallel on backends which support it?
>
> While not many, Oracle does have its own occasional contributors, and I'm
> not
> sure this kind of change would be welcomed by the 3rd-party backends.
>
> This could be done, I think, with a feature flag on the backend
> ("supports_parallel_tests"), defaulting to False, set to True on supporting
> backends.
>
> My 2 cents,
> Shai.
>
>


-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: revisiting the "easy pickings" flag in Trac

[Michael Manfre]

I never liked the "easy pickings" flag either. Your proposed change would
be a good way to identify the technical ability required to make the
changes to Django. Should we have a separate drop down with options to
identify the non-technical (bikeshedding) difficulty of the ticket? There
are certain tickets that are created that are not immediately closed as
won't fix that are not a technically challenging problem, but are a huge
uphill battle to get merged.



On Thu, Aug 20, 2015 at 7:35 PM, Tim Graham  wrote:

> In my experience the "easy pickings" flag is ill-defined and insufficient
> for describing the difficulty of a ticket. I don't want to get stuck in
> categorizing tickets just for the sake of it, but I think a drop down with
> options like the following could be useful in helping contributors find
> suitable tickets:
>
> Trivial - Typos, wording tweaks, etc.
> Easy - Simple features and bugs suitable for a first-time contributor.
> Moderate - Requires a basic knowledge of Django internals.
> Hard - Requires a thorough understanding of Django internals.
> Very Hard - Refactorings or features that are difficult for experienced
> core developers.
>
> Do you think this would be useful? If so, are the selections above
> suitable?
>
> --
> 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/5544efa8-75a0-40ba-9210-bea027d32a72%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

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 <akaar...@gmail.com>
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 <cmawebs...@gmail.com>
> 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|  |
> 

Re: default values on database level

[Michael Manfre]

On Mon, Aug 3, 2015 at 9:25 AM, Podrigal, Aron 
wrote:
>
> >   - Do we want to allow extending this to defaults that are applied on
> every save (automatic database backed modified timestamps for example)?
>
> +1 for this one too.
>

This behavior would be a nice step toward computed (readonly) database
fields.



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: future of QuerySet.extra()?

[Michael Manfre]

As some one who has had to abuse .extra() at times to make mssql things
work, I support this approach.

On Fri, Jul 31, 2015 at 4:00 PM, Tim Graham  wrote:

> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some point in the future.
> Use it only if you cannot express your query using other queryset methods.
> If you do need to use it, please file a ticket with your use case so that
> we can enhance the QuerySet API to allow removing extra(). We are no
> longer improving or fixing bugs for this method.
>
> On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
>>
>> I wonder if there's a way in the docs we can deprecate it as in "we don't
>> recommend you use it", but not actually schedule it for removal.
>>
>> On Friday, July 31, 2015 at 2:01:20 PM UTC-4, Marc Tamlyn wrote:
>>>
>>> I don't know about unmaintained, but I think there's a consensus that
>>> .extra() has a horrible API and we should do away with it eventually. That
>>> said I think there are still enough things that can't be done without it at
>>> present. A lot fewer now we have expressions, but still some.
>>>
>>> I'd be happy to put a moratorium on improving it, but we can't deprecate
>>> it yet.
>>>
>>> On 31 July 2015 at 18:58, Tim Graham  wrote:
>>>
 In light of the new expressions API, the idea of deprecating
 QuerySet.extra() has been informally discussed in IRC and elsewhere. I
 wonder if there is consensus to mark extra() as "unmaintained" and to
 suggest filing feature requests for functionality that can be performed
 through extra() but not through other existing QuerySet methods? There are
 at least several tickets (examples below) of edge cases that don't work
 with extra(). It seems like a waste of time to leave these tickets as
 accepted and to triage new issues with extra() if they won't be fixed.

 https://code.djangoproject.com/ticket/24142
 https://code.djangoproject.com/ticket/19434
 https://code.djangoproject.com/ticket/12890

 --
 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/6e1be326-3b17-49ca-accf-03eec5ad41ef%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/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: default values on database level

[Michael Manfre]

On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron 
wrote:

> Hi Loic,
>
> Agree with having a db_default kwarg.
>
> I am not using multiple databases so no experiance with db routers. So how
> would should we handle routing between different databases when the
> db_default value is not compatible with that backend? for example
> Model.save(using='mysql_db') should we than use the Field.default to
> generate the default value (which is not how it works today, that the
> default is computed at instance creation). I would prefer in such a case to
> rely on the database to handle the situation by omitting that field from
> the columns list, so mysql for example would set a non nullable varchar
> column to an empty string, where with other databases it would cause an
> IntegrityError exception. and that db_default and default kwargs cannot be
> used togethor.
>

If db_default is defined for a field, then it should always be used. If the
db_default is invalid for the configured backend, then it will and should
break. We shouldn't automatically change db_default to a regular default or
do any other magic.

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

Re: Django 1.9 - JSONField

[Michael Manfre]

The django-contrib-postgres JSONField takes advantage of JSON being a
native type that allows it's data fields to be used by the ORM, instead of
just a text field that wraps json.dumps() and json.loads(). All of the core
supported backends seem to have some flavor of native JSON support (MS SQL
is adding native JSON in SQL Server 2016). I haven't investigated whether
or not they could be sanely implemented as a common field. That might be a
worthwhile change to target for Django 1.10, guarded by a DatabaseFeature
for all of the earlier versions of each database that don't support it.

Regards,
Michael Manfre


On Tue, Jul 7, 2015 at 9:57 AM, <lza...@ucs.br> wrote:

>
> Hi all,
>
> I'd like to know why this feature will be only available on postgres and
> not as a Field for any database, like this product? This Field would be
> very usefull for many users I think.
>
> https://github.com/bradjasper/django-jsonfield
>
> https://docs.djangoproject.com/en/dev/releases/1.9/#django-contrib-postgres
>
> By.
>
> Enviado via UCSMail.
>
> --
> 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/0459e983-7098-475c-9e3f-14a076513f4a%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0459e983-7098-475c-9e3f-14a076513f4a%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: 1.9 release planning

[Michael Manfre]

+1. I really don't like the idea of 2.x being odd.

On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer <loic.bist...@gmail.com>
wrote:

> Just when we thought we had a winner... I'd like to make a final proposal.
>
> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by
> introducing the 1.10 and 1.11LTS releases.
>
> The upside is that the new policy applies right away and we avoid the
> oddball 2.0 and 2.1 releases.
>
> It's much less invasive than the previous idea of renaming 1.9 to 2.0, but
> it still requires renaming PendingDeprecationWarnings in 1.8, and both
> warnings in 1.9.
>
> What do you think?
>
> --
> Loïc
>
> > On Jun 17, 2015, at 08:47, Josh Smeaton <josh.smea...@gmail.com> wrote:
> >
> > I'm also +1 on the proposal as it stands, and neutral on when the semver
> versioning should begin.
> >
> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> > I'm +1 on the Google doc proposal and like Markus, I support relabeling
> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1
> LTS oddball.
> >
> > Regards,
> > Michael Manfre
> >
> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <cmawe...@gmail.com>
> wrote:
> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1,
> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we
> sacrifice a little bit of strict semver, but it give some nice meaning to
> the version numbers.
> >
> >
> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> > Thanks Loïc,
> >
> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> > > I've attempted to summarize the history of this thread. Note that I
> > > marked as +1 any generally positive feedback towards a given
> > > proposal, please correct if you feel misrepresented.
> > >
> > [snip]
> > >
> > > # Third iteration:
> > >
> > > 5/ Switching to Semantic Versioning
> > >
> > > Donald mentioned SemVer on IRC a few days ago. Since then various
> > > proposal were made to reconcile it with our release policy. So far
> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> > > various proposals in that direction but I don't think we have yet
> > > reached consensus on a specific one. Tim updated the Google doc to
> > > reflect my latest proposal, so including me that's 2 formal +1 for
> > > it, but I'd say we should wait for at least a couple more votes
> > > before taking it to the technical board.
> > >
> > > Refs: - http://semver.org/ - Carl's analysis
> > >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
> > >
> > >
> > - Ryan's proposals
> >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> > > - Loïc's proposal
> > >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
> >
> > FWIW, I am also +1 on your proposal, as currently documented in the
> > Google doc.
> >
> > I was trying to come up with a proposal where LTS == major release for
> > the sake of argument, since it seemed like that was intuitive to at
> > least some people, but it's not worth the required lengthening of
> > deprecation paths. Your proposal is much better. (And it does make some
> > intuitive sense for the _last_ minor release in a major series to be LTS
> > rather than the first).
> >
> > 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-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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > GPG Fingerprint: 74DE D158 BAD0 EDF8
> > keybase.io/manfre
> >
> > --
> > 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...@

Re: 1.9 release planning

[Michael Manfre]

I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9
to 2.0 to line the versions up with the new paradigm without the X.1 LTS
oddball.

Regards,
Michael Manfre

On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <cmawebs...@gmail.com>
wrote:

> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2
> LTS, 4.0, etc.) LTS is the final of a major version number, and we
> sacrifice a little bit of strict semver, but it give some nice meaning to
> the version numbers.
>
>
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>>
>> Thanks Loïc,
>>
>> On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
>> > I've attempted to summarize the history of this thread. Note that I
>> > marked as +1 any generally positive feedback towards a given
>> > proposal, please correct if you feel misrepresented.
>> >
>> [snip]
>> >
>> > # Third iteration:
>> >
>> > 5/ Switching to Semantic Versioning
>> >
>> > Donald mentioned SemVer on IRC a few days ago. Since then various
>> > proposal were made to reconcile it with our release policy. So far
>> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
>> > various proposals in that direction but I don't think we have yet
>> > reached consensus on a specific one. Tim updated the Google doc to
>> > reflect my latest proposal, so including me that's 2 formal +1 for
>> > it, but I'd say we should wait for at least a couple more votes
>> > before taking it to the technical board.
>> >
>> > Refs: - http://semver.org/ - Carl's analysis
>> >
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>> >
>> >
>> - Ryan's proposals
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
>> > - Loïc's proposal
>> >
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>>
>> FWIW, I am also +1 on your proposal, as currently documented in the
>> Google doc.
>>
>> I was trying to come up with a proposal where LTS == major release for
>> the sake of argument, since it seemed like that was intuitive to at
>> least some people, but it's not worth the required lengthening of
>> deprecation paths. Your proposal is much better. (And it does make some
>> intuitive sense for the _last_ minor release in a major series to be LTS
>> rather than the first).
>>
>> 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: 1.9 release planning

[Michael Manfre]

I like Colin's proposed schedule.

Regards,
Michael Manfre

On Thu, Jun 11, 2015 at 1:12 AM, Anssi Kääriäinen <akaar...@gmail.com>
wrote:

> +1 to Collin's release schedule.
>
> This schedule should make it extremely easy to support "develop using
> latest release, maintain using latest LTS". With the above schedule if
> you started with 1.8 you are already on LTS. If you start with 1.9,
> you should have an easy upgrade path all the way till 2.1 which is
> LTS. Also upgrading from 1.8 to 2.1 should be easy enough if you
> didn't use any deprecated features when running on 1.8.
>
>  - Anssi
>
> On Thu, Jun 11, 2015 at 12:06 AM, Tim Graham <timogra...@gmail.com> wrote:
> > Yep, I think Collin's schedule is it. I'm happy with that option and 3rd
> > party apps shouldn't need to add any compatibility shims to support 2
> > releases -- they just need to ensure they aren't using any deprecated
> APIs.
> >
> >
> > On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote:
> >>
> >> Hi Tim,
> >>
> >> What I mean is we could still make it easy to support both LTS releases,
> >> even if we drop features deprecated in 1.8 before the next LTS
> according to
> >> the normal release schedule. Right? Because apps wouldn't need to use
> those
> >> deprecated features to support both 1.8 and 2.1. We could drop them in
> 2.0
> >> like normal?
> >>
> >> I'm trying to lessen the increased maintenance burden of Loic's proposal
> >> while still making it possible to easily support both LTS releases.
> >>
> >> > For "maintenance costs" I am not worried about supported deprecated
> APIs
> >> > in old releases, only how long they stay around in master as that
> could be a
> >> > barrier to innovation.
> >> Right, so the cost would be an extra 8 months before removing features
> >> deprecated in 1.9 from master.
> >>
> >> Thanks,
> >> Collin
> >>
> >> On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
> >>>
> >>> Collin, I'm not following your reasoning about why dropping features
> >>> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think
> you made
> >>> a typo in your timeline putting it next to 2.0?) will make it possible
> to
> >>> easily support both LTS releases? That's the purpose of Loic's
> proposal I
> >>> believe.
> >>>
> >>> For "maintenance costs" I am not worried about supported deprecated
> APIs
> >>> in old releases, only how long they stay around in master as that
> could be a
> >>> barrier to innovation.
> >>>
> >>> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
> >>>>
> >>>> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
> >>>>>
> >>>>> And there is a significant added maintenance cost to my proposal
> >>>>> compared to yours. Dropping deprecated APIs in the release after an
> LTS
> >>>>> means we still have to support those APIs for three more years
> >>>>> (possibly
> >>>>> for four or five years after they were first deprecated). Dropping
> them
> >>>>> _in_ the LTS release shortens that window drastically.
> >>>>
> >>>>
> >>>> If we release every 8 months, that means we normally support
> deprecated
> >>>> features for 2 years. If we maintained LTS compatibility, then, yes,
> that
> >>>> would mean "supporting" the APIs for more than 5 years after
> deprecation.
> >>>> But to be clear, most of that time it's only security support for
> those
> >>>> APIs, and the APIs are long gone from master. Right?
> >>>>
> >>>> Thanks,
> >>>> Collin
> >>>>
> >>>>
> >>>> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson
> wrote:
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> Here are some thoughts in reply to some of the comments in the
> >>>>> django-compat thread. I don't stick to the LTSs myself, but I've
> helped
> >>>>> maintain apps that have 1.4 compatibility.
> >>>>>
> >>>>> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
> >>>>>>
> >>>>>> 1.8 

Re: Django banking packages

[Michael Manfre]

This group is for the discussion of developing the Django framework.
Discussions and questions related to using Django should take place on the
django-users group.

Regards,
Michael Manfre

On Mon, Jun 1, 2015, 7:11 AM Swapnil Bhadade <swapnilrbhadad...@gmail.com>
wrote:

> Which are Django packages for full stack development of an e-banking web
> app  Any resources / frameworks would be of help.
> Best
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/146810a4-c45c-4664-9193-15ed9961080b%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/146810a4-c45c-4664-9193-15ed9961080b%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: No way to optimize batch deletion

[Michael Manfre]

A pre/post batch_delete signal would be useful for the usage you describe.
There would likely be confusion with its usage because unlike post_delete,
the batch_delete signals would not be able to provide actual records. The
best it could do would be to provide the queryset and the deletion count on
the post. The topic of batch deletion signaling has come up before, but I
don't remember the outcome (or whether it was on here or IRC). I'll try to
find it and report back when I get to a more capable device.

Regards,
Michael Manfre

On Thu, May 7, 2015 at 7:36 PM, Antoine Catton <acat...@fusionbox.com>
wrote:

> Hello,
>
> django-treebeard [1] has an optimized batch deletion for its models. [2]
>
> The main reason is because post_delete signals are called for each
> objects. And custom deletion in treebeard can be done in batch.
>
> I was reading Django's code [3] and it looks like there's no way to hook
> into _raw_delete() or DeleteQuery.delete_batch().
>
> The only way is to hook into signals.post_delete.
>
> This causes problems if we have something like this:
>
>   class A(treebeard.MP_Tree):
>   b = ForeignKey('B')
>
>   class B(models.Model):
>   a = IntegerField()
>
> If we run:
>   B.objects.filter(expression).delete()
> Because Treebeard is overriding A.objects.delete(), the custom delete()
> will never be called on the tree, and the tree will be inconsistent.
>
> One solution I can think of, would be to add a pre/post batch_delete
> signal. But I'm open to any other solution.
>
>
> [1] <http://code.tabo.pe/django-treebeard/src>
> [2] <
> http://code.tabo.pe/django-treebeard/src/04ca69b7daf6390bb2130305cf1325df486d6b7e/treebeard/mp_tree.py?at=default#cl-51
> >
> [3] <
> https://github.com/django/django/blob/3baebf52aa0850de3ebadcbe1eda7e6e9a2c6c44/django/db/models/deletion.py#L284
> >
>
> --
> Antoine Catton
> Software Engineer at Fusionbox, Inc.
> <https://www.fusionbox.com/>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/554BF717.50503%40fusionbox.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: New function to sort words with accents.

[Michael Manfre]

Hi Paulo,

Your issue can be solved by modifying the database collation or with
application code (E.g. SlugField). The django-developer mailing is for
discussion of the Django framework. The django-users mailing list is the
appropriate place to start/continue a discussion about how you can resolve
this issue.

Regards,
Michael Manfre

On Tue, May 5, 2015 at 8:52 PM, Paulo Maciel <paulosouzamac...@gmail.com>
wrote:

> I am returning the query Something.objects.all().order_by(Lower('name'))
> but the order is not respecting names that start with accent, causing these
> results appear at the end of ordering. We need a function to ignore accents
> and order correctly names with accents, as well as function Lower treats
> the results.
>
> *Currently:*
>
> arroz
> baleia
> dado
> limão
> xerox
> água
> ótimo
>
> *As it should be:*
>
> água
> arroz
> baleia
> dado
> limão
> ótimo
> xerox
>
>
> We need a function like it to fix the problem:
> Person.objects.all().order_by(Unaccent('name'))
>
> This is a priority issue because it affects thousands of Brazilians and
> other nationalities who use Portuguese.
>
>
>  --
> 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/27620089-a89e-4e13-9576-637e37395754%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/27620089-a89e-4e13-9576-637e37395754%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Guessable entry points

[Michael Manfre]

I like the alias.

On Fri, May 1, 2015 at 5:58 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> `python -m django` as a alias for `django-admin` sounds good.
>
> --
> Aymeric.
>
>
>
> On 30 avr. 2015, at 19:15, Ryan Hiebert  wrote:
>
> https://github.com/django/django/pull/4588
>
> I this PR I suggest to add a `django` entry point that is identical to
> `django-admin`, and a `__main__.py` that also is a mirror of `django-admin`.
>
> There’s also related discussion at
> https://github.com/django/django/pull/3861
>
> There’s precedent for using these as the primary methods of use all over
> the place. Flask, in particular, uses both the `flask` command as well as
> `python -m flask`. Celery also uses the `celery` command as well as `python
> -m celery`.
>
>
> I see value in adding these endpoints that are more easily guessable.
> However, there’s a cost too, the cost of having more than one way to do it.
> We already have `django-admin` and `django-admin.py`, would adding these
> obvious entry points give too many options?
>
> Ryan
>
> --
> 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/90DC7B87-35F5-4B77-93EA-7734DA31EA86%40ryanhiebert.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/37733725-6295-48F4-98D1-BC82978EE570%40polytechnique.org
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Must a Django Database Support Migrations?

[Michael Manfre]

On Sun, Apr 26, 2015 at 8:33 PM, Marcin Nowak <marcin.j.no...@gmail.com>
wrote:

> Hi.
>
> Before v1.7 there were no migrations and Django was quite useful (for
> example with South as an 3rd party app). What happened then?
>
> I think that migrations can be decoupled from core and you just don't want
> to do this for some unknown reason.
> I'll prepare a pull request if it will not be dropped because of some kind
> of ethos.
>

As the person who started this thread over a year ago with the motivation
of making migrations support optional, I can definitively say that
migrations will not be removed from Django. Any pull request attempting to
do so will be declined. There are certain portions of Django that can (and
likely should) be decoupled, the database API (including migrations) is not
one of those pieces. One of the many reasons for it to remain in core is
that it's useful being able to modify the models that ship with Django.
E.g. increasing the size of user name field.

Regards,
Michael Manfre

-- 
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/CAGdCwBvKVPhERYzSpP9AZ6%2Bd83ehiZhC%2BUqMXf9SRQzw_W%2B5%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Michael Manfre]

On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner  wrote:

> I think rare LTS releases and frequent (6month) incremental upgrades are
> a good compromise.
> Third-party packages should support LTS releases and at least the latest
> Django version. They may drop support for earlier non-LTS releases.
> Either you stick with the LTS release or you go with the cutting edge
> with all dependencies.
>

I'm not advocating for or against more frequent releases, but trying to
impose a support policy upon 3rd party packages is not going to work. It
would great if they support whatever versions of Django are still
supported, but sometimes that takes more time/effort than the maintainer is
willing to devote.

The number or frequency of releases doesn't matter as much as the content
of the releases. Depending on the app, some Django versions are harder to
support at the same time. The back-to-back major changes to the Datatbase
API forced django-mssql to only support a single Django version with each
release. After that change, I was less inclined to backport fixes and even
stopped testing against Django 1.4 well before it was out of support.



> Advantages of release early, release often are that new features have
> more time to mature before a LTS release, you don't have to risk using
> the unstable HEAD for new features, and more feedback from users.
>
> On 04.04.15 14:30, Tim Graham wrote:
> > Now that Django 1.8 is released, I wanted to bump this thread for
> > discussion so we can hopefully ratify this schedule or modify it based
> > on feedback. In particular, I heard a concern that a six month release
> > schedule may be too often for the community. On the other hand, I think
> > smaller releases would make incremental upgrades easier.
> >
> > One difficulty could be if third-party packages try to support every
> > version since the last LTS (this seemed to be common with 1.4). A 6
> > month release schedule would mean 5 versions of Django until the next
> > LTS, instead of 3 as we had since 1.4, so more `if DJANGO_X_Y`
> > conditionals. One idea is that third-party packages could declare their
> > own "LTS" versions (if needed) and drop support for older versions more
> > freely in future development.
>
> --
> 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/552017D7.6020907%40gmx.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: inspectdb database defaults

[Michael Manfre]

I agree with Tim.

I would support refactoring inspectdb so that it would be easier for anyone
to subclass the command and add additional logic to the introspection
process. Alternatively, moving much of the logic out to a function that
returns a JSON representation of the database that inspectdb uses to write
the model data.

Regards,
Michael Manfre

On Tue, Mar 10, 2015 at 11:56 AM, Collin Anderson <cmawebs...@gmail.com>
wrote:

> Hi All,
>
> We recently added database introspection of defaults for purposes of
> testing migrations.
>
>
> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc
>
> I would find it useful to have inspectdb attempt to use those defaults
> when generating models. (My use case is running inspectdb on a WordPress
> database which has a bunch of database defaults.)
>
> Rough proof of concept: https://github.com/django/django/pull/4030
>
> Though Tim says: "Translating database level defaults into model field
> defaults isn't functionally equivalent and given that Django doesn't
> translate the model field default option into a database level default, I
> think it would be inconsistent to do a conversion in the other direction."
>
> Collin
>
>  --
> 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/11972cea-2565-4940-abe6-8cdec8f40a1e%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/11972cea-2565-4940-abe6-8cdec8f40a1e%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Composite fields

[Michael Manfre]

al implementation and API simple).
>
> The point is (no pun intended) that I can't really think of a good way to
> map a python None to the values of a composite field _without_ the extra
> implicit column. It's not the nicest solution in the world, but it works.
>

I'd argue that not being able to have a hierarchy of Composite fields is a
feature.

Regards,
Michael Manfre

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

Re: Composite fields

[Michael Manfre]

As the others have already stated, patience is required if you want
meaningful feedback.

Have you thought about how CompositeFields and SubFields will interact with
migrations?

Regards,
Michael Manfre

On Wed, Mar 4, 2015 at 8:16 AM, Thomas Stephenson <ovan...@gmail.com> wrote:

> Considering the past two proposals I've made here, I doubt I'll get more
> than an echo chamber effect on this one.
>
> For the past week or so I've spent a bit of time on a feature I've always
> wanted to see land in django -- composite fields. The tickets have been
> open in the bug tracker for quite some time (and there's a few related
> ones, such as multi-column primary keys that can all be killed with the one
> stone).
>
> The work is available on this branch of my fork of django
> <https://github.com/ovangle/django/tree/composite_fields> for the moment
> -- I haven't opened up a PR yet because there's still some features that
> are still to be implemented that will be explained below, but I want to
> give everybody a chance to tell me where I can stick it before I spend
> *too* much time on it.
>
> So, without further ado, the proposal.
>
>
> Composite Fields - Implemented
>
> A composite field is an encapsulation of the functionality of a subset of
> fields on a model. Composite fields can be defined in one of two ways:
>
> 1. Statically declared composite fields
>
> A statically declared composite field is defined in the same way a django
> model is defined. There are two customisable transformation functions,
> CompositeField.value_to_dict(self, value) and
> CompositeField.value_from_dict(self, value) which can be used to associate
> the field with a python object.
>
> All the serialization functions are implemented via the implementations of
> the subfields.
>
> For example,
>
> class MoneyField(models.CompositeField):
>currency_code = models.CharacterField(max_length=3)
>amount = models.DecimalField(max_digits=16, decimal_digits=4)
>
>## Overriding __init__ can be used to pass field parameters to the
> subfields
>
>def value_from_dict(self, value):
>if value is None:
>   return None
>return Money(**value)
>
>def value_to_dict(self, value):
>   if value is None:
>  return None
>   return {attr: getattr(value, attr) for attr in ('currency_code',
> 'amount')}
>
> 2. Inline composite fields.
>
> An inline composite field is declared at the field definition site on the
> body of a model, by providing the subfields as the 'fields' argument of the
> CompositeField constructor. There are no transformation parameters
> available to override when declaring a composite field in this fashion --
> the value of the field is always available as a python `dict` as an
> attribute on the MyModel
>
> class MyModel(models.Model):
> id = models.CompositeField(fields = [
>('a', models.IntegerField()),
>('b', models.CharField(max_length=30)
> ], primary_key=True)
>
> This method for defining composite fields has a few drawbacks, but can be
> useful if the only reason to add the composite field to the model was to
> implement a unique_together or index_together constraint *
>
> * Although it's still possible to do that directly on class Meta.
>
> 3. Null
>
> Setting the value of a multi-column field to NULL is different than
> setting any of the individual subfields to NULL. But there are cases (e.g.
> Money) where we would like to be able to set `null=True` on a composite
> field, but still retain 'NOT NULL' constraints on each of the subfield
> columns.
>
> To solve this problem, every table which implements a CompositeField will
> also add an implicit (semi-hidden) `isnull` subfield on the attribute,
> which keeps track of whether it is the value of the composite field that is
> null, or any of the particular subfields.
>
> 3. Querying.
>
> The syntax for querying over the subfields of a composite field will be
> familiar to anyone who has queried over a relationship attribute in django.
>
> model.objects.filter(price__currency_code='USD',
> price__amount__lt=Decimal('50.00')).all()
>
> In addition, composite fields can be queried via EXACT and IN lookups. It
> is possible to implement custom lookups for specific statically defined
> fields, but not recommended and not part of the official API.
>
> 4. Restrictions
>
> The following restrictions are currently imposed on the use of composite
> fields. None of these are restrictions that can't be worked around in
> future extensions, but they're restrictions which considerably simplify
> both the implementation and API.
>
> - No related fields as a subfield of a composite

Re: A general way to batch SQL queries in Django

[Michael Manfre]

Stored procedures, at least with MSSQL, provide another way of returning
multiple result sets with a single SQL statement. The queries will be
parsed and executed faster due to stored procedures being parsed and
compiled when created, instead of when executed. A stored procedure will
also allow you to get more complex results with a few simple queries,
instead of a single complex query.

Using stored procedures adds complexity to a Django project and should be
used sparingly. From my personal experience, the extra server resources to
have more instances running to service requests is usually better than
having the extra complexity of using stored procedures in a Django project.

Regards,
Michael Manfre

On Fri, Feb 27, 2015 at 2:46 PM, Tom Evans <tevans...@googlemail.com> wrote:

> On Fri, Feb 27, 2015 at 3:19 PM, aRkadeFR <cont...@arkade.info> wrote:
> > What do you mean by a single roundtrip?
>
> He means asking the database server to consider multiple queries
> (concurrently?), and return data once all of them are available. In
> pseudo code:
>
> people, jobs, cities = DB.fetch_multi(
> Person.objects.all(),
> Job.objects.all(),
> City.objects.all())
>
> MySQL's C API supports executing multiple SQL statements in a single
> round trip, the data sets are made available in turn to the client API
>
> http://dev.mysql.com/doc/refman/5.7/en/c-api-multiple-queries.html
>
> however, each statement is executed in turn, not concurrently, so the
> only speed up you would have is that there is only one query to parse,
> and a few small packets less sent to the database server... The
> database connection is not torn down between requests to the database.
>
> The only way I could see it having any non-marginal effect is if you
> have high latency to your database server. But then you have a lot of
> problems.
>
> Cheers
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFHbX1%2BMgfwHL%3DL8hjgRMyf%2B2-Rap9L01PF9cxERFqU6c8uHdA%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/CAGdCwBuxXXSTrB68YFQ503RAfxH1z_BBxpytLk-75gwuGs3-zw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding missing aggregate functions to contrib.postgres ?

[Michael Manfre]

It's reasonable to support backend specific aggregate functions. The
database backend API contains
BaseDatabaseOperations.check_expression_support for this exact reason. Feel
free to create the ticket.

Regards,
Michael Manfre

On Sat, Feb 7, 2015 at 9:00 AM, Andriy Sokolovskiy (coldmind) <
sokand...@yandex.ru> wrote:

> So, since django has contrib.postgres, maybe it would be reasonable to add
> postgres-specific aggregate functions to this module?
> If it is good idea, I'm gonna create ticket and implement this.
>
> --
> 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/2d3b2bd2-3bce-4e40-8383-ef5ca328bc26%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/2d3b2bd2-3bce-4e40-8383-ef5ca328bc26%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Making the test suite run faster

[Michael Manfre]

Anything to make the test suite faster is a worthwhile effort. The speed up
will be even better for those of us with slower dev systems. Getting the
speed boost for in memory sqlite is a good start and Django is much more
than an ORM. It'll take work to improve the database isolation for the test
suite, but that is something that should probably happen regardless of
parallelization.

I'm imagining database backends being able to control whether or not they
support parallelization and if each process needs its own database.

Regards,
Michael Manfre

On Fri, Feb 6, 2015 at 11:05 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> As the test suite is growing, it’s getting slower. I’ve tried to make it
> faster by running tests in parallel.
>
> The current state of my experiment is here:
> https://github.com/django/django/pull/4063
>
> I’m distributing the tests to workers with the multiprocessing module.
> While the idea is simple, the unittest APIs make its implementation painful.
>
> ** Results **
>
> Without the patch:
>
> Ran 9016 tests in 350.610s
> ./runtests.py  355,86s user 20,48s system 92% cpu 6:48,23 total
>
> With the patch
>
> Ran 9016 tests in 125.778s
> ./runtests.py --parallel  512,31s user 29,92s system 300% cpu 3:00,73 total
>
> Since it takes almost one minute to create databases, parallelization
> makes the execution of tests go from 6 minutes to 2 minutes.
>
> This isn’t bad, but the x3 speedup is a bit disappointing given that I
> have 4 physical / 8 logical cores. Perhaps the IPC is expensive.
>
> Does anyone have insights about scaling with multiprocessing?
>
> ** Limitations **
>
> This technique works well with in-memory SQLite databases. Each process
> gets its own copy of the database in its memory space.
>
> It fails with on-disk SQLite databases. SQLite can’t cope with this level
> of concurrency. It timeouts while attempting to lock the database.
>
> It fails with PostgreSQL (and, I assume, other databases) because tests
> collide, for instance when they attempt to load the same fixture.
>
> ** Next steps **
>
> At this point, the patch improves the common use case of running
> `./runtests.py` locally to check a database-independent change, and little
> else.
>
> Do you think it would be useful to include it in Django anyway? Do you
> have concerns about the implementation? Charitably, I’ll say that “it
> works”…
>
> Releasing it separately as a custom test runner may be more appropriate.
>
> What do you think?
>
> --
> 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/639C2955-7AAB-4BC6-940D-EA69F7F51280%40polytechnique.org
> <https://groups.google.com/d/msgid/django-developers/639C2955-7AAB-4BC6-940D-EA69F7F51280%40polytechnique.org?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Settings: lists or tuples?

[Michael Manfre]

The situation you described was definitely a learning experience for your
company. Your strong opinion in favor of tuples is also noted.

For the various reasons stated in this thread, I'm still +1 for lists.

Regards,
Michael Manfre

On Mon, Jan 19, 2015 at 3:13 PM, Andreas Kahnert <kahn...@cruise-systems.com
> wrote:

> I advertise that strongly against lists, because we actually had that kind
> of issue in our company.
> One colleague created a list with phrases for some verbose logging in the
> settings.py. In the view function he promoted this list together with the
> actual data, also a list which is used for storing the data afterwards, to
> another function. The other function was implemented by another colleague,
> he was aware that he should not modify the second list for not corrupting
> the data to be safed. So he appended the data components to the first list
> zipped it to an dict and called the logging function. The result was that
> every log entry contained all data from previous calls and the server loked
> down very quick. It took them a day to debug this.
>
> --
> 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/64cb1e61-8eb2-4459-ac77-6fa1c3837c98%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/64cb1e61-8eb2-4459-ac77-6fa1c3837c98%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: documenting changes to the database backend API

[Michael Manfre]

For completeness, I'm Michael Manfre and have been the maintainer of
Django-mssql [1] for the last 6+ years. Future releases of Django-mssql
will officially support a single version of Django. Support for legacy
versions of Django will be maintained if it requires little effort.

Work on Django 1.8 support has started and I'll update the release notes as
I encounter issues.

Regards,
Michael

[1] https://bitbucket.org/Manfre/django-mssql/
On Jan 9, 2015 12:00 PM, "Tim Graham" <timogra...@gmail.com> wrote:

> To authors of third-party database backends,
>
> We'd like to start documenting changes to the database backend API [1],
> but we need some help with this.
>
> First, please introduce yourself and which backend you maintain so we know
> of your existence.
>
> Second, we'd like to know if you attempt to support multiple versions of
> Django in a particular release of your backend? This will help us to decide
> whether or not try to document the changes in a backwards and forwards
> compatible way.
>
> Third, could you try updating your backend to 1.8 and let us know what
> problems you run into so we know what documentation to add?
>
> The section of the release notes that will be expanded with details is:
> https://docs.djangoproject.com/en/dev/releases/1.8/#database-backend-api
>
> Thank-you!
>
> [1] https://code.djangoproject.com/ticket/24106
>
> --
> 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/a9c2aefc-f6f0-46db-804a-3608d033017c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/a9c2aefc-f6f0-46db-804a-3608d033017c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Multiple template engines for Django - week 13

[Michael Manfre]

+1 to delaying the freeze to get this feature fully in place, especially
since 1.8 will be an LTS release. Is there precedent to doing a freeze with
an exemption for an in progress feature? If so, that is another option to
an outright extension.

Regards,
Michael Manfre

On Sat, Jan 3, 2015 at 8:44 PM, Jeremy Dunck <jdu...@gmail.com> wrote:

> If getting proper support for other template backends would only delay the
> 1.8 release timeline by a couple weeks, I think that is preferable to a
> generalized 1.8 backend which only include DTL until 1.9.
>
> What do others think?
>
>
> On Sat, Jan 3, 2015 at 3:23 PM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello,
>>
>> Here’s the thirteenth update (good thing I learnt all these ordinals when
>> I was a kid!)
>> https://myks.org/fr/multiple-template-engines-for-django/#2015-01-04
>>
>> At this point my main concern is the 1.8 feature freeze scheduled in one
>> week.
>> Dealing properly with some of the items I listed in my report for week 11
>> may
>> require changes falling in the "new features” bucket and therefore being
>> postponed to Django 1.9. At worst, I’ll have to document that some
>> features
>> only work with the Django template language in Django 1.8. That’s sad but
>> not
>> worth delaying the entire project until early 2016.
>>
>> --
>> Aymeric.
>>
>>
>>
>> > On 27 déc. 2014, at 23:59, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >
>> > Hello,
>> >
>> > My twelfth update is online:
>> > https://myks.org/en/multiple-template-engines-for-django/#2014-12-28
>> >
>> > It comes with a question — should I drop `select_template` from the
>> backend API? I think I should. Follow the link above for details.
>> >
>> > Looking forward to your feedback,
>> >
>> > --
>> > Aymeric.
>> >
>> >
>> >
>> >> On 20 déc. 2014, at 23:57, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I haven’t written to this mailing-list for three weeks because nothing
>> warranted your immediate attention.
>> >>
>> >> Now the code is in reasonably good shape. Feel free to have a look:
>> >> https://github.com/aaugustin/django/commits/multiple-template-engines
>> >>
>> >> I plan to merge this branch within a few days.
>> >>
>> >> Updates for weeks 9 to 11 are available at the usual location:
>> >> https://github.com/aaugustin/django/commits/multiple-template-engines
>> >>
>> >> --
>> >> Aymeric.
>> >>
>> >>
>> >>
>> >>> On 30 nov. 2014, at 10:37, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> Here’s my eight update — this is getting repetitive :-)
>> >>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-30
>> >>>
>> >>> --
>> >>> Aymeric.
>> >>>
>> >>>
>> >>>
>> >>>> On 23 nov. 2014, at 00:02, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >>>>
>> >>>> Hello,
>> >>>>
>> >>>> I published my seventh update:
>> >>>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-23
>> >>>>
>> >>>> I have another pull request ready for review:
>> >>>> https://github.com/django/django/pull/3605
>> >>>>
>> >>>> Let me know if you have any questions!
>> >>>>
>> >>>> --
>> >>>> Aymeric.
>> >>>>
>> >>>>
>> >>>>
>> >>>>> On 16 nov. 2014, at 09:19, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >>>>>
>> >>>>> Hello,
>> >>>>>
>> >>>>> Here’s my sixth update:
>> >>>>>
>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-16
>> >>>>>
>> >>>>> I have a first pull request ready for review:
>> >>>>> https://github.com/django/django/pull/3555
>> >>>>>
>> >>>&g

Re: Multiple template engines for Django - week 12

[Michael Manfre]

Thanks for the explanation. It makes sense to remove select_template.

Regards,
Michael Manfre

On Sun, Dec 28, 2014 at 3:53 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hi Michael,
>
> > On 28 déc. 2014, at 07:12, Michael Manfre <mman...@gmail.com> wrote:
> >
> > If I'm understanding your post correctly, any potential performance
> improvement that a special cased select_template would have would likely be
> negated by caching.
>
> Sorry, I didn’t explain sufficiently clearly. My reasoning was:
>
> 1) Is there any situation where I can call a backend's select_template?
> Yes, when only one template engine is configured.
> 2) Does this have any advantages? Unclear, it may allow some performance
> optimizations at the backend level but that's completely theoretical.
> 3) Does that make it worth keeping select_template? Probably not.
>
> > Have you observed, or do you expect to see any significant performance
> hits to the test suite, which doesn't cache as intensely as live sites?
>
> No, I don’t expect to see a measurable impact on the test suite’s run
> time, because the current code and the new code will do roughly the same
> amont of work and neither optimizes anything.
>
> --
> 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/05BAC9A8-41C3-4FD8-88F2-531E933C517C%40polytechnique.org
> .
> 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/CAGdCwBtv7jkA-y-c3OcCs-hUbRfwi9y66v_JpHSbEFxCeY-1Ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 12

[Michael Manfre]

If I'm understanding your post correctly, any potential performance
improvement that a special cased select_template would have would likely be
negated by caching. Have you observed, or do you expect to see any
significant performance hits to the test suite, which doesn't cache as
intensely as live sites?

Regards,
Michael Manfre

On Sat, Dec 27, 2014 at 5:59 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> My twelfth update is online:
> https://myks.org/en/multiple-template-engines-for-django/#2014-12-28
>
> It comes with a question — should I drop `select_template` from the
> backend API? I think I should. Follow the link above for details.
>
> Looking forward to your feedback,
>
> --
> 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/CAGdCwBsUd4B%3D7NkKh6oEaaqwFNvCCcupRsOMFcEfRfMoUsH0vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Michael Manfre]

+1 for lists.

On Wed, Dec 17, 2014 at 3:54 PM, Carl Meyer  wrote:
>
> On 12/17/2014 01:48 PM, Aymeric Augustin wrote:
> > I’m about to introduce a new setting that is a sequence of things,
> TEMPLATES, and I have to decide whether it will be a tuple of a list.
> >
> > Unfortunately Django is very inconsistent in the type of settings. In
> global_settings.py:
> >
> > - 22 settings are tuples
> >   - 10 are empty, 12 aren't
> >   - 12 are referred to as “lists” in code comments, 1 as “tuple”
> > - 6 settings are lists
> >   - all of them are empty
> >
> > Even the tutorial is inconsistent. The first two settings described are:
> >
> > - INSTALLED_APPS: example is a tuple
> > - TEMPLATE_DIRS: example is a list
> >
> > It would be nice to standardize on tuples or lists — at least for new
> code if it’s undesirable to change the existing code.
> >
> > This is purely a matter of consistency and aesthetics. Using a tuple or
> a list never makes any difference in the code.
> >
> > While lists are less common than tuples currently, I prefer them for two
> reasons:
> >
> > 1) All these settings are sequences of similar things. Such values are
> best represented with lists, unless they have to be immutable, in which
> case a tuple can be used. (tuples are both “namedtuples without names” and
> “immutable lists” in Python.)
> >
> > 2) Lists aren’t prone to the “missing comma in single-item tuple”
> problem which bites beginners and experienced pythonistas alike. Django
> even has code to defend against this mistake for a handful of settings.
> Search for “tuple_settings” in the source.
>
> I agree with your preference for lists, for the same two reasons.
>
> > Surprisingly, it seems that there isn’t a backwards compatibility
> problem with changing the type to lists, as the following pattern still
> works:
> >
> > # myproject/settings.py
> > from django.conf.global_settings import FILE_UPLOAD_HANDLERS
> > FILE_UPLOAD_HANDLERS += ('myproject.uploadhandler.FooBarUploadHandler',)
> >
> > Proof:
> >
>  foo = ['abc']
>  foo += ('def',)
>  foo
> > ['abc', ‘def’]
> >
> > I can’t think of another circumstance it which the type of the default
> value will make a difference.
> >
> > So… can we normalize the code and satisfy my OCD? Or should I just stop
> caring and move on? ;-)
>
> Unfortunately `__iadd__` and `__add__` do not have the same behavior here:
>
> >>> foo = ['abc']
> >>> foo = foo + ('def',)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: can only concatenate list (not "tuple") to list
>
> So I think there is a backwards-compatibility issue.
>
> Personally, I would love to decide to just bite this bullet and
> normalize to lists, but I think it would need to be marked as a
> backwards-incompatibility in the release notes, and it would certainly
> bite people.
>
> 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/5491ED93.2080506%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Feature request: delegate more password related operations to auth backends (#23896)

[Michael Manfre]

I've used third party authentication backends, but your request seems a bit
odd to me. I think I'm being caught up on the some of the specifics without
enough context. Why can you not use a custom User that stores the backend
that created it (or last used for authentication) and overrides
set_password to delegate the password saving to the referenced
authentication backend? You would need to also create your own subclass of
ModelBackend that does the original User.set_password behavior. The only
scenario that I can think of where your implementation would get a bit more
complicated is if you wanted to support multiple active sessions using
different authentication backends for the same user object.

Regards,
Michael Manfre

On Sat, Dec 13, 2014 at 4:28 AM, Roman Akopov <ado...@gmail.com> wrote:
>
> Tim,
>
> It's not about the benefit, it's about the possibility. The one simply
> cannot use two external backends with support of password change because
> each backend will have to provide own User model. I understand your point,
> and I agree that some logic I suggest seems controversial, but current
> implementation of plugable authentication backends is technically incomplete,
> because password cannot be changed or reset, and ideologically broken,
> because full functionality cannot be correctly added even with a lot of
> code. Actually whole contrib.auth should be replaced to allow pluggable
> authentication backends to provide password change or password reset
> independently.
>
> Also, if you think it is good idea to force old behavior even if backend
> supports extended functionality, what stops us from introducing two boolean
> settings AUTHENTICATION_BACKEND_DELEGATE_PASSWORD_CHANGE and
> AUTHENTICATION_BACKEND_DELEGATE_PASSWORD_RESET which will be False by
> default? This will force old behavior while allowing to use extended
> backends if required.
>
> I want it to be clear, I'm not asking for specific functionality, I'm
> asking for extensibility. External authentication is complex subject by
> itself and fighting with incomplete Django extensibility interface does not
> make it simpler, but better extensibility interface does.
>
> Maybe, it will be wiser to discuss this feature request with people
> actually using external authentication, not core developers, to let them
> share their experience and maybe suggest better ways to implement this from
> the users/app developers point of view. Maybe this feature is desired one,
> but I'm just first who asked or maybe nobody actually needs it and I;m just
> Django-pervert. I can talk about my end users only, and about theirs user
> experience, you have no externally authenticated users at all. If we've
> done with technical side, I mean it seems clear what should be changed at
> source code level, and if only specific behavior logic is to be discussed,
> maybe it is better to discuss this non-core developer question with wider
> audience. What do you think?
>
>
>
> On Saturday, December 13, 2014 3:19:26 AM UTC+4, Tim Graham wrote:
>>
>> I haven't used external authentication backends for any projects, but I
>> still think the concept of dynamically changing how the password change
>> form/views work based on which backend you authenticated with is too much
>> complexity. This scheme feels very brittle and I'm not sure that making
>> this change in Django offers much benefit (in reduced code, for example) in
>> the end.
>>
>> On Thursday, December 11, 2014 2:05:22 PM UTC-5, Roman Akopov wrote:
>>>
>>> I've researched a little more, and looks like there is
>>> BACKEND_SESSION_KEY so it is possible to annotate user with backend on
>>> subsequent requests.
>>> https://github.com/django/django/blob/master/django/
>>> contrib/auth/__init__.py#L169
>>> Look like it should be a one line fix for this like
>>> user.backend = backend
>>> I think this will not break any existing code.
>>>
>>> At non-request situations for non-authenticated User model, i.e.
>>> instantiated from database, or just created and saved, we can simply
>>> fallback to old behavior. Actually, I think this is correct, because a user
>>> can have valid credentials in various backends simultaneously. Imagine we
>>> have three backends: Model, LDAP, SMTP. So if you authenticate with
>>> credentials valid for SMTP backend, you can't change password because SMTP
>>> does not support this at all. It should be something like methods throwing
>>> NotImplementedError. If you authenticate with credentials valid for LDAP
>>> backend you can change password and that change will be performed against
>>> LDAP. If you authenticate with credent

Re: Optional schemes in URLValidator causes backward incompatible changes

[Michael Manfre]

Please open a ticket for this.

On Fri, Dec 12, 2014 at 9:11 AM, Bruno Ribeiro da Silva <
bruno.dev...@gmail.com> wrote:

> Hey everyone,
>
> I just found out that the new schemes option of URLValidator causes
> incompatible changes for people who were using custom regex to restrict
> schemes. Could somebody put a note in Django 1.7 backward incompatible
> changes documentation? Should I open a ticket for this?
>
> Thanks!
>
> --
> Bruno Ribeiro da Silva
> Python Dev and Homebrewer!
>
> --
> 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/CAE-2%3DJyajyKdvJ6-0oK%3D7NTt4fkpcOkFU8U9r9B8dQO9ob%3D7KA%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/CAGdCwBvt3VKvpkkGYKwWJZO%3D_4irF4LuJV3Th5G_vBFiNJcFOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimental APIs DEP

[Michael Manfre]

On Sun, Dec 7, 2014 at 6:37 PM, Russell Keith-Magee <russ...@keith-magee.com
> wrote:

>  * The corollary of this last point is that the release *before* a stable
> release can't have any experimental/provisional features.
>

 Does this mean that there should be no experimental/provisional features
in an LTS?

Regards,
Michael Manfre

-- 
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/CAGdCwButvr%2B6Fzj6-h4_U_p-RX_b4E%2BAjWeHTH-mUkqRvZ%3DBow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: uuid field short websafe representation

[Michael Manfre]

A non-standard, compressed unique value is not a UUID. Also, this forces
database backends to store the value in a string datatype and doesn't allow
taking advantage of uuid specific datatypes. E.g. Postgresql couldn't use
its uuid datatype. Any data can be made safe for any specific usage, e.g.
URLs, but there is no reason to enforce this requirement in all uses of the
data because not everyone will expose a UUID in a URL.

-1 from me.

Regards,
Michael Manfre

On Sat, Dec 6, 2014 at 11:31 AM, Radek Svarz <radek.sv...@gmail.com> wrote:

> Hi, I am glad to see the UUID field coming to 1.8
>
> Bellow is how we do it now in 1.7.
>
> The advantages:
>
>  - it only uses 21 chars (instead of 32)
>
>  - chars are safe for URLs
>
>  - uuid is created when default is called
>
> I advocate to have the short websafe representation. What do you think?
>
> code:
>
>> def safe_uuid():
>> return uuid.uuid4().bytes.encode('base64').rstrip('=\n').replace('/',
>> '_')
>>
>
>
>> class UUIDField(CharField) :
>> """
>> UUIDField stored in 21 Chars
>> Example: uuid = UUIDField(primary_key=True, editable=False)
>> """
>> description = "UUIDField stored in 21 Chars"
>> def __init__(self, *args, **kwargs):
>> kwargs['max_length'] = kwargs.get('max_length', 22 )
>> kwargs['default'] = safe_uuid
>> CharField.__init__(self, *args, **kwargs)
>>
>> def deconstruct(self):
>> name, path, args, kwargs = super(UUIDField, self).deconstruct()
>> return name, path, args, kwargs
>
>
> Radek
>
>  --
> 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/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: delegating our static file serving

[Michael Manfre]

Requiring fewer moving parts for small sites is definitely an improvement.
+1 to Collin's plan.

Regards,
Michael Manfre

On Fri, Dec 5, 2014 at 2:02 AM, Loïc Bistuer <loic.bist...@gmail.com> wrote:

> I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of
> sense.
>
> --
> Loïc
>
> > On Dec 5, 2014, at 12:33 PM, Collin Anderson <cmawebs...@gmail.com>
> wrote:
> >
> > Hi All,
> >
> > I'm pretty interested in getting secure and _somewhat_ efficient static
> file serving in Django.
> >
> > Quick history:
> > 2005 - Jacob commits #428: a "static pages" view.  Note that this view
> should only be used for testing!"
> > 2010 - Jannis adds staticfiles. Serving via django is considered
> "grossly inefficient and probably insecure".
> > 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn.
> > 2012 - Aymeric adds StreamingHttpResponse and now files are read in
> chunks rather than reading the entire file into memory. (No longer grossly
> inefficient IMHO.)
> >
> > I propose:
> > - Deprecate the "show_indexes" parameter of static.serve() (unless
> people actually use it).
> > - Have people report security issues to secur...@djangoproject.com
> (like always)
> > - Audit the code and possibly add more security checks and tests.
> > - add wsgi.file_wrapper support to responses (5-line proof of concept:
> https://github.com/django/django/pull/3650 )
> > - support serving static files in production, but still recommend
> nginx/apache or a cdn for performance.
> > - make serving static files in production an opt-in, but put the view in
> project_template/project_name/urls.py
> >
> > I think it's a huge win for low-traffic sites or sites in the "just
> trying to deploy and get something live" phase. You can always optimize
> later by serving via nginx or cdn.
> > We already have the views, api, and logic around for finding and serving
> the correct files.
> > We can be just as efficient and secure as static/dj-static without
> needing to make people install and configure wsgi middleware to the
> application.
> > We could have staticfiles classes implement more complicated features
> like giving cache recommendations, and serving pre-gzipped files.
> >
> > Is this a good idea? I realize it's not totally thought through. I'm
> fine with waiting until 1.9 if needed.
> >
> > Collin
> >
> > On Saturday, November 29, 2014 6:07:05 PM UTC-5, Collin Anderson wrote:
> > Hi All,
> >
> > I think doing something here is really good idea. I'm happy with any of
> the solutions mentioned so far.
> >
> > My question is: what does static/dj-static do that our built-in code
> doesn't do? What makes it more secure? It seems to me we're only missing is
> wsgi.file_wrapper and maybe a few more security checks. Why don't we just
> make our own code secure and start supporting it?
> > Here's basic wsgi.file_wrapper support:
> https://github.com/django/django/pull/3650
> >
> > We could then, over time, start supporting more extensions ourselves:
> ranges, pre-gziped files, urls with never-changing content, etc. That way
> we get very, very deep django integration. It seems to me this is a piece
> that a web framework should be able to support itself.
> >
> > Collin
> >
> >
> > On Friday, November 28, 2014 9:15:03 AM UTC-5, Tim Graham wrote:
> > Berker has worked on integrating gunicorn with runserver so that we
> might be able to deprecate our own homegrown webserver. Windows support for
> gunicorn is supposedly coming soon which may actually make the idea
> feasible. This way we provide a more secure solution out of the box
> (anecdotes indicate that runserver is widely used in production despite our
> documentation warnings against doing so).
> >
> > On the pull request, Anssi had an idea to use dj-static to serve
> static/media files. My understanding is that we would basically integrate
> the code for dj-static into Django and then add a dependency on static. It
> could be an optional dependency since you might want to serve static files
> differently in production, but it would likely be more or less universally
> used in development. We could then say that django.views.static.serve (and
> its counterpart in staticfiles) is okay to use in production (and I guess
> people are already using them in production despite our warnings that they
> are not hardened for production use).
> >
> > What do you think of this plan?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Dj

Re: Configurable safety options for high performance Django systems

[Michael Manfre]

On Mon, Nov 24, 2014 at 3:32 PM, Christophe Pettus <x...@thebuild.com> wrote:

> In your particular case, where you have the relatively unusual situation
> that:
>
> 1. You have this problem, and,
> 2. You can't fix the code to solve this problem.
>
> ... you probably have the right answer is having a local patch for Django.
>

Alternatively, the same could be accomplished with a custom database
backend that enforces whatever limit value is desired. If I needed this
behavior, I'd probably tweak the query.low_mark and query.high_mark values
in SQLCompiler.as_sql before passing it along to the parent.

I think it's safe to say that this functionality is unlikely to find its
way in to Django, but if you have questions about the custom database
backend approach, feel free to contact me.

Regards,
Michael Manfre

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

Re: Configurable safety options for high performance Django systems

[Michael Manfre]

Django is a generic framework. Those who use it to implement functionality
are the ones who kill either the browser or their entire application.
Applications must be written to meet functional and performance
requirements of the project. When dealing with large tables, more effort is
certainly needed when using the Admin. E.g. write custom ModelAdmins or
admin filters that restrict the resultset size.

I don't think Django should automatically limit these queries.

Regards,
Michael Manfre

On Tue, Nov 18, 2014 at 7:58 AM, Rick van Hattem <wolp...@gmail.com> wrote:

> Hi guys,
>
> As it is right now Django has the tendency to kill either your browser (if
> you're lucky) or the entire application server when confronted with a large
> database. For example, the admin always does counts for pagination and a
> count over a table with many rows (say, in the order of 100M) can really
> stall your app and database servers.
>
> In the past I've simply patched Django to include a few "security"
> features for cases like these so someone can't accidently kill the site by
> doing something silly, but I was wondering if it would be a good idea to
> include some of these configurable options in the core.
>
> Examples:
>  - If COUNT_LIMIT is set than wrap counts in a subquery and limit the
> results: SELECT COUNT(*) FROM (SELECT pk FROM table LIMIT )
>  - When someone does "if queryset" automatically limit it to a default
> slice size so someone doesn't accidently fetch all rows in the queryset.
>
> ~wolph
>
> --
> 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/9ec3e5e6-0681-4e5b-bb8e-c450ce38c96a%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/9ec3e5e6-0681-4e5b-bb8e-c450ce38c96a%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Template render performance

[Michael Manfre]

Thanks to the work Aymeric recently started, Django will have more options
with regards to templating. See his DEP on Multiple Template Engines.
https://myks.org/en/multiple-template-engines-for-django/dep/

Regarding changing the Django Template Language syntax for the sake of
performance improvements, backwards incompatible changes are not likely to
happen. There is a huge cost involved with forcing everyone to update their
templates. Ideas on improvements that are backwards compatible would be
welcomed by many!

Regards,
Michael Manfre


On Mon, Nov 17, 2014 at 9:17 PM, <cristianocc...@gmail.com> wrote:

>  Hello,
>
> Mostly a question, but are there any work in progress to improve templates
> render performance? Times when having medium to big data and/or loops get
> excesively high, compared to jinja2 which sadly is not as easy to use as
> django native template language. I would really trade a feature or two in
> order to achieve better performance. For example, accessing variables from
> a dict, or even calling functions, all with the same syntax, I believe
> there's a huge overhead in there, and trading a xx.call for xx.call() is
> not such a big deal.
>
> What about a high performance option inside a template which trades
> flexibility for performance.
>
>   --
> 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/546aacd0.caa7340a.6c15.29a8%40mx.google.com
> <https://groups.google.com/d/msgid/django-developers/546aacd0.caa7340a.6c15.29a8%40mx.google.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Unicode SlugField design decision (#16501)

[Michael Manfre]

On Wed, Nov 5, 2014 at 7:53 PM, Shai Berger <s...@platonix.com> wrote:

> On Wednesday 05 November 2014 17:29:20 Michael Manfre wrote:
> > We can change the internal type of SlugField for option 1 based upon
> > whether or not the field should be unicode. Whether or not an existing
> > backend stores SlugField in an ascii char datatype shouldn't dictate
> > whether we go with SlugField(unicode=True) or UnicodeSlugField(). Let me
> > rephrase the question as, Do we want to provide backends enough
> information
> > so that they can decide to store an ascii slug field in an ascii char
> field
> > (e.g. varchar) and a unicode slug field in a unicode char field (e.g
> > nvarchar)?
> >
>
> Could you please clarify the question? As far as I understand, schema
> editors
> get all the information anyway.
>

Constructing the schema is only one part of the process. The main bit I am
concerned about is how the ORM will translate the data. There are several
methods on DatabaseOperatoins that exist to act based upon a field's
internal type string. E.g. get_db_converters, field_cast_sql.

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

Re: Unicode SlugField design decision (#16501)

[Michael Manfre]

We can change the internal type of SlugField for option 1 based upon
whether or not the field should be unicode. Whether or not an existing
backend stores SlugField in an ascii char datatype shouldn't dictate
whether we go with SlugField(unicode=True) or UnicodeSlugField(). Let me
rephrase the question as, Do we want to provide backends enough information
so that they can decide to store an ascii slug field in an ascii char field
(e.g. varchar) and a unicode slug field in a unicode char field (e.g
nvarchar)?

On Wed, Nov 5, 2014 at 7:15 AM, Marc Tamlyn <marc.tam...@gmail.com> wrote:

> It feels to me more like an option to SlugField and I feel
> UnicodeSlugField is a bit ugly. If however we find an example where
> Michael's point is valid (an external 3rd party backend which uses ascii
> chars for SlugField now) then we should go with that.
>
> On 5 November 2014 03:20, Michael Manfre <mman...@gmail.com> wrote:
>
>> Should the unicode validated field (either options) have a different
>> internal type for the sake of 3rd party database backends? I'm not sure if
>> any currently store SlugFIeld in an ascii char datatype and would need an
>> easy way to differentiate.
>>
>> Regards,
>> Michael Manfre
>>
>> On Tue, Nov 4, 2014 at 8:27 PM, Tim Graham <timogra...@gmail.com> wrote:
>>
>>> I wanted to solicit feedback on the two approaches to supporting unicode
>>> in SlugField:
>>>
>>> 1. Added a unicode argument to models.SlugField and forms.SlugField.
>>> https://github.com/django/django/pull/1979
>>>
>>> 2. Added models.UnicodeSlugField and forms.UnicodeSlugField.
>>> https://github.com/django/django/pull/1987
>>>
>>> The patch author says, "On one hand, I like the new field approach
>>> because it gives us an easier upgrade path. On the other hand, it feels
>>> like I'm polluting django.db.models and django.forms with slightly
>>> different versions of something that's already there."
>>>
>>> Approach 1 does seem cleaner to me, but I'd be interested in hearing
>>> from those interested in this feature.
>>>
>>> Ticket: https://code.djangoproject.com/ticket/16501
>>>
>>> --
>>> 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/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAGdCwBv%3DfGD-DpG4w9Bd3_9FkcKiw_CYqhR8tJK8W1EC_zvQNg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAGdCwBv%3DfGD-DpG4w9Bd3_9FkcKiw_CYqhR8tJK8W1EC_zvQNg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1H%2BCUXs%2B8_fQ_xiAMu%3DR%2BAxMNMmaTwaAEkavOmtAPcy8w%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMwjO1H%2BCUXs%2

Re: Unicode SlugField design decision (#16501)

[Michael Manfre]

Should the unicode validated field (either options) have a different
internal type for the sake of 3rd party database backends? I'm not sure if
any currently store SlugFIeld in an ascii char datatype and would need an
easy way to differentiate.

Regards,
Michael Manfre

On Tue, Nov 4, 2014 at 8:27 PM, Tim Graham <timogra...@gmail.com> wrote:

> I wanted to solicit feedback on the two approaches to supporting unicode
> in SlugField:
>
> 1. Added a unicode argument to models.SlugField and forms.SlugField.
> https://github.com/django/django/pull/1979
>
> 2. Added models.UnicodeSlugField and forms.UnicodeSlugField.
> https://github.com/django/django/pull/1987
>
> The patch author says, "On one hand, I like the new field approach because
> it gives us an easier upgrade path. On the other hand, it feels like I'm
> polluting django.db.models and django.forms with slightly different
> versions of something that's already there."
>
> Approach 1 does seem cleaner to me, but I'd be interested in hearing from
> those interested in this feature.
>
> Ticket: https://code.djangoproject.com/ticket/16501
>
> --
> 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/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Multiple template engines for Django - week 4 - DEP ready for review!

[Michael Manfre]

Overall the DEP looks really good.

It's currently assumed that BaseEngine.select_template() will scan the list
in order and return the first one it can load, but it might make sense to
explicitly state that in the DEP.

To avoid having 3rd party template engines suffering some of the same
disparity that 3rd party database backends faced, what are your thoughts on
having the jinga2 engine maintained outside of core? This would leave only
the string template reference implementation and the DTL in the core.

Regards,
Michael Manfre

On Sat, Nov 1, 2014 at 6:30 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I’m happy to annonce that the DEP is ready for public review!
>
> Direct link, HTML:
> https://myks.org/en/multiple-template-engines-for-django/dep/
>
> Direct link, ReStructured Text:
>
> https://raw.githubusercontent.com/aaugustin/mtefd/master/multiple-template-engines.rst
>
> (I’m not reproducing it here because I don’t think email is a very good
> medium for communicating 50kB of markup.)
>
> I’ve written a bit more about what “ready” means:
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-01
>
> Of course, your regularly scheduled update will also be available (in half
> an hour):
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-02
>
> I’m looking forward to your feedback!
>
> --
> Aymeric.
>
>
>
> > On 26 oct. 2014, at 22:36, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >
> > Hello,
> >
> > I just published the third update:
> > https://myks.org/en/multiple-template-engines-for-django/#2014-10-26
> >
> > --
> > Aymeric.
> >
> >
> >
> >> On 19 oct. 2014, at 00:09, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >>
> >> Hello,
> >>
> >> Here’s the second update:
> >> https://myks.org/en/multiple-template-engines-for-django/#2014-10-19
> >>
> >> Best,
> >>
> >> --
> >> Aymeric.
> >>
> >>
> >>
> >> On 12 oct. 2014, at 20:31, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >>
> >>> Hello,
> >>>
> >>> I just posted the first update on this project:
> >>> https://myks.org/en/multiple-template-engines-for-django/#2014-10-12
> >>>
> >>> My work in progress on the DEP is available here:
> >>> https://myks.org/en/multiple-template-engines-for-django/dep/
> >>>
> >>> Feedback is welcome, especially on sections I’ve described as “done”
> in the update.
> >>>
> >>> Thanks,
> >>>
> >>> --
> >>> 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/AF442429-4EFF-4C78-804F-F47ADF453245%40polytechnique.org
> .
> 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/CAGdCwBtp52jVbtdi13hwSG%3D90A%3DjWdj6UVzKVXhoKCHF3%2BKkXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: cursor.callproc()

[Michael Manfre]

On Wed, Oct 22, 2014 at 12:35 PM, Carl Meyer <c...@oddbird.net> wrote:

> Here is where we differ. I think calling a database stored procedure is
> fundamentally a different thing from calling a Python function (even one
> that accesses the database), and the difference should be obvious in the
> calling code. I don't think it is good API design to abstract away
> differences that the caller should be aware of. (For one example of a
> difference, database stored procedures "return a modified copy of the
> input arguments", which would be extremely unusual behavior for a normal
> Python function.)
>
> I think this is mostly a question of level. In an actual Django app that
> uses stored procedures, I think it is quite likely a good idea for the
> author of the app to provide a nice Python API that abstracts away the
> internal implementation. But I think this API should be consciously
> designed for-purpose (for example, it should likely return something
> other than a possibly-modified copy of all its input arguments), and at
> the level of Django core the benefits of a generic API that attempts to
> mask the difference between Python functions and database stored
> procedures are not enough to justify the magic required.
>
> Perhaps I'm wrong - but I'd definitely want to see the utility of such a
> generic "magic" layer proved as an external library before it gets added
> to core.
>

As someone who has used a very large number of stored procedures with
Django, I am a solid -1 on adding a generic "magic" layer to Django. Stored
procedures are purpose built. Their python usage should also be purpose
built to match the various combinations of input/output parameters, return
values, and result sets that are possible for a stored procedure.

Regards,
Michael Manfre

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

Re: Setting dictionaries (was Re: integrating django-secure)

[Michael Manfre]

On Thu, Sep 4, 2014 at 7:36 PM, Collin Anderson <cmawebs...@gmail.com>
wrote:

> I'm trying to think outside the box on settings.
>
> If we want to logically group settings together, what if we supported
> syntax like this?
>
> MIDDLEWARE_CLASSES = (
> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
> SecurityMiddleware(content_type_nosniff=True, xss_filter=True),
> )
>
> It could be a more pythonic way for middleware to have their own settings.
>


This is likely to run afoul of circular imports. It would need to do
something like the following to provide init kwargs.

MIDDLEWARE_CLASSES = (
'django.middleware.clickjacking.XFrameOptionsMiddleware',
('django.middleware.security.SecurityMiddleware',
{'content_type_nosniff': True, 'xss_filter': True}),
)

Regards,
Michael Manfre

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

Re: integrating django-secure

[Michael Manfre]

On Sat, Aug 30, 2014 at 8:33 PM, Josh Smeaton <josh.smea...@gmail.com>
wrote:
>
> I think the problem becomes more pronounced when you want to override a
> single sub-setting between your different environments:
>
> # base.py
>
> SECURITY_MIDDLEWARE = {
> 'HSTS_SECONDS': 10,
> 'HSTS_INCLUDE_SUBDOMAINS': True,
> 'CONTENT_TYPE_NOSNIFF': True,
> 'BROWSER_XSS_FILTER': True,
> 'SSL_REDIRECT': False,
> 'SSL_HOST': 'prod.my.host.com',
> }
>
>
>
> #staging.py
>
> from base import *
>
>
>
> SECURITY_MIDDLEWARE = {
> 'SSL_HOST': 'staging.my.host.com',
> }
>
>
> Does staging now represent the merged dicts of base and staging, or the
> merged dicts of default and staging? I believe, with the merged dict
> implementation, it is the merge of staging and default. Now if all of the
> settings were their own setting rather than an entry in a dict, I'd just
> set the single setting I'd need to change, and be done with it.
>
> There are very little gains to using a dict, and I would argue it harms
> readability and the use of settings in general unless it's actually
> required.
>

Auto merging dicts is the wrong approach. Staging.py should contain exactly
what it appears to contain, SECURITY_MIDDLEWARE with a single key defined.
If some one needs to tweak one of the values, they should use dict's
update. This is the same behavior that is required for DATABASES and the
other existing dict settings.

SECURITY_MIDDLEWARE.update({
'SSL_HOST': 'staging.my.host.com',
})

Regards,
Michael Manfre

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

Re: integrating django-secure

[Michael Manfre]

On Thu, Aug 28, 2014 at 8:44 AM, Tim Graham  wrote:

> I've implemented the ability to register "deployment checks" by adding
> deploy=True to register: @register("tag_name", deploy=True). These checks
> are only run if you pass the --deploy flag to check. So in development you
> can run `manage.py check --deploy --settings=settings_prod` to check your
> production settings file. Running these checks automatically if DEBUG is
> False would likely give them better visibility, but I don't see an easy way
> of disabling them when testing if we did that.
>
> Regarding settings, would it be preferable to move them into a single
> dictionary setting called something like SECURITY_MIDDLEWARE_CONFIG?
>

Yes. It is much nicer having a collection of related settings in a dict.


>
> On Thursday, August 28, 2014 6:27:40 AM UTC-4, Tim Graham wrote:
>>
>> The settings for the SecurityMiddleware as they appear in django-secure
>> are:
>>
>> SECURE_HSTS_SECONDS=0
>> SECURE_HSTS_INCLUDE_SUBDOMAINS=False
>> SECURE_CONTENT_TYPE_NOSNIFF=False
>> SECURE_BROWSER_XSS_FILTER=False
>> SECURE_SSL_REDIRECT=False
>> SECURE_SSL_HOST=None
>> SECURE_REDIRECT_EXEMPT=[]
>>
>> Yo-Yo, would be helpful to say *why* you are -1 so we can take that into
>> consideration.
>>
>
-1 on having to subclass a middleware to define its settings. Doing that
seems like the wrong approach and prevents having settings consolidated in
a single place. This would make it more difficult to have different
settings for different environments. This would likely result in a snippet
that subclasses the middleware to look in settings.


>
>> On Thursday, August 28, 2014 2:45:07 AM UTC-4, Yo-Yo Ma wrote:
>>>
>>> +1 on basically adding the functionality of checksecure to the default
>>> validation.
>>>
>>> -1 to adding the middleware.
>>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5069271f-8a21-4fdd-921f-ee2baa11b45b%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" 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/CAGdCwBtC-eBxk0D1Wka5FKjaNg9_dxpWwsb6m84Er3Q%3D%2BfsdAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Michael Manfre]

AssertNumQueries is often a problem for 3rd party backends.
AssertMaxQueries would become the same and likely result in poorly written
tests because of the inherent slop factor in the arbitrarily chosen max
value.

I'm not opposed to Django adding this. I'm opposed to Django using it in
its own test suite.

Regards,
Michael Manfre


On Sun, Aug 17, 2014 at 2:52 AM, Roger Hunwicks <roger.hunwi...@gmail.com>
wrote:

> I'm doing some refactoring of a Django app and I want to make sure that I
> don't introduce any really poorly performing pages as a result of poor
> queries.
>
> I want to write a test that tries every registered URL and makes sure that
> none of them has an excessive number of queries.
>
> AssertNumQueries doesn't seem very helpful to me, because it requires you
> to know when you write the test exactly how many queries the function
> should require.
>
> I'd like to create an AssertMaxQueries that passes as long as the number
> of queries is less than or equal to the parameter provided to the context
> manager. You could also do this my adding a parameter to AssertNumQueries
> to tell it whether to test for equality or "less than or equal to": that
> would involve less duplicated code in testcases.py, but is possibly less
> discoverable for a test author.
>
> Would that be a useful contribution to Django proper, or should I just
> create it in my own tests/utils.py.
>
> Roger
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4d8d120a-8819-4a7d-977f-4acae670130f%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/4d8d120a-8819-4a7d-977f-4acae670130f%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: multiple django projects on same database schema

[Michael Manfre]

This mailing list is for the development of Django. Please direct questions
about how to use Django to the django-users mailing list.

Regards,
Michael Manfre
On Aug 7, 2014 12:06 PM, "Héctor Urbina" <hurbi...@gmail.com> wrote:

> Hello,
>
> I'm developing a django project for my office, a small project management
> system. I'm doing some tries to incorporate a third party document
> management system, namely mayan-edms, by making use of the same database,
> so that users maintain theirs credentials. Is that good practice?.
>
> Greetings,
> Héctor.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/11496ed6-b11c-4325-9729-fa79d36aa5b0%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/11496ed6-b11c-4325-9729-fa79d36aa5b0%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Requiring GitHub login for actions on Trac

[Michael Manfre]

On Wed, Aug 6, 2014 at 8:59 PM, Josh Smeaton  wrote:

> In that case, is it easy enough to support github oauth + the current trac
> auth concurrently? If a user chooses to go through the harder path, that's
> fine.
>
> I like the idea of using github oauth. Password managers usually have a
> miserable time supporting HTTP basic auth.
>

I've made many comments without logging in because LastPass doesn't seem to
work with basic auth and having to manually copy & paste credentials is too
much of a hassle to bother with.

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

Re: Problem migrating from South to Django migrations for Linux distributions

[Michael Manfre]

On Thu, Jul 24, 2014 at 4:44 PM, Joseph Curtin <4...@jbcurtin.io> wrote:
>
> My question now would be, can django migrations and south migrations
> co-exist and can I turn off django migrations?
>
No, migrations is a required feature of Django and cannot be turned off.
The best you could do is generate the SQL from the migrations and manually
apply to the database.

Regards,
Michael Manfre

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

Re: future of @skipIfCustomUser decorator? (#22993)

[Michael Manfre]

On Fri, Jul 11, 2014 at 8:07 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> @skipIfCustomUser may not have a use in Django's own test suite, but I can
> see it being useful for a while for projects that are migrating (slowly)
> away from the old test runner.
>

This is also used by 3rd party apps that support multiple versions of
Django with a single code base.

Regards,
Michael Manfre

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

Re: Removing formtools from contrib (and call for maintainers)

[Michael Manfre]

Python packaging is definitely a lot better than it was and starting to
move the contribs to their own repos and packages would be a good thing to
do.

Regards,
Michael Manfre


On Fri, Jul 11, 2014 at 8:15 PM, Josh Smeaton <josh.smea...@gmail.com>
wrote:

> I think the "blessed packages" idea is a good one - especially if it
> entails inclusion into the build/test system. At the moment it is very
> difficult to know if any changes that are made will affect third party
> libraries unless you have an extremely good grasp of an entire sub-system
> (ORM, I'm looking at you). On the other hand, should changes to core be
> prevented from landing if it breaks these blessed libraries using
> undocumented features?
>
> As for formtools, are there any proposals for features that would make
> breaking it away from core profitable? If it hasn't changed in the last 18
> months it certainly doesn't mean it will gain features just because it is
> extracted. Also, I know that I'm wary of using a third party library if it
> hasn't been updated in over a year but I'm more than happy to use a
> non-updated package in core.
>
> Josh
>
> On Saturday, 12 July 2014 09:25:48 UTC+10, Russell Keith-Magee wrote:
>
>>
>> On Fri, Jul 11, 2014 at 10:52 PM, Tim Graham <timog...@gmail.com> wrote:
>>
>>> continuing https://groups.google.com/d/topic/django-developers/
>>> km2xIHM-gIA/discussion under a better subject (was "FormWizard needs
>>> confirmation step logic. ticket #21644")...
>>>
>>> I'd like propose removing formtools from contrib.
>>>
>>> Reason to move it out:
>>> - Allow more maintainers next to Django core devs
>>> - Release individually from Django (perhaps more often) on PyPI as
>>> django-formtools
>>>
>>> Reasons something should be in contrib (from Marc Tamlyn):
>>>
>>> - The application is of vital importance to the vast majority of Django
>>> sites, and needs to be done "correctly". Examples include auth and
>>> staticfiles, sessions.
>>> - The application closely depends on internal, undocumented features of
>>> Django or is strongly intertwined with the core features like the ORM. Such
>>> applications are often very difficult to maintain their feature support
>>> across multiple versions of Django. Examples include gis, postgres,
>>> contenttypes.
>>>
>>> (Marc again): "To me, formtools meets neither of these requirements. It
>>> is not a 90%+ use case application like the admin or auth, and I don't
>>> believe there is much to it that is not workable outside of Django itself.
>>> It is useful, and does not deserve to be abandoned (like comments). Under
>>> github.com/django seems ideal to me."
>>>
>>
>> The definition that we used "back in the day" was "Contrib is a
>> collection of optional, defacto standard implementations of common
>> patterns."
>>
>>  * Optional - if we deleted the directory, Django would still work, and
>> you could build the deleted functionality yourself.
>>  * Defacto Standard - This is "the way you should do it". No point in
>> having multiple auth or session frameworks for 99% of users.
>>  * Common Patterns - Things that needs to be done, so lets give them an
>> obvious way to do it.
>>
>> By that definition, formtools falls is caught as a common pattern.
>> Wizards may not be needed on every website, but Wizard functionality is
>> definitely something I've had to build a bunch of times, and it's fiddly to
>> build it yourself. Having an "in the box" way to do wizards was helpful for
>> those cases.
>>
>> One of the major reasons to do this back in the day was because Python
>> packaging was such a mess, and the only way to make sure people had a good
>> out-of-the-box experience was to package all the bits they'd need. This is
>> no longer true. To that end, I'm fully in support of repackaging most of
>> contrib as separate modules, with their own release schedule, maintenance
>> teams, and so on.
>>
>> However, the other role that contrib plays is drawing attention to
>> specific packages as trusted sources of functionality. *This* is a role
>> that still exists, but it's one that I don't know we're doing a good job
>> with at the moment.
>>
>> I've suggested this before, but since we seem to be in a new round of
>> purging stuff from contrib, I'll suggest it again: should we be building a
>> repository of "trusted" packages?
>>
>> By this, I mean a c

Re: Building a library of SQL functions into Django

[Michael Manfre]

Monkey patching is not really an API hook. It's what non-core code is
forced to do when the core is not flexible enough to support what it needs.
If this is the chosen route, which is the way it appears to be heading,
then at least try to hide the fact that it's a monkey patch and mimic
SQLAlchemy [1] with a decorator, or some type of register method.

I'm on the fence about whether I'd even use a monkey patch mechanism,
instead of defining my own compile() for each of the SQLCompilers;
DatabaseOperations.compile_node(self, compiler, node) would be better than
overriding each compile. To me, it seems much more elegant to duck type the
nodes as they're being compiled, instead of a giant import and monkey patch
setup function.

Regards,
Michael Manfre

[1] http://docs.sqlalchemy.org/en/rel_0_9/core/compiler.html


On Tue, Jul 1, 2014 at 11:32 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>
wrote:

> On Tue, 2014-07-01 at 17:49 +0300, Shai Berger wrote:
>
> > I think we can reach very similar results, with a much nicer API, by
> letting
> > the backends just override the function classes.
>
> The backend specific class must be instantiated at query compile time.
> How is the data contained in the original class copied to the overriding
> class? One possibility is to copy the original instance's __dict__ to
> the overriding class.
>
> Also, "if the attribute has an attribute named like the function class"
> isn't good, clashes between plain class names is expected. The overrides
> could be a dictionary of original class -> overriding class. So,
> something like this:
>
> class BackendLower(models.Lower):
> def __init__(self, from_node):
> # The hacky way
> self.__dict__ = from_node.__dict__
>
> def as_sql(self, qn, connection):
> 
> overrides = {models.Lower: BackendLower}
>
> And compiler.compile() would look something like this:
>
> if node.__class__ in connection.overrides:
> return connection.overrides[node.__class__](node).as_sql(...)
> else:
> return node.as_sql(...)
>
> Using the above way there is no need to alter classes dynamically. On
> the other hand, copying data from the original class to the implementing
> class can be risky (circular dependencies for example), and it is a bit
> more expensive. Still, inheritance will not work like with as_vendor(),
> but I am not sure how common subclasses without custom as_sql() are.
>
>  - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1404228748.9408.189.camel%40TTY32
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Building a library of SQL functions into Django

[Michael Manfre]

On Fri, Jun 27, 2014 at 7:04 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>
wrote:

> This is possible to do by supplying a custom SQLCompiler class for the
> backend, and overriding its .compile() method.
>
> Personally I don't see usage of as_vendor() as that problematic. Supplying
> as_vendor in first DatabaseWrapper.__init__() should work. Yes, we are
> dynamically altering the node's class. But we are just using the __dict__
> of the node to store backend specific implementation instead of using a
> dictionary somewhere in the backend for the implementation. Using the
> __dict__ has the advantage that inheritance works automatically.
>
> As multiple core developers have said they don't like as_vendor() for 3rd
> party backend support it might be better to offer official hook for
> altering the generated SQL. That is, change the SQLCompiler.compile()
> method from
>
> def compile(self, node):
> vendor_impl = getattr(
> node, 'as_' + self.connection.vendor, None)
> if vendor_impl:
> return vendor_impl(self, self.connection)
> else:
> return node.as_sql(self, self.connection)
>
> to
>
> def compile(self, node):
> ret = self.connection.compile(node)
>

If this is going to be moved off SQLCompiler, I think DatabaseOperations is
a better place for it because we already have
DatabaseOperatoins.combine_expression. The compile method will need access
to the compiler to match the signature of as_sql (and it is necessary in
some cases to inspect the query).


> The main reason for offering a hook is that overriding SQLCompiler is a
> bit problematic. There exists various subclasses of SQLCompiler, and the
> backend needs to support those, too.
>

All of the subclasses are going to inherit SQLCompiler.compile and do the
same exact logic. I don't understand what problem is caused by overriding
compile that is solved by a function call to compile on some other class.

Regards,
Michael Manfre

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

Re: Changes to ORM expressions API

[Michael Manfre]

After spending a bit more time looking over the patch, I think the best and
most logical place for a database backend to hook in to the as_vendor
override is in SQLCompiler.compile, which is where Django checks the node
for the vendor specific override and then calls it.

Database backends are already required to use what is deemed internal API,
which includes SQLCompiler, so that is the most logical place for us to
make the changes we need. Projects and 3rd party apps would still use the
public API (either register or monkey patch). This also avoids the need to
try to make the public API work for two conflicting needs.

Regards,
Michael Manfre





On Wed, Jun 18, 2014 at 8:31 PM, Josh Smeaton <josh.smea...@gmail.com>
wrote:

> manfre has raised some issues about registering implementations in IRC. I
> had been assuming that AppConfigs could be used for backends to register
> their changes, but that would require users to modify their INSTALLED_APPS
> for that to work. Otherwise, backends never really get an opportunity to
> run start up code. That is obviously not a good approach to take.
>
> Perhaps we could implement a setup hook for each of the backends where
> startup code could be run. Maybe this could even be an implicit way of
> registering an AppConfig for the backend? I'm not familiar enough with
> AppLoading to know if an implicit AppConfig is a good idea or not - but I
> assume it probably isn't.
>
> As a concept though, would a setup hook be useful to backends? It would
> allow patching of aggregates and functions for this refactor, but would it
> find other uses?
>
> Josh
>
>
> On Wednesday, 18 June 2014 16:49:13 UTC+10, Anssi Kääriäinen wrote:
>>
>> This is a heads-up post about some planned changes to the ORM and
>> specifically to the expressions API. This affects how the following
>> features work inside the ORM:
>>   - F-expressions (and other ExpressionNode subclasses)
>>   - aggregates
>>   - anything using SQLEvaluator (django.db.models.sql.expressions)
>>
>> While the changes target private APIs, these APIs have remained stable
>> for a long time. I expect there to be significant amount of users of the
>> above APIs. The main concern is that the planned changes will break
>> existing code. I am looking for feedback from 3rd party library developers
>> - does the planned changes break existing code for you, and if yes, why? If
>> we find some common cases we might be able to add backwards compatibility
>> code paths for those cases.
>>
>> There are two main reasons for doing the changes. First, the change
>> allows for a lot of nice new features - doing conditional aggregates,
>> aggregates using expressions and writing custom expressions, all this using
>> public APIs. The second reason is that the current coding is somewhat
>> complex, and that complexity makes it hard to write custom aggregates or
>> expressions.
>>
>> Currently the expressions and aggregates are built up from two classes.
>> The first one is public facing API (for example Sum in
>> django.db.models.aggregates), the second is how the public facing API is
>> executed in the ORM (Sum in django.db.models.sql.aggregates). The idea
>> is that we have one public facing component users should use for different
>> queries. Then different Query implementations can have different
>> implementation classes. Thus the same public facing class can be executed
>> in different ways depending on the used Query class. Unfortunately this
>> leads to cases where it is hard to extend expressions or aggregates - while
>> it is easy to add a new public facing API class, it isn't easy to add an
>> implementation for that class - the implementation belongs to the used
>> Query class, but that class isn't under user control.
>>
>> In addition to the extensibility problem the current implementation is
>> somewhat complex to follow. Still, aggregation implementation doesn't share
>> code with expressions, but after all expressions are just a special kind of
>> expression.
>>
>> The new way is simplified - there is just public facing classes. The
>> classes know how to implement themselves. The new expressions know how to
>> add themselves to the query, and they know how to generate a query against
>> different database backends. Different database backends are handled with
>> as_vendorname() syntax. Aggregates are a subclass of certain kind of
>> expression (Func class), so aggregates use the same code paths as other
>> expressions. The end results is simplified code, ability to use Sum('foo')
>> + Sum('bar') style aggregations, and the ability to write new expressions
>> an

Re: 3rd-party database backends: Do you need a "can_introspect_null" feature flag?

[Michael Manfre]

On Tue, Jun 17, 2014 at 8:49 AM, Shai Berger <s...@platonix.com> wrote:

> > Should we eliminate all the `else:` clauses of tests controlled by `if
>  > connection.features.can_introspect_xxx:`? If the backend can't
> introspect
> > something properly, we don't care that much about what it introspects
> > instead.
>
> I think that is going too far in the other direction -- specifically, in
> the
> case of parameters. As a backend maintainer, if I couldn't introspect
> NullBooleanField, I think I'd still like to verify that I get a
> BooleanField.
> If I can't get the right length, I still want to know it's a CharField.
>
> In that spirit, Rahul (and Michael), I think we should just change the
> test to
> allow for either IntegerField or SmallIntegerField when not
> can_introspect_boolean_field.
>

That's not much better than just skipping the assertion for those
databases. My suggestion would be to allow a backend to provide its own
assertFieldType [1]. This would move all of the feature checking out of the
tests and allow a backend to inspect custom fields. We could probably get
rid of some of these introspect features too. I'm not sure whether it makes
more sense to put assertFieldType on DatabaseFeatures or
DatabaseIntrospection.

[1]
https://github.com/django/django/blob/master/tests/inspectdb/tests.py#L36

Regards,
Michael Manfre



>
> >
> > Backwards-compatibility concerns are minimal. I don't think it's a big
> deal
> > if the output of inspectdb changes accidentally for a core backend for a
> > field that isn't correctly inspected anyway.
>
> Right -- within the above, IMO.
>
> Shai.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/201406171549.08377.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Supporting and using EOL'd software (was Re: Time to drop support for Oracle < 11?)

[Michael Manfre]

I don't see how it should be up to Django to continue to support all of
these archaic versions of Oracle. To paraphrase the mantra repeated during
various mssql discussions, "Django doesn't need to include everything in
core, it just needs to make it possible for others to implement". If people
feel strongly about staying on a no longer supported version of Oracle,
then they can either stick with an older version of Django or create
django-decrepit-oracle.

Django should strip this legacy code.

Regards,
Michael Manfre

On Sat, Jun 14, 2014 at 10:01 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:

>
>
>
> On Sat, Jun 14, 2014 at 5:49 PM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>>
>> On Sun, Jun 15, 2014 at 7:51 AM, Shai Berger <s...@platonix.com> wrote:
>>
>>> Hi guys,
>>>
>>> TL;DR -- ...sorry, there's no TL;DR here. It's a bunch of separate
>>> ideas. It's
>>> a little lengthy. Please bear with me.
>>>
>>> I'd like to compare our support for old database servers with our support
>>> for old browsers. We only recently dropped code that supported IE 6/7 (!)
>>> for a security (!) fix, and even that decision wasn't taken trivially. I
>>> don't
>>> think suggestions that will break Django sites for IE8 users will be
>>> appreciated, unless there is a great benefit on the other side. And IE8,
>>> along with the OS which required it, are long EOL'd.
>>>
>>> I also don't subscribe to the position that it's irresponsible to claim
>>> support
>>> for EOL'd products; by the same token, the reponsible thing would be to
>>> include, by default, a middleware that sends warnings to users of old
>>> browsers. We don't do that, because we're all consenting adults here.
>>> And on that comparison, the old browser is arguably more of a risk than
>>> the old database server -- the db, most likely, is not directly
>>> accessible
>>> from the internet.
>>>
>>
>> There's another, more important difference, though. The database server
>> is under the direct control of the developer. If I'm a developer, I'm
>> actively choosing Django X, and I choose MyWonderDB 1.2.3. If I make a
>> decision to upgrade to Django Y, the fact that my database is no longer
>> supported is part of that decision - I either need to upgrade my database
>> as well, or I need to evaluate whether "not supported" means "will actually
>> break" or "might work, but we just aren't testing for it", and take the
>> risk (and the related testing responsibility) onto my own project.
>>
>> However, the website that I deploy is accessed by people whose software
>> isn't under my control. People are still using IE6. Never mind that it's
>> been EOLd; you'll pry their copy of Win95 out of their cold, dead hands.
>> This long tail is essentially endless - as a web framework, when we drop
>> support for a browser, we're talking about how much of this tail we're
>> willing to cut off. IE8 may well be EOL, but Microsoft adoption rates and
>> upgrade policies mean that there is still s substantial population using
>> it, especially in non-technical and non-English speaking demographics.
>>
>>
>
> I think an important consideration is "can a user work around it in their
> application", e.g. if we remove something from common middleware, they can
> add it into their own middleware easily enough, if we change the core HTTP
> processing pipeline, that's considerably more difficult for them, and such
> changes shouldn't be made lightly.
>
> Alex
>
>
>>  To address a specific suggestion:
>>>
>>> On Saturday 14 June 2014 18:08:41 Marc Tamlyn wrote:
>>> >
>>> > That's not to say we should actively break support for old databases if
>>> > they happen to work, but we should remove any conditional code we might
>>> > have regarding them and we should not consider them when adding new
>>> > features.
>>>
>>> "remove any conditional code regarding them" is exactly what I'd call
>>> "actively
>>> break support". What I want to do for "secondary support versions" is
>>> - keep conditionals regarding them
>>> - protect them from newer-version-only functionality (with no attempt to
>>>   add workarounds or client-side implementations)
>>> - accept community patches to fix problems, as long as they don't put too
>>>   much of a burden on the code.
>>>
>>> I'm +0 on dropping Oracle9 support com

Re: 3rd-party database backends: Do you need a "can_introspect_null" feature flag?

[Michael Manfre]

The feature was added by Aymeric for django-pymssql, which needs the
feature.

Regards,
Michael Manfre


On Thu, Jun 12, 2014 at 6:17 PM, Shai Berger <s...@platonix.com> wrote:

> Hi all,
>
> Bug #22816[1] is a test failure on Oracle. It was caused by the
> introduction
> of the "can_introspect_null" database-feature-flag, which was set to True
> for
> all core database backends except for Oracle; and use of that flag in the
> test
> of introspection of NullBooleanField. The easiest way to fix the tests is
> to
> simply revert the relevant commits -- as far as core backends are
> concerned,
> they only affect Oracle, and there, they break the tests for no good reason
> (details below, if you care).
>
> However, if there actually is some backend which has trouble introspecting
> nullability, then the flag could be useful, and should be kept. In that
> case,
> we'll fix its use with Oracle and the tests.
>
> So -- is there a backend which needs this flag, or can I just kill it?
>
> Details about Oracle:
>
> The test fails because, in fact, Oracle introspects NullBooleanField's
> perfectly well -- it only fails to introspect nullability correctly on
> CharField's; this is due to its interpretation of empty strings as nulls,
> which forces the backend to make all CharField's nullable. Thus, the commit
> message on the flag addition -- "Previously this was conflated with another
> Oracle-specific behavior" -- is actually wrong; the "conflation" is fully
> justified.
>
> Thanks,
> Shai.
>
> [1] https://code.djangoproject.com/ticket/22816
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/201406130117.32421.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Loading fixtures once for each TestCase to improve running time

[Michael Manfre]

That ticket seems to address issues with initial_data and not necessarily
deal with fixtures that are loaded for a specific TestCase. I do agree that
we should encourage people to not use fixtures and build their test data
within the scope of the test or the TestCase.

Regards,
Michael manfre


On Thu, Jun 12, 2014 at 9:17 AM, Schmitt, Christian <
c.schm...@briefdomain.de> wrote:

> Just a quick question regarding to these posts / tickets.
>
> In the last few weeks we fixed:
> https://code.djangoproject.com/ticket/22487
>
> So I think that we now don't need to rely on fixtures and should just tell
> the people to use that behavior in the first place.
> I mean I'm not a Django core developer, but since we fix our code for
> Django 1.7 our test suite runs faster since we dropped them out.
>
> Also we wrote somethings in the docs about that:
> Deprecated since version 1.7: If an application uses migrations, there is
> no automatic loading of fixtures. Since migrations will be required for
> applications in Django 2.0, this behavior is considered deprecated. If you
> want to load initial data for an app, consider doing it in a data
> migration
> <https://docs.djangoproject.com/en/dev/topics/migrations/#data-migrations>
> .
>
> The question about that is, what happens if you don't use migrations. Will
> fixtures still be loaded in Django 2.0 and upwards or not.
> If they will be loaded, we should fix this, but if not we should maybe
> clear that things up that the people SHOULD migrate away from fixtures to
> migrations.
>
> Quick Note: I think, currently the data migrations still uses the old
> technique, by serializing / deserialize on every test case, so maybe we
> should expand that logic somehow instead of putting work onto fixtures.
>
>
>
>
> 2014-06-11 16:37 GMT+02:00 Josh Smeaton <josh.smea...@gmail.com>:
>
> manfre was nice enough to test this patch out on mssql for me. The subset
>> of tests that use fixtures went from 385 seconds to 158 seconds (+2
>> failures). The improvement seems to be stable across backends, but isn't
>> very significant when considering the entire test suite.
>>
>> I'm going to abandon this patch and ticket myself - mainly due to the
>> sqlite threading issues. If someone else would like to run with it, I'll be
>> happy to share any information I have.
>>
>> - Josh
>>
>>
>> On Wednesday, 11 June 2014 09:34:14 UTC+10, Josh Smeaton wrote:
>>>
>>> I used the patch in the above ticket as a base, and implemented fixture
>>> loading in the setUpClass classmethod rather than the setUp method. I found
>>> that it improved the total running time of the entire test suite by about
>>> 10%, but it improved TestCases that use fixtures by a factor of 3.
>>>
>>> https://github.com/jarshwah/django/tree/testcase-optimization
>>>
>>> I'm unable to test this patch on Oracle or mssql though, which are known
>>> to be a lot slower than most of the other backends (for the test suite).
>>> The list of test modules that use fixtures are:
>>>
>>> admin_changelist admin_custom_urls admin_docs admin_inlines admin_views 
>>> admin_widgets aggregation aggregation_regress contenttypes_tests fixtures 
>>> fixtures_model_package generic_inline_admin known_related_objects 
>>> m2m_through_regress multiple_database proxy_models raw_query servers 
>>> syndication_tests test_client test_client_regress test_utils timezones
>>>
>>>
>>> If someone is able to test Oracle or mssql with that set of test modules 
>>> and report back the difference in time taken between master and the above 
>>> branch, that'd be extremely useful information.
>>>
>>>
>>> As for profiling the entire test suite:
>>>
>>>
>>>  vagrant@djangocore:~$ PYTHONPATH=/django 
>>> /home/vagrant/.virtualenvs/py2.7/bin/python
>>> -m cProfile -s cumulative /django/tests/runtests.py
>>>
>>> This shows that for psql, mysql (inno), and sqlite, the majority of
>>> (cumulative) time is spent inside the request/response phases of the test
>>> client, reversing urls, and rendering templates. I don't think the choice
>>> of backend would massively influence these tests (unless transactions
>>> themselves are especially slow per backend), so I'm betting that the
>>> loaddata/rollback operations are the primary pain points. See my output
>>> (with loaddata optimisations) here: https://gist.github.com/
>>> jarshwah/42c4cd1f54c8fb3dd273
>>>
>>> Unfortunately, this patch has introduced some bad threading issues 

Re: Support for function application in ORDER BY

[Michael Manfre]

On Mon, Jun 9, 2014 at 7:48 PM, Josh Smeaton <josh.smea...@gmail.com> wrote:

> - should expressions in order_by support random ordering (?) ? I don't
> think so, but I haven't ever had a need for random ordering so I'm not sure.
>

It should be possible to create an expression for order_by that essentially
does this, at least for simpler databases that support an ORDER BY RAND().
E.g. .order_by(Random())


> > I haven't yet implemented the LowerCase and related functions
>
> I think we can build out a handy little library of utility functions like
> Lower and Coalesce that could(should) be included directly in django. But
> it'll also open up, to library developers, the ability to easily develop
> backend specific structures, similar to parts of the
> django.contrib.postgres kickstarter.
>

Anything utility functions included in core need a way for 3rd party
backends to flag as not supported or be able to tweak the underlying SQL.
The most likely tweak would be renaming the function to match the specifics
of the database. I have to do this for some of the aggregation functions,
so it's safe to assume that some database might need to do the same for
order_by functions.

Regards,
Michael Manfre

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

Re: Support for function application in ORDER BY

[Michael Manfre]

Each expression must be able to define it's own ordering because order_by
allows you to define a sort based upon multiple expressions.


On Mon, Jun 9, 2014 at 4:00 PM, Daniel Moisset 
wrote:

> I see everyone trying to put the direction (ascending vs decending) inside
> the expression, while it's actually a property of the ordering clause.
> Wouldn't it make more sense and avoid ambiguities to do:
>
> qs.order_by(..., descending=True)
>
> ?
>
> Then you can add functions (and even a __neg__ operator to fields mapped
> to SQL unary minus) and still have a clear separation of functions vs order
> direction.
>
> D.
>
>
>
> On Mon, Jun 9, 2014 at 4:44 PM, Tim Martin  wrote:
>
>> My concern about the filter(foobar_lt=-F('baz')) issue is that it
>> violates the principle of least surprise: it will be accepted silently and
>> do something that nobody could expect unless they know a bit about the
>> internals. However, I think having some special case code in filter(),
>> annotate() and anything else that takes expressions would be OK. Provided
>> it throws some kind of exception, I think it resolves my concern.
>>
>> I'll go ahead and try to implement this using __neg__() to invert the
>> ordering.
>>
>> Tim
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/20cd8bd0-9d5d-4ed3-9748-1412188e6726%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" 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/CALuYSZVYnXHapfvf5SwPJxLYkxiv%3DTPyJg2XYGFVhCPSyc7Fgw%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" 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/CAGdCwBuHBtQLsVEeftfZAVrx6hdZSvz9ED%3DMmjZvyg%2B--%3D6moQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: feature request - use logging in WSGIRequestHandler

[Michael Manfre]

Today I learned that the devserver messages are supposed to be in color.

Having all output from Django controlled by logging would be a nice
improvement.

Regards,
Michael Manfre


On Wed, May 28, 2014 at 9:40 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Wed, May 28, 2014 at 3:35 AM, Martín Massera 
> <martinmass...@gmail.com>wrote:
>
>> Hi sometimes when you are developing you get so much output in the
>> console, especially when you have many medias on the page. It would be nice
>> to use the logging system to remove those messages, but right now stderr is
>> being used.
>>
>> Using the logging system for choosing whether we want to see this output
>> or not sounds like a natural solution, right?
>>
>>
>> http://stackoverflow.com/questions/23833642/django-how-to-filter-out-get-static-and-media-messages-with-logging/23845219
>>
>>
> Well, logging *could* be used for this, sure.
>
> However, there's a cost - we'd be adding the requirement for a logging
> configuration for something that is only ever used during development. So
> we'd end up complicating the process of deploying the devserver, which is
> one of those things that is supposed to Just Work™ out of the box.
>
> I *think* this would also mean losing the colorisation of devserver
> messages, and for me, colorisation of output of the devserver is a higher
> priority than the need to filter specific lines out of devserver output
> (don't quote me on this one though -- it might be possible to preserve
> colorisation. Some experimentation may be required).
>
> It's also a feature that can be achieved using pipes and grep, which would
> be more in line with the broader Unix philosophy.
>
> In summary: I don't personally see a particularly compelling case for this
> feature. However, the real test will be whether you can come up with an
> implementation that doesn't overly complicate the deployment of the
> devserver for the case that *most* users need it - a simple server that
> Just Works™.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq8482r1TJy9rv7xGimCz27mVqtkbC6M3u%2BUirWeVKQBA5kQ%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAJxq8482r1TJy9rv7xGimCz27mVqtkbC6M3u%2BUirWeVKQBA5kQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Master/slave trolling pull request accepted to django master branch

[Michael Manfre]

It was very clearly stated in the other email thread about this, by the no
longer offensively titled BDFL :P, that the rename will not be reverted.
It's nearly impossible to get a change in to core when there is a single
core dev opposed to it and there have been many core devs who are -1 on
reverting.

The battle has been lost. The only potential outcome from continuing to
press your argument is to anger core devs and flood inboxes of many people
who would never have seen those doc pages if it were not for these
controversial commits.

Regards,
Michael


On Tue, May 27, 2014 at 3:56 PM, bartek  wrote:

> On Tue, 27 May 2014 05:26:52 -0700 (PDT)
> Kai  wrote:
>
> > What is so bad about removing terms like master/slave that are
> > related to or even originate from so much suffering and injustice and
> > replacing it with neutral terms? Primary/Replica is used in many DB
> > systems too.
>
> Bad thing is that the whole logic of removing or changing every single
> word that in theory might sound unpleasant to somebody is fundamentally
> flawed, for a number of reasons:
>
> First, to be consistent you should first find at least one person who
> really feels personally offended by the term - but, from what I see,
> nobody even tried; the assumption that in theory there might be somebody
> somewhere is enough.
>
> Second, there is no end to it - for nearly every word you can find
> someone who dislikes it for one reason or another, whereas you have to
> name things somehow or we would be unable to communicate.
>
> And third, by going that way you are ignoring a quite large group of
> people who care about their language, and their history too, and really
> feed bad seing both of them tweaked and mangled. Those people deserve
> some respect, too. Personally, I feel very strongly about it, and fully
> understand and support Meira et al.
>
> B.
>
> >
> > On Tuesday, May 27, 2014 2:14:43 PM UTC+2, Meira wrote:
> > >
> > > As some of you may have notice, a hot discussion is happening in
> > > the comments of this pull request:
> > > https://github.com/django/django/pull/2692 Essentially, this pull
> > > request suggests that all occurences of master/slave be replaced
> > > with leader/follower. While this is clearly insane, a less
> > > jaw-dropping, but still weird change was made in commit
> > >
> https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a02352ae1
> > >
> > > Many users in comments to the original pull request agreed that
> > > primary/replica is not a good word choice, is vague and misleading.
> > > Current django docs compensate for the confusion by referring to
> > > "master/slave" in parentheses after mentioning "primary/replica".
> > > Of course, this change is nothing more than cosmetical, but it
> > > still carries more downsides than upsides.
> > > Master/slave is* immediately obvious* for the experienced users,
> > > and *easily googleable* for the newbies.
> > >
> > > I reverted the change and sent a pull request
> > > https://github.com/django/django/pull/2720. In the corresponding
> > > ticket, I was told to "wait 6 months" and then resubmit the ticket.
> > > ( https://code.djangoproject.com/ticket/22707), and the pull
> > > request was closed immediately with an advice to start a discussion
> > > on mailing list. So that's what I'm doing here :)
> > >
> > > I sum up my personal point of view in this comment:
> > > https://github.com/django/django/pull/2692#issuecomment-44265422
> > >
> > > Of course, it'll be hard for the django maintainers to admit their
> > > mistake and revert the change. It's always hard to admit mistakes,
> > > but it's better than leaving it how it is.
> > >
> >
>
>
>
> --
> I don't want to belong to any club that accepts people like me as
> members. (Groucho Marx)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20140527215632.1c093394%40fiodor
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Schema tests: delete_tables

[Michael Manfre]

On Tue, May 20, 2014 at 8:11 AM, Andrew Godwin <and...@aeracode.org> wrote:

> Hi all,
>
> It's done as a raw DROP TABLE because it has to run in weird situations
> with transactions and models where the core delete_model doesn't work (if
> you swap it out, you'll see other failures). We can definitely work towards
> improving this, perhaps by moving this onto a method on the backend.
>

I didn't notice those problems back in January with my pull request (closed
as won't merge) that made this exact change. [1] I haven't devoted much
time toward testing schema migrations since, so perhaps the transactions
issues were introduced sometime later.

[1]
https://github.com/manfre/django/commit/27d69e0134d0ab5b668c954eec0234c1e4e7d3ee#diff-12(also
https://github.com/manfre/django/commit/5167bc1aaf225588f128c89ffe2c580df1bdaf35to
explicitly close those cursors)


> However, I disagree that it is a release blocker. We're inevitably going
> to have a 1.7 point release anyway, 1.7.0 is not some time where everything
> like this gets clad in stone, and these tests are only for the backends
> themselves, not for end-users to run.
>

Your statement effectively turns Django in to Windows by encouraging a
subset of the users to wait until a service pack or entirely skip a
version. If schema migrations are not properly supported by a backend, it
could easily lead to data issues. Missing or wrong constraints are a PITA
to track down. If a 3rd party backend author cannot validate that it is
working as expected, they might choose to not support 1.7.0 and hold their
end-users back until the necessary fixes make their way in to Django.

I personally don't care whether or not this is deemed a release blocker. I
tried to be proactive with 1.7 by devoting a lot of time and effort trying
to get changes in, but in the end I gave up frustrated. My 1.7 plan is to
wait until it's released and then review schema migrations' growing list of
"we'll fix it later" issues and monkey patch as necessary.

Regards,
Michael Manfre

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

Re: Schema tests: delete_tables

[Michael Manfre]

Hi Russell,

I understand what Maximiliano is asking. It's a flaw with
SchemaTests.delete_tables [1] and it is essentially doing a raw drop table,
instead of using the 3rd party backend friendly SchemaEditor.delete_model
[2]. There was the last time I checked (and still exists) a lot of raw SQL
in the schema tests that caused tests to fail for django-mssql. It appears
other non-core backends are also facing these issues.

Regards,
Michael Manfre

[1]
https://github.com/django/django/blob/stable/1.7.x/tests/schema/tests.py#L38
[2]
https://github.com/django/django/blob/stable/1.7.x/django/db/backends/schema.py#L274


On Mon, May 19, 2014 at 10:45 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Tue, May 20, 2014 at 7:07 AM, Maximiliano Robaina <
> maxiroba...@gmail.com> wrote:
>
>> Hi,
>>
>> Running tests, (I'm using firebird) in schema app, I see that the
>> tearDown method deletes all tables created by each test. The problem here
>> is for tables with AutoInc field where sequences are created independently,
>>  when the table is dropped we need delete the sequence object too.
>> The, to me, customized delete_model method from schema editor do that,
>> when the model is deleted, then the sequence is deleted if any.
>>
>> So, the delete_tables method used in tearDown, needs to delete the
>> correlated sequences either calling to drop_sequence_sql from
>> DatabaseOperations or implementing something in Schema editor.
>>
>> Hi Maximiliano,
>
> It's not clear (to me, at least) what you're asking for here.
>
> In the general case, resetting sequences *shoudn't* be needed as part of a
> test suite. Tests that are dependent on a specific PK value being allocated
> are wrong by design, because you simply can't guarantee allocation order in
> a database.
>
> If you've got a specialist sequence being used as a part of a particular
> model, then you might need to have some custom code to reset particular
> sequences… but then, you're dealing with a custom scenario, in which case I
> don't think it's unreasonable to require some custom reset code as part of
> your test.
>
> If this is a Firebird specific issue, then it isn't clear to me why the
> statements you need can't be integrated into the flushing infrastructure
> that is already in place. In all the built-in backends, the tearDown method
> on tests doesn't *delete* tables, it flushes them; sequences are reset as
> part of that process. If Firebird requires something extra, you're going to
> need to give us a specific proposal for a database API modification that
> would meet your needs.
>
> Yours,
> Russ Magee %-)
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq84-Nu9gVDdwJWGu-LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAJxq84-Nu9gVDdwJWGu-LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Great Wall of DEP

[Michael Manfre]

Hi Jannis,


On Fri, May 9, 2014 at 3:11 AM, Jannis Leidel <lei...@gmail.com> wrote:

> Michael,
>
> First, I would appreciate if you'd give feedback in a less passive
> aggressive style. I hope it's just a matter of language barrier but your
> mail came over as far too demanding for just a "curious" question.
>

I apologize if my email came across as passive aggressive. Probably an
artifact of the dozens of revisions I made while composing it. My usual
nature is overly direct and I put a great deal of time and effort revising
my emails to make sure that my directness cannot be interpreted as
aggressive. I will continue to extensively revise my emails to the list
before clicking send because I think it is better to be interpreted as
passive aggressive instead of outright aggressive. When directing emails to
you, I'll try to be more direct so please assume that anything I write is
not meant to be offensive or an attack.

If you or anyone else thinks I'm being too direct or not direct enough,
feel free to call me out on it or ask me to clarify anything I've rewritten
and I'd be happy to do so.


> but simply no one spent the time doing the necessary steps to mark a DEP
> as active.


That is the entire point of my various DEP related emails. The process is
new and not well understood, especially by those of us in the community
that are left wondering and waiting.


> Next to personal reasons like recuperating from PyCon I think the fact
> that it's a new effort means
> also some hiccups and awkward waiting. Please bare with us and in doubt
> lean toward the side where you see us as humans and not machines
> implementing a process.
>

My biggest gripe about the process so far is the lack of communication.
Just like the devs, the community members are humans and largely comprised
of volunteers. If we were machines, there would be no complaints as we
block waiting for an unknown amount of time for something to happen. If I
hadn't written my emails, how many weeks/months do you think it would have
been before the next steps took place or anything was communicated about
what the community can expect? There will always be a conference or
personal reason. I understand that and our personal lives are clearly more
important than Django. This is also the reason why I asked questions about
if there are enough active core developers. This is a new process that
demands more time of the core team.

Regards,
Michael Manfre

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

Re: Great Wall of DEP

[Michael Manfre]

It's been almost a month and the next step in the process for the first two
DEPs is to merge the PRs and assign numbers to make them "active". The
discussion for each of them can take place over the coming months. I hate
to sound so cynical, but if none of the 30+ current core developers are
able to find 10-15 minutes of available time over the span of a month to
merge and assign a number to a DEP, I think it's safe to say that the DEP
process is not going to work in its current form.

I realize that most of the core developers are not paid to work on Django,
are very busy with polishing 1.7, or busy with non-Django things, but there
are clearly some questions that need to be discussed (some probably just
among the core devs) to figure out how to improve the current situation and
avoid repeating it. The current situation is not really that bad, but I
would be surprised if I was the only person that thinks any feature
proposal that would require a DEP is probably not worth doing at this point
in time.

This discussion is more involved than activating a DEP and should probably
be postponed until 1.7 is out of the way.

1) The DEP process was quickly brainstormed and put in to practice. Did
this move too quickly? Should this sort of process change be more
conscientious of the Django release cycle and not take place after the
feature freeze?

2) The core devs know their "territory" in the code, but did enough of them
agree to take on /django/deps before it was put in to practice?

3) Django lists over 30 current core developers. Does Django have enough
*active* core developers for its current user base and existing processes?
Is there a process in place for moving an inactive core developer from
"Current Developers" to "Developers Emeritus"?

Regards,
Michael Manfre

PS The DEP experience so far has been reminding me of a few specific
examples of "government bureaucracy" that I've banged my head against many
times over the years. My motivation for pressing the DEP issue is for the
sake of everyone's sanity by avoiding it devolving to that level of
frustration.



On Thu, May 8, 2014 at 8:21 AM, Florian Apolloner <f.apollo...@gmail.com>wrote:

> Hi,
>
>
> On Thursday, May 8, 2014 2:13:52 PM UTC+2, Carl wrote:
>>
>> Just noticed this message, and the DEP PRs are still open a week later.
>
>
>> Can someone shuffle this along, please?
>>
>
> We are in the final stages of 1.7, I personally would rather focus on that
> first.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1d33bd04-a509-4c34-8bfe-2e4df31a3add%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/1d33bd04-a509-4c34-8bfe-2e4df31a3add%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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