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

yond 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 gr

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

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

Re: models.CalculatedField feature

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

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

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

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

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

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

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

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

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 th

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

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

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

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

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

;> >>> 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 Ba

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

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

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

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

DEP201 / Simplified URL routing progress report

m 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-develope

Re: Review of DEP 201 - simplified routing syntax

th? * 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+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,

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

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

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

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

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

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 or

Re: is_valid as property

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

Re: Challenge teaching Django to beginners: urls.py

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

Re: Challenge teaching Django to beginners: urls.py

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 >

Re: Challenge teaching Django to beginners: urls.py

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/

Re: Challenge teaching Django to beginners: urls.py

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:

Re: Challenge teaching Django to beginners: urls.py

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

Re: Challenge teaching Django to beginners: urls.py

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 >

Re: Challenge teaching Django to beginners: urls.py

gt; 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: > >>

Re: Challenge teaching Django to beginners: urls.py

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. >> >>

Re: Challenge teaching Django to beginners: urls.py

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), >