from:"Jure Erznožnik"

Re: Feature request: making gettext more robust

2023-06-15 Thread Jure Erznožnik

The behaviour is the same on Android. iOS makes it more straight-forward
because you HAVE TO have all translations in all languages you support.

LP,
Jure

On 15. 06. 23 16:15, Tobias Kunze wrote:

On 23-06-15 04:29:59, Gergely Kalmár wrote:

It seems that gettext is currently quite permissive – it falls back to the
default language whenever a translation file is missing or if the requested
message ID is missing from the translation file. This can lead to errors
slipping through easily.

I think it would be great if there was a way to make gettext raise an error
when the translation file is missing or when the msgid is missing.

Agreed that this is annoying behaviour, but as far as I can tell, there's not
much that Django can do. IIRC we only wrap Python's gettext module¹.

The relevant method, GNUTranslations.gettext, returns the original message if
no translation has been found, and it does so without indicating that this is
a fallback response².

AIUI this behaviour is rooted in GNU's gettext, which (just like the Python
version) allows you to set a priority list of languages to fall back to³.

Tobias

¹ https://docs.python.org/3/library/gettext.html
² https://docs.python.org/3/library/gettext.html#gettext.GNUTranslations
³ https://www.gnu.org/software/gettext/manual/gettext.html#The-LANGUAGE-variable

Re: Can we move the activity on this list to the Forum now?

2023-05-03 Thread Jure Erznožnik


This has been answered affirmatively in this very thread before.

The forum even has a "Mailing list mode" in addition to several other 
mailing options (including a nifty "activity summary").


LP,
Jure

On 4. 05. 23 07:28, Curtis Maloney wrote:

Does the Forum allow me to get email notifications / summaries?

If not, it will mean I disconnect with that part of the community.

--
Curtis

On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:

Yes please!



On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com 
(jure.erznoz...@gmail.com) wrote:




+1


*From:*django-developers@googlegroups.com 
 *On Behalf Of *natali...@gmail.com

*Sent:* sreda, 03. maj 2023 20:10
*To:* Django developers (Contributions to Django itself) 


*Subject:* Re: Can we move the activity on this list to the Forum now?


Hello everyone!


I was wondering if we could make a decision about this topic. On the 
one hand, and as far as I understand, the forum is the preferred 
channel of communication. On the other hand, having multiple 
channels of communication can spread important discussions too thin, 
making it difficult to have productive conversations in one place.



As a newcomer to the contributing community, I can attest that the 
current situation causes some confusion. IMHO, the same applies to 
the chat options: there is IRC and the Discord server (though 
perhaps I should start a new forum topic about that in order to keep 
decisions separated).



In summary, I'm +1 to "move on-mass (all few of us :) over there"!


Thank you!

Natalia.

On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:

I just submitted a proposal to create a Discourse plugin to
improve the accuracy of their inbound email parsing. This would
enable two things:

  * Folks who prefer to live in their inbox could continue to do
so and contribute by just replying to emails. Discourse
currently has reply-by-email, but it often mangles
formatting and/or entirely deletes text. Once these issues
are fixed, folks who like the current experience would be
able to just pretend the forum doesn't exist and continue
having the same experience as they currently have with
Google Groups.
  * Right now importing the archives from Google Groups into
Discourse isn't realistic for the same reasons; some
messages will import correctly, but others will be mangled
or missing text. This would also be made possible.

If this is something you care about (positively or negatively),
here is the exploratory proposal:



https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944


Any feedback and/or testing would be much appreciated! Right now
Discourse recognizes that this is a problem and is interested in
solving it, but getting it prioritized will require folks to A)
speak up saying they want it done B) test the underlying API to
verify that it actually solves the problem.


Alex


On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson
 wrote:

OK, I've updated the Trac wiki page to point to the forum
too. (We use this as a wiki-link in responses to guide folk
onwards.)


The docs have a `|django-developers|` shortcut used in quite
a few places so that needs a moment more to review and adjust.

