Re: A Django Async Roadmap

[James Addison]

If you're following that 'medium' article, then you'll see it 
uses https://github.com/jneight/django-db-geventpool, which has 
instructions for using `psycogreen` with gunicorn... I believe what it 
states is correct.

On Thursday, December 13, 2018 at 3:21:32 AM UTC, Ray Marceau wrote:
>
> James Addison,
>
>  I also currently use `psycogreen.gevent` for postgresql async behaviour.
>>
>
> How did you go about using psycogreen.gevent for async postgres?  I tried 
> using various tools and was unsuccessful in seeing any performance 
> improvements.  I was following the info here: 
> https://medium.com/@bfirsh/squeezing-every-drop-of-performance-out-of-a-django-app-on-heroku-4b5b1e5a3d44
>
> Have any suggestions/tips?  django blocking while waiting for postgres is 
> a huge bottleneck for my app.
>
> Thanks!
>
>
> How did you go about using psycogreen.gevent for postgresql async 
> behavior?  I'm 
> On Tuesday, August 21, 2018 at 10:16:03 AM UTC-7, James Addison wrote:
>>
>> On Monday, June 4, 2018 at 6:18:23 AM UTC-7, Andrew Godwin wrote:
>>>
>>> For a while now I have been working on potential plans for making Django 
>>> async-capable, and I finally have a plan I am reasonably happy with and 
>>> which I think we can actually do.
>>>
>>
>> Andrew,
>>
>> Out of curiosity, how would these kinds of changes interact with gunicorn 
>> running with a `gevent` worker? I also currently use `psycogreen.gevent` 
>> for postgresql async behaviour.
>>
>> Thanks,
>> James
>>
>

-- 
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/f765848c-6e8f-4402-8baf-ca5ed0c96b4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A Django Async Roadmap

[James Addison]

On Monday, June 4, 2018 at 6:18:23 AM UTC-7, Andrew Godwin wrote:
>
> For a while now I have been working on potential plans for making Django 
> async-capable, and I finally have a plan I am reasonably happy with and 
> which I think we can actually do.
>

Andrew,

Out of curiosity, how would these kinds of changes interact with gunicorn 
running with a `gevent` worker? I also currently use `psycogreen.gevent` 
for postgresql async behaviour.

Thanks,
James

-- 
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/bfcaec8a-179d-4e9d-b72b-0fd07d7afbe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Discussion: ModelForms not allowing unbounded RangeField values

[James Addison]

For others getting up to speed, prior discussion is 
here: https://code.djangoproject.com/ticket/29656.  Tim's comment from the 
ticket commentary is most instructive, I think:
 

> I'm not sure if there's a model field in Django where there's a chance for 
> two values that could be considered "empty" besides CharField and the range 
> fields. The docs for Field.null say, "In most cases, it’s redundant to have 
> two possible values for “no data;” the Django convention is to use the 
> empty string, not NULL."
>

Given model fields: 

text_field = CharField(blank=True, default='')
range_field = FloatRangeField(blank=True, default=NumericRange)

The `CharField` (or a `TextField`) has similar parameters to the 
`RangeField`. For the `CharField`, a ModelForm correctly uses the default 
value to save '' (avoids raising an `IntegrityError`), but the RangeField 
does not (raises an `IntegrityError`).

I'll let the team discuss; I'm not sure that I can add much else. Please 
correct me if/where I'm wrong.

-- 
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/f14af5fa-dc99-4f1a-a077-713070085e8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: We should be given the possibility of turning OFF the migrate-automatic run of "The CREATE EXTENSION postgis command"

[James Addison]

On Mon, Feb 8, 2016 at 9:39 AM, Matlau Issu  wrote:

> I mean, if i work with a postgresql whose version is lower than 9.1, the
> automatic run of "CREATE EXTENSION postgis" crashes everything !
> Indeed there is no extension concept for versions lower than 9.1.
>

https://docs.djangoproject.com/en/1.9/ref/databases/#postgresql-notes -
PostgreSQL < 9.1 is not supported. Your options to are to upgrade
PostgreSQL or downgrade Django. Obviously, the former is recommended.


-- 
[image: photo] James Addison
e: add...@gmail.com

<http://ca.linkedin.com/in/jamesaddison>  <https://twitter.com/jamesaddison>

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

Re: add prefered/default protocol in the sites framework #26079

