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

[Kevin Henry]

Thanks to Paul for this proposal, and for working to put proper timezone 
usage into Python itself. PEP 495 and 615 definitely make Python better, 
and it seems inevitable that everyone will sooner or later switch over. I'm 
all for getting this process going in Django.

I have doubts over whether it's a good idea to use the shim, though. 
Briefly: 1) The shim is not backward compatible with pytz; 2) To avoid the 
subtle bugs resulting from that, the developer must review pretty much the 
whole scope of their datetime usage when they adopt the shim; therefore 3) 
it will probably be easier on everyone (both developers and Django itself) 
to simply switch directly to zoneinfo.

1) I'm referring to the change in semantics around datetime arithmetic (see 
here 

 
for the description in the shim documentation, and here 
 for a simple demonstration). 
Basically, if you're saying anything like "give me the datetime one day 
after this one", the value (both the wall-clock time and the actual 
point-in-time) could change once you stop using pytz.

2) Because of the above, the developer can't simply drop in the shim as a 
replacement for pytz. They need to review their codebase to see if they're 
doing datetime arithmetic anywhere. If they are, and if the change could 
affect the resulting values, they need to think about whether they want to 
use the old value or the new value. If they want the old value, they need 
to add some more code to recreate it. If they want the new value, they need 
to think about how to reconcile that change with previous behavior (and 
previous values stored in the database).

3) That's the hardest part of the transition, I think, so I'm not sure it's 
actually helpful to delay the rest. Removing calls to localize() and 
normalize() is comparatively simple. The difference between is_dst and fold 
does require some thought, but it's pretty much the same thought you need 
to do arithmetic right, and developers will benefit from making those 
changes at the same time.

In essence, the shim creates another, third way of handling datetimes, 
neither backwards compatible with pytz (due to the change in semantics) nor 
forward compatible with zoneinfo (due to the use of normalize(), etc.). And 
developers might end up in this twilight zone for years given typical 
Django deprecation cycles.

So my thought is simply to not use the shim; developers should either be 
doing things the pytz way or the Python (zoneinfo) way. I don't have strong 
feelings about how that should happen (e.g. a feature flag), or when it 
should happen.

Cheers,
Kevin

-- 
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/c3a3a788-2300-4361-ab06-0d89523424ecn%40googlegroups.com.

Re: The blacklist / master issue

[Alexander Lyabah]

Ahmad, 

> we should strive to set an international standard

No, we shouldn't we are here for creating framework, just treat your child 
well and it is enough to changing the world for the best.

> If a certain word is off-putting or problematic to individuals in our 
community

We can always find words that "off-putting or problematic to individuals in 
our community", the only difference between those words is that not all of 
them are on news-channel, but it should be a reason for changing anything.

> if it does not convey an accurate and least astonishing meaning to a 
non-native English speaker

Well, bases on this very week statement, we can change a lot of words in 
django source code. And it will not make Django community better, as well 
the world better.



On Friday, June 19, 2020 at 4:18:52 PM UTC+3, Ahmad A. Hussein wrote:
>
> I'd argue that since Django is an international framework, we should 
> strive to set an international standard. If a certain word is off-putting 
> or problematic to individuals in our community, and if it does not convey 
> an accurate and least astonishing meaning to a non-native English speaker, 
> then we should definitely change it.
>
> On Fri, Jun 19, 2020 at 2:54 PM Alexander Lyabah  > wrote:
>
>>
>> Django in international framework, not US-framework. You should not 
>> change variable names just because meaning of some words have been changed 
>> in US recently. Those words have been used in source-code for years, and 
>> nobody put racism in those word when this framework was founded and nobody 
>> puts any racism in when one is using for creation something big and 
>> meaningful.
>>
>> What I'm encourage you to do, is to thing farther than what is going on 
>> right now.
>>
>> If Django Foundation really want to help in this revolution - add a 
>> banner on that landing page. Feel free to choose
>>
>> https://eji.org/
>> https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/
>>
>> And this kind of contribution will work much better.
>>
>> Thank you, for this opportunity to share my opinion.
>>
>> On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>>>
>>> This ticket was closed wontfix 
>>>  as requiring a 
>>> discussion here.
>>>
>>> David Smith mentioned this Tox issue 
>>>  stating it had been 
>>> closed, but to me it seems like it hasn't been closed (maybe there's 
>>> something I can't see) and apparently a PR would be accepted to add aliases 
>>> at the least (this is more recent than the comment on the Django ticket).
>>>
>>> My impetus to bring this up mostly comes from reading this ZDNet article 
>>> 
>>>  
>>> - it seems like Google have already made moves in this direction and GitHub 
>>> is also planning to. Usually Django is somewhere near the front for these 
>>> types of changes.
>>>
>>> I'm leaning towards renaming the master branch and wherever else we use 
>>> that terminology, but I'm less sure about black/whitelist, though right now 
>>> it seems more positive than negative. Most arguments against use some kind 
>>> of etymological argument, but I don't think debates about historical terms 
>>> are as interesting as how they affect people in the here and now.
>>>
>>> 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.
>>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1c9178a3-cb80-428c-bacb-e8904695f6b6o%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/169bc6b4-5027-48f1-b4f9-a5ccc87dea14o%40googlegroups.com.