(I'll look at it soon-ish... — if no-one beats me to it :)


Thanks.

C


On Thu, 19 Jan 2023 at 18:15, Andrew Godwin
 wrote:

We should at least update those Trac and Triage Workflow
docs to point to both, maybe with the Forum first?


Andrew


On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:

I'm trying to begin new conversations there where I
can.


The main issue is that we're still pointing people
here from Trac and the Triage Workflow docs — so if
there's a rough "Yeah, let's do it" we can adjust
practice there.


I expect there will always be the "How do I start?"
posts. The Forum at least has a pinned post for
that. ...


On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via
Django developers (Contributions to Django itself)
 wrote:

Hi all,


I find that the signal-to-noise ratio on this
mailing list is (by my determination) quite bad
around this time of year.


Is a move to the forum still on the cards?


Kye

On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin
, wrote:


I did some investigation of moving
django-users and django-developers to the
Forum right after

Re: Drop CSRF middleware from the settings template

2023-04-20 Thread Jure Erznožnik


OK, I'll bite:

For the first issue, my problem revolved around this code:

@property def POST(self): # Ensure that request.POST uses our request 
parsing. if not _hasattr(self, '_data'): self._load_data_and_files() if 
is_form_media_type(self.content_type): return self._data return 
QueryDict('', encoding=self._request._encoding)


The second `if` asks whether the payload is form media type, and, if so, 
returns the parsed content, otherwise it returns a blank QueryDict. In 
my case, the content-type was set to application/json. It parsed 
successfully and self._data was still populated when the code reached 
the second if. However, the second if rejected the content and skipped 
to returning the empty QueryDict, which then resulted in payload 
consequently being served as the empty QueryDict also for DRF. I can't 
really say where the actual request._data got reset because of this, but 
I did (get reset). I'm guessing DRF tries to parse the data from 
scratch, but the stream was consumed already or some such. I didn't 
nearly debug this enough to KNOW what went wrong.


I was unable to find the actual culprit for this behaviour, so I 
ultimately just exempt the view. But the circumstances of the actual 
issue were very unclear: I have a commit where CSRF middleware chose 
this path and a commit where it did not. I was unable to find the 
culprit by being unable to find the condition that made the middleware 
go into the check at all - contrary to the commit before where it did 
not. Needless to say, the commits did not deal with anything I perceived 
as anything near CSRF or AJAX. They were super small too...


This is the actual section of the code that triggers the POST processing 
in the middleware:


if request.method == "POST": try: request_csrf_token = 
request.POST.get('csrfmiddlewaretoken', '') except OSError:


IIUC, this code tries to match the token received from the headers with 
one that's supposed to be in the form data payload. The code is allowed 
to fail just fine, but in this case it has the side-effect mentioned: 
the form payload will have been parsed and cannot be parsed again - 
while at the same time rejecting the parsed data because it is not form 
payload type.


As for the second issue, I must admit I don't understand your reply at 
all. I'm a pretty bad n00b while you're one of the Django đombas (tough 
big guys) and it's entirely possible I am misinterpreting what I'm 
seeing here. I just stated my observation that Django now only serves 
the index.html for me, generating a CSRF token along the way and then I 
use that CSRF token for all subsequent AJAX requests. I don't even 
understand the "visual representation changes" and "looks like it's 
different". So, sorry, I'm afraid I can't be of assistance here.


What I was trying to say with that paragraph was that I'd like to 
actually figure out a way to START doing token rotation because my 
observation is that it's currently NOT rotating and is therefore a lot 
less useful as a security measure.


Now I have bit my chunk off and I'm chewing. Hopefully no hooks in there ;)

LP,
Jure


On 20. 04. 23 11:51, Florian Apolloner wrote:

Hi,

On Tuesday, April 18, 2023 at 10:57:55 PM UTC+2 jure.er...@gmail.com 
wrote:


Well, TBH, I've just completed dealing with CSRF form in my
projects. I ended up exempting the particular view from CSRF
because I didn't know how to get the stuff to work. The problem
was that django parsed the body payload, which was JSON and thus
rejected its contents (because it wasn't form payload type – POST
method). As a result, DRF then had no payload to work with… I
shouldn't go into too much detail as it's irrelevant to the point.


I do not think this is true. Django only parses the POST data if the 
content-type is a form type, so if you are sending JSON properly 
Django will not parse the data and DRF can handle it just fine.


 But, I've been considering I need a modernised CSRF: currently it
works by generating a new token every page served. But we have
switched our front-end to SPA and that doesn't make much sense any
more since CSRF token itself doesn't change at all, since Django
template system only ever serves one page. AFAIK, DRF doesn't
ganerate new tokens in its pipelines.


That is not accurate either. The token does not change for every page 
served, only it's visual representation does. That means that you can 
keep using the same CSRF token even though it looks like it is 
different (note: This assume that you are not triggering a codepath 
that is rotating the token).


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 view this discussion on the web visit

Re: Drop CSRF middleware from the settings template

2023-04-17 Thread Jure Erznožnik

https://security.stackexchange.com/questions/262245/are-csrf-attacks-a-thing-of-the-past

Looks like lax will do the trick, but it's not like there aren't legit
cases for same-site policy to be set to something less restrictive.

LP,
Jure

On 17. 04. 23 09:24, Jacob Rief wrote:

On Monday, April 17, 2023 at 8:45:16 AM UTC+2 Curtis Maloney wrote:

Are you implying that all CSRF attacks protected by Django's
current machinery are entirely mitigated by SameSite=Lax on the
_session_ cookiue?

Yes. Therefore imho, the CSRF protection is just some nasty legacy,
developers have to fiddle with. It doesn't add any security benefit
anymore.
That said, maybe there is still a possible attack vector on cross site
request forgeries, but I was unable to exploit them with disabled CSRF
protection.
Therefore it would be great, if someone with more hacking experience
than myself, could try this.

– Jacob
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/18aaa4cf-4612-4373-bd91-90cfb3fd07b8n%40googlegroups.com
.

Re: #21978 include production-ready web server

2022-10-26 Thread Jure Erznožnik

IMHO, adding YAML support would introduce a dependency that's not 
needed: why not just use Python, instead of ini/yaml/toml?


Projects could have a (.gitignore) env.py that settings.py imports and 
then sets the appropriate variables from it. You can use straight 
assignment, e.g.


   LANGUAGE_CODE = env.LANGUAGE_CODE

or a getattr for optional settings:

   LANGUAGE_CODE = getattr(env, 'LANGUAGE_CODE', 'en-gb')

No dependencies at all, not even internal python ones.

But maybe I'm just being ignorant: there must be good reasons if core 
python accepted toml. In that case, I hope to be enlightened (no sarcasm 
here).


LP,
Jure

On 26. 10. 22 09:30, Florian Apolloner wrote:

Hi Pete,

this does look interesting. And I agree that this is something that 
would be nice to have in core in one form or another. That said I 
think we have to do it iteratively (ie in smaller parts) and evaluate 
along the way.


Since you asked for feedback, I'll tell you what I'd do differently 
(and this is also a sign that production environment vary widely).


 * As soon as health checks check something aside from simply 
returning a 200 status code I'd want to be able to limit access to them
 * I like my dev env to be as close as possible to production so I 
usually also use whitenoise in dev. I had to many times where dev 
worked and whitenoise in prod failed then :D
 * I do hate `DJANGO_ENV` but I guess there is no way around it. 
Currently my projects often piggy-back on DEBUG but that can be rather 
hard from time to time
 * I prefer settings in settings files (ini/yaml/toml) as opposed to 
env variables that leak down the whole process-tree. django-environ 
does support this; that said there are other options like dynaconf 
which also support hashicorp vault which is a massive plus imo. Just 
being able to utilize vault for free from every django application out 
there would be stellar.


Another thing about settings, and this is something I really like in 
spring-boot is their relaxed binding for configuration variables. You 
can look at 
https://github.com/spring-projects/spring-boot/wiki/Relaxed-Binding-2.0 
for an example. They describe there how hierarchical variables are 
handled and translated between yaml and env variables. Of course this 
binding is not exactly bidirectional always (I think) but it allows 
for a few nice things. First off you can start with a config file in 
yaml (one might dislike yaml but I find it easier to read than say a 
.env file with 100 settings):


```
db:
  host: myhost
  port: 1234

caches:
  default:
     type: memory
  second:
    type: redis
```

which would translate to the following env variables:
```
DB_HOST: myhost
DB_PORT: 1234
CACHES_DEFAULT_TYPE: memory
CACHES_SECOND_TYPE: redis
```

This is imo really a powerful concept and allows for so much nicer and 
easier definitions.


Cheers,
Florian

On Friday, October 21, 2022 at 9:56:50 PM UTC+2 pe...@lincolnloop.com 
wrote:


I put together a first stab at this at
https://github.com/lincolnloop/django-production. Feedback is
appreciated!

On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com
 wrote:

I hadn't seen django-simple-deploy. At first glance, it looks
interesting, but more platform-specific than what I was thinking.

I'll play around with creating a third-party app that
encapsulates some of these thoughts and see where I end up.

Thanks for your time and feedback!

On Tuesday, August 23, 2022 at 1:17:12 PM UTC-6
carlton...@gmail.com wrote:

Hey Pete.

Yes, there can be a lot of steps... (and trouble is every
one has a different opinion once you get to specifics :)

django-webserver looks good — in a similar ballpark to
what I had in mind, yes, but I'd probably not want to
bundle the options for each server myself, as that seems a
lot to maintain over time... (Better to outsource to the
individual projects no?)

Have you seen what Eric Matthes is doing with
django-simple-deploy?

https://github.com/ehmatthes/django-simple-deploy

I really like the idea: in an opinionated way, it applies
the project changes you need to deploy (and it's plugable
so folks could provide a *template* for their own flavour
of deployment if they wanted, which is kind of important
given the number of options in the landscape, even if you
only to *ship* a beginner option.)

Tim Allen also recently raised improving the Django
project template, which I think is related here. (That's
on my list too: async this QTR, then hoping to take on
Adam's proposal to modernise the Request object for the
end of year, then 爛 swinging back here for "OK, what does
it look like, what can we do?" after that: there's

Re: Model-level validation

2022-10-12 Thread Jure Erznožnik

I'd like to chime in with this:

There was a point in time when we ran into this issue and solved it with
our own Model descendant.

IMHO, I'm completely with Aaron on this: all the guts are there, just
not being used. It took me quite a while to wrap my brain around the
idea that validation would be specified in models, but only used in
forms. And then some more looking at why all the support functions are
in models, but not being used. It just didn't compute why I would have
validation when using Django one way, but not when I wanted something a
little different.

While all the arguments against providing this function are valid and
good, they neglect that an implementation satisfying n00bs like me would
really not carry any penalties: it's just an if in the model.save
checking against a global setting. No code creep, no additional tests to
write (but I'm pretty sure some of the existing ones might fail, django
or end-app). It would remove some confusion, but grandmasters like
yourselves could still turn it off and do it the way you believe is "the
correct one".

Also, just to be clear: the above solution (turning this on) yielded
TONS of bugs when we did it for our projects. We vastly improved unit
testing following this implementation, so it was a total win for us.

LP,
Jure

On 9. 10. 22 08:58, James Bennett wrote:

On Sat, Oct 8, 2022 at 8:32 PM Aaron Smith wrote:

Surely we can agree that /something/ should happen here? The
status quo is confusing, a footgun and a gotcha. If it's not
Model's concern, then get it out of Model.

I've already said that I wish model-level validation hadn't been added
to Django.

Unfortunately it's something that's been in long enough now that it
would be very difficult to deprecate and remove. But that's not an
argument, to my mind, for expanding it.

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAL13Cg8ZvG6%3DtCNEEKV-4rQURzZ_GFSuPRypkoOOqGULFC9pZw%40mail.gmail.com
.

Re: Developer wanted

2021-09-08 Thread Jure Erznožnik

I think this is the wrong mailing list to ask questions like that: you 
should try django forums instead. That said...:


We might be interested. Can you share more details?

There's no website, but we're doing about ten or so django apps for 
various purposes. We have 6 years experience with the framework. Our 
front end is Vue and Bootstrap, usually, but we also do Android and iOS 
apps, so you can get the whole package with us.


Contact me on jure at velis.si for more info. This should not be 
continued here.


LP,
Jure

On 5. 09. 21 16:49, 'la...@larrylobert.com' via Django developers 
(Contributions to Django itself) wrote:
I would like to connect with an experienced Django developer to 
continue with some work that was started and nearly completed and to 
take the project to new levels.  Any advice or help in finding someone 
is 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8ee7485e-b41b-4e80-8542-f18199e9e495n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ab2cfd44-0a7c-b20b-7783-4805b4ab770a%40gmail.com.

Re: include_block template tag

2021-04-19 Thread Jure Erznožnik


Hi Pierre,

I like your solution very much: implements what needs to be implemented, 
rationalises it very well and also adds all the other bits'n'pieces 
required for a proper PR.


I really hope this gets accepted, it was a huge thorn in our butts until 
we implemented it. Now we're (ab)using it everywhere.


LP,
Jure

On 17. 04. 21 10:23, Pierre Vanliefland wrote:

Hi Carlton,

Thanks for replying so quickly. It's definitely been an itch for me, 
as check the docs and Stack Overflow every year to check if this has 
been implemented!


I've completed the Gist with an "include/extends" example, but I 
haven't done the same for inclusion tags: as far as I know, an 
inclusion tag has a single, fixed template, which would require you to 
create one inclusion tag by component in your "design system", which 
would be even more cumbersome. And it would not allow you to override 
multiple block contents with arbitrary HTML, which is the goal here.


I plan to use my own implementation more extensively in the coming 
weeks to check its robustness, but I would be super happy to propose a 
PR if you find it interesting.


At the moment, it's not a big pain point for me, as I can use my 
custom tag, but I agree with the feeling of Carl above: while useful, 
it's a small feature and I'm afraid users won't be attracted by a 
third-party plugin for 50 lines of code...


I was wondering why I was feeling like this is a missing piece, and I 
remembered this morning: I used this feature a lot when I was using 
Twig (https://twig.symfony.com/doc/3.x/tags/embed.html).


It was super useful, especially when working on a web application (vs 
website), where you have a lot of similar sections and widgets, and 
I've been missing it a lot over the years.


Have a nice day!

Pierre

On Saturday, April 17, 2021 at 5:44:05 AM UTC+2 carlton...@gmail.com 
wrote:


Hi Pierre,

No problem at all! There’s some itch that folks have here so all
for the good discussing it.

Thanks for your work on the gist it looks good. I just glanced at
it now, and need to sit down longer but, can I ask you to add a
“What’s wrong with the current tools” section to text? i.e. How
would it look using include or a custom inclusion tag, and so why
would a new tag be better? I think that would be helpful. (Make
sense?)

Kind Regards,

Carlton



On 16 Apr 2021, at 23:03, Pierre Vanliefland
 wrote:

Hello! First, sorry if it is not appropriate to bring back this
thread from the grave, but I spent some time on finding a
solution for this and came up with an implementation that:

 1. Needs very little code
 2. Re-uses the existing code for the extends and include tags

I have written a Gist that contain the full code (including text)
and a bit of context:
https://gist.github.com/pvanliefland/bb676a906b900c7e29e46b474038a6ca


Do you think this is worth discussing here?

*Usage:*


  {% embed "section.html" %}
    {% block title %}Stats{% endblock %}
    {% block content %}
       
          A stat
          ...
      
    {% endblock %}
  {% endembed %}
  {% embed "section.html" %}
    {% block title %}Activity{% endblock %}
    {% block content %}
       Yesterday
       All my troubles seem so far away
    {% endblock %}
  {% endembed %}


On Wednesday, December 2, 2020 at 9:51:03 AM UTC+1
jure.er...@gmail.com  wrote:

Final comment for this:

we implemented the tag in our dynamicforms library (commit
with initial implementation

).

The initial implementation straight-out replaces the django
include tag, giving it an additional option to also declare a
block tag with nested blocks. That didn't work on Django 2.2.
though, so the final implementation now splits the tag in
block and non-block variants.

Anyway, I wanted to say that initial implementation wasn't
much feature-creep on the include tag anyway. It should be a
very small PR that would eliminate a huge disclaimer in
documentation in exchange for a couple (literally) lines of
new code.

TL;DR:

So: having implemented this, I'd say that code feature-creep
is cheaper than documentation / support effort needed to
explain away demands for the functionality?

Curtis, you're free to use this in your Sniplates. I'd just
warn about the helper function parse_tag which we got here


and don't know the license of, yet. We will get rid of it
ourselves if there's no reply shortly, but it was convenient

Re: Feature request: Template tag like stateless component in JSX React

2021-01-29 Thread Jure Erznožnik


Aztec,

Just look in the dynamicforms/templates folder: all templates for input 
fields are built using this tag in its various forms. There's plenty of 
examples there. And yes, it's exactly what you asked for.


LP,
Jure

On 29. 01. 21 09:18, Aztec Rabbit wrote:
Curtis - This is nested block right? what i want is like tag 
include (can be called more than once) but with children.


Jure - I've read the documentation, can you give me a sample code? I 
am confused


Hmmm, but i think this feature is very useful (for card, container, 
wrapper, and anythink with different content) and each component can 
be included in other components, thats awesome. I think this feature 
should be in django core, but, yes, I understand.


On Friday, January 29, 2021 at 11:27:26 AM UTC+7 jure.er...@gmail.com 
wrote:


Source is here

(https://github.com/velis74/DynamicForms/blob/master/dynamicforms/templatetags/dynamicforms.py



- see at end of file), documentation will follow shortly as we near
1.0 release (right now it's pretty pathetic, but it is there at
readthedocs), but there are examples & unit tests included showing
most of the functionality.

As far as I understood the feature wasn't perceived as something that
would improve Django as a whole. There is that thing we need to be
wary of - feature creep. Generally added features are preferred to be
provided as third party libraries. Easier to maintain, easier to find
that exact match you're looking for. Just look: Curtis also pointed
you to his own version, a bit different that ours, but maybe it would
suit you more?

LP,
Jure

On Thu, Jan 28, 2021 at 6:52 PM Aztec Rabbit 
wrote:
>
> Is there a link to the documentation or source code to the
library you created? And can i know why it is not accepted?
>
> On Thursday, January 28, 2021 at 9:34:03 PM UTC+7
jure.er...@gmail.com wrote:
>>
>> We have just created a tag like that in our dynamicforms
library. It's called "extendtemplateblock". Feel free to use or
copy, but it doesn't look like it's going to be accepted in Django
itself.
>>
>> We tried to keep API similar to the "include" tag, so it should
be easy to use.
>>
>> You can choose to only pull one block from your extended
template ("block" parameter) or define any of the blocks in it
using "block" nested blocks.
>>
>> LP,
>> Jure
>>
>> On 28. 01. 21 07:33, Aztec Rabbit wrote:
>>
>> Hi,
>>
>> I think template tag like in JSX is very useful, for example:
>>
>> > card.html
>>
>> 
>> {{ title }}
>> {{ component.children }}
>> 
>>
>> > index.html
>>
>> {% component './card.html' with title='Foo' %}
>> Bar
>> {% endcomponent %}
>>
>> --
>> 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 view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%40googlegroups.com

.

>
> --
> You received this message because you are subscribed to the
Google Groups "Django developers (Contributions to Django itself)"
group.
> To unsubscribe from this group and stop receiving emails from
it, send an email to django-develop...@googlegroups.com.
> To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/0cb2a1f6-9070-4875-90e2-eb6da241ea82n%40googlegroups.com

.


--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/109df365-750f-483d-8043-cf8c7c360c5en%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this

Re: Feature request: Template tag like stateless component in JSX React

2021-01-28 Thread Jure Erznožnik

Source is here 
(https://github.com/velis74/DynamicForms/blob/master/dynamicforms/templatetags/dynamicforms.py
- see at end of file), documentation will follow shortly as we near
1.0 release (right now it's pretty pathetic, but it is there at
readthedocs), but there are examples & unit tests included showing
most of the functionality.

As far as I understood the feature wasn't perceived as something that
would improve Django as a whole. There is that thing we need to be
wary of - feature creep. Generally added features are preferred to be
provided as third party libraries. Easier to maintain, easier to find
that exact match you're looking for. Just look: Curtis also pointed
you to his own version, a bit different that ours, but maybe it would
suit you more?

LP,
Jure

On Thu, Jan 28, 2021 at 6:52 PM Aztec Rabbit  wrote:
>
> Is there a link to the documentation or source code to the library you 
> created? And can i know why it is not accepted?
>
> On Thursday, January 28, 2021 at 9:34:03 PM UTC+7 jure.er...@gmail.com wrote:
>>
>> We have just created a tag like that in our dynamicforms library. It's 
>> called "extendtemplateblock". Feel free to use or copy, but it doesn't look 
>> like it's going to be accepted in Django itself.
>>
>> We tried to keep API similar to the "include" tag, so it should be easy to 
>> use.
>>
>> You can choose to only pull one block from your extended template ("block" 
>> parameter) or define any of the blocks in it using "block" nested blocks.
>>
>> LP,
>> Jure
>>
>> On 28. 01. 21 07:33, Aztec Rabbit wrote:
>>
>> Hi,
>>
>> I think template tag like in JSX is very useful, for example:
>>
>> > card.html
>>
>> 
>>   {{ title }}
>>   {{ component.children }}
>> 
>>
>> > index.html
>>
>> {% component './card.html' with title='Foo' %}
>>   Bar
>> {% endcomponent %}
>>
>> --
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/0cb2a1f6-9070-4875-90e2-eb6da241ea82n%40googlegroups.com.

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

Re: Feature request: Template tag like stateless component in JSX React

2021-01-28 Thread Jure Erznožnik

We have just created a tag like that in our dynamicforms library. It's
called "extendtemplateblock". Feel free to use or copy, but it doesn't
look like it's going to be accepted in Django itself.

We tried to keep API similar to the "include" tag, so it should be easy
to use.

You can choose to only pull one block from your extended template
("block" parameter) or define any of the blocks in it using "block"
nested blocks.

LP,
Jure

On 28. 01. 21 07:33, Aztec Rabbit wrote:

Hi,

I think template tag like in JSX is very useful, for example:

> card.html

> index.html

{% component './card.html' with title='Foo' %}
Bar
{% endcomponent %}
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%40googlegroups.com
.

Re: Collectstatic verbosity, again

2020-12-13 Thread Jure Erznožnik

I'd just like to mention that ManifestStaticFilesStorage doesn't output
one line. It will output a line for every file, even if file with that
hash already exists. This is without the clear flag.

I hope it's relevant to the discussion: seems different storages
implement output separately.

LP,
Jure

On 12. 12. 20 11:45, Fran Hrženjak wrote:
I would love to get only one line of output when running
`collectstatic` command with `-v1`. This is actually so, except when
using `--clear` option. With it I still get hundreds of lines of
output similar to:

Deleting 'admin/img/icon-calendar.svg'

There seemed to be a consensus about this, but I guess that the
`--clear` option went unnoticed?

https://code.djangoproject.com/ticket/28973
https://code.djangoproject.com/ticket/29464

I'd like to change this output level to 2:
https://github.com/django/django/blob/master/django/contrib/staticfiles/management/commands/collectstatic.py#L228-L230

Any reasons against?

Re: include_block template tag

2020-12-02 Thread Jure Erznožnik


Final comment for this:

we implemented the tag in our dynamicforms library (commit with initial 
implementation 
).


The initial implementation straight-out replaces the django include tag, 
giving it an additional option to also declare a block tag with nested 
blocks. That didn't work on Django 2.2. though, so the final 
implementation now splits the tag in block and non-block variants.


Anyway, I wanted to say that initial implementation wasn't much 
feature-creep on the include tag anyway. It should be a very small PR 
that would eliminate a huge disclaimer in documentation in exchange for 
a couple (literally) lines of new code.


TL;DR:

So: having implemented this, I'd say that code feature-creep is cheaper 
than documentation / support effort needed to explain away demands for 
the functionality?


Curtis, you're free to use this in your Sniplates. I'd just warn about 
the helper function parse_tag which we got here 
 
and don't know the license of, yet. We will get rid of it ourselves if 
there's no reply shortly, but it was convenient when programming the tag :).


To also attempt answer Carlton's fears / second thoughts: this form of 
the tag gives you content / presentation separation in your template. 
Your main template contains and provides all the data required for 
displaying and you then display it by including the actual rendering 
template, giving it the content in content blocks. This way you can 
easily swap presentation without having to swap an entire page's worth 
of template. Very easy to do "view result" vs "view code" in your 
templates then to give one example. In our templates we use it to 
seamlessly switch between various CSS frameworks that we support.


LP,
Jure


On 19. 08. 20 18:08, Carlton Gibson wrote:

Hey Sam.

(“I” is a placeholder in what follows…)

What I’m missing here, personally, having read this thread, and the 
old-one is motivating examples where I go "wow, yeah, that would 
really make my life easier”.


I read it and think yeah maybe. I see a couple of positive comments 
from people who’s judgement I would trust. But I STILL don’t really 
see what I’d gain. (I could spend hours thinking over it but it’s not 
clear I have that time.)


Then I see Curtis, who’s judgement I do trust, saying “I have this (or 
similar) working in my package over here”. I then think, well let’s 
push forward with that, and I’ll put it on the list to check out next 
time I need something in this ballpark. (Not a placeholder: I think I 
recall Curtis showing me this package in Florence a few years ago, but 
I have to admit to forgetting about it until this thread came up.)


I suspect it’s not really that pressing: after all this time, maybe a 
custom tag is good/easy enough…? — the recent survey showed that 
people aren’t abandoning the DTL on mass: the lack of this feature 
doesn’t seem to be enough to make people jump ship.


Maybe this is the missing feature, but can be show WHY it would be so 
good?


I think compelling use-cases gain converts. The advantage of the 
third-party package is it allows that to be worked out, outside the 
main development cycle, which is so slow, and had such strong 
backwards compatibility constraints that we simply can’t take things 
which are fully worked out… — it has to be right, or there about when 
we first take it.


C.




On 19 Aug 2020, at 15:34, Sam Willis > wrote:


Hi Carlton,

Thanks for chipping in.

As a long time user of Django (I first stated with it back in 2006) 
from my experience where is excels is in providing a full toolbox for 
building things for the web. The most successful “third party” apps 
and library’s tend to be very large editions of functionality rather 
than small functions and template tags. I personally stay away from 
small libraries as I have been bitten before when they are no longer 
maintained.


One of the criticisms of Node.js and from personal experience reasons 
why people prefer Django and similar “everything included” frameworks 
is the fragmentation of tools and large number of dependancies.


For this reason I don’t think there will ever be a successful “third 
party” implementation of this particular idea. It’s not a big enough 
tool for people to justify adding to their dependancies. (People are 
more likely to swap to Jinja which has Macros and are “sort of” 
similar if you squint at them)


Also, last year I had a quick look at my old implementation again and 
I think I came to the conclusion that it would require some small 
changes to core in order to work. I don’t remember what they are now 
though.


I understand completely that the barrier for adding new functionality 
to Django should be high. It important to maintain its 
“maintainability” and stop feature creep, but I also think that

Re: Revisiting Python support for after Django 3.2 LTS

2020-11-19 Thread Jure Erznožnik

Maybe I'm getting old, but:

This is going extremely (too?) fast. I don't think Ubuntu LTS releases
provide Python versions in time before the release chosen for the LTS
becomes expired. I've definitely had an issue like this with
django-channels and its required redis version.

So if I choose a few different LTSs for my server deployments, all of
them dropping support so aggressively, I will end up with something
out of date for a good portion of my server lifetime. For example,
Ubuntu 20.04 will be supported until 2025, but it is using python 3.7
which will only be supported until 2023... So if I want to keep
up-to-date, I will have to move to 22.04 as soon as it gets out. Same
with any Django LTS, same with any other thingy LTS. All of that often
requiring custom builds because maybe some other LTS won't be
supporting the new versions yet...

OTOH, the new features are so nice to use...

So, maybe we don't really have to be SO strict dropping support?

LP,
Jure

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson  wrote:
>
> Hi all.
>
> The Python version support policy reads [0]: "Typically, we will support a 
> Python version up to and including the first Django LTS release whose 
> security support ends after security support for that version of Python ends. 
> For example, Python 3.3 security support ends September 2017 and Django 1.8 
> LTS security support ends April 2018. Therefore Django 1.8 is the last 
> version to support Python 3.3."
>
> Updating that to current numbers we have:
>
> Python  EOL [1]
> 3.6 2021-12-23
> 3.7 2023-06-27
> 3.8 2024-10
> 3.9 2025-10
>
> Compared with the next two LTS versions for Django
>
> Django  EOL [2]
> 3.2 2024-04
> 4.2 2026-04
>
> By my reckoning this makes Django 3.2 "the first Django LTS release whose 
> security support ends after security support for that version of Python ends" 
> for both Python 3.6 and Python 3.7.
>
> Thus on the current policy we should drop support for both Python 3.6 and 
> Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0.
>
> I'm not sure what I think about that. I started writing this thinking just 
> about Python 3.6 — and then I looked up the dates.
>
> I think we should drop Python 3.6 at this time. asyncio is still evolving and 
> there are API changes between 3.6 and 3.7 that I think we need to get the 
> other side of.
>
> I think though that dropping support for Python 3.7 would be a little 
> aggressive — it will still have ≈18months of life at the point Django 4.0 is 
> released.
>
> I've argued previously for a loosening in the policy here[3]. Roughly, unless 
> there are technical reasons to advance, the situation I'd like is that, if 
> you have a (python-)supported version of Python then you can `pip install 
> Django` and get the latest major version. That is, roughly, the ideally, we'd 
> follow Python's support versions policy. (The flip side being I think we 
> should probably be actively dropping support for versions of Python as they 
> go EOL, even if between LTS versions.)
>
> With the change to Python's new annual release cycle[4], we're going to need 
> to adjust the policy somehow. Python 3.8 will be EOL for a full 2 years 
> before Django 4.2 is itself EOL.
>
> Can I ask for consideration and ideas at this stage, which hopefully can lead 
> to a fresh consensus?
>
> Thanks!
>
> Kind regards,
> Carlton
>
> [0] 
> https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
> [1] https://devguide.python.org/#status-of-python-branches
> [2] https://www.djangoproject.com/download/#supported-versions
> [3] https://groups.google.com/g/django-developers/c/YDJwI7uvgxU/m/c0ZPHaXZFQAJ
> [4] https://www.python.org/dev/peps/pep-0602/
>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/731dc68b-d3b9-4368-8efb-e77f8c3b9d89n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJ%3D9zieOHxefv%2BpUF%2BT2xch-N%2BWusMeeaFv%3DGzFhHY_LNw%3DfAw%40mail.gmail.com.

Re: Welcome email

2020-10-26 Thread Jure Erznožnik

I think this thread was abandoned, but wrongfully so. Frequency of 
unrelated posts is increasing lately.

Are there any serious issues with the moderation queue Google provides?

Reminder: https://support.google.com/groups/answer/2466386?hl=en


LP,
Jure

On Saturday, 25 July 2020 at 00:58:26 UTC+2 m...@kye.id.au wrote:

> This issue is exacerbated by similarly unaware / uncaring mailing list 
> users responding to support requests.
>
> What is the best path forward here?
>
> On 10 Jul 2020, at 3:09 pm, Jure Erznožnik  wrote:
>
>  
>
> I too volunteer for the screening job. 
>
> LP,
> Jure
> On 09/07/2020 16:10, Peter Inglesby wrote:
>
> Hi folks,
>
> Is there any moderation for posts from new users?  It can be enabled 
> <https://support.google.com/groups/answer/2466386?hl=en>, and I'd be 
> willing to be part of a team that filters posts from new users.
>
> All the best,
>
> Peter.
>
> On Thu, 9 Jul 2020 at 13:59, Adam Johnson  wrote:
>
>> I think that's a good improvement, not bikeshedding :)
>>
>> On Thu, 9 Jul 2020 at 13:17, Shai Berger  wrote:
>>
>>> Sorry for the bike-shedding, but I think the text should drop the
>>> "using Django" language. The people who come here with these questions
>>> clearly think of themselves as developers, not users.
>>>
>>> IMO It should go something like,
>>>
>>> Welcome to django-developers, the mailing list for discussion
>>> of the development of Django itself.
>>>
>>> This mailing list is not for support developing apps and
>>> websites with Django. For support, please follow the "Getting
>>> Help" page: https://docs.djangoproject.com/en/3.0/faq/help/ .
>>> This page will direct you to the django-users mailing list or
>>> other resources, so you can find people who are willing to
>>> support you, and to ask your question in a way that makes it
>>> easy for them to answer.
>>>
>>> Thanks,
>>>
>>> The Django Community
>>>
>>>
>>>
>>> On Wed, 8 Jul 2020 11:50:16 +0100
>>> Adam Johnson  wrote:
>>>
>>> > Okay I'm in favour. That said, there's already a banner on the groups
>>> > page:
>>> > 
>>> > This group is for the discussion of the development of Django itself.
>>> > If
>>> > > you want to ask questions about using Django, please post on
>>> > > django-users.
>>> > >
>>> > 
>>> > Suggested wording, adapted from my templated reply:
>>> > 
>>> > Welcome to django-developers, the mailing list for discussion of the
>>> > > development of Django itself.
>>> > >
>>> > > This mailing list is not for support using Django. For support,
>>> > > please follow the "Getting Help" page:
>>> > > https://docs.djangoproject.com/en/3.0/faq/help/ . This page will
>>> > > direct you to the django-users mailing list or other resources, so
>>> > > you can find people who are willing to support you, and to ask your
>>> > > question in a way that makes it easy for them to answer.
>>> > >
>>> > > Thanks,
>>> > >
>>> > > The Django Community
>>> > >
>>> > 
>>> > Who has access to add this? Someone from the DSF board, the ops team,
>>> > or the fellows?
>>> > 
>>> > On Mon, 6 Jul 2020 at 00:02, Ahmad A. Hussein
>>> >  wrote:
>>> > 
>>> > > +1 on this. Here's the relevant feature
>>> > > <https://support.google.com/a/users/answer/9308780?hl=en> I found.
>>> > >
>>> > >
>>> > > Ahmad
>>> > >
>>> > > On Sun, Jul 5, 2020 at 7:58 PM Adam Johnson  wrote:
>>> > >
>>> > >> I can't find a google groups feature that would allow this. Do you
>>> > >> know of one? It might otherwise require a custom bot.
>>> > >>
>>> > >> On Sun, 5 Jul 2020 at 16:14, Arvind Nedumaran
>>> > >>  wrote:
>>> > >>
>>> > >>> Oh I understand. I meant we could include the distinction in the
>>> > >>> welcome email and possibly a link to the other list.
>>> > >>>
>>> > >>> That may reduce the number of people who may be looking for help

Re: Instance Based Management?

2020-10-26 Thread Jure Erznožnik

Hi Matthew,

I think you found the wrong mailing list for this question. Might I
suggest you try django-us...@googlegroups.com? The question seems better
suited there.

That said, I don't know why you wouldn't want to use foreign keys in
this scenario, but Django does support a thing called content types
for
what you seem to be suggesting. There's a section on that page called
"Generic relations
".

Have a look.

LP,
Jure

On 27. 10. 20 01:21, Matthew Amstutz wrote:

Hello, I was wondering about instance based management. If I'm wrong,
please tell me.

When we have users and user generated content in a large database,
query times are increased significantly. Why is there no instance
based manager (like the models.Manager()) that basically generates a
table for each user and queries ONLY that table? Would that not just
flatten the database instead of increasing it's size? For example, if
we have 1,000,000 users all of which generate at least 10 posts per
day and one of the users only generates 5 in the span of 10 days,
unless we have a many to many field or something to hold those five
posts, the query time to find their posts would be ridiculous.

So if we have a table generated for each user that holds arbitrary
connections to anything they generate, it would in theory cut query
times significantly. Why is there no feature like this? Again, if I'm
wrong please tell me but the amount of tables doesn't matter and
instead the data they hold does so, in my understanding, 1,000,000,000
posts will always be the size of 1,000,000,000 posts no matter their
organization.

I've got ideas on implementation and even asyncronous supports as well
as customization but I have no idea how to bring this up to the django
developers and I'm not even sure it would work (though, no matter how
hard I try, I can't see anything wrong with it).

Let me know your input and if there's a way I can ask the django devs
about this and possibly even suggest a few things pertaining to it.
I'd like to help make django the best it can be and if this works and
we can implement it, django will be very fast with user generated content.

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

2020-10-10 Thread Jure Erznožnik

Sorry guys for asking a really stupid question, but :

I just made a search for pytz in Django master and found 17 occurrences 
in 5 files. More in docs and tests though. But still.

Isn't what we're debating here moot since Django itself doesn't really 
depend on pytz all that heavily? I mean, I realise the difference 
between the libraries bears grave consequences, but not in Django 
itself, AFAIR.

Seems like changing the implementation such that it would be able to use 
either approach (e.g. via a setting & a common import wrapper) shouldn't 
be too much of a hassle anyway.

Or am I missing something really obvious here?

LP,
Jure

P.S., but totally irrelevant to the discussion: I always found having to 
import pytz to handle TZ-related stuff wasn't optimal. I would have 
preferred having access to the necessary API from Django's framework.

On 9. 10. 20 21:21, Paul Ganssle wrote:

On 10/9/20 2:46 PM, Kevin Henry wrote:
> It is not really possible to make the shims work the same way 
because there's not enough information available to determine whether 
an adjustment needs to be made.

But since you're shimming pytz, don't you, by definition, have access 
to the all the same information that it has?

No for two reasions:

1. The shims wrap zoneinfo (and dateutil, though that is not relevant 
in this case), they do /not/ wrap pytz (and in fact do not have a 
dependency on pytz, though there is some magic that allows them to 
play nicely with things namespaced in pytz).
2. pytz's mechanism for attaching time zones is incompatible with PEP 
495. It would not really be possible to have the shims work both as 
pytz zones and as PEP 495 zones in all cases.

You are right that it would be possible to make it so that 
`shim_zone.localize()` basically does what pytz does, attaching a 
tzinfo specific to the offset that applies at that time, and for 
shim_zone.normalize() to make sure that the one attached is the right 
one, while also allowing `tzinfo=shim_zone` to work as a PEP 495 zone. 
That would make it very difficult to reason about the system, though. 
It would make it so that depending on how you attached your time zone, 
you would get different semantics for comparisons and arithmetic. 
Sometimes normalize would work and sometimes it wouldn't. So, for 
example, imagine you have:

def f(dt):
    return shim_zone.localize(dt)

x = shim_zone.normalize(f(datetime(2020, 10, 31, 12) + timedelta(days=1))

If someone changes `f` to instead use `dt.replace(tzinfo=shim_zone)`, 
the value for `x` changes, because some function you have is no longer 
using `localize`. Similarly, if we have say `datetime.now(shim_zone)` 
return a non-localized datetime, you have differences in semantics 
between `shim_zone.localize(datetime.now())` and 
`datetime.now(shim_zone)` (both of which are valid with pytz). If we 
have it return a /localized/ datetime, subtraction and comparison 
semantics would be affected, because now times localized to one or the 
other offset will be inter- rather than intra-zone comparisons.

Unfortunately there's simply no way to make it fully backwards and 
forwards compatible. The best options I see are a shim around pytz in 
3.2 that just adds warnings and doesn't do anything else, followed by 
a hard break in 4.0 or pytz-deprecation-shim in 4.0 and hard break in 5.0.

I think both are fine plans. I suspect that the slower plan will get 
people upgrading to 4.0 much faster, but it does have the disadvantage 
that some of the breakage is subtle and won't raise big errors (which 
is also the case, though to a lesser extent, with the faster plan).

In any case, it seems uncontroversial that 3.2 should support "bring 
your own zoneinfo", and I think most people agree that a feature flag 
in 3.2 is also a good idea, so to the extent that I have time to work 
on this, I'll work on those things.

Best,
Paul

So, for example, you could wrap pytz and keep a shadow copy of the 
pytz tzobject inside your tzobject, and use that to determine the 
correct behavior whenever a pytz-specific call is made. So when 
localize() is called you call localize on your internal object, and 
store that pytz EST tzobject. Then when normalize() is called you use 
that to get pytz's version of the EDT time.

> This occurs because localized pytz zones are different tzinfo 
objects, and as such comparisons and subtraction use inter-zone 
semantics.

Thank you for that example, I hadn't considered that. Unfortunately 
that is another fundamental incompatibility between pytz and any 
shim-around-zoneinfo (here 
 is a runnable version). 
I can't think of any way around that one.

> Of course, there is another option, which is to, rather than 
adopting a wrapper around zoneinfo, adopt a wrapper around pytz that 
does not follow PEP 495, but instead just deprecates `pytz`'s API and 
tells people to turn on the "use zoneinfo" feature flag.

Agreed, that is the other

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

2020-10-08 Thread Jure Erznožnik

I would definitely be in favor of an opt-in: it would give developers
time to move to the new system at their convenience.

Example: we're about to try and tackle the TZ issue in our apps and we
want to do it "globally" with one definitive solution. I'd much rather
do it on a library that is currently favoured, but not yet default than
on a deprecated one, even if it's not yet officially deprecated. We do
have some "import pytz", but currently they are few. Once we have a
proper approach to handling timezone stuff, there's likely going to be
more of them... or less, depending on the solution ;-)

LP,
Jure

On 7. 10. 20 17:25, Paul Ganssle wrote:

This sounds like a reasonable timeline to me. I think the breakage
will be relatively small because I suspect many end-users don't really
even know to use `normalize` in the first place, and when introducing
the shim into a fundamental library at work I did not get a huge
number of breakages, but I am still convinced that it is reasonably
categorized as a breaking change.

I do think that there's one additional stage that we need to add here
(and we chatted about this on twitter a bit), which is a stage that is
fully backwards compatible where Django supports using non-pytz zones
for users who bring their own time zone. I suspect that will help ease
any breaking pain between 3.2 and 4.0, because no one would be forced
to make any changes, but end users could proactively migrate to
zoneinfo for a smoother transition.

I think most of what needs to be done is already in my original PR, it
just needs a little conditional logic to handle pytz as well as the shim.

I am not sure how you feel about feature flags, but as a "nice to
have", I imagine it would also be possible to add a feature flag that
opts you in to `zoneinfo` as time zone provider even in 3.2, so that
people can jump straight to the 5.0 behavior if they are ready for it.

I should be able to devote some time to at least the first part —
making Django compatible with zoneinfo even if not actively using it —
but likely not for a few weeks at minimum. If anyone wants to jump on
either of these ahead of me I don't mind at all and feel free to ping
me for review.

Best,
Paul

On 10/7/20 10:48 AM, Carlton Gibson wrote:

Hi Paul.

Thanks for the input here, and for your patience

> I am fairly certain this is going to be a tricky migration and will
inevitably come with /some/ user pain. I don't think this will be
Python 2 → 3 style pain, but some users who have been doing the
"right thing" with pytz will need to make changes to their code in
the long run, which is unfortunate.

Looking at all the docs, your migration guide on
pytz_deprecation_shim, the example Kevin gave
, where we do some
arithmetic in a local timezone, and call `normalize()` in case we
crossed a DST boundary, there's no way we can do this without forcing
a breaking change somewhere.

So, probably, I've been staring at this too long today, but I think
we should introduce the shim in Django 4.0. Django 3.2, the next
major release will be an LTS. If we hold-off introducing the change
until 4.0, we can flag it as a breaking change in the 4.0 release
notes, with big warnings, allowing folks extra time to hang out on
the previous LTS if they need it.

What I wouldn't want to do is to bring the breaking change in in
Django 3.2, because we'll have a whole load of folks updating from
the 2.2 LTS at about the time when it goes End of Life, and with no
warning, that'd be a hard breaking change to throw on top of their
other issues.

We'd keep the shim in place for the entire 4.x series, removing in
Django 5.0 as per the deprecation policy
.

I think the advantages of doing it this way are two-fold:

* We allow people to focus on the semantic breaking change (in folds)
separately from the code changes per se — the logic may have changed
slightly in these cases, but it'll still run.
* It looks easier to migrate Django's code vs branching on a new
setting. (I didn't think through exactly what that might look like,
so happy to see a PoC from anyone.)

I'm more attached to the timeline (i.e. making the change after the
next LTS) than whether we use the deprecation shim or not, but can I
ask others to give this their thought too?

