Django 4.2 release candidate 1 released

[Mariusz Felisiak]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2023/mar/20/django-42-rc1/

--
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/df17f71b-a76e-3b82-507f-f867878d2d8a%40gmail.com.

Re: Exporting some of the `datetime` functions from `django.utils.timezone`

[Mariusz Felisiak]

Hi,

> I would say we should at least consider exporting `timedelta` What do you 
think?

I'm strongly against it. Things should be imported from source modules, not 
cross-imported from Django modules just because we use them. This is 
confusing to the users who might have the impression that 
`django.utils.timezone.timedelta` is more than `datetime.timedelta`, which 
is not True.

Best,
Mariusz

-- 
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/977ea70e-8241-4855-a983-8c4173d8c879n%40googlegroups.com.

Re: Exporting some of the `datetime` functions from `django.utils.timezone`

[Jacob Rief]

I find it confusing that we have to import now from django.utils.timezone, 
but timedelta from Python's internal datetime.
This btw. is a violation of the Law of Demeter 
, hence I agree with Suayip's 
proposal.

– Jacob

On Monday, March 20, 2023 at 10:09:02 AM UTC+1 Mariusz Felisiak wrote:

I'm strongly against it. Things should be imported from source modules, not 
cross-imported from Django modules just because we use them. This is 
confusing to the users who might have the impression that 
`django.utils.timezone.timedelta` is more than `datetime.timedelta`, which 
is not True.

-- 
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/4c5d6229-49d5-41b2-9d08-2a185c584952n%40googlegroups.com.

Re: Exporting some of the `datetime` functions from `django.utils.timezone`

[Mariusz Felisiak]

I find it confusing that we have to import now from django.utils.timezone, 
but timedelta from Python's internal datetime.
This btw. is a violation of the Law of Demeter 
, hence I agree with Suayip's 
proposal.

– Jacob


There is a big difference between `now()` and `timedelta`, 
`django.utils.timezone.now` is defined in Django it is not the same as `
datetime.now`. Unlike, `timedelta` would be always Python's `datetime.
timedelta`. Following this proposition, we should reintroduce most of the 
standard Python libraries in the django.utils modules 🤯 TBH, we're trying 
to do the exact opposite and remove all aliases, e.g. 
https://github.com/django/django/commit/d6816bff73b37af05c968c009419c7c608e37307

I remember a discussion where a user tried to convince me that `
django.utils.timezone.datetime` is not the same as `datetime.datetime` and 
that Django is definitely adding some magic here and I have to use 
`datetime` from Django. This is of course not true.

Best,
Mariusz

-- 
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/40cce83a-4967-4a6c-9ae2-7e15386814dcn%40googlegroups.com.

Test Errors, if `getpass.getuser` fails, i.e. tox on windows

[Glen Fletcher]

There are 4 tests in `auth_test/test_management.py` which fail when run by 
tox on windows.

- `test_system_username` - Raises an `ImportError`
- `test_non_ascii_verbose_name` - mock input mapping assumes default 
username, and raise an error
- `test_default_username` - Enters an infinite loop asking for a valid 
username
- `test_createsuperuser_command_suggested_username_with_database_option` - 
Enters an infinite loop asking for a
  valid username

I've traced this to `getpass.getuser`. Under windows `import pwd` cause an 
`ImportError`, unless `USERNAME` is set,
tox doesn't seem to  include this environment variable in the environments 
it creates, even when I tried adding
`USERNAME` to `passenv` in `tox.ini:testenv` (Note this is the first time 
I've used tox, so I could be doing
something wrong).

This causes `test_system_username` to raise an `ImportError` thereby 
failing and `get_system_username` to return an
empty string.

This means that `get_default_username` also returns an empty string. This 
causes `test_non_ascii_verbose_name` to
have an invalid mock input mapping as its map assumes the username request 
has a default option.

Further the empty string from `get_default_username`, results in a input 
validation error causing `get_input_data`
to return `None` resulting in `test_default_username` and
`test_createsuperuser_command_suggested_username_with_database_option` 
causing them to  enter an infinite loop
requesting a valid username, in `handle`.

See Code extracts below:

**def handle, 
django/contrib/auth/management/commands/createsuperuser.py:90**
*(username loop, starting on line 122)*
```python
while username is None:
message = self._get_input_message(
self.username_field, default_username
)
username = self.get_input_data(
self.username_field, message, default_username
)
if username:
error_msg = self._validate_username(
username, verbose_field_name, database
)
if error_msg:
self.stderr.write(error_msg)
username = None
continue
```

**def get_input_data, 
django/contrib/auth/management/commands/createsuperuser.py:250**
```python
def get_input_data(self, field, message, default=None):
"""
Override this method if you want to customize data inputs or
validation exceptions.
"""
raw_value = input(message)
if default and raw_value == "":
raw_value = default
try:
val = field.clean(raw_value, None)
except exceptions.ValidationError as e:
self.stderr.write("Error: %s" % "; ".join(e.messages))
val = None