Re: The blacklist / master issue

[Alexander Lyabah]

let's not change the subject

we are not talking about black and white, we are talking about whitelist / 
blacklist and master / slave. Those statements have a big history in 
programming, which has nothing to do with slavery at all. 

Don't mix words with meaning and senses.

... It is important to understand when you make changes like this. ... 
words and meaning

I've never seen anyone who is by doing 'git checkout master', think about 
white race superior. - It is because master has a different meaning, 
different sense, which is nothing to do with slavery, and fight for freedom.

I've never seen anyone who is by playing white in Go-game, think about 
white race superior. (Even though by Go-rules white gets +7.5 points 
against Black at the beginning of the game) - it is because white has 
different meaning and different sense, and it is nothing to do with 
slavery, and fight for freedom (it is because blacks move first).

You have power here to do what ever you want to do in this framework. I 
what you to use common sense and don't follow the rules dictated by 
news-channels and big corporations. I want rules, you follow, being strong 
and independent from what is going on around. In that case you don't need 
to split community after next big news.

Thank you, with all respect.

On Friday, June 19, 2020 at 4:18:04 PM UTC+3, Tom Forbes wrote:
>
> As an international framework I think we should make our interface as 
> language and culturally agnostic as possible. ‘Allow’ and ‘Deny’ are simply 
> semantically clearer than ‘white’ and ‘black’. That alone is a convincing 
> argument for me.
>
> On 19 Jun 2020, at 13:55, Alexander Lyabah  > wrote:
>
> 
>
> Django in international framework, not US-framework. You should not change 
> variable names just because meaning of some words have been changed in US 
> recently. Those words have been used in source-code for years, and nobody 
> put racism in those word when this framework was founded and nobody puts 
> any racism in when one is using for creation something big and meaningful.
>
> What I'm encourage you to do, is to thing farther than what is going on 
> right now.
>
> If Django Foundation really want to help in this revolution - add a banner 
> on that landing page. Feel free to choose
>
> https://eji.org/
> https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/
>
> And this kind of contribution will work much better.
>
> Thank you, for this opportunity to share my opinion.
>
> On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>>
>> This ticket was closed wontfix 
>>  as requiring a 
>> discussion here.
>>
>> David Smith mentioned this Tox issue 
>>  stating it had been closed, 
>> but to me it seems like it hasn't been closed (maybe there's something I 
>> can't see) and apparently a PR would be accepted to add aliases at the 
>> least (this is more recent than the comment on the Django ticket).
>>
>> My impetus to bring this up mostly comes from reading this ZDNet article 
>> 
>>  
>> - it seems like Google have already made moves in this direction and GitHub 
>> is also planning to. Usually Django is somewhere near the front for these 
>> types of changes.
>>
>> I'm leaning towards renaming the master branch and wherever else we use 
>> that terminology, but I'm less sure about black/whitelist, though right now 
>> it seems more positive than negative. Most arguments against use some kind 
>> of etymological argument, but I don't think debates about historical terms 
>> are as interesting as how they affect people in the here and now.
>>
>> 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.
>>
> -- 
> 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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1c9178a3-cb80-428c-bacb-e8904695f6b6o%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-