Thanks again!

Kind Regards,

Carlton

Re: include_block template tag

2020-08-19 Thread Jure Erznožnik


It definitely does. Thanks.

Jure

On 19/08/2020 14:03, Carlton Gibson wrote:

 From the thread, I’d suggest collaboration with Curtis if the ideas are 
similar enough.

Also from the thread: the idea seems to fit between include as we have it now, 
and a custom tag.
Maybe that gap hasn’t been wide enough to grasp sufficient interest?

I think the standard path for inclusion into core goes more or less:

* Here’s an idea
* Here’s a third-party implementation.
* Everyone[*] is using it, and the troubles have been ironed-out
* let’s merge it.

[*]: Everyone ≈ a good number.

For a third-party lib, there’s no need for it ever get to the last step. (It 
could but it doesn’t have to.)
Everything we can keep somewhere else makes Django more maintainable, so 
there’s a general preference for NOT including things if possible.

Hopefully that makes sense.

Kind Regards,

Carlton



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/52b88e00-c2f7-1d10-f4e1-76d24294ba90%40gmail.com.

Re: include_block template tag

2020-08-19 Thread Jure Erznožnik

Hi Sam,

It seems that even your complete proposal with working code did not
receive any attention from the core developers at the time. It would
seem from that thread that Jonathan Slenders also made a similar
proposal / solution and it too was rejected. Well, his was at least
rejected - judging by his post.