[James Addison]

In using Marten Kenbeek's URL dispatch rewrite branch, I've found that
using the pattern of defining some site configuration in your settings is
the way to go: it more easily allows you to have URL patterns on multiple
domain/scheme combinations.

I use a dict similar to what Tim has shown, and then use it to initialize
my scheme/domain URL constraints in my root urls.py.
On Jan 25, 2016 08:01, "Tim Graham"  wrote:

> Oh, looks like django-hosts also has this problem. It looks like in some
> cases the URLs will be correct (due to the PARENT_HOST setting, I think,
> which is 'djangoproject.dev:8000' in the djangoproject.com dev settings),
> but if you are browsing a different host (e.g. the docs site), then those
> URLs use the value from the Site model.
>
> Another thought: I've sometimes thought that the Site model violates the
> principle that you shouldn't put configuration in your database. I guess
> there's some usefulness to having a ForeignKey to the site, but... would it
> be feasible to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> That would solve the portability issue, I think, since you could easily
> override the necessary parts in development settings. Not sure if it'd be
> palatable to deprecation the models though. I don't think maintaining both
> versions would be worthwhile in the long run.
>
> On Monday, January 25, 2016 at 9:57:39 AM UTC-5, Aymeric Augustin wrote:
>>
>> On 25 janv. 2016, at 14:19, Tim Graham  wrote:
>>
>>
>> I believe it's a common use case to import a copy of a production
>> database and examine it locally -- that's what I meant about portability.
>>
>>
>> I’m not convinced by this argument because the data for the Site model
>> will be wrong anyway in this situation. Or did I miss something?
>>
>> --
>> 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/b12433a7-aa49-4951-9a77-32747699038d%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/CALfx8k3fZev0ZOfUdKBq-74qSa6qu5n-O7pBTcLz9q7-25Sb%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatching framework: feedback requested

[James Addison]

Marten,


As you likely remember, I've been running your code for a few months now, 
overall it's been pretty good. I mentioned some time ago that the list of 
URLs displayed with `DEBUG=True` when triggering a 404 is sometimes empty, 
or partially empty. This still happens for me, and I believe it has 
something to do with using scheme/domain constraints - here are mine:

class ConstraintBase(Constraint):
"""
This exists purely as a way to ensure MRO mixin inheritance will work
"""
def match(self, path, request=None):
return path, (), {}

def construct(self, url_object, *args, **kwargs):
return url_object, args, kwargs


class SchemeConstraintMixin(object):
scheme = ''

def match(self, path, request=None):
if request and request.scheme == self.scheme:
return super().match(path, request)
raise Resolver404

def construct(self, url_object, *args, **kwargs):
url_object.scheme = self.scheme
return super().construct(url_object, *args, **kwargs)


class HostConstraintMixin(object):
host = ''

def match(self, path, request=None):
if request and request.get_host() == self.host:
return super().match(path, request)
raise Resolver404

def construct(self, url_object, *args, **kwargs):
url_object.host = self.host
return super().construct(url_object, *args, **kwargs)


class SchemeHostConstraint(SchemeConstraintMixin, HostConstraintMixin, 
ConstraintBase):
def __init__(self, scheme, host):
self.scheme = scheme
self.host = host