Re: The blacklist / master issue

[Adam Johnson]

Alexander, it's not really up for debate any more. We've already merged the
PR's to Django.

On Sat, 20 Jun 2020 at 13:51, Alexander Lyabah  wrote:

> let's not change the subject
>
> we are not talking about black and white, we are talking about whitelist /
> blacklist and master / slave. Those statements have a big history in
> programming, which has nothing to do with slavery at all.
>
> Don't mix words with meaning and senses.
>
> ... It is important to understand when you make changes like this. ...
> words and meaning
>
> I've never seen anyone who is by doing 'git checkout master', think about
> white race superior. - It is because master has a different meaning,
> different sense, which is nothing to do with slavery, and fight for freedom.
>
> I've never seen anyone who is by playing white in Go-game, think about
> white race superior. (Even though by Go-rules white gets +7.5 points
> against Black at the beginning of the game) - it is because white has
> different meaning and different sense, and it is nothing to do with
> slavery, and fight for freedom (it is because blacks move first).
>
> You have power here to do what ever you want to do in this framework. I
> what you to use common sense and don't follow the rules dictated by
> news-channels and big corporations. I want rules, you follow, being strong
> and independent from what is going on around. In that case you don't need
> to split community after next big news.
>
> Thank you, with all respect.
>
> On Friday, June 19, 2020 at 4:18:04 PM UTC+3, Tom Forbes wrote:
>>
>> As an international framework I think we should make our interface as
>> language and culturally agnostic as possible. ‘Allow’ and ‘Deny’ are simply
>> semantically clearer than ‘white’ and ‘black’. That alone is a convincing
>> argument for me.
>>
>> On 19 Jun 2020, at 13:55, Alexander Lyabah  wrote:
>>
>> 
>>
>> Django in international framework, not US-framework. You should not
>> change variable names just because meaning of some words have been changed
>> in US recently. Those words have been used in source-code for years, and
>> nobody put racism in those word when this framework was founded and nobody
>> puts any racism in when one is using for creation something big and
>> meaningful.
>>
>> What I'm encourage you to do, is to thing farther than what is going on
>> right now.
>>
>> If Django Foundation really want to help in this revolution - add a
>> banner on that landing page. Feel free to choose
>>
>> https://eji.org/
>> https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/
>>
>> And this kind of contribution will work much better.
>>
>> Thank you, for this opportunity to share my opinion.
>>
>> On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>>>
>>> This ticket was closed wontfix
>>>  as requiring a
>>> discussion here.
>>>
>>> David Smith mentioned this Tox issue
>>>  stating it had been
>>> closed, but to me it seems like it hasn't been closed (maybe there's
>>> something I can't see) and apparently a PR would be accepted to add aliases
>>> at the least (this is more recent than the comment on the Django ticket).
>>>
>>> My impetus to bring this up mostly comes from reading this ZDNet article
>>> 
>>> - it seems like Google have already made moves in this direction and GitHub
>>> is also planning to. Usually Django is somewhere near the front for these
>>> types of changes.
>>>
>>> I'm leaning towards renaming the master branch and wherever else we use
>>> that terminology, but I'm less sure about black/whitelist, though right now
>>> it seems more positive than negative. Most arguments against use some kind
>>> of etymological argument, but I don't think debates about historical terms
>>> are as interesting as how they affect people in the here and now.
>>>
>>> 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.
>>>
>> --
>> 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-d...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/1c9178a3-cb80-428c-bacb-e8904695f6b6o%40googlegroups.com
>> 
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" grou

i encounter this error when i first try http://localhost:8000/ ( module 'json' has no attribute 'JSONDecoder')

[Ibar Osman Ibrahim]

Request Method: GET
Request URL: http://localhost:8000/
Django Version: 3.0.7
Exception Type: AttributeError
Exception Value: 

module 'json' has no attribute 'JSONDecoder'

Exception Location: 
E:\Blogs\ll_env\lib\site-packages\django\contrib\messages\storage\cookie.py 
in , line 27
Python Executable: E:\Blogs\ll_env\Scripts\python.exe
Python Version: 3.8.3
Python Path: 