Gathering such proposals in external projects like sniplates (proposed
by Curtis) seems like a good approach as long as the target library has
such enhancements in its scope. It would seem Curtis has issues
implementing stuff like that though: he proposed the same to you as
well, you allowed it, but it's not in his library.

Given the evidence, it seems there is no interest in core team to do
something like this. I am yet to figure out how decisions on feature set
are made: I have not found any document stating missions for various
django parts. Something like that could be very helpful in determining
whether to propose something to this list at all. It is difficult to
determine whether something would benefit from being in core django vs
in a separate library.

LP,

Jure

On 18/08/2020 17:57, Sam Willis wrote:

Hi Jure,

I think this would be a great addition to Django!

I also proposed something a few years ago which was almost identical
(https://groups.google.com/d/msg/django-developers/-75sOjhJuRU/ax_TZJgRmPQJ)
and had a basic implementation (it probably won't work anymore without
some tweaks). However from my experience then it will be difficult to
get this into core without the championing from a core developer.

If there was enough interest I would certainly be happy to contribute
to the feature!

Sam

On Monday, August 17, 2020 at 10:05:29 AM UTC+1, Jure Erznožnik wrote:

While rendering templates we often come into situations where data
remains the same, but sometimes we want to render it one way,
other times - another.

Examples:

a library supporting various CSS frameworks. You would always
render panel
<https://getbootstrap.com/docs/3.3/components/#panels-heading>
title and panel body, but bootstrap does it using one HTML,
material uses another.

you may decide to render a piece of data in a panel, input, table
cell, etc.

analysis:

There's a huge note with include tag
<https://docs.djangoproject.com/en/3.1/ref/templates/builtins/#include>
clarifying how include tag is NOT used for purposes listed above.
This leads me to believe (but I have not researched it thoroughly)
that the question has been asked many times before.

proposal:

implement support for passing HTML renders into an included template.

I see two possible approaches for this:

Approach 1 template example:

{% includeblock template with ... %}
{% subblock block1 %}
HTML code
{% endsubblock %}
{% subblock block2 %}
HTML code
{% endsubblock %}
{% endincludeblock %}

block1 and block2 would be blocks defined in template using
existing block syntax. I'm not sure if recycling existing block
tag would be possible in this context, but I would certainly
prefer to avoid new template tag syntax. Basically what this tag
would do is first evaluate the subblocks, then override the blocks
defined in the template, then render the template.

Approach 2 template example:

{% block block1 as block1_var %}
HTML code
{% endblock %}
{% subblock block2 %}
HTML code
{% endsubblock %}
{% include template with block1=block1_var block2=block2_var %}

This approach is a bit less structured than the first one, but it
requires a lot less modification. Basically it would only add the
with parameter to store block render in a variable instead of
actually rendering it to output. Possible problem with block
inheritance within the template.

Would either of the above be interesting to include in Django
templating code?

Thanks for your consideration,
Jure

--
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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/bb721678-2220-41ae-8624-29661df353f2o%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/bb721678-2220-41ae-8624-29661df353f2o%40googlegroups.com?utm_medium=email_source=footer>.

Re: Cache framework

2020-08-19 Thread Jure Erznožnik


May I ask where that survey was conducted? I totally missed it.

LP,
Jure

On 18/08/2020 15:33, Carlton Gibson wrote:

I think we SHOULD bring a redis cache backend into core.

The recent survey showed 70% of our users using redis for caching, with 20%+ 
using memcached.

Nick is working on
https://github.com/django/django/pull/13310 now.

This’ll give us three memcached backends and zero for redis.
That doesn’t seem right.

The cache backend API is small and redis is stable. I think we can offer that, 
freeing third party packages some work, to do the more interesting things.

C.



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c5902e09-c9b5-4a99-5d83-c53dd72ba38f%40gmail.com.

include_block template tag

2020-08-17 Thread Jure Erznožnik

While rendering templates we often come into situations where data
remains the same, but sometimes we want to render it one way, other
times - another.

Examples:

a library supporting various CSS frameworks. You would always render
panel
title and panel body, but bootstrap does it using one HTML, material
uses another.

you may decide to render a piece of data in a panel, input, table cell, etc.

analysis:

There's a huge note with include tag

clarifying how include tag is NOT used for purposes listed above. This
leads me to believe (but I have not researched it thoroughly) that the
question has been asked many times before.

proposal:

implement support for passing HTML renders into an included template.

I see two possible approaches for this:

Approach 1 template example:

{% includeblock template with ... %}
{% subblock block1 %}
HTML code
{% endsubblock %}
{% subblock block2 %}
HTML code
{% endsubblock %}
{% endincludeblock %}

block1 and block2 would be blocks defined in template using existing
block syntax. I'm not sure if recycling existing block tag would be
possible in this context, but I would certainly prefer to avoid new
template tag syntax. Basically what this tag would do is first evaluate
the subblocks, then override the blocks defined in the template, then
render the template.

Approach 2 template example:

{% block block1 as block1_var %}
HTML code
{% endblock %}
{% subblock block2 %}
HTML code
{% endsubblock %}
{% include template with block1=block1_var block2=block2_var %}

This approach is a bit less structured than the first one, but it
requires a lot less modification. Basically it would only add the with
parameter to store block render in a variable instead of actually
rendering it to output. Possible problem with block inheritance within
the template.

Would either of the above be interesting to include in Django templating
code?

Thanks for your consideration,
Jure

Cache framework

2020-08-17 Thread Jure Erznožnik

Apologies for wall of text, but it's a complex issue I'm raising. 
Hopefully you will see something you thought about in the recent past. I 
have also indented the rationalisation part, so if it's TL;DR, don't 
read it. Well, on with it:


I've lately had some dealings with Django caching framework that left me 
somewhat wanting. To be specific, these things stood out:


1. There is no listing function. It is impossible to enumerate keys
   matching a pattern
2. There are no synchronisation functions.
3. There is no default redis support

Proceeding with rationalisation:

   #1: Sometimes I just need records in the cache that would be easily
   iterable, easily insertable, but both with minimum locking / racing.
   An enumeration function would allow for easy retrieval of thusly
   inserted objects.

   This proposal is partly opposed by having support for atomic list
   operations, such as cache.append_to_list(key, items) and
   cache.pop_from_list(key, num_of_items). Such operations could be
   supported using #2

   Another possible approach might also be a cache.pop(key) function
   that would atomically retrieve current value and delete the cache
   entry at the same time. Such operation could also be supported using
   #2.

   #2: With complex data, there comes a need for synchronisation
   functions. The easiest to solve with existing commands, we have
   implemented a mutex class supporting "with Mutex('mutex_name'):" syntax.

   There was some debate within our team on what to do when even the
   cache is distributed among multiple cache servers, but we reached no
   consensus. It would definitely require a (separate) shared cache
   server, so maybe it's not really a huge problem as Django caching
   framework already supports that.

   #3: Current cache implementations in Django doesn't have redis support.

   I don't know whether that should be included or not, but even
   django-channels implements the channels backend with redis (and only
   redis), not with memcached. TBH I do not recall why we went with
   redis and not memcached when we were deciding infrastructure for our
   servers, but is seems the rationale we used lead to similar
   conclusion as that of django-channels developers.

   There was also a recent discussion debating obsoletness of memcached
   (i think, but did not verify just now) implementation. IIRC the
   problem was use of library that is no longer maintained while an
   up-to-date, well maintained alternative was available.

   Furthermore the django-channels redis backend is implemented such
   that it requires redis server 5.0 or greater (use of BZPOPMIN
   command). Ubuntu 18.04 LTS does not have this version in its apt
   archives. This I only mention as a curiosity as it's pretty easy to
   solve, but still, it was a nuisance requiring a workaround.

   I find it interesting that django-channels does not implement that
   channels backend with standard Django caching framework, but it
   seems it was inadequate at the time (hint: redis 5.0 requirement).
   Perhaps I should look up the discussion threads where channels
   developers were deciding this approach to see what made them decide
   for custom redis approach vs using the Django cache.

   TBH I find this one the hardest: there is third-party support for
   Redis caching in django. There must be a policy behind what cache
   backends should be supported and for some reason that policy has so
   far excluded Redis. However, I find it conflicting that
   django-channels would then only support Redis for some of its
   functionality. I hope I'm not going into politics too much here.


To finish up, is this something that Django core team would be willing 
to consider for improvement? If yes, I would be willing to provide 
relevant PRs (Django only), but I wanted to feel the general attitude 
towards the problem first.


To be clear, this is what I'm proposing to implement:

1. cache.list(pattern) returning matching cache entries. I would like
   the pattern to be regex compatible, but I have not done any analysis
   on listing support for existing backends yet.
2. hand over the Mutex class we implemented
3. quite frankly, I don't know what to do about this one. We're using
   django-redis package for our Redis backend, so I would hate to write
   something up from scratch. What is the standard approach with this,
   if support is decided by the core team?
4. While at it, I have seen that various backends now implement their
   own pickling. With the exception of memcached, they all implement
   the same thing. Perhaps it would be beneficial to move pickling
   functionality to BaseCache?

Thank you for your consideration,
Jure

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

Re: Critical hints about Django migrations

2020-08-09 Thread Jure Erznožnik

It seems to me that article is written by a guy who has a lot of
knowledge of the database engine and has some issues (mostly) with
Django migrations system. His solution to the problem is to use direct
SQL statements which of course can be more finely controlled than
whatever Django creates.

While Django migrations really is a pain sometimes, it does 95% of work
automatically and keeps you from worrying about schema changes that you
made in your models. While I've been programming migrations by hand all
my life before Django - and I DO see the advantages - I'm not sure I
need those advantages. I could use some simplification and a bit less
nitpicking, but I haven't yet encountered a need to hand code the
migrations.

The rest of features Django doesn't have, I can use (and sometimes do)
just the way he proposes: by simply defining them and having the DB
server do it without Django's knowledge. So, no problem there...

So far Django has kept most of the DB issues I've been suffering from in
the past away from me. And I'm quite happy to have them there. Away.

LP,
Jure

On 06/08/2020 21:27, Paolo Melchiorre wrote:

HI all,

I would suggest reading this interesting article by Daniele Varrazzo
(the maintainer of psycopg2 and creator of psycopg3) on Django
migrations.

It contains some criticisms but I also think some interesting hints
for improving Django ORM :
https://www.varrazzo.com/blog/2020/07/25/surviving-django/

See you,
Paolo

Re: Suggestion: "django-admin startproject" should not put secrets in settings.py

2020-07-28 Thread Jure Erznožnik

+1 on this approach.

No problems with external storage mechanisms where the newbie then needs
to do something to provide the required data. It's all done neatly in
Python, but secrets themselves are conveniently placed in a different file.

LP,
Jure

On 26/07/2020 15:09, Roy Smith wrote:
In the past, I've worked on a couple of django projects where we
violated the:

# SECURITY WARNING: keep the secret key used in production secret!"

advice because on day one, somebody didn't know what we they were
doing and never fixed it. Looking around at a collection of django
projects (by various developers), I see that's often the case.
SECRET_KEY, oauth keys, aws keys, etc all end up in settings.py
files. And show up in github, etc.

This is not terribly surprising. I expect most people just sit down
with the tutorial
,
follow the first example:

$ django-admin startproject mysite

and instantly have a working, but insecure, setup.

So, why not have startproject start people off on the right foot?
Build a settings.py file and a secret_settings.py file. Put the
SECRET_KEY in secrets.py. Have settings.py do "from secret_settings
import SECRET_KEY". Make secret_settings.py mode 0400 by default (or
whatever that translates to on windows). Print out a message telling
people to exclude secret_settings.py from version control.

