Re: Vendoring multipledispatch

[Anssi Kääriäinen]

+1 to allowing dependencies.

For multipledispatch, I'd like to first verify the following items:
  1. Does the author consider the API for multipledispatch stable?
  2. Are the rules in multipledispatch what we want? If we vendor it,
we can easily change the matching rules.

On Tue, Apr 5, 2016 at 2:01 AM, Florian Apolloner  wrote:
>
>
> On Monday, April 4, 2016 at 3:58:09 PM UTC+2, Donald Stufft wrote:
>>
>> Without looking at this specific thing too closely, maybe it’s time for
>> Django to gain a required dependency instead of bundling or reinventing
>> everything?
>
>
> +I_do_not_know_how_much
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To 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/9470fda1-67ab-4d92-b819-597d364fb460%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/CALMtK1H0LBvO4yKu35H67VK-LaSnizpF2h1xDYyGptf88W8Bdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring multipledispatch

[Florian Apolloner]

On Monday, April 4, 2016 at 3:58:09 PM UTC+2, Donald Stufft wrote:
>
> Without looking at this specific thing too closely, maybe it’s time for 
> Django to gain a required dependency instead of bundling or reinventing 
> everything? 
>

+I_do_not_know_how_much 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/9470fda1-67ab-4d92-b819-597d364fb460%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: utils.suppress_warning, TestCase.assertWarns

[Shai Berger]

On Monday 04 April 2016 18:37:39 Tim Graham wrote:
> I think django.test.ignore_warnings may meet your needs.
> 

Yes, probably. I had misunderstood the warnings.catch_warnings() documentation 
(and might have misunderstood the django.test.ignore_warnings documentation as 
well, if there was such doumentation).

> As for the latter idea, unless something is really eager to add a Python 2
> compatible version (if possible) to Django's SimpleTestCase, we can wait
> until dropping Python 2 support and then use the TestCase.assertWarns() in
> Python 3.2+.
> 

Agreed.

Thanks,
Shai.

Re: Feedback on improving GeoDjango docs

[Tim Graham]

I'm not sure about expanding and/or splitting the platform-specific 
instructions. These are not so well maintained and might be better suited 
for some wiki pages or something, e.g. 
https://code.djangoproject.com/ticket/25633.

On Monday, April 4, 2016 at 7:10:03 AM UTC-4, Mattias Linnap wrote:
>
> Great to hear, GeoDjango documentation has always seemed half-finished to 
> me, and only useful to people who are already familiar with GIS terminology.
>
> Based on my impressions from various forum posts over the years, beginners 
> who are looking at GeoDjango:
> * Have never heard about OGC geometries, PostGIS, WKT, WKB, SRIDs, ESRI 
> Shapefiles, GEOS, GDAL and Proj libraries, etc.
> * Have some understanding of Google Maps and GPS longitude & latitude 
> coordinates.
>
> Their main questions seem to be:
> * How to have models of "places" which have a location field, and how to 
> find N nearest places, all places in the currently visible map region, or 
> distances between places.
> * Is it worth learning GeoDjango for this, or should they just add two 
> FloatFields to the model.
>
> For example:
>
> https://www.reddit.com/r/django/comments/4csqm0/im_wondering_if_geodjango_is_overkill_in_my_case/
>
> https://www.reddit.com/r/learnpython/comments/4240va/making_a_webapp_in_django_how_to_do_locationbased/
>
> For the tutorial, the content might cover:
> 0: Installation of required dependencies, with recommended versions 
> (otherwise they get scared of the version compatibility matrices at 
> https://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS). 
> Explaining the purpose of each dependency can be a separate optional page.
> 1: A "places" type model, with N nearest + distance or region lookups. It 
> should default to WGS84 coordinates, leaving the discussion of other 
> coordinate systems for later.
> 1.5: Best practices for displaying the places on a map in the browser with 
> some Javascript library (OpenLayers, Leaflet or Google Maps).
> 2. In a more advanced tutorial, perhaps adding some more complex 
> geometries like polygons for regions or linestrings for GPS tracks, and 
> operators like contains or intersections.
>
> For the theme around the tutorials, I'm sure restaurants, apartments for 
> rent, ice cream kiosks, or elephants in natural parks work equally well. :)
>
> Mattias
>
> On Sunday, 3 April 2016 12:55:18 UTC+3, Sylvain Fankhauser wrote:
>>
>> Hello,
>>
>> I'm currently working on ticket #22274 
>> , which is an effort to 
>> improve the GeoDjango documentation to make it more accessible to 
>> newcomers. This represents quite some work and I'm still in the early 
>> stages but I'd love to have some feedback on the general structure I'm 
>> planning to create. You can find the current status of the potential new 
>> docs here: 
>> http://sephii.github.io/django-22274/ref/contrib/gis/index.html (current 
>> version of the docs can be found here 
>> https://docs.djangoproject.com/en/1.9/ref/contrib/gis/).
>>
>> The tutorial part is not yet representative of what I'm planning to do so 
>> no need to check that yet. That said, I found it quite difficult to come up 
>> with a tutorial topic that would allow me to get through most of the 
>> features from GeoDjango. So if you have an idea for a usecase I could use 
>> for the tutorial, this would be more than welcome.
>>
>> Some other things I have on my todo list are:
>>
>> * Clarify installation instructions, split the platform-specific 
>> instructions into separate documents
>> * Check if we can try to merge together some parts in the "Models" 
>> section (ie. GeoDjango Database API, Geographic Database Functions and 
>> GeoQuerySet API Reference), which all serve the same purpose
>>
>> If you see anything else, feel free to comment.
>>
>> Cheers,
>> Sylvain
>>
>