return val
```

 **def get_system_username, django/contrib/auth/management/__init__.py:114**
```python
def get_system_username():
"""
Return the current system user's username, or an empty string if the
username could not be determined.
"""
try:
result = getpass.getuser()
except (ImportError, KeyError):
# KeyError will be raised by os.getpwuid() (called by getuser())
# if there is no corresponding entry in the /etc/passwd file
# (a very restricted chroot environment, for example).
return ""
return result
```

**def getuser, getpass.py:154**
```python
def getuser():
"""Get the username from the environment or password database.

First try various environment variables, then the password
database.  This works on Windows as long as USERNAME is set.

"""

for name in ('LOGNAME', 'USER', 'LNAME', 'USERNAME'):
user = os.environ.get(name)
if user:
return user

# If this fails, the exception will "explain" why
import pwd
return pwd.getpwuid(os.getuid())[0]
```

## TOX Environment
Below I've include a sanitized version of my tox environment, generated by 
the Python Debug console (pycharm python
debugger)

```pycon
for k, v in os.environ.items():
print(f"{k}: {v}")

PROGRAMFILES: C:\Program Files
TEMP: c:\users\{username}\AppData\Local\Temp
SYSTEMDRIVE: C:
PROGRAMFILES(X86): C:\Program Files (x86)
PATHEXT: 
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW;.RB;.RBW
TMP: c:\users\{username}\AppData\Local\Temp
USERPROFILE: c:\users\{username}
COMSPEC: C:\WINDOWS\system32\cmd.exe
PATH: {repo_path}\.tox\py3\Scripts;{venv_path};{python_path};{windows_path}
SYSTEMROOT: C:\WINDOWS
PROGRAMDATA: C:\ProgramData
APPDATA: c:\users\{username}\AppData\Roaming
PROCESSOR_ARCHITECTURE: AMD64
NUMBER_OF_PROCESSORS: 20
PYTHONDONTWRITEBYTECODE: 1
PYTHONHASHSEED: 261
TOX_ENV_NAME: py3
TOX_ENV_DIR: {repo_path}\.tox\py3
_JB_DO_NOT_CALL_ENTER_MATRIX: 1
VIRTUAL_ENV: {repo_path}\repo\.tox\py3
TMPDIR: c:\users\{username}\AppData\Local\Temp\django_0vhaflop
DJANGO_SETTINGS_MODULE: test_sqlite
RUNNING_DJANGOS_TEST_SUITE: true
```

## Possible Solution

I was able to solve this by adding `os.environ.setdefault("USERNAME", 
"test_user")` to `runtests.py` to ensure that
`USERNAME` is always defined so `getpass.getuser` wi

Re: Exporting some of the `datetime` functions from `django.utils.timezone`

['Adam Johnson' via Django developers (Contributions to Django itself)]

I agree with Mariusz. Encouraging alternative import paths for standard
library functions can only lead to confusing code.

On Mon, Mar 20, 2023 at 11:47 AM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:

>
> I find it confusing that we have to import now from django.utils.timezone,
> but timedelta from Python's internal datetime.
> This btw. is a violation of the Law of Demeter
> , hence I agree with
> Suayip's proposal.
>
> – Jacob
>
>
> There is a big difference between `now()` and `timedelta`,
> `django.utils.timezone.now` is defined in Django it is not the same as `
> datetime.now`. Unlike, `timedelta` would be always Python's `datetime.
> timedelta`. Following this proposition, we should reintroduce most of the
> standard Python libraries in the django.utils modules 🤯 TBH, we're
> trying to do the exact opposite and remove all aliases, e.g.
> https://github.com/django/django/commit/d6816bff73b37af05c968c009419c7c608e37307
>
> I remember a discussion where a user tried to convince me that `
> django.utils.timezone.datetime` is not the same as `datetime.datetime`
> and that Django is definitely adding some magic here and I have to use
> `datetime` from Django. This is of course not true.
>
> Best,
> Mariusz
>
> --
> 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/40cce83a-4967-4a6c-9ae2-7e15386814dcn%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/CAMyDDM1UCrdbvT0YRuyET%2B0dmMgajPvy_VzES6ub69CbPGPTuw%40mail.gmail.com.