www_urlpatterns = [
url(r'^$', images_views.photos, {'template': 'images/homepage.html'}, 
name='homepage'),
url(r'^users/', include('users.urls.profiles')),
url(r'^blog/', include('writing.urls.content'), {'section_slug': 'blog'}),
url(r'^galleries/', include('writing.urls.content'), {'section_slug': 
'galleries'}),
url(r'^writers/', include('writing.urls.authors')),
url(r'^', include('vendors.urls.www')),
url(r'^', include('images.urls')),
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

my_urlpatterns = [
url(r'^', include('users.urls.my')),
url(r'^businesses/', include('vendors.urls.my')),
url(r'^user/', include('users.urls.auth')),
url(r'^user/', include('users.urls.social')),
]

manage_urlpatterns = [
url(r'^admin/', include(admin.site.urls)),
]

payments_urlpatterns = [
url(r'^braintree/', include('payments.urls.payments_braintree')),
]

urlpatterns = [
# non-logged in pages; public facing and indexable by search engines
url(SchemeHostConstraint(*settings.SITE_DOMAIN_WWW), 
include(www_urlpatterns)),
# logged in users only, public facing and not indexable by search engines 
(perhaps some exceptions...)
url(SchemeHostConstraint(*settings.SITE_DOMAIN_MY), 
include(my_urlpatterns)),
# staff only; logged in users only; Django admin + custom management pages
url(SchemeHostConstraint(*settings.SITE_DOMAIN_MANAGE), 
include(manage_urlpatterns)),
# webhooks for payment processing
url(SchemeHostConstraint(*settings.SITE_DOMAIN_PAYMENTS), 
include(payments_urlpatterns))
]


Relevant settings:

SITE_DOMAIN_MY = ('http', 'mylocal.project.com:9000')
SITE_DOMAIN_WWW = ('http', 'wwwlocal.project.com:9000')
SITE_DOMAIN_MANAGE = ('http', 'managelocal.project.com:9000')
SITE_DOMAIN_PAYMENTS = ('http', 'paymentslocal.project.com:9000')


I'm running this within a vagrant/virtualbox setup, hence the `:9000` port. 
That said, this still happens on our preview server.

Just today, however, I was wondering why `APPEND_SLASH=True` was no longer 
having an effect - no redirection happens. I *think* it is due to the 
`CommonMiddleware` code 
here 
https://github.com/knbk/django/blob/dispatcher_api/django/middleware/common.py#L75.
 
As both `request.get_full_path()` and `request.path_info` do not include 
the scheme or domain, using `is_valid_path()` will fail. Is this correct?

Cheers,
James




On Friday, January 8, 2016 at 8:46:39 AM UTC-8, Marten Kenbeek wrote:
>
> The first argument to Constraint.construct() is a URL helper object which 
> allows you to set the scheme, host, path, querystring and fragment 
> separately. So reversing a domain constraint is as simple as this:
>
> class DomainConstraint(Constraint):
> ...
> def construct(self, url_object, *args, **kwargs):
> url_object.host = self.domain
> return url_object, args, kwargs
>
>
> On Thursday, January 7, 2016 at 2:07:03 PM UTC+1, Florian Apolloner wrote:
>>
>>
>>
>> On Monday, December 28, 2015 at 5:23:19 PM UTC+1, Marten Kenbeek wrote:
>>>
>>> One can for example implement a DomainConstraint or MethodConstraint to 
>>> match a domain name or request method in the URL, or implement a set of 
>>> constraints based on the parse library for better performance than the 
>>> built-in regex-based constraints.
>>>
>>
>> A method constraint seems simple enough, how wo

Custom inclusion_tag returned context data cannot be type Context

[James Addison]

When I create a custom inclusion tag, I commonly use the 
`takes_context=True` functionality, which passes in the current context 
into the custom tag's function as the first parameter, `context`. I 
recently ran into an issue with admittedly how *I* sometimes write these 
tags.

Depending on the use case, I return a `dict` as necessary - no problems 
here. However sometimes I need more information that is present in the 
`context` passed in, so I simply repurpose `context`, adding new values to 
it and then returning `context` itself. This __usually__ works fine, except 
in the case demonstrated in the ticket I created 
here: https://code.djangoproject.com/ticket/26041 - see the sample project.

The problem encountered in that project is caused by the fact that 
`context` is of type RequestContext, not a `dict`. If I instead `return 
context.flatten()` instead of `return context` in my custom tag, everything 
works fine.

I'm wondering if it might be a good idea to check the result from all 
inclusion tags (which in the docs is recommended to be a `dict`, but is a 
`RequestContext` in my case) and if it is of type `Context` or 
`RequestContext` call `flatten()` on it.

Looking for feedback here. Thanks.
James Addison

-- 
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/1dbc41cd-c446-4e16-a300-aa683a1daf65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.9: default='' no longer permitted on model field (with blank=False)

[James Addison]

I have a model like so:

class Provider(models.Model):
description = models.TextField(default='')


In recent Django 1.9 changes (this did not occur with 1.8.x), this causes 
the following traceback:

Performing system checks...


Traceback (most recent call last):
  File 
"/home/vagrant/.virtualenvs/myproject/lib/python3.4/site-packages/gevent/greenlet.py"
, line 523, in run
result = self._run(*self.args, **self.kwargs)
  File 
"/home/vagrant/.virtualenvs/myproject/src/django/django/utils/autoreload.py"
, line 226, in wrapper
fn(*args, **kwargs)
  File 
"/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/commands/runserver.py"
, line 116, in inner_run
self.check(display_num_errors=True)
  File 
"/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/base.py"
, line 472, in check
raise SystemCheckError(msg)
django.core.management.base.SystemCheckError: SystemCheckError: System 
check identified some issues:


ERRORS:
businesses.Provider.description: (fields.E008) Invalid 'default' value: This 
field cannot be blank.
images.ImageSet.hash: (fields.E008) Invalid 'default' value: This field 
cannot be blank.
users.User.gender: (fields.E008) Invalid 'default' value: This field cannot 
be blank.


System check identified 3 issues (0 silenced).

Why is it that this was perfectly allowable before but not now? I have a 
data processing script that's pulling in data from an external source and 
creating instances with blank 'descriptions', it now doesn't work.  I have 
to set `blank=True` on fields having this error, which I don't want to do 
(for form validation reasons).

I believe the following links are pertinent:

https://code.djangoproject.com/ticket/25417
https://github.com/django/django/pull/5303

James

-- 
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/c6ffdd4b-6147-43ff-be73-daef2e8149fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL Dispatcher

[James Addison]

Marten, good to have you back in the fold. I'll leave the effort in your
hands (phew!) - as before, let me know if I can help in any way. I'm fairly
new to Django internals, so don't expect much!

I can test, however, and help with docs somewhat (based on limited
knowledge).

Cheers,
James
On Sep 9, 2015 2:52 AM, "Marten Kenbeek"  wrote:

> Hi James,
>
> Thanks for keeping this alive while I had some personal issues to sort
> out. I'll be working on this again, though I can use all the help I can
> get.
>
> As for the work that still needs to be done:
>
>- 3.1 is done, mostly as a proof-of-concept that can be found at
>https://github.com/knbk/django/tree/url_dispatcher
>- 3.2 is done. I've worked on this in separate PR's, which have all
>been merged by now.
>- 3.3:
>   - Legacy functionality has been implemented, namely through the
>   RegexPattern, LocalizedRegexPattern and LocalePrefix constraints.
>   - I've kept a lot of functional tests, and I believe the unit tests
>   have decent coverage. It would be good to have more tests, but I don't
>   think it's a necessity.
>   - Yes, pretty much all the documentation must still be written.
>   - These could be implemented pretty straight-forward in separate
>   patches after the main project has been merged.
>
> The resolver is not quite as fast as I'd hoped, especially `reverse()`.
> There are some trade-offs we can make, but we'll have to decide which are
> worth it.
> I think that is the main problem we need to tackle before we push for a
> merge.
>
> Marten
>
> Op dinsdag 25 augustus 2015 20:57:14 UTC+2 schreef Tim Graham:
>>
>> Thanks for taking this on, James. I do think it would be best to defer
>> this to Django 1.10 rather than try to rush it into Django 1.9 at this
>> point. Also, there are several URL related deprecations scheduled to
>> complete in 1.10 which should simplify things (I've started on those
>> removals here: https://github.com/django/django/pull/5143). Absent
>> another interested person, I should be able to mentor you on this during
>> the Django 1.10 release cycle (which can start once we cut the stable/1.9.x
>> branch after 1.9 alpha around September 21). In the meantime, if you want
>> take a look for some simpler tickets to tackle to get a feel for our
>> contribution process, I think that would be helpful.
>>
>> On Tuesday, August 25, 2015 at 2:25:07 PM UTC-4, James Addison wrote:
>>>
>>> In the interests of keeping the excellent work done by Marten Kenbeek
>>> (knbk on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current
>>> and moving along, I've created a new branch [2] and rebased it against
>>> current master. (I am doing this because it seems like Marten is no longer
>>> able to continue working on the effort. *If this should change or is
>>> incorrect, Marten, please let me/us know!*)
>>>
>>> To try and find how far along the project is, I've quickly compared the
>>> original GSOC outline/timeline [1] against my updated branch [2] to see
>>> what is done/remaining:
>>>
>>>- section 3.1 (Design phase) I believe was done, but am unable to
>>>find anything other than a few posts on the django-developer mailing 
>>> list - *is
>>>there a source for this?*
>>>- section 3.2 (Namespace overhaul) hasn't been addressed that I can
>>>tell - *I'd recommend dropping this as it isn't core to the effort*
>>>- Items completed in section 3.3 (Dispatcher API): 3.3.[1-4]
>>>- *Items remaining* in section 3.3: (Dispatcher API): 3.3.[5-9] -
>>>some highlights:
>>>   - re-implementing some legacy functionality for backward
>>>   compatibility (ie. RegexURLPattern)
>>>   - additional tests
>>>   - lots of documentation!
>>>   - additional resolvers (ie. scheme, sub-domain, etc)
>>>
>>>
>>>
>>> Please keep in mind that I'm mostly unfamiliar with the internals of
>>> Django core elements, so I may have easily overlooked/mistook relevant
>>> information. I'd appreciate any other review/input as well. Here is the
>>> branch comparison [3] on Github.
>>>
>>> Based on the Django 1.9 release schedule, I have doubts that this will
>>> be merged in for feature freeze, which is unfortunate. I would like to
>>> think that I am up to the task, but the URL functionality in Django is
>>> about as 'core' as it g

URL Dispatcher

[James Addison]

In the interests of keeping the excellent work done by Marten Kenbeek (knbk 
on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current and 
moving along, I've created a new branch [2] and rebased it against current 
master. (I am doing this because it seems like Marten is no longer able to 
continue working on the effort. *If this should change or is incorrect, 
Marten, please let me/us know!*)

To try and find how far along the project is, I've quickly compared the 
original GSOC outline/timeline [1] against my updated branch [2] to see 
what is done/remaining:

   - section 3.1 (Design phase) I believe was done, but am unable to find 
   anything other than a few posts on the django-developer mailing list - *is 
   there a source for this?*
   - section 3.2 (Namespace overhaul) hasn't been addressed that I can tell 
   - *I'd recommend dropping this as it isn't core to the effort*
   - Items completed in section 3.3 (Dispatcher API): 3.3.[1-4]
   - *Items remaining* in section 3.3: (Dispatcher API): 3.3.[5-9] - some 
   highlights:
  - re-implementing some legacy functionality for backward 
  compatibility (ie. RegexURLPattern)
  - additional tests
  - lots of documentation!
  - additional resolvers (ie. scheme, sub-domain, etc)
   

   
Please keep in mind that I'm mostly unfamiliar with the internals of Django 
core elements, so I may have easily overlooked/mistook relevant 
information. I'd appreciate any other review/input as well. Here is the 
branch comparison [3] on Github.

Based on the Django 1.9 release schedule, I have doubts that this will be 
merged in for feature freeze, which is unfortunate. I would like to think 
that I am up to the task, but the URL functionality in Django is about as 
'core' as it gets and I would not want to bite off more than I can chew 
without backup. Any thoughts on the continued viability of this effort? Is 
this something that someone inexperienced with Django internals should take 
on? If so, I'd definitely need coaching!

Lastly, I want to mention that I do have a new project in which I had been 
using Marten's branch (and am now using my own branch [2]), and it has been 
functionally solid for the scheme, (sub) domain and url resolving and 
reversing use cases. See the the urls.py [4] from that project to whet your 
appetites as to the possibilities of all this. :)

Previous discussions on the django-developers mailing list [5].

[1] 
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904
[2] https://github.com/jaddison/django/tree/gsoc2015_url_dispatcher
[3] 
https://github.com/django/django/compare/master...jaddison:gsoc2015_url_dispatcher
[4] https://gist.github.com/jaddison/18dea1bf93767f326aa5
[5] 
https://groups.google.com/forum/#!searchin/django-developers/marten/django-developers/IoivPLHJ_nw
 
and 
https://groups.google.com/forum/#!searchin/django-developers/marten/django-developers/WQoJN_MGTOg
 
(most recent)

Cheers,
James Addison

-- 
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/8fe229a5-4418-4d14-8f41-1bf8613e32c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatcher API

[James Addison]

Assuming 
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904
 
is the canonical source for the project details, what is the status of each 
of its goals? From a high level, the project seems well described on that 
page, but everything after (ie. status) seems opaque - unless there is 
another resource?

It would be a shame for something so powerful to fall by the wayside. I'm 
sure I'm not the only one to see such value in this addition.

On Monday, August 24, 2015 at 10:36:53 AM UTC-4, Tim Graham wrote:
>
> I don't think so. Marten has been MIA unfortunately. Someone else could 
> try to pick it up, but it seems a bit ambitious to complete in the time 
> remaining before alpha.
>
> On Monday, August 24, 2015 at 10:02:38 AM UTC-4, James Addison wrote:
>>
>> Hi Marten,
>>
>> I'm just curious if this is still on track for inclusion within the Sept 
>> 21 Apha feature deadline? I've been using your Django `dispatcher_api` 
>> branch for a new project since I learned of your proposed changes and am 
>> excited to see them in stable Django. There hasn't been any changes in 
>> about a month on your branch, so I'm (hopefully understandably) curious as 
>> to its future?
>>
>> Cheers,
>> James
>>
>> On Friday, July 10, 2015 at 4:55:22 PM UTC-4, Marten Kenbeek wrote:
>>>
>>> Hi James,
>>>
>>> Thanks for taking a look at this, I really appreciate it. 
>>>
>>> *Major bug:* the `request` object needs to be passed into `resolve()` 
>>>> here: 
>>>> https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
>>>>  
>>>> - otherwise host and scheme constraints cannot work. I believe there are 
>>>> other instances of `resolve()` not getting `request`, but mostly in tests. 
>>>> Is there a way for `request` to be a required parameter instead of 
>>>> defaulting to `None`?
>>>>
>>>
>>> Damn... I'll fix this asap. I haven't implemented any request-based 
>>> constraints yet, which allowed this to slip through without any test 
>>> failures. I'm afraid I can't just make `request` a required parameter, as 
>>> it needs to maintain backwards compatibility. With that said, the current 
>>> function signature of `resolve()` is just... awkward. One option is to 
>>> change it to `resolve(request_or_path, urlconf=None)`, and get the 
>>> path_info from the request if a request is supplied. `resolve()` might 
>>> still be called in a context where there is not request available, so I 
>>> think we need to maintain the ability to resolve just the path. 
>>>  
>>>
>>>> *Minor bug:* Given two subdomains, my.example.com and localhost:8000, 
>>>> going to a url using the 'localhost:8000' subdomain that only exists 
>>>> on the 'my' subdomain (ie. http://my.example.com/test3/ exists, but 
>>>> you try to go to http://localhost:8000/test3/), the debug mode 
>>>> 'patterns tried list' is a series of blank lines. See image below:
>>>>
>>>
>>> I would've expected at least the regexes here. I'll look into this. 
>>>
>>> *​Nice to have:* When attempting to use multiple constraints (ie. list 
>>>> or tuple of constraints), using `RegexPattern` seems to be required 
>>>> when doing pattern matching - otherwise it messes up while calling 
>>>> `construct`. First glance says this is by design? I think it would be nice 
>>>> to still be able to use the old r'' (without wrapping in 
>>>> `RegexPattern`) syntax as well. Not critical, as the multi-constraints is 
>>>> NOT breaking behaviour, just new.
>>>>
>>>
>>> Yes, this is more or less by design. While in the case of a single 
>>> constraint it's nice and concise. Once you use a list of constraints you'll 
>>> have to start counting brackets to see if that string is a RegexPattern or 
>>> a parameter to another constraint, or you'll put each constraint on a new 
>>> line and it doesn't matter as much imo. It isn't set in stone, so if you 
>>> have any compelling arguments to change this, let me know. 
>>>  
>>>
>>>> *Nice to have:* I realise this isn't likely to happen at all, but it 
>>>> would be nice if when `reverse()` and `{% url %}` are called, it would be 
>>>> good to be able to automatically drop the schem

Re: URL dispatcher API

[James Addison]

Hi Marten,

I'm just curious if this is still on track for inclusion within the Sept 21 
Apha feature deadline? I've been using your Django `dispatcher_api` branch 
for a new project since I learned of your proposed changes and am excited 
to see them in stable Django. There hasn't been any changes in about a 
month on your branch, so I'm (hopefully understandably) curious as to its 
future?

Cheers,
James

On Friday, July 10, 2015 at 4:55:22 PM UTC-4, Marten Kenbeek wrote:
>
> Hi James,
>
> Thanks for taking a look at this, I really appreciate it. 
>
> *Major bug:* the `request` object needs to be passed into `resolve()` 
>> here: 
>> https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
>>  
>> - otherwise host and scheme constraints cannot work. I believe there are 
>> other instances of `resolve()` not getting `request`, but mostly in tests. 
>> Is there a way for `request` to be a required parameter instead of 
>> defaulting to `None`?
>>
>
> Damn... I'll fix this asap. I haven't implemented any request-based 
> constraints yet, which allowed this to slip through without any test 
> failures. I'm afraid I can't just make `request` a required parameter, as 
> it needs to maintain backwards compatibility. With that said, the current 
> function signature of `resolve()` is just... awkward. One option is to 
> change it to `resolve(request_or_path, urlconf=None)`, and get the 
> path_info from the request if a request is supplied. `resolve()` might 
> still be called in a context where there is not request available, so I 
> think we need to maintain the ability to resolve just the path. 
>  
>
>> *Minor bug:* Given two subdomains, my.example.com and localhost:8000, 
>> going to a url using the 'localhost:8000' subdomain that only exists on 
>> the 'my' subdomain (ie. http://my.example.com/test3/ exists, but you try 
>> to go to http://localhost:8000/test3/), the debug mode 'patterns tried 
>> list' is a series of blank lines. See image below:
>>
>
> I would've expected at least the regexes here. I'll look into this. 
>
> *​Nice to have:* When attempting to use multiple constraints (ie. list or 
>> tuple of constraints), using `RegexPattern` seems to be required when 
>> doing pattern matching - otherwise it messes up while calling `construct`. 
>> First glance says this is by design? I think it would be nice to still be 
>> able to use the old r'' (without wrapping in `RegexPattern`) 
>> syntax as well. Not critical, as the multi-constraints is NOT breaking 
>> behaviour, just new.
>>
>
> Yes, this is more or less by design. While in the case of a single 
> constraint it's nice and concise. Once you use a list of constraints you'll 
> have to start counting brackets to see if that string is a RegexPattern or 
> a parameter to another constraint, or you'll put each constraint on a new 
> line and it doesn't matter as much imo. It isn't set in stone, so if you 
> have any compelling arguments to change this, let me know. 
>  
>
>> *Nice to have:* I realise this isn't likely to happen at all, but it 
>> would be nice if when `reverse()` and `{% url %}` are called, it would be 
>> good to be able to automatically drop the scheme and host when 
>> reconstituting an absolute URL if the scheme and host of the current 
>> request match.  However, I'm pretty sure that this is not possible, given 
>> the various scenarios in which these methods can be called. Obviously, this 
>> is not required, as the resulting URL (with scheme/host or without when 
>> matching) will still work regardless!
>>
>
> I'll probably implement something like this before it is merged. I've been 
> struggling to implement the `URL` class in a way that provided such methods 
> in a way that fully conformed RFC 3986, but it was taking up too much of my 
> time and I dropped it for now. I'm not sure I'll get it to conform to RFC 
> 3986, but I'll surely write some basic implementation to output urls 
> relative to the current host and scheme. Of course it won't cover 100% of 
> the cases as the "current" host and scheme are not always available, but in 
> the basic cases it should be doable. 
>
> Op vrijdag 10 juli 2015 15:21:36 UTC+2 schreef Tim Graham:
>>
>> Marten, did you consider putting the new API in `django.urls` instead of 
>> `django.core.urls`? I don't need there's a need to namespace it under 
>> "core", but others might be able to confirm the philosophy behind this.
>>
>
> That's certainly worth considering, in fact, I quite like the idea. If 
> there are no objections (philosophical or otherwise) I'll move it to 
> `django.urls`. 
>
> Marten
>

-- 
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@google

Re: Major features for 1.9

[James Addison]

 

> Hopefully we can add Marten's URLs GSoC project to this list.
>

To me, this would be a killer feature of Django. Marten, if you see this, 
know that I'll help you out in testing as best I can - feel free to reach 
out!

On Friday, July 17, 2015 at 10:19:38 AM UTC-7, Tim Graham wrote:
>
> Currently we have two items on the roadmap: 
> https://code.djangoproject.com/wiki/Version1.9Roadmap
>
> PostgreSQL Full Text Search  
> (Marc Tamlyn)
> Custom indexes  (Marc Tamlyn)
>
> Hopefully we can add Marten's URLs GSoC project to this list.
>
> I removed composite fields as Thomas indicated he doesn't plan to continue 
> work on it. 
>
> We have about two months until the alpha feature freeze (planned for 
> September 21). If anyone is planning any ambitious patches, let us know!
>

-- 
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/e69212cd-e050-4c2d-93de-04e064d74414%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatcher API

[James Addison]

Marten,

Using your *dispatcher_api* branch, I found a few issues - I believe this 
is an acceptable place to post them. My apologies if this is not the case.

My use case is this: Using a single Django codebase, I plan to have 
www.example.com and my.example.com. 'my' will be https, while 'www' will be 
http. 'my' will be for logged in actions (including signup/logging in), and 
'www' will be largely anonymous usage and cached using various mechanisms. 
I've figured out how to do scheme and host based constraints easily enough, 
thanks to a code sample you provided to me.  This is what I've developed it 
into, and it works pretty well (once I got around the *Major* issue listed 
below):

from django.conf.urls import url, include
from django.core.urls import Constraint, Resolver404


class ConstraintBase(Constraint):
"""
This exists purely as a way to ensure MRO mixin inheritance will work
"""
def match(self, path, request=None):
return path, (), {}

def construct(self, url, *args, **kwargs):
return url, args, kwargs


class SchemeConstraintMixin(object):
scheme = ''

def match(self, path, request=None):
if request and request.scheme == self.scheme:
return super(SchemeConstraintMixin, self).match(path, request)
raise Resolver404()

def construct(self, url, *args, **kwargs):
url.scheme = self.scheme
return super(SchemeConstraintMixin, self).construct(url, *args, 
**kwargs)


class HostConstraintMixin(object):
host = ''

def match(self, path, request=None):
if request and request.get_host() == self.host:
return super(HostConstraintMixin, self).match(path, request)
raise Resolver404()

def construct(self, url, *args, **kwargs):
url.host = self.host
return super(HostConstraintMixin, self).construct(url, *args, 
**kwargs)


class SchemeHostConstraint(SchemeConstraintMixin, HostConstraintMixin, 
ConstraintBase):
def __init__(self, scheme, host):
self.scheme = scheme
self.host = host


www_constraint = SchemeHostConstraint('http', 'localhost:8000')
my_constraint = SchemeHostConstraint('https', 'my.example.com')

urlpatterns = [
url(www_constraint, include([
url(r'^$', 'testviews.views.testview', {'template': 
'testview1.html'}, 'testview1'),
url(r'^test2/$', 'testviews.views.testview', {'template': 
'testview2.html'}, 'testview2')
])),
url(my_constraint, include([
url(r'^test3/$', 'testviews.views.testview', {'template': 
'testview3.html'}, 'testview3'),
url(r'^test4/$', 'testviews.views.testview', {'template': 
'testview3.html'}, 'testview4')
]))
]

The view simply renders a template. The templates simply display the `{% 
url %}` output of the available url patterns mentioned above. With that 
preamble done, I'll mention my findings below:

*Major bug:* the `request` object needs to be passed into `resolve()` here: 
https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
 
- otherwise host and scheme constraints cannot work. I believe there are 
other instances of `resolve()` not getting `request`, but mostly in tests. 
Is there a way for `request` to be a required parameter instead of 
defaulting to `None`?

*Minor bug:* Given two subdomains, my.example.com and localhost:8000, going 
to a url using the 'localhost:8000' subdomain that only exists on the 'my' 
subdomain (ie. http://my.example.com/test3/ exists, but you try to go 
to http://localhost:8000/test3/), the debug mode 'patterns tried list' is a 
series of blank lines. See image below:



*​Nice to have:* When attempting to use multiple constraints (ie. list or 
tuple of constraints), using `RegexPattern` seems to be required when doing 
pattern matching - otherwise it messes up while calling `construct`. First 
glance says this is by design? I think it would be nice to still be able to 
use the old r'' (without wrapping in `RegexPattern`) syntax as 
well. Not critical, as the multi-constraints is NOT breaking behaviour, 
just new.

*Nice to have:* I realise this isn't likely to happen at all, but it would 
be nice if when `reverse()` and `{% url %}` are called, it would be good to 
be able to automatically drop the scheme and host when reconstituting an 
absolute URL if the scheme and host of the current request match.  However, 
I'm pretty sure that this is not possible, given the various scenarios in 
which these methods can be called. Obviously, this is not required, as the 
resulting URL (with scheme/host or without when matching) will still work 
regardless!

I hope this was clear. If there is a way I can be of more assistance, 
please let me know!  Nice work, by the way. I'm stoked to have this in 1.9.

James

-- 
You received this message bec