-- 
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/fd989d40-6afa-4fad-abc4-60f1a49613e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: utils.suppress_warning, TestCase.assertWarns

[Tim Graham]

I think django.test.ignore_warnings may meet your needs.

As for the latter idea, unless something is really eager to add a Python 2 
compatible version (if possible) to Django's SimpleTestCase, we can wait 
until dropping Python 2 support and then use the TestCase.assertWarns() in 
Python 3.2+.

On Sunday, April 3, 2016 at 6:21:59 AM UTC-4, Shai Berger wrote:
>
> Hi all, 
>
> While working on a ticket that had to do with cookies, I found myself 
> writing 
> this code (essentially): 
>
> with warnings.catch_warnings(record=True) as warnings_log: 
> # 
> # Begin actual code I'm trying to test 
> # 
> CsrfViewMiddleware().process_view(req, token_view, (), {}) 
> # 
> # End actual code I'm trying to test 
> # 
> if (len(warnings_log) > 1 or 
> not issubclass(warnings_log[0].category, UnicodeWarning)): 
> for warning in warnings_log: 
> warnings.warn(warning) 
>
> The code I'm trying to test is going to make a UnicodeWarning, because the 
> whole point of the test is to see how the code deals with broken user 
> input. 
> Having to wrap it in 5 lines of unrelated code feels odd. 
>
> So I thought a context manager to suppress specific warnings in a block 
> might 
> be generally useful, and for tests, it may be even useful to have an 
> assertWarns -- an analog of assertRaises. 
>
> Opinions? 
>
> Thanks, 
> Shai. 
>

-- 
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/79a74215-bd1e-4df4-a56f-2b485b94ee33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring multipledispatch

[Donald Stufft]

> On Apr 4, 2016, at 7:50 AM, Michał 'Khorne' Lowas-Rzechonek 
>  wrote:
> 
> So, I think I'm left with two options: reinvent 
> https://pypi.python.org/pypi/multipledispatch, or import that into 
> django.utils along with the license etc.
> 

Without looking at this specific thing too closely, maybe it’s time for Django 
to gain a required dependency instead of bundling or reinventing everything?


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/3B506FDB-54D2-440D-8295-05DFDB88719D%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Vendoring multipledispatch

[Michał 'Khorne' Lowas-Rzechonek]

Hi,

On last DjangoCon sprints I started working on ticket #26355 
, WIP is 
at https://github.com/django/django/pull/6395.

During the implementation I've realized that I need a double-dispatch 
mechanism for registering overloaded operators.
Current approach uses Python operator overloading exclusively, which can't 
(generally) take into account types of both operands.

