Add support for filter arguments in queryset.exists() and queryset.count()

[Sjoerd Job Postmus]

Dear all,


This is probably a feature that has been proposed before, but I could 
not find a discussion on it, so I proposed it on the tracker, and Tim 
also couldn't find a discussion.


(ticket: https://code.djangoproject.com/ticket/30118 )

I would like to propose being able to write 
`SomeModel.objects.exists(field=value)` over 
`SomeModel.objects.filter(field=value).exists()` (and similar for 
`.count(**kwargs)`.



As Tim rightfully commented: "There should be one-- and preferably only 
one --obvious way to do it.".



I'm proposing this is a case where the obvious way would eventually be 
more in line with my suggestion instead of what we currently use.



Consider the following code example (from 
https://github.com/django/django/blob/709a8b861de14204f0e13c9a0fbfd61c11b3565d/tests/auth_tests/test_management.py#L998):



    Permission.objects.filter(
    content_type__model=opts.model_name,
    content_type__app_label=opts.app_label,
    codename=codename,
    ).exists()

There is a weird (to me, your mileage might vary) ").exists()" as a 
final line, and I would like to write this as


    Permission.objects.exists(
    content_type__model=opts.model_name,
    content_type__app_label=opts.app_label,
    codename=codename,
    )

This pattern seems to be quite rare in the Django codebase itself, but 
in the codebase at work we have several cases of `queryset.filter(of lines>).exists()` (and similar with count), and I am expecting this 
to also be prevalent in other codebases out there.



Arguing against it however are the following lines of the Zen of Python:

- "Explicit is better than implicit."

- Maybe also "Special cases aren't special enough to break the rules.", 
because `.filter().count()` and `.exclude().count()` are both the same 
pattern, but this would only create an alternative for the first.


- "There should be one-- and preferably only one --obvious way to do it."


Beyond these short quips, I was hoping there might also be an earlier 
discussion covering this.



Kind regards,

Sjoerd Job Postmus

--
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/63f21e13-4c6e-89f2-aca3-6961e98832df%40sjec.nl.
For more options, visit https://groups.google.com/d/optout.

Re: makemessages - Add an option to disable fuzzy translations?

[Sjoerd Job Postmus]

Regarding the "default keyword TODO": there are tools that can be used 
for working with translations, in the gettext suite.



For instance, for a given django.po file, the following command prints 
all untranslated strings:



    msgattrib --untranslated path/to/django.po


We have the following command somewhere in a wiki:


    for k in */locale/*/LC_MESSAGES/django.po; do echo $(msgattrib 
--untranslated $k | grep msgstr | wc -l) $k; done | grep -v '^0 ' | sort -n


which prints the files with missing translations, together with how many 
translations are missing.




Unrelated tips for makemessages, but if you start overriding 
makemessages, good extra flags would be:


* just hard-code `no_location` to True. It makes the generated .po-file 
non-stable when adding even 1 extra line in the source file.


* same for hard-coding `no_wrap` to be honest, *or* the line-width.

* "--sort-output" (for msgmerge and msgattrib), so that the generated 
.po-file is stable, even when the code itself has been moved around.


* add the flag "--keyword=_l", so that you can use `_l` instead of 
`gettext_lazy`, but that's depending on taste.


Regards,

Sjoerd Job


On 11/01/2019 07:42, אורי wrote:

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

I also don't like the "fuzzy" keyword and I spent hours in deleting 
them from our django.po files after running makemessages. I would like 
to disable them completely since they don't make sense in our project. 
Every time after running makemessages I have to search for the "fuzzy" 
keywords, delete them and also delete translations which are 
incorrect. I would like all the translations to be blank if not 
exactly translated.


I didn't understand what you mean by "msgmerge with the "-N" option 
swiches off fuzzy-matching.".


By the way, is it possible to add a default keyword that will be used 
for all new translations instead of "" in a specific language? 
For example "TODO"? Because I don't want to forget to translate them. 
Currently I have to search and manually replace "" with "TODO". And by 
the way the string "" appears also with translated texts.


Thanks,
אורי (Uri)
u...@speedy.net 
--
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/CABD5YeHU68Vr9M%2BMCvb3DiJYUpBUaO2PJuEpXb%3DctqE1HJX4fQ%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/6082c7ef-e39c-3109-3bcf-dd19ef6f7bad%40sjec.nl.
For more options, visit https://groups.google.com/d/optout.

Re: models.CalculatedField feature

[Sjoerd Job Postmus]

I disagree with not being able to calculate it locally (without the database): such a calculation depends on other fields. What if a dependent field is updated, but the object is not yet saved. What should the value be?>>> c.age, c.is_adult17, False>>> c.age = 40>>> c.age, c.is_adult40, FalseWould not make sense to me.As a first step, maybe it would make sense to make it easier to support custom filter attribute. Right now you have to create a custom query set subclass implementing .filter where you intercept the valuedef filter(self, *args, **kwargs):    if 'is_adult' in kwargs:        value = kwargs.pop('is_adult')        if value:            kwargs['age__gte'] = 18        else:            kwargs['age__lt'] = 18    return super().filter(*args, **kwargs)And that's ignoring exclude and Q, and probably a lot of other cases.Could we make that simpler first? On 16 Nov 2017 07:43, Shai Berger  wrote:On Thursday 16 November 2017 07:21:38 Josh Smeaton wrote:

> 

> I don't agree with reimplementing lookups/transforms/funcs to produce the

> python version of a SQL concept. It's a leaky abstraction. Instead, I'd

> prefer the model author provides their python calculation:

> 

> is_adult = models.CalculatedField(Q(age__gte=18), lambda c: c.age >= 18)



(name shortened to fit in a 80-char line)



I disagree. The way I see it, these calculated fields should essentially 

provide a declarative way to add an annotate() that's always going to be 

there. There should be only one source of truth, and that's the database; 

parallel implementations tend to disagree on fringe cases with disappointing 

results (e.g. consider if age above is nullable -- the database then makes the 

calculated field null, the python above makes it raise an exception). Or 

consider calculated fields which are aggregates -- a Python version could very 

easily become painfully inefficient.



> 

> There may be destructuring/serialisation issues (migrations/pickle) using

> lambda, unless we can ignore these model fields during deserialisation.

> 



That's another (though minor) argument against lambdas here.



No, the way I see it, the API should just use expressions. Of note, I think it 

should also support the output_field keyword. At the hand-waving, brainstorming 

level, I think we might, at some point, actually try to implement this by 

creating objects in the database (views on Postgres, computed columns on 

MySql, etc) -- so that the field is really available in all contexts.



My 2 cents,



	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/fdf87ea3-aa91-452a-8336-d73dc92efe8d%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: There should be a way to make Templates substitution to raise an exception on error

[Sjoerd Job Postmus]

Also: inline.

On Wednesday, September 27, 2017 at 4:55:32 PM UTC+2, pandyas...@gmail.com 
wrote:
>
> Please find comment inline
>
> On Friday, 22 September 2017 15:44:38 UTC+5:30, Sjoerd Job Postmus wrote:
>>
>> Indeed it could be!
>>
>> What if it was not `string_if_invalid` but `if_invalid`. The value could 
>> be:
>>
>> * An Exception instance (which would then be raised)
>> * An Exception class (which would be instantiated with the "invalid" 
>> thing), and then be raised
>> * A callable (which would be called, and must return a string or raise), 
>> and the result used (unless it raises an exception, in which case that 
>> exception is propogated upwards)
>> * A string (which would be interpolated with `%` if it contains "%s") to 
>> be used instead.
>>
> This seems like an overkill. What if we instead provide an additional 
> boolean flag `raise_if_invalid`
>

I do agree that the above specification seems overkill. However, I think 
that a boolean flag `raise_if_invalid` is the wrong approach: One could 
have both `string_if_invalid` defined and `raise_if_invalid` (and will we 
also add `log_if_invalid`?).

For simplicity, having an `if_invalid` that is a callable that either 
returns a string (or raises an exception) seems to be the most generic 
approach. For Django it's "always call the function" (the default simply 
would be `return ''`). One can add all the logic one wants into that 
specific function: raising exceptions, logging, returning a string (like 
`string_if_invalid`?)

All the other options (Exception instances and classes and strings) are 
indeed overkill (it can be handled by that function I mentioned), but would 
allow for a simpler `settings.py`.

-- 
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/75152154-6a86-4d4a-8513-faea06d556b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: There should be a way to make Templates substitution to raise an exception on error

[Sjoerd Job Postmus]

Indeed it could be!

What if it was not `string_if_invalid` but `if_invalid`. The value could be:

* An Exception instance (which would then be raised)
* An Exception class (which would be instantiated with the "invalid" 
thing), and then be raised
* A callable (which would be called, and must return a string or raise), 
and the result used (unless it raises an exception, in which case that 
exception is propogated upwards)
* A string (which would be interpolated with `%` if it contains "%s") to be 
used instead.

(in that order).

We also use the `string_if_invalid` trick with a custom class that provides 
`__mod__`/`__contains__`. Would be great if we could handle that at the 
Django layer.

On Friday, September 22, 2017 at 11:00:00 AM UTC+2, Adam Johnson wrote:
>
> I've used a solution like the one Emil links to before to great success, 
> though perhaps there's scope to make it a bit less hacky in Django.
>
> On 22 September 2017 at 07:10, Emil Stenström  
> wrote:
>
>> It as actually possible, just in a very hacky way. Django has a setting 
>> called TEMPLATE_STRING_IF_INVALID (or TEMPLATES[0]["OPTIONS"]["
>> string_if_invalid"] in current versions of Django). If you override it 
>> and set it to a class with a __str__ that raises an exception you can get 
>> the effect you want. We use this in tests to find missing variables quickly.
>>
>> Reference code: https://djangosnippets.org/snippets/646/
>>
>> On Thursday, 21 September 2017 13:05:28 UTC+2, Shreyas Pandya wrote:
>>>
>>> Hi All,
>>>
>>> What is your opinion on having an option to raise an error in template 
>>> if variable is not found in context. This may be useful for automated 
>>>  tests as discussed in ticket. 
>>>
>>> reference ticket #28618  ; 
>>>
>>> Thanks
>>>
>>> regards
>>> Shreyas
>>>
>>
>> -- 
>> 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/02995ca2-2721-4526-89de-408bb3be642d%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/e26084e2-da3b-4194-8fe5-018130a941a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Sjoerd Job Postmus]

To be honest, I'm quite surprised that the password reset feature does not 
use `TimestampSigner` which already supports timedeltas explicitly.

Is the Signing backend overkill for this? Probably yes. But I think using 
the signing backend still makes sense since it's already there. So if one 
were to move from day-based timeouts to second/timedelta based timeouts, 
one might as well use the TimestampSigner.

On Thursday, September 21, 2017 at 10:22:20 AM UTC+2, Tom Forbes wrote:
>
> I think we shouldn't shoe-horn a timedelta into the existing setting, so 
> my vote is with the second option, but I think a timedelta is much more 
> readable than just an integer.
>
> Also, the existing 3 day timeout for password links is quite surprising 
> from a security point of view. The consultants I work with would flag up a 
> token that lasts longer than 12 hours as an issue during a pentest. 
>
> IMO a new, far shorter default should be added to this setting.
>
> On 21 Sep 2017 03:56, "Zhiqiang Liu"  
> wrote:
>
> I need general consensus on how to proceed with supporting password expire 
> time to be under a day. Currently it is not possible because we use 
> PASSWORD_RESET_TIMEOUT_DAYS.
>
> In ticket 28622  we have two 
> options. 
>
> One is to continue to use the same setting PASSWORD_RESET_TIMEOUT_DAYS, 
> but change the value to non-integer (such as timedelta) so we can send 
> hours, minutes, etc to it.
>
> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT which 
> takes seconds.To support backward compatibility, I think we should keep 
> PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
> PASSWORD_RESET_TIMEOUT when provided.
>
> I'm unsure which one is better, so inputs are welcome.
>
> -- 
> 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/c8e96008-eb95-4924-8e5e-9b02d6b90c99%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/ec9588a0-5193-4b11-8087-0d00441e8275%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

Thank you Tim for all the hard work you have put into this!In your opinion, do you think it will be ready/merged before the big freeze?On 16 Sep 2017 03:23, Tim Graham <timogra...@gmail.com> wrote:Hi,Tom got sick and hasn't been able to work on the documentation as he'd hoped. If anyone wants to help, I left some TODOs (denoted by XXX) on the pull request: https://github.com/django/django/pull/9072. I'll be offline tomorrow morning (EDT) but I hope to resume work on it around 1700 UTC tomorrow. Anyone else is welcome to contribute until then (or even after that... I can always work on other things). Just coordinate here so we don't duplicate effort.I've spent most of the past two days doing cleanup on the corresponding code changes (https://github.com/django/django/pull/7482). I don't have any big todos remaining there besides giving it a review for cosmetic improvements.Thanks!On Wednesday, September 13, 2017 at 4:17:22 PM UTC-4, Sjoerd Job Postmus wrote:Hi all,I have not mentioned this so far in public channels. However, I will not really able to spend a lot of time on this PR for the upcoming days due to my son's birthday coming up this Saturday.I will keep an eye on the pull request and comments, and reply to the best of my ability.Thank you all for the willingness to push this forward at the last minute, but I can understand if it is a bit too much to handle in a short timeframe.If after this weekend there is more work that needs to be done, I'll happily put in the effort.Kind regards,Sjoerd JobOn 13 Sep 2017 9:19, Tim Graham <timog...@gmail.com> wrote:Okay, I'll work on the patch and make it my top priority.On Wednesday, September 13, 2017 at 1:54:00 PM UTC-4, Claude Paroz wrote:Perhaps we can find a compromise to ship this feature in the alpha with minimal docs and complete the docs later?I'm in favour.Claude 



-- 
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/ada721d9-50f9-42e8-97eb-d4fbb073bddf%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+unsubscribe@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/a0d798b3-2177-433b-a1fb-253ca1b0442e%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/0b3c0aa4-8698-4b06-9547-dc14e9e11525%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

Hi all,I have not mentioned this so far in public channels. However, I will not really able to spend a lot of time on this PR for the upcoming days due to my son's birthday coming up this Saturday.I will keep an eye on the pull request and comments, and reply to the best of my ability.Thank you all for the willingness to push this forward at the last minute, but I can understand if it is a bit too much to handle in a short timeframe.If after this weekend there is more work that needs to be done, I'll happily put in the effort.Kind regards,Sjoerd JobOn 13 Sep 2017 9:19, Tim Graham  wrote:Okay, I'll work on the patch and make it my top priority.On Wednesday, September 13, 2017 at 1:54:00 PM UTC-4, Claude Paroz wrote:Perhaps we can find a compromise to ship this feature in the alpha with minimal docs and complete the docs later?I'm in favour.Claude 



-- 
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/ada721d9-50f9-42e8-97eb-d4fbb073bddf%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/5cea81c6-982c-49c7-9f52-58dbdee2d362%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

Hi all,

Here a minor status update regarding the pull request, and a huge request.

I believe the pull request is feature complete. Marten Kenbeek has proposed 
some changes to the code which I have accepted and merged into the original 
pull request.

The pull request itself can be found at 
https://github.com/django/django/pull/7482

However, and here comes the huge request: the pull request needs a review 
from someone with the authority to merge it into the django/django github 
repository. Since the Django 2.0 feature freeze is coming soon, it would be 
greatly beneficial if that review could happen on short notice. If any 
concerns arise, I hope to be able to resolve those before the freeze, but 
that does depend on when the concerns are being raised.

Yes, I know this is a big ask, but I would greatly appreciate any and all 
effort made to push this feature to the finish.

Kind regards,
Sjoerd Job Postmus

-- 
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/df22db76-28a6-4dd8-8b16-5adc83350e19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

Hi John,

It's a bit unfortunate that I can't find any trace of your changes. They 
are probably on your local machine, so I can't see any of the changes you 
have made or the errors they cause.

Do you believe the problems you are running into come from a bug in the 
path() implementation, not yet fully understanding it, or something else?

Also, I think the changes to all the other tests URLs is a "nice to have" 
but not necessarily a merge-blocker. In fact, letting the old syntax remain 
tested is still important.

Some more remarks inline.

Regards,
Sjoerd Job

On Tuesday, August 1, 2017 at 5:40:58 PM UTC+2, John Griebel wrote:
>
> Hi Sjoerd, Emil (and everyone else),
> I wanted to give a quick update here so you all have some visibility into 
> the progress being made. I have begun by working on the "Update the tests 
> throughout, updating to the new style wherever possible." in Sjoerd's check 
> list just to get my feet wet and familiarize myself with the code base a 
> little more, how path() works, etc. 
>
> At this point I've converted the URL configs for all test packages with 
> the following exceptions:
> 1.) auth_tests - About 16 tests are still failing, all related to 
> password-reset. 
>

It would be great to have some info on the failure: an exception, error, ?
 

> 2.) check_framework - path() makes some URLs configurations valid that are 
> not valid with url() such as including '$' in an include, etc. For the time 
> being, I have elected not to convert the URLs that would be valid with 
> path() but not url(). I am sure this merits some discussion. If it's 
> already been discussed and I missed it, just let me know.
>

In the path() syntax, a dollar sign is interpreted as matching a literal 
dollar sign, not as in "end of string".
 

> 3.) generic_views - 16 tests are failing, all related to date tests. I 
> suspect the majority of problems here will be fixed by getting urls.py 
> exactly correct. I do think there may have to be a small change to the 
> _date_from_string method in /generic/dates.py, however.
>

would love to see the test failures.
 

> 4.) i18n - I haven't dealt much with i18n in the past so I've left this 
> one for a bit later.
>
> 5.) messages_test - Only one failure that I need to figure out.
>

Kindly share with us.
 

> 6.) urlpatterns_reverse - Should these be left as is, and similar tests 
> for path() be created since url() will not be deprecated immediately? 
>

in urlpatterns_reverse I have left most testing as-is, because I think it 
is important still for re_path (url) to be validated. Should probably be 
left untouched.
 

> 7.) view_tests - I see Sjoerd already made some small changes here and 
> wanted to confirm that the rest of the URL conf was not left unconverted 
> intentionally before converting them myself.
>
> Feedback on 6 and 7, in particular, would be great.
>
> Thanks,
> John Griebel | Senior Backend Engineer | 3Blades.io | 814-227-4213
>
> On Sat, Jul 29, 2017 at 10:01 AM, John Griebel <johnkg...@gmail.com 
> > wrote:
>
>> I think the review comments and the Todo list should get me off to a good 
>> start. I'm sure I'll have a few questions along the way as I've contributed 
>> to other open source projects before, but not Django. I spent some time 
>> last evening reading the contribution docs and getting my environment set 
>> up.
>>
>>
>> On Jul 29, 2017 4:49 AM, "Emil Stenström" <e...@kth.se > 
>> wrote:
>>
>> John: Awesome! Do you need anything to get started or is Sjoerd's review 
>> comments and todolist enough?
>>
>>
>> On Friday, 28 July 2017 15:03:12 UTC+2, John Griebel wrote:
>>
>>> Hi Sjoerd,
>>> I too would love to see this feature in Django 2.0; in fact, I've been 
>>> following its progress quite closely. I would love to help out with it and 
>>> have the necessary time to do so.
>>>
>>> John Griebel | Senior Backend Engineer | 3Blades.io | 814-227-4213
>>>
>>> On Thu, Jul 27, 2017 at 5:06 PM, Sjoerd Job Postmus <sjoe...@sjec.nl> 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Due to scheduling, I have not been able to give this the attention I 
>>>> would like to give it, and I don't see myself freeing up a significant 
>>>> amount of time to give it the final push forward before the feature freeze 
>>>> on September 18th.
>>>>
>>>> I did a final review of my changes. Though there are some things that 
>>>> might need a bit of cleaning up, I have the feeling the pull request (
>>>> https://github.com/django/django/pull/7482) is in a reasonabl

Re: To keep or not to keep: logging of undefined template variables

[Sjoerd Job Postmus]

As an anecdotal data-point: at the company I'm working at, we are running 
Django with a custom object as "string_if_invalid" that raises an exception 
on string-interpolation. This way missing template variables *do* get 
converted to an exception. I myself am very happy with this solution, as it 
forces us to make sure templates and views match up correctliy. The essence 
is that it's better to get an exception, than incorrect output (Yes, you 
should test beforehand, but sometimes there's a combinatorial explosion 
that makes that hard).


On Thursday, August 24, 2017 at 5:21:38 PM UTC+2, Tim Graham wrote:
>
> We received a report that shows the large number of undefined variable 
> warnings when rendering an admin changelist page [0]. 
>
> I'm still not sure what the solution should be, but I created #28526 [1] 
> to track this problem: finding a remedy to the problem of verbose, often 
> unhelpful logging of undefined variables.
>
> I don't think "the end goal of errors raising when using undefined 
> variables" is feasible. My sense is that relying on the behavior of 
> undefined variables is too entrenched in the Django template language to 
> change it at this point. (If someone wanted to try to fix all the warnings 
> in the admin templates, that might provide a useful data point). See the 
> "Template handling of undefined variables" thread [2] for a longer 
> discussion.
>
> [0] https://code.djangoproject.com/ticket/28516
> [1] https://code.djangoproject.com/ticket/28526
> [2] 
> https://groups.google.com/d/topic/django-developers/LT5ESP0w0gQ/discussion
>
> On Tuesday, June 20, 2017 at 4:12:52 AM UTC-4, Anthony King wrote:
>>
>> -1 for removing logs. Like Vlastimil, it's helped me spot a couple of 
>> stray bugs.
>>
>> What I'd actually like to see is this becoming stricter, with the end 
>> goal of errors raising when using undefined variables.
>>
>> For the verbosity, perhaps there's a middle ground? only log once per 
>> variable access per template context, and provide a formatter that will 
>> clean up the output?
>>
>> I believe in debug mode, you have access to line numbers and character 
>> positions, so the final output could look something like this:
>>
>> ``
>> some_app/home.html:32:24: Undefined variable: *missing_variable*
>> ``
>>
>> I'm unsure how much effort this would take, but it would definitely make 
>> the logging a lot more user + developer friendly.
>>
>> On 20 June 2017 at 08:48, Vlastimil Zíma  wrote:
>>
>>> -1 to the removal. I was annoyed by the logging at first, but then I 
>>> started to clean individual logs. Half way through, I found several usages 
>>> of long removed variables, one unused template (as a side effect) and I 
>>> updated several views to always provide defined context variables.
>>>
>>> All in all, I consider the warnings very useful for a cleaning, though I 
>>> wouldn't be against an option to silence them. Which can already by 
>>> accomplished by LOGGING, can't it?
>>>
>>> Vlastik
>>>
>>> Dne neděle 26. března 2017 11:14:23 UTC+2 Melvyn Sopacua napsal(a):

 On Thursday 16 March 2017 12:03:07 Tim Graham wrote:

 > Ticket #18773 [0] added logging of undefined template variables in

 > Django 1.9 [1], however, I've seen several reports of users finding

 > this logging more confusing than helpful. 

  

 With channels hitting 2.0 and the already large stack of moving parts 
 surrounding Django you need some basic system administration skills and 
 programming experience to work with the system. And there are quite a few 
 examples to link to from the user's list that deal with those moving parts 
 rather then Django itself. It is not an application that you download, 
 install and run.

  

 An introduction "What you need to know before starting Django" would 
 help a lot in this respect and explaining the noisiness of some logging 
 belongs in there.

  

 Because it *is* useful if you defined that variable to True in your 
 settings, and it's working in all projects but this one. It could be 
 there's an extra piece of context middleware that uses the same name and 
 deletes the variable from the context. It could be there's a Mixin missing 
 in the view hierarchy. Or a typo you don't notice anymore after plowing 
 through 20+ included template bits.

  

 Noisy logging is exactly what you want when debugging. It should log 
 things that may be working as designed, especially things that are 
 ambiguous (like undefined and false).

  

 Another thing is that logging is the ugly duckling of Django. It's not 
 mentioned much if at all in the tutorial. It is not mentioned at all in 
 "How to write reusable apps" and it shows in the eco system. It's like 
 finding a diamond when an app actually has logging implemented.

  

 But it also 

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

Hi all,

Due to scheduling, I have not been able to give this the attention I would 
like to give it, and I don't see myself freeing up a significant amount of 
time to give it the final push forward before the feature freeze on 
September 18th.

I did a final review of my changes. Though there are some things that might 
need a bit of cleaning up, I have the feeling the pull request 
(https://github.com/django/django/pull/7482) is in a reasonable state. 
There are a lot of comments by me about things that might be improved, 
though. There's also a TODO list 
(https://github.com/django/django/pull/7482#issuecomment-305482442) about 
things that still need doing.

Based on the check-list, I think the following items remain:

- Documentation the new syntax (but Tom already has a PR open for that), 
but that should only be picked up after this feature is merged/mergeable.
- Updating existing documentation (maybe even the tutorial?) to use the new 
syntax. I think that's also included in Tom's PR.
- Extra tests. There are dedicated tests already, but given such a core 
feature I would feel more comfortable if there were even more tests.
- Not mentioned in the checklist, but performance concerns should also be 
checked [1].

Personally, I would love for this feature to land in Django 2.0, but I'm 
doubtful that I can push it further myself, and would be greatly 
appreciative if somebody were willing to help push it forward.

[1]: Previously, the code used `LocaleRegexDescriptor`, which acted as 
`@property` when the regular expression was lazy, while if it is a pure 
string it would set the attribute directly as an optimisation trick. This 
might need to be replicated.

Regards,
Sjoerd Job

-- 
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/d75698e7-e75e-4719-a000-4172f3ed1082%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DEP201 / Simplified URL routing progress report

[Sjoerd Job Postmus]

Hi all,

I finally had some more time to continue on the WIP implementation of 
DEP201, and spent it on getting two missing items working:

* Showing the supplied argument to `path` in the technical 404 page.
* Making `path` work with "lazy" (think `ugettext_lazy`) arguments.

I also (finally) reserved a dedicated test-folder `urlpatterns` for some 
(as of now 1) tests.

However, in doing so I "had" to get rid of a minor performance 
optimisation: the caching of `.regex` using LocaleRegexDescriptor, so there 
might be a performance drawback in case one does not use the 
lazy/translateable URLs. I'm not sure if this performance drawback is going 
to be significant enough to actually be bothered by it.

Another issue that I now have is that if one does not use the `reverse` 
functionality, the needed parts are now prepared (whereas before, loading 
this was delayed until the first call to `reverse`).

If possible, I would really appreciate it if somebody could do a brief 
review of the code to check if it's not getting "too bad".

During the upcoming week I hope to complete the set of test-cases and have 
the code functioning. How should I proceed from there?

Kind regards,
Sjoerd Job Postmus

-- 
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/220dbc21-fcae-41f7-9ce5-f57176ad8420%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Review of DEP 201 - simplified routing syntax

[Sjoerd Job Postmus]

Thinking about it some more: that is not the solution.

Also, there are probably a couple of corner cases to consider (still: the 
same as for normal regular expressions):

* What if the "keys" (named parameters) of a translated path differs from 
that of the original path?
* What if the converters differ?

For now I think the best way forward is to assume the above corner cases do 
not happen, or otherwise fall out-of-scope.

On Saturday, May 13, 2017 at 2:32:00 PM UTC+2, Sjoerd Job Postmus wrote:
>
>
>
> On Saturday, May 13, 2017 at 1:35:37 PM UTC+2, Marten Kenbeek wrote:
>>
>> The regex in `url()` can be translated 
>> <https://docs.djangoproject.com/en/1.11/topics/i18n/translation/#translating-urlpatterns>
>>  
>> using `ugettext_lazy()`, in which case the lazy translation happens when 
>> `resolve()` or `reverse()` is called. It seems the current `path()` 
>> implementation would force evaluation when the URLs are first loaded, so 
>> `resolve()` and `reverse()` would use a fixed language (whichever was 
>> active when they were loaded) rather than allowing lazy translations.
>>
>> I'm not sure how often this feature is used, but it seems like something 
>> `path()` should support out of the box. 
>>
>
> I agree. It's an oversight which I think is solvable. The 
> `LocaleRegexProvider` class already handles the caching.
>
> I will check later, but I think all that's needed is to decorate the 
> `path` function with `keep_lazy_str`. Does that seem correct to you?
>

-- 
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/37d03083-ce35-4b9d-a881-0f9c45e90db6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

On Wednesday, May 3, 2017 at 12:35:30 AM UTC+2, Marten Kenbeek wrote:
>
>  
>
>>
>>- The more complex part is (I think) figuring out how to deal with 
>>cases where we have a `path('/', include(other_urls))` and 
>>`other_urls` also has a `path()` mentioning `something`. However this 
>> might 
>>just be my perfectionism and paranoia seeing edge-cases where there are 
>>none, or are sufficiently "edge" cases that we can suffice with a "just 
>>don't do it!".
>>
>>
>  The current resolver doesn't really handle this either. When resolving, 
> the current implementation simply passes on the outermost capture group to 
> the view. When reversing you can only pass in a single value that must 
> match both groups. If you can solve it, great, but I think it's sufficient 
> to let the underlying resolver handle it the same way. 
>

Yes, that's somewhat what I expected as well, just wasn't as sure. I 
*think* it's probably better to make a check that the capture groups do not 
overlap than to write code to deal with that elegantly. But that could 
probably happen in a different PR.

-- 
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/427a0347-4fa9-4692-88e4-a35248e408ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

On Tuesday, May 2, 2017 at 2:18:27 PM UTC+2, Tom Christie wrote:
>
> > Some positive yes/no on whether or not this is an actual desirable 
> feature for Django from the core team.
>
> We've positive feedback from at least Jacob, Ola, Aymeric, and myself, so 
> I'd broadly assume we're good there, so long as there's not any specific 
> blockers that emerge.
>
> I'd expect there could(?) end up being some awkward aspects in consensus 
> around how we approach the documentation, but we'll see how that progresses.
>

Yes, I see now. It's been a while since I last browsed through the thread, 
and was trying to just get it a bit closer to "completed" today.

Tests all pass, but I'm sure it could do with some improvements.

Ola, Aymeric: Thank you both for also offering up a segment of your time to 
help push further this feature. It's greatly appreciated.

-- 
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/2d73316f-fdef-4973-8236-b57679b68813%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

On Tuesday, May 2, 2017 at 7:39:06 AM UTC+2, Emil Stenström wrote:
>
> I talked to Sjoerd separately. He is also very busy at the moment, but was 
> working on getting merge conflicts resolved soon. He will also post a list 
> of things that are still missing, but spontaneously thought that this list 
> would be short. 
>

Just a quick list of things I think/know missing:


   - There are probably some simple converter implementations missing 
   (FloatConverter, IntConverter, UUIDConverter, etc), and bikeshedding might 
   need to happen on the exact implementation (what regex to use). Also, these 
   could be added after the main logic is already completed.
   - The more complex part is (I think) figuring out how to deal with cases 
   where we have a `path('/', include(other_urls))` and 
   `other_urls` also has a `path()` mentioning `something`. However this might 
   just be my perfectionism and paranoia seeing edge-cases where there are 
   none, or are sufficiently "edge" cases that we can suffice with a "just 
   don't do it!".
   - Some positive yes/no on whether or not this is an actual desirable 
   feature for Django from the core team.
   - Like I mentioned to Emil, I *think* this is "everything" that remains, 
   but I might be missing a few things.

Anyway, a careful review like Aymeric Augustin is suggesting might probably 
turn up a few more things that are missing.

Emil: Thanks for pushing this forwards again, it got off the top of my 
mind, and it is good to have it back in focus again.

-- 
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/c39a40a0-25b3-4a7b-b002-767fadb38db7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

[Sjoerd Job Postmus]

On Mon, Dec 19, 2016 at 08:23:09AM +, Adam Johnson wrote:
> >
> >  I guess the "safest" option is to keep the code around and let this
> > feature die when the deprecation ends in Python 3.7 (and meanwhile see if
> > anyone notices the deprecation warning in their code and files a ticket
> > about it). The only extra work compared to removing this now is silencing
> > the Python deprecation warnings in the Django tests in the meantime.
> 
> 
> Sounds fair. Flags could always be added to *url()* as an extra parameter.
 
How would that work with nested URL patterns? Would adding a flag also
apply that for the "parent" and/or "child" patterns? Would that also
work correctly for reverse?

Asking because I seriously don't 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20161220071528.GA21882%40sjoerdjob.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting full URL using django.urls.base.reverse - PR

[Sjoerd Job Postmus]

If you go with storing the base domain in the threadlocals, why not go full in and store the request itself in the locals? [1]
As far as using it in the templates... We have a RequestContext right? So in most cases that should not be an issue I presume.
But yes, Celery would be a problem, unless we push the request object to celery as well, but I presume that makes mostly no sense except for this.
[1] I must confess I greatly prefer being explicit with passing the request around, but sometimes you suddenly need the request object 10 layers deep but nowhere in the middle. Or, you want to use the request object in your AuthenticationBackend (for security counter-measures). For instance, django-brutebuster stores the request in a threadlocal to get the IP address.
On Nov 5, 2016 5:59 PM, Florian Apolloner  wrote:What I was trying to suggest is that the base domain gets stored in one of our threadlocals so that we can generate the full URL without having access to the domain (though I just realize that this wouldn't work in the case of celery etc :/)On Saturday, November 5, 2016 at 5:53:49 PM UTC+1, Mislav Cimperšak wrote:For me use cases were callback urls sent to some 3rd party and of course - emails.Yeah, I wasn't thinking about url tag.I'm not 100% sure I understand what you are suggesting.If we choose to go down the path of using kwarg I could change this in the `reverse` method itself. That way calling `reverse('foo', kwargs={'full': True})` would return a full URL. But that opens a whole other can of issues. For example if someone already has in their code `full` as a parameter for url.On Saturday, November 5, 2016 at 4:40:46 PM UTC+1, Florian Apolloner wrote:To be honest, I think I do not really see the usecase here. I know that sometimes it is required to generate full urls (especially in emails), but quite often in those you do not have access to the request at all. Also, how would this play together with the url tag? Personally I would set the current domain on the local "urlconf" (we have one per thread) and add a "full" kwarg to reverse (and something similar to the urltag).Cheers,FlorianOn Saturday, November 5, 2016 at 3:41:09 PM UTC+1, Mislav Cimperšak wrote:During the sprint in Amsterdam I created a pull request https://github.com/django/django/pull/7484In it I'm adding an optional argument `request` to `django.urls.base.urls.reverse`method.The idea is that using `request` object one can get a fully qualified URL.The idea is taken from Django Rest Framework (https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/reverse.py#L55-L59).I've talked to Tim Graham in person and he said that there are some possibilities that django-hosts will be merged into main django code base with it's own implementation of `reverse` method.To move this issue forward I need an input from core team members regarding my implementation and future plans. If necessary I'll trash my current implementation if it will just bring on more potentials problems in the future.My arguments for suggested implementation is that it's much more simple and easier for the enduser than django-hosts implementation and it's already Tom Christie approved(TM).



-- 
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+unsubscribe@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/613aacf1-95de-43ac-8cc6-a54c09e22aca%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/18df8e3a-79f8-4976-86c3-4779d24a4fc9%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

So I reformatted the markdown to rST, as required by the DEP process, and 
created a pull request.

https://github.com/django/deps/pull/27

(And I see the first review is already in too!)

On Monday, October 10, 2016 at 11:02:58 AM UTC+2, Tom Christie wrote:
>
> > What is the current status of this pre-proposal?
>
> I think it's ready for some initial work to validate the approach.
> I've got some time available for this in the near future, given that I'm 
> currently on open source work full time 
> .
>
> > Is there anything I can help with?
> If you also wanted to get involved I'd suggest considering:
>
> A PR for the DEP, taking it from the current markdown Gist, into a 
> properly formatted Rst document.
> A PR for any of the implementation tasks listed (all fairly separate 
> pieces of work) to get things moving. (Things may still change once the DEP 
> starts to be fully reviewed, but there's no great harm in getting started.)
>
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b632629a-7b3c-4c24-acdb-7c867733a271%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

What is the current status of this pre-proposal? Is there anything I can 
help with?

-- 
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/8b85ae8e-0cd5-424a-a479-4f90ac19342c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

+1. Looks finished to me. I'd like to contribute on this one way or 
another. I'll try to make sure `django-simple-url` is as compatible with 
this as possible. If need be I'm willing to change the current license if 
it's not compatible with inclusion in Django core.

On Wednesday, October 5, 2016 at 11:59:49 AM UTC+2, Tom Christie wrote:
>
> I've iterated on the pre-proposal, with what I think represents the best 
> options to date.
>
> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>
> The updates are:
>
> * Using a different name for the syntax: `path()`.
> * Dropping the leading slashes.
> * Simplifying the "unintended errors" section.
>
> At some point I'll likely start working towards a validation of this. 
> (Other takers also most welcome.)
> If/when we decided to submit a draft DEP for more in-depth review & 
> consideration, we'll need a shepherd for the proposal. Any takers? (Must be 
> someone from the core team, with commit access.)
>
> Cheers all,
>
>   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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9fdd77e3-bd26-457c-becc-9060baf921fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

In all fairness, it's actually
magic_urlpatterns_you_will_never_see = path('/', include(the_urlconf))
Django uses the magic_urlpatterns_you_will_never_see, which already includes that slash.
My recommendation would be to forgo the starting slash. In Flask you provide the full route ("absolute path") to your view, in Django the relative path. Relative paths don't start with a slash.
On Oct 4, 2016 22:01, Tom Christie  wrote:Yup, good points there. I wasn't really considering `include` at that point.Definitely some awkwardnesses that need thinking about there.urlpatterns = [    path('', homepage),    path('users/', users_list)]Looks very odd to me, since those are not actually valid URL paths. ('/' and '/users/' are the actual URL paths)Anyways, something to mull over. That and the import names are probably the two areas that'll need resolutions.



-- 
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+unsubscribe@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/70d64bf4-6ba9-444f-b161-165e6607d257%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/d2678f29-c8e9-4c46-9eae-65afe07eae2a%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

On Oct 4, 2016 15:53, ludovic coues  wrote:
>
>
> The question about the old routing system is about the plan to build
> on top the old one. I'm not saying the old one is bad. But if we start
> to build upon it, it will be harder to replace it. It might be more
> interesting to refactor the routing system, so the new one could be
> build next to the old one, rather than on top.
>
> This might open the way for third party module providing new way to
> route request in django.
To be fair, the current routing system is reasonably loosely coupled to the rest of Django. If the simpler version were to be built on top of the old system, it would be tightly coupled to the old system, but would not make it any harder to replace it with another 3rd party module than currently is possible.
As I documented in my blog post: if you want you can mostly replace the current URL routing, all you need is to have a class that defines `resolve`. Reversing URLs is a different matter, and I hope to work on a pull request to change the URL reversing to make it also a bit more pluggable.



-- 
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/57f3db67.15691c0a.d1021.46a1SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

Hi Tom,

Nicely written DEP.

I have some ideas/suggestions:

- There's text that elaborates on how to detect which one of the two 
options is implied. I'd recommend making that a section in and of itself.
- The DEP states that the new routing will be implemented in terms of the 
existing regex based system. Could you add a note here stating that that's 
merely an implementation detail?

Kind regards,
Sjoerd Job

On Monday, October 3, 2016 at 12:24:04 PM UTC+2, Tom Christie wrote:
>
> Hi folks,
>
> I wanted to push forward the consideration of introducing a simpler URLs 
> syntax, plus support for URL parameter type conversion.
>
> A pre-proposal is available here: 
> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>
> At this point I'm seeking feedback, before hopefully iterating on the 
> proposal, and making a formal submission.
>
> I'm not making any assumptions right now about where this might get too, 
> or who'd be involved if it does make it to the DEP stage, and would very 
> much welcome outside involvement. I'm also aware that while there's been 
> some positive reception, it's not yet clear if we'll reach a consensus on 
> inclusion in core.
>
> Personally I'm very firmly +1 on this, as I feel that the existing syntax 
> is a rather glaring and unnecessary pain point.
>
> Thanks to everyone who's started to kick this off, in particular Emil 
> Stenström for raising the original thread, and Sjoerd Job Postmus for their 
> work on the Django Simple URL 
> <https://github.com/sjoerdjob/django-simple-url> package.
>
>   - 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1d4e1382-e91b-469d-9f7b-dbf84a94e6b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_valid as property

[Sjoerd Job Postmus]

Thinking of an alternative route:
It seems to me that the default `method.__bool__` is undesirable in Jinja2 templates. I do not know Jinja2 well enough, but maybe they could benefit from a patch where `if`-statements give a warning/error when the _expression_ is a callable (with the default `FunctionType.__bool__`?
This would solve the issue not just for the methods you mention, but more in general.
[Or maybe Python itself should have that warning/error?]
Does that make sense?
On Sep 29, 2016 9:09 PM, "Sven R. Kunze"  wrote:Hi Aymeric,thanks for your ideas.Am Donnerstag, 29. September 2016 20:26:54 UTC+2 schrieb Aymeric Augustin:Hello,On 29 Sep 2016, at 19:57, Sven R. Kunze  wrote:#3 "Errors should never pass silently."Which they do if you write:if form.is_valid:    # will always be executed    # as it is always trueThis is perhaps the strongest argument in this discussion but I’m not convinced it’s strong enough to make the change.It’s weaker than the inconsistency that appeared between `{% if request.user.is_authenticated %}` in Django templates and `{% if request.user.is_authenticated() %}` in Jinja2 templates when Django started supporting both natively. The root cause of that inconsistency was Django’s auto-calling of callable in templates. This factor doesn’t exist here.That could depend on the perspective which argument is stronger or weaker. But independently, I still miss the point why {% if form.is_valid %} cannot be a problem in Jinja2? Writing `if some_callable:` instead of `if some_callable()` will cause the issue described here for any callable whose result makes sense in a boolean context. It’s always possible to build a security vulnerabilities with this behavior, by putting something security sensitive in the `if` or `else` block.Given that virtually anything can be evaluated in a boolean context in Python and in other dynamic languages such as _javascript_, I don’t know how to draw a line between what should be a property and what should be a method. For example, I don’t think we want to make QuerySet.exists a magic CallableBoolean, do we?Now, that you mentioned it  *seeking the "new topic" button* ;)Basically, the same arguments would apply there as well.Generally speaking, properties are expected to be cheap and methods can be expensive. In my opinion, for lack of a better guideline, we should stick to this one. `is_valid()` falls into the expensive category, and for this reason it should remain a method.Oh, I've never heard of this guideline. I just thought that properties should be used to reduce visual noise (such as parentheses and "get_" or "set_" prefixes.) or to replace a static attribute with a dynamic one. Cheap vs. expensive never played a role so far (at least where I worked). If that's relevant, we use "cached_property".Regards,Sven



-- 
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+unsubscribe@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/ecd30665-f698-4199-8fc3-d75ca66557d1%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/88a914b2-13a0-40b8-bb42-20220977c13d%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

I have a feeling this is orthogonal to the original request.
The original request/problem was "regex is hard".
Your response answers/solves "the URL definition is somewhere different from the view definition".
Both issues are realistic [1], and orthogonal.
[1]: I myself have great aversion to the approach where URL patterns are spread out over the codebase, but I know others are greatly prefer the approach that Flask takes.
On Sep 29, 2016 8:11 PM, "Sven R. Kunze"  wrote:Hi Emil,that's not only a teaching issue. Also experienced devs struggle with this way to declaring URLs.Internally, we developed a UrlMixin for our view classes such as:class MyView(UrlMixin, View):    url_pattern = r'^bar/foo/$'    view_name = 'my-index'    # rest of view codeThat's all we need to do in order to define a view with a working url pattern.Reverse works with the optional view_name or by reversing the class itself.Maybe, the simplification of your proposal could be explored by providing such a UrlMixin first.Best,Sven



-- 
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+unsubscribe@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/20a1c1c5-8d5c-49f7-b770-880b7f231798%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/b2d0882f-219b-4e3a-aa33-636c1872d783%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

On Thursday, September 22, 2016 at 5:39:31 PM UTC+2, Alasdair Nicol wrote:
>
> On Thursday, 22 September 2016 15:59:12 UTC+1, Sjoerd Job Postmus wrote:
>>
>> Another part I see is that the high coupling between Django and the URL 
>> resolvers (as mentioned in 
>> http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ ) 
>> should probably be cleaned up, if it is desired to someday support 
>> alternative URL resolvers. I'm willing to provide a patch for the checking 
>> part, but I'm not sure if it would be accepted. Do I need to open a ticket 
>> for that?
>>
>> I wrote the initial url checks code. The current tight coupling is the 
> way the code turned out, it wasn't a deliberate design choice on my part. I 
> read your blog post, and changing the code as you suggest so that the 
> resolver can check itself sounds good to me. Yes, please open up a ticket 
> to go with your patch.
>
> Cheers,
> Alasdair
>

Hi,

Thank you for your feedback. I created the ticket: 
https://code.djangoproject.com/ticket/27262. I'm not sure on what timescale 
I can supply a patch though. Should it be marked as easy picking in the 
hope somebody else can take it up?

I hope I did not offend you with my post on how the code turned out. That 
was not my intention, but if it did offend you: my apologies.

Kind regards,
Sjoerd Job

-- 
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/1991f88f-6592-4d62-b104-e3871e8e54bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

I'll try and update my library over the next couple of days to also support 
regex fragments and converters supporting parameters.

Another part I see is that the high coupling between Django and the URL 
resolvers (as mentioned in 
http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ ) should 
probably be cleaned up, if it is desired to someday support alternative URL 
resolvers. I'm willing to provide a patch for the checking part, but I'm 
not sure if it would be accepted. Do I need to open a ticket for that?

Kind regards,
Sjoerd Job

On Thursday, September 22, 2016 at 2:09:53 PM UTC+2, Tom Christie wrote:
>
> Wanted to add my support for this.
> Personally I'd be totally in favour of considering something along these 
> lines for core, once there's a fully proven design.
>
> The capture syntax is:
>
> * Far simpler.
> * Meets pretty much every single real-world case I ever see.
> * Gives us type coercion.
> * Also able to support regex fragments if needed. Eg see 
> http://stackoverflow.com/questions/5870188/does-flask-support-regular-expressions-in-its-url-routing
>
> Given that we could continue to keep the existing style around as well, 
> this is an area where I'd be happy to see Django take a step forward.
>
> Sticking with the path->existing regex mapping implementation sounds like 
> the best tack, at least initially, rather than getting bogged down in API 
> discussions around how we'd tackle a routing API if we wanted to support 
> non-path routing.
>
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7250a6ba-eb3f-4549-95a4-933367117a5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

Hi,

Before I looked into the code, I found this really hard to believe. In my 
mind, the whole resolving framework would be built upon classes providing 
`resolve` and `reverse` methods. I was only partially right. I looked into 
it a bit more and wrote up my conclusions 
here: http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ .

TL;DR:

- The URL routing is mostly loosely coupled, with the exception of the 
`checks` and the `reverse` method. Furthermore, the `RegexURLResolver` is 
coupled to the idea that all sub-resolvers/patterns are also regex-based.
- By moving the `check` responsibility to the resolvers (same as with 
model-checks) and `reverse` responsibility to the resolvers as well, the 
coupling is lowered, and we would actually be able to switch in a 
completely different set of resolvers.
- It might be a good idea to make `RegexURLResolver.reverse` agnostic of 
the sub-resolvers.

Is there any form of coupling I missed?

Kind regards,
Sjoerd Job

On Friday, September 16, 2016 at 2:57:24 PM UTC+2, ludovic coues wrote:
>
> In my opinion, there is two point. First, core django should allow 
> different url resolver. Second, these different url resolver should 
> start as third party package. 
>
> Without first point, people need to hack django if they want to 
> experiment new kind of resolver. Like one providing typecasting or a 
> faster one or a localized one. And the resolver isn't "loosely 
> coupled" unlike most of the other part of django. 
>
> For the second point, I have a simple reason. Choosing between the 
> rail or the werkzeug syntax is bike shedding. It is not a technically 
> choice. It's an aesthetic one. There is no right answer, only lost 
> time. 
>
>
> 2016-09-16 9:30 GMT+02:00 Curtis Maloney  >: 
> > On 15/09/16 16:37, Curtis Maloney wrote: 
> >> 
> >> Somewhere I have code to provide a "parse" based URL router. 
> >> 
> >> Will dig it up now 1.10 has has shipped 
> > 
> > 
> > Ah, found it... 
> > 
> > So, here is a gist of a sample of using parse 
> > (https://pypi.org/project/parse/) instead of regex. 
> > 
> > https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b 
> > 
> > Since you can register extra type names, and those types can cast also, 
> it 
> > covers a lot of things some people expect [but don't get] from regex. 
> > 
> > 
> > -- 
> > C 
> > 
> > 
> >> 
> >> On 14 September 2016 6:38:20 PM AEST, Florian Apolloner 
> >>  wrote: 
> >> 
> >> Hi Emil, 
> >> 
> >> On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström 
> >> wrote: 
> >> 
> >> and more experienced users are expected to switch over to using 
> >> regexes directly to get the exact behavior they want. 
> >> 
> >> 
> >> How so? Personally I would use this quite quickly since a few 
> >> builtin types would cover 99%. While I can write regex in sleep 
> >> nowadays, I still find it kinda tedious to redefine what "slug" 
> >> means in every URL I wanna match something… I am sure others think 
> >> the same. 
> >> 
> >> 
> >> Beginners likely won't look at all the different options and 
> >> choose one based on it's merits, they'll pick whatever their 
> >> teacher suggests they use. Also installing an extra package 
> when 
> >> setting up django feels a bit strange. 
> >> 
> >> 
> >> I think the eco system is far enough to support that, after all 
> >> south lived long and well as external package. Either way, DEP or 
> >> not, having an implementation out there would definitely help. 
> >> 
> >> 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-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/c455b2d2-39ec-43d8-af79-c276e3a60673%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

Just wanted to announce the following: it's available on pypi:

https://pypi.python.org/pypi/django-simple-url/0.0.2

Kind regards,
Sjoerd Job

On Thursday, September 15, 2016 at 9:03:21 AM UTC+2, Sjoerd Job Postmus 
wrote:
>
> Hi :).
>
> Yes, I also added the other syntax yesterday evening, so the  
> syntax is now fully supported. (But it does not yield an int!!).
>
> Currently only `'int'` is registered as a valid type, with the regex 
> r'[0-9]+'. More can be registered using `django_simple_url.register('hex', 
> '[0-9a-fA-F]+')`.
>
> One downside (still) is that it does not get cast to an int. Although I'm 
> not really sure if I find it logical that it gets cast.
>
> I don't really have that much time to work on it, but I'm hoping to add 
> the `setup.py` either later today or shortly after the weekend.
>
> Kind regards,
> Sjoerd Job
>
> On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström wrote:
>>
>> Great initiative! 
>>
>> I really think you should use the flask syntax instead of the rails one 
>> that I first suggested. Seems this is the consensus from this thread, and 
>> that makes it more likely to get it to core one day.
>>
>> /Emil
>>
>> On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wrote:
>>>
>>> Hi all,
>>>
>>> Since it seemed like an interesting idea to me, I started development of 
>>> a third-party plugin.
>>>
>>> It's currently at:
>>> https://github.com/sjoerdjob/django-simple-url
>>>
>>> Since I only started today, I have no readme/setup.py yet. Will come 
>>> later this week I hope.
>>>
>>> Current usage is
>>>
>>> from django_simple_url import simple_url
>>>
>>> urlpatterns = [
>>> simple_url('hello/world/', hello_world_view),
>>> simple_url(':year/:month/', posts_for_month_view),
>>> ]
>>>
>>> It works proper with includes (not adding a $ to the URL), and leaf 
>>> views (adding a $ to the URL).
>>>
>>> Maybe this week, or early next week I will also add support for the 
>>> '' syntax.
>>>
>>> Kind regards,
>>> Sjoerd Job
>>>
>>> On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim Graham wrote:
>>>>
>>>> I would like to see if this could be done as a third-party project 
>>>> (allow "pluggable URLs" which could use any syntax). If not, then let's 
>>>> accept a patch to Django to support it. Over time, if there's some strong 
>>>> consensus about a particular third-party package, then we could bring it 
>>>> in 
>>>> to core. I think this approach is less controversial then Django adopting 
>>>> some new, untested syntax right now.
>>>>
>>>> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström 
>>>> wrote:
>>>>>
>>>>> So it looks to me that the consensus is that this IS in fact a good 
>>>>> idea, to supply a simpler, regex-free method to define URL:s. 
>>>>>
>>>>> It also seems that the best liked version is something that's similar 
>>>>> to what flask uses: /articles///.
>>>>>
>>>>> I've never written a DEP before, but it sounds like a fun challenge. 
>>>>> I'll try to look at existing DEPs for a pattern and then apply that.
>>>>>
>>>>> Does anyone have something in particular that they would like to add 
>>>>> to the DEP? I figure I'll try to keep this first version as simple as 
>>>>> possible, while maintaining extension points for features that can be 
>>>>> added 
>>>>> later on.
>>>>>
>>>>>

-- 
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/54cdc465-ff11-47ab-905b-0ae6e19c4e83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

On Thursday, September 15, 2016 at 10:38:09 AM UTC+2, Michal Petrucha wrote:
>
>
> As cool as this idea sounds, I really don't think the URL dispatcher 
> is a correct component to make database queries. FWIW, I've seen 
> similar magic implemented in view decorators, and the thing I remember 
> the most from this experience was that it made it a lot harder to 
> follow what was happening where. 
>
> Moreover, I can imagine this turning into a complicated mess of a 
> syntax to allow query customizations using a weird DSL really quickly. 
> After all, if we allow PK lookups, it's not that unreasonable to also 
> want to be able to lookup by other keys, and it all goes downhill from 
> here. 
>
> Cheers, 
>
> Michal 
>


Agreed. It all goes downhill from there, so let's at least not do database 
queries.

To me, that settles it: no typecasting.

-- 
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/d9db908b-d22b-428f-908a-ecdc34b8fbfb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

I'm not sure if I agree.

On the one hand I would like to say:

"I agree. For instance, if the type is `hex`, it would be really weird if 
it were to be cast to an int. For `uuid`, would you expect a `UUID` 
instance, or just a string?"

but alternatively, ...

"Wouldn't it be really cool if you could specify like 
`<model(myapp.Blog):post>`, and it does a `get_object_or_404(myapp.Blog, 
post)`, and passing the actual **instance** to the view?"

Django is really great in that it has a lot of "magic" behind the scenes 
which allow you to write simple code. To me a good library is simple, but 
not too simple.

Some libraries are made in order to make complicated tasks easy.
Some libraries are made in order to make repetitive tasks less repetitive.
Some libraries do both.

For instance, the Django ORM allows you to replace complicated SQL with 
simple Python (although for me I still sometimes prefer the 'simplicity' of 
SQL ;) ).
And Django generic views allow you to have less repetitive code for writing 
forms and listings.

In this case, we have a potential to get rid of the

def my_sum_view(request, left_term, right_term):
left_term = int(left_term)
right_term = int(right_term)
extra_logic_here

and move all the casting to some "magic" place in a library, where it is 
written only once instead of many times over.

As far as naming 'int' or 'integer'... Either the library does casting or 
does not. I think 'int' is more obvious **once** you know Python. But 
'integer' might be an *alias*, though...

Let me re-iterate: I'm not sure what will be the best approach. It really 
is the trade off between a simple library having a singe responsibility, or 
a more complex library allowing simpler code. In this case I'm somewhat 
considering having a bit more complex library to allow a lot more simple 
code.

Kind regards,
Sjoerd Job

On Thursday, September 15, 2016 at 9:27:11 AM UTC+2, Anthony King wrote:
>
> In my opinion, it should remain a string. That's the behaviour it is now, 
> and it'll mean it can remain as a 3rd party package. 
>
> Perhaps to show it isn't being cast, it could be renamed to "integer", 
> which would avoid confusion 
>
> On 15 Sep 2016 8:03 a.m., "Sjoerd Job Postmus" <sjoe...@sjec.nl 
> > wrote:
>
>> Hi :).
>>
>> Yes, I also added the other syntax yesterday evening, so the  
>> syntax is now fully supported. (But it does not yield an int!!).
>>
>> Currently only `'int'` is registered as a valid type, with the regex 
>> r'[0-9]+'. More can be registered using `django_simple_url.register('hex', 
>> '[0-9a-fA-F]+')`.
>>
>> One downside (still) is that it does not get cast to an int. Although I'm 
>> not really sure if I find it logical that it gets cast.
>>
>> I don't really have that much time to work on it, but I'm hoping to add 
>> the `setup.py` either later today or shortly after the weekend.
>>
>> Kind regards,
>> Sjoerd Job
>>
>> On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström wrote:
>>>
>>> Great initiative! 
>>>
>>> I really think you should use the flask syntax instead of the rails one 
>>> that I first suggested. Seems this is the consensus from this thread, and 
>>> that makes it more likely to get it to core one day.
>>>
>>> /Emil
>>>
>>> On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Since it seemed like an interesting idea to me, I started development 
>>>> of a third-party plugin.
>>>>
>>>> It's currently at:
>>>> https://github.com/sjoerdjob/django-simple-url
>>>>
>>>> Since I only started today, I have no readme/setup.py yet. Will come 
>>>> later this week I hope.
>>>>
>>>> Current usage is
>>>>
>>>> from django_simple_url import simple_url
>>>>
>>>> urlpatterns = [
>>>> simple_url('hello/world/', hello_world_view),
>>>> simple_url(':year/:month/', posts_for_month_view),
>>>> ]
>>>>
>>>> It works proper with includes (not adding a $ to the URL), and leaf 
>>>> views (adding a $ to the URL).
>>>>
>>>> Maybe this week, or early next week I will also add support for the 
>>>> '' syntax.
>>>>
>>>> Kind regards,
>>>> Sjoerd Job
>>>>
>>>> On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim Graham wrote:
>>>>>
>>>>> I would like to see if this

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

Hi :).

Yes, I also added the other syntax yesterday evening, so the  
syntax is now fully supported. (But it does not yield an int!!).

Currently only `'int'` is registered as a valid type, with the regex 
r'[0-9]+'. More can be registered using `django_simple_url.register('hex', 
'[0-9a-fA-F]+')`.

One downside (still) is that it does not get cast to an int. Although I'm 
not really sure if I find it logical that it gets cast.

I don't really have that much time to work on it, but I'm hoping to add the 
`setup.py` either later today or shortly after the weekend.

Kind regards,
Sjoerd Job

On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström wrote:
>
> Great initiative! 
>
> I really think you should use the flask syntax instead of the rails one 
> that I first suggested. Seems this is the consensus from this thread, and 
> that makes it more likely to get it to core one day.
>
> /Emil
>
> On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wrote:
>>
>> Hi all,
>>
>> Since it seemed like an interesting idea to me, I started development of 
>> a third-party plugin.
>>
>> It's currently at:
>> https://github.com/sjoerdjob/django-simple-url
>>
>> Since I only started today, I have no readme/setup.py yet. Will come 
>> later this week I hope.
>>
>> Current usage is
>>
>> from django_simple_url import simple_url
>>
>> urlpatterns = [
>> simple_url('hello/world/', hello_world_view),
>> simple_url(':year/:month/', posts_for_month_view),
>> ]
>>
>> It works proper with includes (not adding a $ to the URL), and leaf views 
>> (adding a $ to the URL).
>>
>> Maybe this week, or early next week I will also add support for the 
>> '' syntax.
>>
>> Kind regards,
>> Sjoerd Job
>>
>> On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim Graham wrote:
>>>
>>> I would like to see if this could be done as a third-party project 
>>> (allow "pluggable URLs" which could use any syntax). If not, then let's 
>>> accept a patch to Django to support it. Over time, if there's some strong 
>>> consensus about a particular third-party package, then we could bring it in 
>>> to core. I think this approach is less controversial then Django adopting 
>>> some new, untested syntax right now.
>>>
>>> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström wrote:
>>>>
>>>> So it looks to me that the consensus is that this IS in fact a good 
>>>> idea, to supply a simpler, regex-free method to define URL:s. 
>>>>
>>>> It also seems that the best liked version is something that's similar 
>>>> to what flask uses: /articles///.
>>>>
>>>> I've never written a DEP before, but it sounds like a fun challenge. 
>>>> I'll try to look at existing DEPs for a pattern and then apply that.
>>>>
>>>> Does anyone have something in particular that they would like to add to 
>>>> the DEP? I figure I'll try to keep this first version as simple as 
>>>> possible, while maintaining extension points for features that can be 
>>>> added 
>>>> later on.
>>>>
>>>>

-- 
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/d11376c9-8a6f-45bd-940d-bc72589bf8e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

Hi,

I don't think that the 'including' URLs part forms a problem here.

For the given example, it should be easily doable

> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [
> simple_url('articles/2003/', views.special_case_2003),
> simple_url('articles/:year)/', views.year_archive),
> simple_url('articles/:year/:month/', views.month_archive),
> simple_url('articles/:year/:month/:day/', views.article_detail),
> ]

The following should make it possible:

import re

def simple_url(route, view, *args, **kwargs):
regex_route = re.escape(route)
regex_route = re.sub(r':([A-Za-z0-9_-]+)', r'(?P<\1>[^/]+)', 
regex_route)
# Anchor it to the beginning.
regex_route = '^' + regex_route

if not isinstance(view, (list, tuple)):
# It's not an include...
regex_route += '$'

return url(regex_route, view, *args, **kwargs)

(Not 100% tested, but I tested the re.sub ;) ).

So I think it is at least possible. Whether or not it's desirable though
is another question which I think I'm not suited to answer.

Kind regards,
Sjoerd Job

On Mon, Sep 12, 2016 at 11:26:36PM -0700, Ares Ou wrote:
> Hi,
> 
> Actually flask uses a style very similar to what you want.
> 
> To my knowing, you must use this pattern for Django because it has the
> concept of *including *
> URLs.
> 
> Routing in flask:
> 
> @app.route('post/', methods=['GET'])
> def post_view(post_id=None):
> # do something to render the post
> return render_template('post.html', post=post)
> 
> But the problem is, you have to specify the whole URL for every view you
> define.
> 
> Django avoids this by separating URL patterns into different levels, that's
> why it uses regex to
> identify the exact path. I guess it is hard for Django to organize URLs in
> different apps by using
> such simple method.
> 
> Looking forward to more ideas!
> 
> Best regards,
> Ares Ou
> 
> *Software Engineer / Full-Stack Python Developer  |  **Phone:* (510) 328 -
> 5968
> 
> *Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj  |  *Stack
> Overflow:* http://stackoverflow.com/users/5183727/ares-ou
> 
> Ares Ou
> 
> On Mon, Sep 12, 2016 at 10:20 PM, Constantine Covtushenko <
> constantine.covtushe...@gmail.com> wrote:
> 
> > Hi Emil,
> >
> > It is a very interesting idea.
> >
> > +1 from me
> >
> > On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström  wrote:
> >
> >> Hi Djangonauts,
> >>
> >> I'm just back from my second year of teaching Django to absolute
> >> beginners. The course is a combination of HTML, CSS, Python, and Django,
> >> and after five days of coding they have a real live website that they can
> >> show to friends. It's always such a great experience to see the look in
> >> their eyes when they finally understand how they can tame Django to do what
> >> they want.
> >>
> >> There's one big thing that keeps tripping them up is urls.py. When
> >> specifying URL:s I get lots of questions about the regexes that they have
> >> to specify. First: there's a strange "r" in front of each line: r"regex".
> >> That means I will have to explain string escaping to them. Then there's the
> >> "^" and "$" signs, both which requires explaining regular expressions at
> >> length. Then there's [0-9]+ and finally there's the parenthesis around the
> >> regex. All in all, looking at URLs from a beginners perspective, they are a
> >> bunch of hieroglyphs, and very hard for beginners to grasp right away.
> >>
> >> I'm not suggesting that urls.py are changed for most users, I'm
> >> suggesting that *simple_url* method (name inspired by simple_tag) is added
> >> to django.conf.urls that new users can use to get started quickly. This
> >> means that most beginners can postpone learning regexes a couple of months.
> >> The exact syntax that simple_url takes isn't important to me, as long it's
> >> a lot more beginner friendly than what we have today:
> >>
> >> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
> >>
> >> Just to get the ideas flowing, here's a suggestion, inspired by rails
> >> (again, exact syntax isn't important to me, simplicity to beginners is, so
> >> feel free to suggest something else if you agree that this is an important
> >> issue):
> >>
> >> from django.conf.urls import simple_url
> >> from . import views
> >> urlpatterns = [
> >> simple_url('articles/2003/', views.special_case_2003),
> >> simple_url('articles/:year)/', views.year_archive),
> >> simple_url('articles/:year/:month/', views.month_archive),
> >> simple_url('articles/:year/:month/:day/', views.article_detail),
> >> ]
> >>
> >> All parameters would be passed to the view as keyword parameters with the 
> >> name given and as a string, and validation would happen there instead.
> >>
> >> I'm thinking there should be no settings with simple_url, and that any 
> >> more advanced use-case should switch to using url instead.
> >>
> >> Two