As people add more secrets, they have a low-effort path to continuing
to do something reasonable. A more sophisticated user can tear that
out and replace it with their own secrets infrastructure. But, at
least we will have started newbies off with something reasonable.

I see this has been discussed before
,
but I disagree with a lot of the opinions in that thread. This
wouldn't be forcing developers to do it any specific way. It just
provides a default that's better than the current default. Expecting
that newbies to follow best practices just because they're documented
somewhere is irrational, as can be seen by perusing github.

Re: Welcome email

2020-07-10 Thread Jure Erznožnik


I too volunteer for the screening job.

LP,
Jure

On 09/07/2020 16:10, Peter Inglesby wrote:

Hi folks,

Is there any moderation for posts from new users? It can be enabled 
, and I'd be 
willing to be part of a team that filters posts from new users.


All the best,

Peter.

On Thu, 9 Jul 2020 at 13:59, Adam Johnson > wrote:


I think that's a good improvement, not bikeshedding :)

On Thu, 9 Jul 2020 at 13:17, Shai Berger mailto:s...@platonix.com>> wrote:

Sorry for the bike-shedding, but I think the text should drop the
"using Django" language. The people who come here with these
questions
clearly think of themselves as developers, not users.

IMO It should go something like,

        Welcome to django-developers, the mailing list for
discussion
        of the development of Django itself.

        This mailing list is not for support developing apps and
        websites with Django. For support, please follow the
"Getting
        Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ .
        This page will direct you to the django-users mailing
list or
        other resources, so you can find people who are willing to
        support you, and to ask your question in a way that
makes it
        easy for them to answer.

Thanks,

The Django Community



On Wed, 8 Jul 2020 11:50:16 +0100
Adam Johnson mailto:m...@adamj.eu>> wrote:

> Okay I'm in favour. That said, there's already a banner on
the groups
> page:
>
> This group is for the discussion of the development of
Django itself.
> If
> > you want to ask questions about using Django, please post on
> > django-users.
> >
>
> Suggested wording, adapted from my templated reply:
>
> Welcome to django-developers, the mailing list for
discussion of the
> > development of Django itself.
> >
> > This mailing list is not for support using Django. For
support,
> > please follow the "Getting Help" page:
> > https://docs.djangoproject.com/en/3.0/faq/help/ . This
page will
> > direct you to the django-users mailing list or other
resources, so
> > you can find people who are willing to support you, and to
ask your
> > question in a way that makes it easy for them to answer.
> >
> > Thanks,
> >
> > The Django Community
> >
>
> Who has access to add this? Someone from the DSF board, the
ops team,
> or the fellows?
>
> On Mon, 6 Jul 2020 at 00:02, Ahmad A. Hussein
> mailto:ahmadahusse...@gmail.com>>
wrote:
>
> > +1 on this. Here's the relevant feature
> > 
I found.
> >
> >
> > Ahmad
> >
> > On Sun, Jul 5, 2020 at 7:58 PM Adam Johnson mailto:m...@adamj.eu>> wrote:
> >
> >> I can't find a google groups feature that would allow
this. Do you
> >> know of one? It might otherwise require a custom bot.
> >>
> >> On Sun, 5 Jul 2020 at 16:14, Arvind Nedumaran
> >> mailto:arvindamir...@gmail.com>> wrote:
> >>
> >>> Oh I understand. I meant we could include the
distinction in the
> >>> welcome email and possibly a link to the other list.
> >>>
> >>> That may reduce the number of people who may be looking
for help
> >>> but end up here mistakenly?
> >>>
> >>> Get Outlook for Android 
> >>>
> >>> --
> >>> *From:* django-developers@googlegroups.com
 <