So, I think I'm left with two options: 
reinvent https://pypi.python.org/pypi/multipledispatch, or import that into 
django.utils along with the license etc.

I appreciate this is not a decision to be taken lightly, so I'd rather ask 
here first, than submit a PR with shady imports.

Also, there might be a simpler/cleaner solution that doesn't required 3rd 
party code.

opinions?
-- 
Michał 'Khorne' Lowas-Rzechonek

-- 
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/4a8df55e-825c-4097-85bb-9b600d2c795a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on improving GeoDjango docs

[Mattias Linnap]

Great to hear, GeoDjango documentation has always seemed half-finished to 
me, and only useful to people who are already familiar with GIS terminology.

Based on my impressions from various forum posts over the years, beginners 
who are looking at GeoDjango:
* Have never heard about OGC geometries, PostGIS, WKT, WKB, SRIDs, ESRI 
Shapefiles, GEOS, GDAL and Proj libraries, etc.
* Have some understanding of Google Maps and GPS longitude & latitude 
coordinates.

Their main questions seem to be:
* How to have models of "places" which have a location field, and how to 
find N nearest places, all places in the currently visible map region, or 
distances between places.
* Is it worth learning GeoDjango for this, or should they just add two 
FloatFields to the model.

For example:
https://www.reddit.com/r/django/comments/4csqm0/im_wondering_if_geodjango_is_overkill_in_my_case/
https://www.reddit.com/r/learnpython/comments/4240va/making_a_webapp_in_django_how_to_do_locationbased/

For the tutorial, the content might cover:
0: Installation of required dependencies, with recommended versions 
(otherwise they get scared of the version compatibility matrices 
at https://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS). 
Explaining the purpose of each dependency can be a separate optional page.
1: A "places" type model, with N nearest + distance or region lookups. It 
should default to WGS84 coordinates, leaving the discussion of other 
coordinate systems for later.
1.5: Best practices for displaying the places on a map in the browser with 
some Javascript library (OpenLayers, Leaflet or Google Maps).
2. In a more advanced tutorial, perhaps adding some more complex geometries 
like polygons for regions or linestrings for GPS tracks, and operators like 
contains or intersections.

For the theme around the tutorials, I'm sure restaurants, apartments for 
rent, ice cream kiosks, or elephants in natural parks work equally well. :)

Mattias

On Sunday, 3 April 2016 12:55:18 UTC+3, Sylvain Fankhauser wrote:
>
> Hello,
>
> I'm currently working on ticket #22274 
> , which is an effort to 
> improve the GeoDjango documentation to make it more accessible to 
> newcomers. This represents quite some work and I'm still in the early 
> stages but I'd love to have some feedback on the general structure I'm 
> planning to create. You can find the current status of the potential new 
> docs here: http://sephii.github.io/django-22274/ref/contrib/gis/index.html 
> (current version of the docs can be found here 
> https://docs.djangoproject.com/en/1.9/ref/contrib/gis/).
>
> The tutorial part is not yet representative of what I'm planning to do so 
> no need to check that yet. That said, I found it quite difficult to come up 
> with a tutorial topic that would allow me to get through most of the 
> features from GeoDjango. So if you have an idea for a usecase I could use 
> for the tutorial, this would be more than welcome.
>
> Some other things I have on my todo list are:
>
> * Clarify installation instructions, split the platform-specific 
> instructions into separate documents
> * Check if we can try to merge together some parts in the "Models" section 
> (ie. GeoDjango Database API, Geographic Database Functions and GeoQuerySet 
> API Reference), which all serve the same purpose
>
> If you see anything else, feel free to comment.
>
> Cheers,
> Sylvain
>

-- 
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/49265d32-91dc-45a9-afc9-1c0d6944c256%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Shai Berger]

Hi everybody,

Waking this up again because, going over some older stuff, I found a ticket 
asking for this feature:

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

It was closed wontfix, but if anybody likes to put a 3-digit-numbered Django 
bug under their belt, it's there. The discussion in this thread would indicate 
that it should be re-opened.

Shai.