['E:\\Blogs',
 'C:\\Python\\python38.zip',
 'C:\\Python\\DLLs',
 'C:\\Python\\lib',
 'C:\\Python',
 'E:\\Blogs\\ll_env',
 'E:\\Blogs\\ll_env\\lib\\site-packages']

Server time: Sat, 20 Jun 2020 13:28:59 +








import json

from django.conf import settings
from django.contrib.messages.storage.base import BaseStorage, Message
from django.http import SimpleCookie
from django.utils.crypto import constant_time_compare, salted_hmac
from django.utils.safestring import SafeData, mark_safe


class MessageEncoder(json.JSONEncoder):
"""
Compactly serialize instances of the ``Message`` class as JSON.
"""
message_key = '__json_message'

def default(self, obj):
if isinstance(obj, Message):
# Using 0/1 here instead of False/True to produce more compact json
is_safedata = 1 if isinstance(obj.message, SafeData) else 0
message = [self.message_key, is_safedata, obj.level, obj.message]
if obj.extra_tags:
message.append(obj.extra_tags)
return message
return super().default(obj)


class MessageDecoder(json.JSONDecoder):
"""
Decode JSON that includes serialized ``Message`` instances.
"""

def process_messages(self, obj):
if isinstance(obj, list) and obj:
if obj[0] == MessageEncoder.message_key:
if len(obj) == 3:
# Compatibility with previously-encoded messages
return Message(*obj[1:])
if obj[1]:
obj[3] = mark_safe(obj[3])
return Message(*obj[2:])
return [self.process_messages(item) for item in obj]
if isinstance(obj, dict):
return {key: self.process_messages(value)
for key, value in obj.items()}
return obj

def decode(self, s, **kwargs):
decoded = super().decode(s, **kwargs)
return self.process_messages(decoded)


class CookieStorage(BaseStorage):
"""
Store messages in a cookie.
"""
cookie_name = 'messages'
# uwsgi's default configuration enforces a maximum size of 4kb for all the
# HTTP headers. In order to leave some room for other cookies and headers,
# restrict the session cookie to 1/2 of 4kb. See #18781.
max_cookie_size = 2048
not_finished = '__messagesnotfinished__'

def _get(self, *args, **kwargs):
"""
Retrieve a list of messages from the messages cookie. If the
not_finished sentinel value is found at the end of the message list,
remove it and return a result indicating that not all messages were
retrieved by this storage.
"""
data = self.request.COOKIES.get(self.cookie_name)
messages = self._decode(data)
all_retrieved = not (messages and messages[-1] == self.not_finished)
if messages and not all_retrieved:
# remove the sentinel value
messages.pop()
return messages, all_retrieved

def _update_cookie(self, encoded_data, response):
"""
Either set the cookie with the encoded data if there is any data to
store, or delete the cookie.
"""
if encoded_data:
response.set_cookie(
self.cookie_name, encoded_data,
domain=settings.SESSION_COOKIE_DOMAIN,
secure=settings.SESSION_COOKIE_SECURE or None,
httponly=settings.SESSION_COOKIE_HTTPONLY or None,
samesite=settings.SESSION_COOKIE_SAMESITE,
)
else:
response.delete_cookie(self.cookie_name, 
domain=settings.SESSION_COOKIE_DOMAIN)

def _store(self, messages, response, remove_oldest=True, *args, **kwargs):
"""
Store the messages to a cookie and return a list of any messages which
could not be stored.

If the encoded data is larger than ``max_cookie_size``, remove
messages until the data fits (these are the messages which are
returned), and add the not_finished sentinel value to indicate as much.
"""
unstored_messages = []
encoded_data = self._encode(messages)
if self.max_cookie_size:
# data is going to be stored eventually by SimpleCookie, which
# adds its own overhead, which we must account for.
cookie = SimpleCookie()  # create outside the loop

def stored_length(val):
return len(cookie.value_encode(val)[1])

while encoded_data and stored_length(encoded_data) > 
self.max_cookie_size:
if remove

Re: i encounter this error when i first try http://localhost:8000/ ( module 'json' has no attribute 'JSONDecoder')

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you 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 for your understanding and all the best,

Adam