> >>> django-developers@googlegroups.com
> on behalf of אורי
> >>> mailto:u...@speedy.net>> *Sent:* Sunday,
July 5, 2020 8:39:22 PM
> >>> *To:* Django developers (Contributions to Django itself) <
> >>> django-developers@googlegroups.com
>
> >>> *Subject:* Re: Welcome email
> >>>
> >>> I think because this list is called Django developers
and what we
> >>> call "Django users" are also developers who use Django.
But they
> >>> are developers.
> >>>
> >>> אורי
> >>> u...@speedy.net 
> >>>
> >>>
> >>> On Sun, Jul 5, 2020 at 5:59 PM Arvind Nedumaran
> >>> mailto:arvindamir...@gmail.com>> wrote:

Re: The blacklist / master issue

2020-06-16 Thread Jure Erznožnik

+1 on this discussion progression. I too struggled with certain 
expressions in my earlier English-learning days, but today the used 
expressions don't carry any unnecessary baggage for me as my 
understanding of them is purely technical. So, while I myself don't have 
a problem with them, I can see that others might.


I'd also dare to say there shouldn't be much flak to take anyway. The 
cause seems OK, but there is heightened pressure due to recent events. I 
would say this alone is the only thing that I see might be an issue: why 
exactly now?


LP,
Jure

On 15/06/2020 23:31, Aymeric Augustin wrote:

Hello,

In the context of access control, blacklist / whitelist makes sense 
only if the reader has a preconceived assumption that black = bad, 
illegal, forbidden / white = good, legal, authorized. You can probably 
see where I'm going.


Sure, blacklist / whitelist has nothing to do with race to start with, 
but I find the parallel with Apartheid sufficiently obvious to make it 
embarrassing, certainly because I'm not a native English speaker and I 
don't have enough background on what has racial overtones and what 
doesn't.


I mean, I had been living in the US for several months whet someone 
had to tell me the difference between "to screw" and "to screw up". 
(I'm grateful.) Do you really expect a guy like me to know that 
"blackface" has racial overtones but "blacklist" doesn't, and thus 
interpret the words correctly?


Besides, the connection didn't exist in the first place, but when 
people start making it, can we still pretend it doesn't exist? If I 
wanted to troll a linguist, I'd say it's akin to pretending that words 
people actually use don't exist until they're written in a dictionary ;-)


Lastly, another argument for the statu quo is that humans are good at 
interpreting words based on context, so "black" in "blacklist" isn't a 
problem. However, I counter that humans are even better at making 
connections and detecting patterns, even subconsciously and sometimes 
even when the pattern doesn't actually exist. That's quite likely to 
happen here.


I agree that this isn't as clear cut as master / slave. That must be 
why it took us six years to go from the master / slave discussion to 
the blacklist / whitelist discussion.


No one's gonna get confused on the meaning regardless of whether we 
make the change or not. This is "just" a political marker. It doesn't 
have one correct answer. It has several answers whose correctness vary 
over time.


I think we'll make the change at some point. Some progressives will 
hate us for taking so much time. Some conservatives will hate us for 
being snowflakes. Since we already started spending time on this 
discussion, we might just as well do the change while we're there, 
take some flak for a couple days, and move on.


Best regards,

--
Aymeric.

On 15 Jun 2020, at 21:56, Daniele Procida > wrote:


Tom Carrick wrote:


I don't think there is an easy answer here, and I open this can of worms
somewhat reluctantly. I do think Luke is correct that we should be
concerned with our credibility if we wrongly change this, but I'm also
worried about our credibility if we don't.


There are plenty of black-something terms in English that are both 
negative and have nothing whatsoever to do with race. The black and 
the dark are those things that are hidden and sinister, as contrasted 
with those that are in the light and open to scrutiny (black magic, 
dark arts, black legs, blackguards, blackmail, etc).


I think it would look pretty silly to confuse meanings that refer to 
what's shadowy and obscure with things that have racial overtones, 
and I think we should steer well clear of that. It's not at all like 
metaphors such as master/slave.


If we made such a change and tried to justify it on the grounds of a 
connection between race and the word "black" in those terms, we'd be 
rightly laughed at.


1000 neckbeards would immediately come out of the woodwork having 
done some basic web searches going 'neeer neeer neeer, the Django 
Software Foundation overflowing with snowflakes who think that 
"blacklist" means [etc etc etc]', and who has the stomach for that?


Even choosing to do it on the basis of the potential for offence 
seems to be a fairly flimsy argument.


On the other hand, we can do whatever the hell we like.

We don't have to justify anything to anyone. If we want to change 
words in *our* framework, it's absolutely nobody's business but our own.


If black members of the DSF or the community are disheartened that 
the word "black" gets to refer to so many negative things and are 
bothered when they see them in Django, then that alone is sufficient 
justification.


If we want a reason for changing "blacklist" (or whatever), it's that 
people in our community said they would feel better about it and 
asked to have it changed.


Acknowledging how someone feels about something and acting because 
you care about their

Re: ./manage.py settings

2020-06-12 Thread Jure Erznožnik

There was a GSoC proposal

this year for a SecretsManager that could conceivably make what you
suggest possible. Wasn't accepted though.

Not sure if it's a security issue with beginners that require help
setting up settings.py though. Should be easy enough to just paste the
file (modified) somewhere.

LP,
Jure

On 12/06/2020 13:51, René Fleschenberg wrote:

Hi,

Just a thought that came to my mind: It would be useful to have a
command that dumps the run-time settings, but automatically replaces
secrets with dummy values.

I think this should not be too hard to do for Django's own secret
settings, and maybe it can also be done for some known common third
party settings (AWS_SECRET_ACCESS_KEY, for example).

Even better would be to have a standardized way of marking settings as
secret, though I am not sure if this is feasible.

Regards,
René

On 6/12/20 5:09 AM, '1337 Shadow Hacker' via Django developers
(Contributions to Django itself) wrote:

Hi all,

So, just on #django IRC channel there was a user trying to help another
one, asking for some settings through ./manage.py shell etc ... A
discussion that went kind of like "Print out your settings" "How would I
print, I tried that, I'm in settings.py" "With ... print()" "but in the
shell, __file__ is not defined" and so on, and 20 minutes later the user
couldn't print his settings and left.

TBH I'm pretty fine because the users I support are on projects where I
added djcli to the requirements, so I can always ask the to do the djcli
setting command to print out a setting. It's very useful useful to me, I
think Django should a command to dump runtime settings because that
should make the life easier of Django users trying to support newbies in
their own projects, where they don't have installed a custom command,
it's pretty cheap to make and maintain and should save quite some
frustration from both sides of the story.

What do you think ?

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/X2HkH0yasxu2XVxBuVkbTfdSHctL7y3pW9seQ8CHFcVOpmsiyN80JlDYH2g5F6IfPvEdN4zyG6vuxj2HEMJaXUSErMUM5IT70iLvkxsrc7U%3D%40protonmail.com
.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

2020-05-06 Thread Jure Erznožnik

I agree. If anything, I've always had issues with GET & POST being
different entities in the first place, but never with their names. I
would really like to see an entity combining both of them. THAT one,
maybe the preferred way of doing so, would be lowercase, but RAW
representations of incoming data, I for one like them being upper case.
Always makes me think twice before playing with them.

The content negotiation thingy is also something I would like to see
more time invested in: I have a project where I have to hack & slash
DRF's implementation in order to get what I want, but perhaps I'm
tackling the issue incorrectly. But that's beside the point. People will
always try to do stuff framework developers didn't think of. What's
important is to give them a platform where they can do so easily.

LP,
Jure

On 06/05/2020 08:08, Carlton Gibson wrote:
Hmmm. I have to say I think there are areas where we could get a
better ROI on our time than this.

I always took the capitalisation of GET to come from HTTP
— I'd say that's where
PHP took it from too but 路‍♀️
That they're a bit "unpythonic" (Meh™) is OK: they serve to remind
that request was ultimately mapped from an HTTP request, and most of
that is still available if you care to dig.

Then request.form_data -> Oh, where's my form data, if not in
"form_data"? Well it's in "query_params"... Hmmm
That's no better learning experience. Folks still have to learn how
HTTP maps to request properties.

> ... better ROI...

There's lots we might take from DRF. The one that's come up before,
and which for work was began, but only began, was content negotiation.

I'd rather see work/energy/effort spent there.

Maybe we'd have different names if we began today. But this would be
very disruptive.
We've just had a discussion re url() suggesting that "deprecated but
not really" is an error on our part, and having two ways to do things
definitely isn't "pythonic".
So I'm inclined towards the range between -1 and -0 — but I haven't
had my coffee yet. 

Kind Regards,

Carlton

Re: Best Practices Creating a User

2020-05-05 Thread Jure Erznožnik

I think you found the wrong mailing list for this question. Might I
suggest you try django-us...@googlegroups.com? The question seems better
suited there.

LP,
Jure

On 05/05/2020 14:47, 'Debjyoti Biswas' via Django developers
(Contributions to Django itself) wrote:

I am a new Django user, I am working on a platform and I chose Django
to develop it solely because of how "batteries included" it feels.

I have to create users for my platform when they sign up, I was just
wondering if its best practice to use `User` from
`django.contrib.auth.models` for this. The user in my case will have
different levels of access and also there will be different types of
users like Vendors and Clients, logically I would use different user
Models.

Just wondering what's the best practice.

Regards
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/de7fa534-697e-44ec-8d1f-f0b28f8b861a%40googlegroups.com
.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

2020-04-24 Thread Jure Erznožnik


I too am in favour of this change.

But I read Andrew's comment differently: it's maybe not the 60 
characters, but some sort of "aggregation" we could be looking for. So 
maybe instead of "0026_remove_book_title_add_book_description" we could 
have "0026_book_add_remove" - especially when multiple fields were involved.


Alternatively, makemigrations could also generate multiple migrations 
(by default?) in order to obtain the goal of meaningful names? Have a 
parameter to force combining?


LP,
Jure

On 23/04/2020 21:34, Adam Johnson wrote:

Thank you all for the feedback.

Re: Andrew:

(60 is a bit long though, maybe we can bump it down to something a
bit shorter?)


Sure, how about 42? 

Re: Jon:

Did you have a suggestion for this situation? Revert back to
auto-naming or request the user to name the migration?


The patch as-is accumulates suggested names from operations in order, 
until the length is >=60 characters. Later operations just aren't 
mentioned.


Re: Claude:

An alternative could be to ask the user in interactive mode (and
keep the current behaviour in non-interactive mode).


I'd be up for this if we "pre-fill" the input with the auto-generated 
name, to make it easy to continue when we can suggest a reasonable 
name. Forcing users to type a name from scratch could be annoying 
especially when iterating on a new feature and dropping/rebuilding the 
respective migration.


Re: Caio:

I work on a project where migration names are fixed to “auto”. We
use a similar technique to those mentioned in the blog post to do
that. The reason is that we want to force developers to get
conflicts (git) on migration names during the review process,
rather than having to handle migration merging manually during deploy


Yes, this is a secondary problem with migrations, trying to keep the 
history linear via git.


I've used an alternative solution where a second file is created in 
the migrations folder called "latest" or similar, that simply contains 
the name of the latest migration file. This forces a conflict.


Although that's an alternative proposal, I think adding something like 
that to Django could be a good idea. It's better than forcing all 
migrations to have meaningless names.


On Wed, 22 Apr 2020 at 16:47, Andrew Godwin > wrote:


I am a little mixed on this change - the behaviour during the
initial development was indeed to concatenate names like this,
albeit only for adding fields or models; I thought it looked
unwieldy, which is why I added the "auto" name.

That said, the number is the only part that actually matters, and
while the date is sometimes useful for people to resolve merge
conflicts, I don't think it's better than more informative
autogenerated names, so I'm happy to go with the change.

(60 is a bit long though, maybe we can bump it down to something a
bit shorter?)

Andrew

On Wed, Apr 22, 2020 at 7:06 AM Adam Johnson mailto:m...@adamj.eu>> wrote:

Hi djangonauts,

In a blog post earlier this year I outlined my technique to
prevent Django creating migration files with automatic date
names. I had a lot of response with other techniques and ended
up adding two more techniques to the post. It's at

https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/
.

The problem with such migration names:

When you run Django’s |manage.py makemigrations|, it will
try to generate a name for the migration based upon its
contents. For example, if you are adding a single field,
it will call the migration |0002_mymodel_myfield.py|.
However when your migration contains more than one step,
it instead uses a simple ‘auto’ name with the current date
+ time, e.g. |0002_auto_20200113_1837.py|. You can provide
the |-n|/|--name| argument to |makemigrations|, but
developers often forget this.

Naming things is a known hard problem in programming.
Having migrations with these automatic names makes
managing them harder: You can’t tell which is which
without opening them, and you could still mix them up if
they have similar names due to being generated on the same
day.

Django *currently* sets the migration name to something other
than the automatic date name in two cases:

  * If the migration contains a single operation, it uses a
name based on that operation, e.g.
00023_remove_model_field, or 0024_add_model_field (but not
for all operation types)
  * If the migration consists *only* of model creation
operations, it combines their operation names names, which
come as just the lower-cased model names e.g.

Re: Adding ability to choose AutoField type (signed vs unsigned)

2020-04-12 Thread Jure Erznožnik

I would like to try again:
I believe having a general setting for autofields could cause all
sorts of issues. As illustrated, I immediately thought that some
people might want to use that for migrating to UUID fields for that (I
read about using them somewhere about when I started using Django 5
years ago). The point is that an option like that immediately sparks
imagination.

However, the problem being attempted at here is only migrating from
signed to unsigned integer. A very minor change most deployments would
not even be affected by.

That one could be handled less aggressively by:

>>OTOH, JUST FOR the unsigned vs signed integer PK, it should be relatively 
>>easy to modify makemigrations code detect existing migrations for the model, 
>>detect that the only difference is IntegerField vs PositiveIntegerField and 
>>in this case skip generating the migration (for migrating the field to an 
>>unsigned one). There could also be a flag to the management command 
>>specifying to force generating said migrations.

I believe this would be unintrusive enough allowing everyone to
migrate their models at will. Since most of users won't even notice
the difference, a solution like this could be preferable even if it
introduces one additional special case in the code.
OTOH, the proposed setting DOES provide more flexibility (to introduce
more varied options for the PK field), but a necessity for a
biginteger or guid or anything else, for that matter, is already
catered for in the API - by specifying the super-special pk manually
for the affected table.

I sure hope I'm not just derailing the discussion with my uninformed
ideas, but perhaps the minor change could be handled in a simpler
manner like proposed above.

LP,
Jure

On Sat, Apr 11, 2020 at 12:21 AM Caio Ariede  wrote:
>
> I believe that it is already possible to trigger new migrations in a 
> third-party app by changing its AppConfig.label, for example. Please correct 
> me if I’m wrong.
>
> From that perspective, it think it wouldn’t be wrong if a migration is 
> created after someone changes its AppConfig’s default_auto_field. The extra 
> migrations could be handled manually using MIGRATION_MODULES.
>
> I feel like adding such option to AppConfig would give a pretty good 
> flexibility, but I’m not sure it dismisses the use of 
> settings.DEFAULT_AUTO_FIELD. Specially if one desires to keep an old default 
> behavior.
>
> --
> Caio
>
>
>
> On Apr 10, 2020, at 04:29, Nick Pope  wrote:
>
> People can also choose to set this for a third-party app by subclassing the 
> AppConfig, but as you say, they'd then be forced to handle migrations 
> manually - is this even avoidable? I'm not sure how this would look for 
> moving to a new default though.
>
>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3FE8A93E-1A7F-436D-87CC-3D87A6C16801%40gmail.com.

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

Re: Adding ability to choose AutoField type (signed vs unsigned)

2020-04-06 Thread Jure Erznožnik


Sorry if I understand stuff incorrectly, but:

I agree with Adam where he discusses migration issues, but I also don't 
see how "DEFAULT_AUTOFIELD" setting could leave tables out of the 
migration(s).


My understanding is that it would cause immediate re-provisioning of all 
the pk fields, including in the core django modules and third-party 
modules. Some of them might have programmed their logic such as to 
include some integer math around the primary keys (and now all auto 
primary keys might be GUID).


If I understand the above correctly, the setting would have to be 
per-module. Could it simply be done like this:


class PKMixin(object): id= models.UUIDField(primary_key=True, )

Naturally, then all desired models would (also) derive from this mixin. 
A bit of a chore, but it would not require reconfiguration of all 
migrations, just the ones the programmer would specify - and would only 
be limited to their own module.


OTOH, JUST FOR the unsigned vs signed integer PK, it should be 
relatively easy to modify makemigrations code detect existing migrations 
for the model, detect that the only difference is IntegerField vs 
PositiveIntegerField and in this case skip generating the migration (for 
migrating the field to an unsigned one). There could also be a flag to 
the management command specifying to force generating said migrations.


Of course, ignore if this is gibberish.

LP,
Jure


On 06/04/2020 17:11, Adam Johnson wrote:

I'm in favour of the move. The setting strategy seems appropriate.

Simon's comment on the PR that this affects a small % of projects is 
true. But if your project does reach that scale, you're probably one 
of the bigger Django organizations in the world - hopefully key 
advocates for the framework. It's also possible to hit this on smaller 
projects with tables that import a lot of new rows, such as rolling 
time series data imports.


Also, this problem is *highly* asymmetric. Unnecessarily using big PK 
fields wastes a little storage space - unlikely to be noticed. 
Migrating to big PK fields can be a massive task (and can feel like 
"Django let you down here with bad defaults") ("Ruby on Rails does it 
right!").


It will need a careful migration guide though. Pre-existing projects 
may need to migrate one table at a time to reduce downtime/load, or 
keep the setting to the smaller auto field forever. I'm happy to help 
with this.


One thing we *could* add is a deploy time system check (or a 
management command, or something), to check what % of your tables' 
autofields' PK values have been "used up." This allows larger projects 
to prioritize their migrations.


On Mon, 6 Apr 2020 at 15:37, Caio Ariede > wrote:


Hi folks,

I’ve been working on ticket #56 "Primary key columns should be
UNSIGNED"  (really old) for a while now. It’s cumbersome and hard
to fix for some reasons, including backwards compatibility,
nothing that a single PR can solve but I’ll try to summarize where
things are at this moment. Hopefully we can get to a consensus so
I can continue.

The problem: Django has been storing primary keys as signed
integers since the beginning and this is considered a waste of
resources. Very few people seem to use negative values as primary
keys, apparently.

The desired solution: We want to change that in a
backwards-compatible way to not cause migrations to happen in all
projects using Django, in all of a sudden. This is where things
start to get difficult.

These are the links for the related ticket and PR up to this point:

https://code.djangoproject.com/ticket/56 (Primary key columns
should be UNSIGNED)
https://github.com/django/django/pull/11900 (PR)

—

While I was working on PR 11900, I stumbled across this other PR
8924 "BigAutoField as new default in 2.0”, and a particular
comment from Nick Pope got my attention:

https://github.com/django/django/pull/8924#issuecomment-516792989

The idea o adding a new DEFAULT_AUTOFIELD setting made a lot of
sense to me, as we would be able to keep things backwards compatible.

My first reaction after following that discussion, was to add a
missing part that would likely help, which was
the PositiveBigIntegerField. This is already fixed and merged:

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

—

Now that we have PositiveBigIntegerField merged in, we can also
have PositiveBigAutoField and finally move forward with ticket
#56. But we’d still need the ability to set a different default
Auto Field.

To achieve this, I’ve created a new ticket and Mariusz Felisiak
suggested to bring this discussion to the developers list, whether
or not we should move forward with this approach:

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

I want to hear from you folks, whether or not we can get to a
consensus on adding this new setting but also,

Re: Psycopg3 Redesign

2020-03-11 Thread Jure Erznožnik

His proposed changes look awesome to me!

IMHO, the biggest issue going async with current implementation was
connection pooling for async code. I feared that we might need huge
numbers of connections in certain scenarios, especially if the code
required altering the connections themselves. The proposed changes look
like they eliminate the issue altogether and I'm not referring to direct
async support alone.

LP,
Jure

On 11/03/2020 09:28, Asif Saif Uddin wrote:

Hi,

As this library is used by django, I thought it would be good to share
with django internals deveopers?

https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/

Hope it is useful.

./auvipy
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/faea6068-ec43-4da6-9780-1beaedaf0b16%40googlegroups.com
.

Re: Extent of async integration into 3.0

2020-01-08 Thread Jure Erznožnik

I am sorry, it seems I misunderstood that "reply to list" (quick way of
entering the "to" field) with subject change would create a new thread.
I'm not really used to mailing lists.

LP,
Jure

On 08/01/2020 10:31, Javier Buzzi wrote:
What does this have to do with what Johan Schiff asked about
"customizable urlize"?

On Tuesday, January 7, 2020 at 1:55:00 PM UTC+1, Jure Erznožnik wrote:

I've been monitoring this list for a bit, enough to see that 3.x
is now
moving in the async direction.

Is there a roadmap as to where we want to get with this direction?

Or, to ask more directly:

I have been looking into django-channels for a while in order to
start
catering for ever-increasing demands for more and more
responsiveness in
my apps. Basically I see django-channels as a good approach at
getting
the server to actually PUSH information to the clients. I sure
hope I'm
not just wishful here, but that's how I understood this particular
facet
of the project. There are some other things I also see quite
appealing
in there.

Anyway, I understood that django-channels was a project just a tad
too
big to simply be integrated into Django, but was heavily supported by
django core team?

OTOH I fear that with core django moving towards async will make
django-channels either hard to maintain or outright obsolete.

So, to finally arrive at the question: is the async action I have
been
seeing going anywhere near where django-channels is today or is it a
completely separate effort? If the latter, what's the future
outlook for
django-channels?

I sure hope I'm asking this in the right mailing list.

Thanks,
Jure

--
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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/17d5062b-b7cb-419f-9d72-560eb1e7ef34%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/17d5062b-b7cb-419f-9d72-560eb1e7ef34%40googlegroups.com?utm_medium=email_source=footer>.

Extent of async integration into 3.0

2020-01-07 Thread Jure Erznožnik

I've been monitoring this list for a bit, enough to see that 3.x is now
moving in the async direction.

Is there a roadmap as to where we want to get with this direction?

Or, to ask more directly:

I have been looking into django-channels for a while in order to start
catering for ever-increasing demands for more and more responsiveness in
my apps. Basically I see django-channels as a good approach at getting
the server to actually PUSH information to the clients. I sure hope I'm
not just wishful here, but that's how I understood this particular facet
of the project. There are some other things I also see quite appealing
in there.

Anyway, I understood that django-channels was a project just a tad too
big to simply be integrated into Django, but was heavily supported by
django core team?

OTOH I fear that with core django moving towards async will make
django-channels either hard to maintain or outright obsolete.

So, to finally arrive at the question: is the async action I have been
seeing going anywhere near where django-channels is today or is it a
completely separate effort? If the latter, what's the future outlook for
django-channels?

I sure hope I'm asking this in the right mailing list.

Thanks,
Jure

Re: Forms submitted by bots

2019-12-14 Thread Jure Erznožnik

We're using django-recaptcha (google recaptcha) and it requires a single
checkbox click for most "ordinary" users. Some do have to go through a more
complex image-identification process, but that one is a few seconds, not 30.

Lp,
Jure

On Sat, 14 Dec 2019, 14:29 אורי  wrote:

> Hi,
>
> I'm looking for a solution which will be zero time wasting for human
> users, not even clicking on the recaptcha's button, but on the other hand
> will prevent bots from submitting the form. I'm not sure how this can be
> implemented technically. But right now the "no bots" field I added prevents
> all the bots from submitting the forms on our websites. The only
> disadvantage of it is that it wastes about ~30 seconds of human users who
> have to type this number for the form to be submitted successfully.
>
> We also have a registration form but luckily it was not abused (yet) by
> bots. All the other forms on our website (except registration, login and
> contact) can only be submitted by logged in users anyway. And if the user
> is logged in - he is not a bot.
>
> I have another website which uses MediaWiki and there it was flooded by
> bots who also signed up for the website and created accounts and then
> pages. I guess these bots are MediaWiki-specific bots.
>
> אורי
> u...@speedy.net
>
>
> On Sat, Dec 14, 2019 at 1:41 PM Adam Johnson  wrote:
>
>> Preventing bot submissions is a bit of an arms race. Django could add
>> some protection but if many Django sites use it then bot scripts might be
>> adapted to workaround it.
>>
>> I've had success using django-recaptcha in the past:
>> https://github.com/praekelt/django-recaptcha . django-honeypot looks
>> good too.
>>
>> I think adding such protection would be a major project - research plus
>> implementation. I think it could make a good Google Summer of Code project
>> and will suggest it to the other DSF members.
>>
>> ‪On Fri, 13 Dec 2019 at 04:02, ‫אורי‬‎  wrote:‬
>>
>>> Thank you. How do I use django-honeypot and how does it work? How does
>>> it affect our human users and how does it affect the bots? I didn't
>>> understand from their website.
>>>
>>> I added a new feature request
>>> https://code.djangoproject.com/ticket/31085
>>> אורי
>>> u...@speedy.net
>>>
>>>
>>> On Fri, Dec 13, 2019 at 5:50 AM Kye Russell  wrote:
>>>
 This is more of a support question, but:
 https://github.com/jamesturk/django-honeypot will thwart the majority
 of (naive) automation attempts.


 On 13 December 2019 at 10:42:54 am, אורי (u...@speedy.net) wrote:

 Django developers,

 After releasing Speedy Net to production I received lots of spam to our
 contact forms [https://en.speedy.net/contact/ &
 https://en.speedymatch.com/contact/]. I found out that all of these
 spam messages were produced by bots. I had to add a new "no bots" field to
 this form, where I just ask users to type a specific number and validate it
 in the form. Since I added this field I didn't receive any more spam from
 the contact forms. I know Django is using CSRF cookie directives, but isn't
 it possible to prevent bots from submitting forms? I would like to remove
 the "no bots" field from this form as it is wasting time of our users who
 want to contact us. But I don't want to receive messages from bots. Is
 there another way to prevent bots from submitting forms?

 אורי
 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 view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/CABD5YeGj%2BFdsrmq%3D_Yai3bJHDSG_5Q1tmXSHLSQv4YexgomZxQ%40mail.gmail.com
 
 .

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

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to

Re: python-memcached is deprecated, but still used in core Django

2019-11-25 Thread Jure Erznožnik

I am currently attempting to involve myself more into Django
development. Have little to no idea how.

This seems to me like an easy pickings and I would be willing to port
existing code to the new package, if that's okay with the core team.

My expected approach:

1. verify claims

2. take the ticket

3. read up on the contribution guidelines

4. start with master, replace all memcached references with the new
library, possibly with minimal API impact

5. backport to 2.x, 1.x?

If this sounds remotely what's supposed to be done, let me know, I will
start working on it.

LP,
Jure

P.S. My planned involvement should ultimately reach around 200 hours of
yearly investment, should I prove to be useful. All pending verification
and validation, of course. I don't even know if that's a measurable
quantity, but right now these are my mid-term plans.

On 25/11/2019 00:45, Adrian Turjak wrote:

A while ago now I opened a ticket that we need to deprecate the
python-memcached backend in Django, and ideally make a new one which
uses Pinterest's pymemcache instead (which is now the most commonly used
one).