On Sat, 20 Jun 2020 at 17:41, Ibar Osman Ibrahim 
wrote:

> Request Method: GET
> Request URL: http://localhost:8000/
> Django Version: 3.0.7
> Exception Type: AttributeError
> Exception Value:
>
> module 'json' has no attribute 'JSONDecoder'
>
> Exception Location: 
> E:\Blogs\ll_env\lib\site-packages\django\contrib\messages\storage\cookie.py
> in , line 27
> Python Executable: E:\Blogs\ll_env\Scripts\python.exe
> Python Version: 3.8.3
> Python Path:
>
> ['E:\\Blogs',
>  'C:\\Python\\python38.zip',
>  'C:\\Python\\DLLs',
>  'C:\\Python\\lib',
>  'C:\\Python',
>  'E:\\Blogs\\ll_env',
>  'E:\\Blogs\\ll_env\\lib\\site-packages']
>
> Server time: Sat, 20 Jun 2020 13:28:59 +
>
>
>
>
>
>
>
>
> import json
>
> from django.conf import settings
> from django.contrib.messages.storage.base import BaseStorage, Message
> from django.http import SimpleCookie
> from django.utils.crypto import constant_time_compare, salted_hmac
> from django.utils.safestring import SafeData, mark_safe
>
>
> class MessageEncoder(json.JSONEncoder):
> """
> Compactly serialize instances of the ``Message`` class as JSON.
> """
> message_key = '__json_message'
>
> def default(self, obj):
> if isinstance(obj, Message):
> # Using 0/1 here instead of False/True to produce more compact 
> json
> is_safedata = 1 if isinstance(obj.message, SafeData) else 0
> message = [self.message_key, is_safedata, obj.level, obj.message]
> if obj.extra_tags:
> message.append(obj.extra_tags)
> return message
> return super().default(obj)
>
>
> class MessageDecoder(json.JSONDecoder):
> """
> Decode JSON that includes serialized ``Message`` instances.
> """
>
> def process_messages(self, obj):
> if isinstance(obj, list) and obj:
> if obj[0] == MessageEncoder.message_key:
> if len(obj) == 3:
> # Compatibility with previously-encoded messages
> return Message(*obj[1:])
> if obj[1]:
> obj[3] = mark_safe(obj[3])
> return Message(*obj[2:])
> return [self.process_messages(item) for item in obj]
> if isinstance(obj, dict):
> return {key: self.process_messages(value)
> for key, value in obj.items()}
> return obj
>
> def decode(self, s, **kwargs):
> decoded = super().decode(s, **kwargs)
> return self.process_messages(decoded)
>
>
> class CookieStorage(BaseStorage):
> """
> Store messages in a cookie.
> """
> cookie_name = 'messages'
> # uwsgi's default configuration enforces a maximum size of 4kb for all the
> # HTTP headers. In order to leave some room for other cookies and headers,
> # restrict the session cookie to 1/2 of 4kb. See #18781.
> max_cookie_size = 2048
> not_finished = '__messagesnotfinished__'
>
> def _get(self, *args, **kwargs):
> """
> Retrieve a list of messages from the messages cookie. If the
> not_finished sentinel value is found at the end of the message list,
> remove it and return a result indicating that not all messages were
> retrieved by this storage.
> """
> data = self.request.COOKIES.get(self.cookie_name)
> messages = self._decode(data)
> all_retrieved = not (messages and messages[-1] == self.not_finished)
> if messages and not all_retrieved:
> # remove the sentinel value
> messages.pop()
> return messages, all_retrieved
>
> def _update_cookie(self, encoded_data, response):
> """
> Either set the cookie with the encoded data if there is any data to
> store, or delete the cookie.
> """
> if encoded_data:
> response.set_cookie(
> self.cookie_name, encoded_data,
> domain=settings.SESSION_COOKIE_DOMAIN,
> secure=settings.SESSION_COOKIE_SECURE or None,
> httponly=settings.SESSION_COOKIE_HTTPONLY or None,
> samesite=settings.SESSION_COOKIE_SAMESITE,
> )
> else:
> response.delete_cookie(self.cookie_name, 
> domain=settings.SESSION_COOKIE_DOMAIN)
>
> def _