This is the ticket:
https://code.djangoproject.com/ticket/29887

But it seems there hasn't been any work on it. Someone assigned
themselves, but nothing beyond that has happened.

At this stage we really need to remove the docs that recommend
python-memcached, and the backend associated with it, and say officially
that only pylibmc is a valid and safe option from the core backends
using Memcached.

Considering how important Memcached is to a lot of projects, this ought
to be a high priority item, with some urgency given that Django core is
sporting support for a now very deprecated and outdated library (Last
released: Dec 16, 2017), with no future, and a clear successor in
pymemcache.

I'm sadly not in a position where I can contribute this myself, but
would be happy to test/review. Are there any willing contributors for
this? Or some people from the Django core team which will tackle this?

Cheers,
Adrian Turjak

Re: Deprecate HttpRequest.is_ajax

2019-11-21 Thread Jure Erznožnik


>> "I want A, B, C or D - I can give you B or D - Then D - OK"

Yes, this. As long as I have the chance to determine B & D BEFORE the 
content negotiation is complete. As opposed to having them fixed in code 
by e.g. specifying to_json & to_html methods.


LP,
Jure

On 22/11/2019 02:04, Matemática A3K wrote:

"I want A, B, C or D - I can give you B or D - Then D - OK"


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5ed3ebaf-9f89-8570-f6a6-9f4453d27751%40gmail.com.

Re: Deprecate HttpRequest.is_ajax

2019-11-21 Thread Jure Erznožnik

If possible, could the logic determining "the best match for your 
options" be overridable?


That way standard implementation would cater for 80/20 and everyone 
would still have an option to customise further.


LP,
Jure

On 21/11/2019 02:22, Matemática A3K wrote:



On Wed, Nov 20, 2019 at 11:52 PM James Bennett > wrote:


On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney
mailto:cur...@tinbrain.net>> wrote:


Yeah, I expected DRF had this "solved" already. From my own
experimentation, mapping `cgi.parse_header` over the the
"Accept" header value, split by comma, gets a usable result;
then sort that list by 'q' (defaulting to 1.0) and you have
your priority.


Both the original and forks seem to've been abandoned now, but the
mimeparse library encapsulated this into a nice little function
that took an Accept header, and a list of content-types you could
support in the response, and told you which one was the best
match. The code's still out there and under a permissive license
if somebody wants to pick it up again.


I think now that providing alternatives is the way to go :)

When 'is_ajax' is used for content negotiation, then proper content 
negotiation via the Accept headers should be done.


When 'is_ajax' is used for different content delivery (like routing), 
then make the convention explicit or refactoring should be done.

|
|
|In the case of content negotiation - 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation 
- this is only about media types (Accept-Language is already parsed in 
i18n).|

|
|
|Just parsing them it and make them available in the request - 
filtered by the supported ones - as an ordered list 
("accepted_media_types") and the preferred one 
("preferred_media_type") seems sufficient to me.|

|
|
|For functional views, it would be up to you to decide which one you 
support and how it is delivered with something like "if 'json' in 
request.preferred_media_type:".  We can add decorators for setting the 
response type for a specific media type and optionally returning a 406.

|
|
|
|For CBVs, a mixin should be done - something like 
ContentNegotiationMixin - where you define the the types you want to 
support in it (or otherwise use the settings) and you should define or 
override methods like "to_JSON", "to_XML", "to_LABEL" that will 
serialize your context into the media type that is the best match for 
your options.

|
|
|
||
|As more than one media type may correspond to one format, if a dict 
that labels the supported types is defined, something like:|

|
|
|SUPPORTED_MEDIA_TYPES_LABELS = {|
|  "application/json": "JSON",|
|  "text/json": "JSON",|
|  "application/pdf": "PDF",|
|  "text/html": "HTML",|
|}
|
||
||
|
|
|All the filtering can be easily done.
|
|
|
||
||
||
If so, the deprecation warning should be something like:
|DeprecationWarning: Request.is_ajax is deprecated. Given that the 
X-Requested-With header is not a part of any spec, it is not reliable. 
If you are doing content negotiation, see 
..docs/media_type_negotiation. If you are serving different content if 
the requests are made via AJAX, choose a convention for *your* project 
to discern them or consider refactoring your code (making your views 
specific to one intent for each verb).|

||
|
|
|If you agree - in general - with this direction, I can find time to 
implement it.

|

-- 
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 view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/CAL13Cg9x9ZWM0LTLoMMF%3DxgMydqrOKhEnhsRn-miFkVk5Rx6tg%40mail.gmail.com

.

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


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails

Re: Deprecate HttpRequest.is_ajax

2019-11-20 Thread Jure Erznožnik

Agree.

I understood that the discussion already turned to /"//If it is
deprecated, then the question that arises naturally is "What would be
the proper/new way of doing it?"//"/.

Also, to clarify:

What I wrote wasn't trying to impose a particular solution. I was just
hoping to point out the challenges involved.

LP,
Jure

On 20/11/2019 02:17, Matemática A3K wrote:

On Tue, Nov 19, 2019 at 9:20 PM Matemática A3K
mailto:matematica@gmail.com>> wrote:

On Tue, Nov 19, 2019 at 1:29 PM Jure Erznožnik
mailto:jure.erznoz...@gmail.com>> wrote:

Sorry for barging in like this, but this is actually a problem
I have been dealing with quite a bit lately, so:

In my work I very often have to decide, depending on what's
calling, what the rendered output might be. Ultimately I went
with DRF and its content negotiation, though even that one -
as implemented - sometimes isn't sufficient.

See, the problem sometimes isn't that you request JSON and
then get JSON, request HTML and get HTML.

I think content negotiation is about giving the option to request
the content in different formats, not rendering different content
based on which format is requested.

You also have to cater for exceptions. Maybe a 4xx would
return additional objects to insert into the DOM while a 200
would be fine with a JSON or even without data. What about 500?

This (and below) is about how to design a particular API for your
needs, I think it is out of the scope of the problem discussed.
The problem discussed is that is_ajax is not a reliable way to
determine the origin of a request (and then format the content of
a response)

(let me try to expand myself a bit so we can refocus)

If it is deprecated, then the question that arises naturally is "What
would be the proper/new way of doing it?" because it is a pattern that
have been applied previously (i.e.
https://docs.djangoproject.com/en/2.2/topics/class-based-views/generic-editing/#ajax-example),
then decorators have been proposed and refactors.

It seems to me that if there is no reliable way of determining it from
the back-end side, then in the end it will be a convention between the
front and the back. This could be a GET parameter, a "ClientWants:
JSONOrNothing" header, or whatever convention you like to make, but
not rely on a convention which seems to be fading out.

You can ensure the actual convention by setting the header manually
(as stated in the is_ajax doc) - as you do with the CSRF token.
Another convention could be better (i.e. "accepts json")

So far, is what the discussion went through to my understanding :)

I'm currently handling this with custom headers and the caller
(the browser) tells the server what kind of outputs it can
handle in different types of output.

The server then performs the branching at certain code points,
specifically the ones mentioned above. DRF allows me to choose
the appropriate renderer. Though I should mention here, that
the data is already serialised at that point: sometimes this
creates issues for renderers that might desire more
information to do their work. Just mentioning that render
stages need to be accounted for too. This may not be a problem
for core Django as it doesn't have stages.

Again, sorry, but still hoping this helped in some way.

LP,
Jure

On 19/11/2019 01:06, Matemática A3K wrote:

I agree with Adam that it should be deprecated with no
replacement.

The content negotiation is something that should be in but
not as a replacement of it, as a general improvement.

I think there shouldn't be a replacement because "is_ajax"
asks whether it came from a ""regular"" browser instead of
jQuery and with the content negotiation you ask if the
requester accepts a type - which can also lead to errors
because the client may also accept other types (no example
coming to my mind), and if so, it will lead to undesired
behavior.

The right approach would be making AJAX requests request JSON
output explicitly, by using a dedicated endpoint or by
appending something that manifests their intention - like in

https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html
is done with a get parameter. Not decide the response type by
where it came from as it is unreliable as stated before, it
provides convenience in some use cases but can lead to errors.

Seems better to me to refactor the view code so you can write
a different view for Ajax requests that returns a JSON
without code duplicati

Re: Deprecate HttpRequest.is_ajax

2019-11-19 Thread Jure Erznožnik

Sorry for barging in like this, but this is actually a problem I have
been dealing with quite a bit lately, so:

In my work I very often have to decide, depending on what's calling,
what the rendered output might be. Ultimately I went with DRF and its
content negotiation, though even that one - as implemented - sometimes
isn't sufficient.

See, the problem sometimes isn't that you request JSON and then get
JSON, request HTML and get HTML. You also have to cater for exceptions.
Maybe a 4xx would return additional objects to insert into the DOM while
a 200 would be fine with a JSON or even without data. What about 500?

I'm currently handling this with custom headers and the caller (the
browser) tells the server what kind of outputs it can handle in
different types of output.

The server then performs the branching at certain code points,
specifically the ones mentioned above. DRF allows me to choose the
appropriate renderer. Though I should mention here, that the data is
already serialised at that point: sometimes this creates issues for
renderers that might desire more information to do their work. Just
mentioning that render stages need to be accounted for too. This may not
be a problem for core Django as it doesn't have stages.

Again, sorry, but still hoping this helped in some way.

LP,
Jure

On 19/11/2019 01:06, Matemática A3K wrote:

I agree with Adam that it should be deprecated with no replacement.

The content negotiation is something that should be in but not as a
replacement of it, as a general improvement.

I think there shouldn't be a replacement because "is_ajax" asks
whether it came from a ""regular"" browser instead of jQuery and with
the content negotiation you ask if the requester accepts a type -
which can also lead to errors because the client may also accept other
types (no example coming to my mind), and if so, it will lead to
undesired behavior.

The right approach would be making AJAX requests request JSON output
explicitly, by using a dedicated endpoint or by appending something
that manifests their intention - like in
https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html
is done with a get parameter. Not decide the response type by where it
came from as it is unreliable as stated before, it provides
convenience in some use cases but can lead to errors.

Seems better to me to refactor the view code so you can write a
different view for Ajax requests that returns a JSON without code
duplication.

As a shortcut, something like "For simple AJAX endpoints wrap your
view with (something like) a "jsonview" decorator which will check the
accept header (with something like Claude's code), return the
appropriate error code if not, set the response type accordingly, and
you should return a dict of strings (you have to take care of the
serialization, i.e with
https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json).

On Mon, Nov 18, 2019 at 3:28 PM Tom Forbes > wrote:

What I meant by that is it’s not an approach that scales well to
lots of views. It might be better to have separate endpoints to
return JSON (e.g adding a /json suffix), and in the past this has
made services I’ve worked on a lot more maintainable and easy to
understand. But it’s not as quick to do as `if request.is_ajax()`
and requires a bit more upfront work. If you find you need to do
this a lot then maybe something more structured like Django Rest
Framework will be a better choice, which also handles content
negotiation really well (it can produce XML, CSV, JSON, etc etc).

On 18 Nov 2019, at 15:18, Matthew Pava mailto:matthew.p...@iss.com>> wrote:

“In my opinion there are not many good reasons to have to change
behaviour if a request is made via XHR. I think the most common
usage is to have a single view that returns a JSON response or a
HTML response depending on if XHR is used
(https://github.com/search?l=Python=request.is_ajax=Code),
which isn’t great and isn’t reliable.”
I do this. What would the best way to handle this? Perhaps the
proper practice should be documented when it is deprecated?
*From:*django-developers@googlegroups.com

[mailto:django-developers@googlegroups.com]*On Behalf Of*Tom Forbes
*Sent:*Saturday, November 16, 2019 10:16 AM
*To:*django-developers@googlegroups.com

*Subject:*Re: Deprecate HttpRequest.is_ajax
I would agree. Flask has done the same:
|DeprecationWarning: Request.is_xhr is deprecated. Given that the
X-Requested-With header is not a part of any spec, it is not
reliable|
In my opinion there are not many good reasons to have to change
behaviour if a request is made via XHR. I think the most common
usage is to have a single view that

42 matches

Mail list logo