date:20200304

Hi all.

Especially from those with long memories, can I request thoughts on a
proposed
adjustment to `Field.contribute_to_class()`, which affects the manner in
which
fields override attributes from parent classes?

The entails a breaking change. As such... 😬 — but I think it's acceptable
and
worth it.

I'm posting here to ensure we get sufficient review on that.

Sorry for the long post. I've tried to lay it out as clearly as possible.
Thank you for your time and effort.

The pull request for all this is here:

https://github.com/django/django/pull/11337

Details
---

There are a cluster of tickets pertaining to the behavior of
`Field.contribute_to_class()`:

* Descriptors not accessible for inherited models.
https://code.djangoproject.com/ticket/30427
* Overwriting a property with field during model inheritance.
https://code.djangoproject.com/ticket/16176
* Model attributes shouldn't override deferred fields
https://code.djangoproject.com/ticket/28198

The are all related. Ultimately, they're different versions of the same bug.

The essence of it looks like this:

```
>>> from django.contrib.auth.models import User
>>> User.objects.create_user(username='spam', password='eggs',
is_active=False)

>>> User.objects.get().is_active
False
>>> User.objects.defer('is_active').get().is_active
True
```

Which happens for two reasons:

1. `AbstractBaseUser` provides a scalar default for the `is_active` field:

class AbstractBaseUser(models.Model):
...
is_active = True
...

2. `Field.contribute_to_class()` will then not set the field descriptor on
the
subclass:

if self.column:
# Don't override classmethods with the descriptor. This means
that
# if you have a classmethod and a field with the same name, then
# such fields can't be deferred (we don't have a check for
this).
if not getattr(cls, self.attname, None):
setattr(cls, self.attname, self.descriptor_class(self))

This leads to all the issues above, plus additional problems in the
eco-system.
e.g. https://github.com/jazzband/django-model-utils/issues/382

The payoff of the proposed change is fixing all these issues.

The history didn't tell me much so, I mailed the list in June last year to
ask
if anybody had any recollection of the _Why?_ to that _"Don't override
classmethods with the descriptor"_.

https://groups.google.com/d/msg/django-developers/zXB0oJ8tD3E/nH8yx_FpBAAJ

Nobody could remember that _Why_.

* One post, saying:

> I’ve run into this a few times, and the current behaviour has felt
> jarring and unpythonic.

* One post pointing to one of the related tickets above.

Again then, maybe last chance, do you have a long memory? Do you know that
_Why_? :)

Discussing #16176, Carl Meyer made a comment that was never picked up on:

> [The] suggestion to set all fields as class attributes so they override
> descriptors from a parent class is certainly worth considering, as it
would
> make models behave more like regular Python classes. This could result in
> some backwards-incompatibility; would need to look into it more to get a
> clearer sense of what cases might cause trouble, but I think it's probably
> acceptable if documented in the release notes.

https://code.djangoproject.com/ticket/16176#comment:6

The idea is to implement that, always setting the descriptor in the `if
self.column` block:

if self.column:
setattr(cls, self.attname, self.descriptor_class(self))

Implementing that in a PR, leads to **three** failures in the current tests.

PR: https://github.com/django/django/pull/11337

Two failures are tests for system checks, which cover edge cases arising
from
the existing behavior. I think the tests can be adjusted safely:

* `models.E020`.

Originally added for: `Fixed #23615 -- Validate that a Model instance's
"check" attribute is a method`

https://github.com/django/django/commit/a5c77417a651c93036cf963e6da518653115be7e

PR Diff:

https://github.com/django/django/pull/11337/files#diff-dc8c55ebf8072120b505dd8dade78efcR289-R294

* `models.E025`.

Originally added for: ` Fixed #28867 -- Added system check for a model
property that clashes with a related field accessor.`

https://github.com/django/django/commit/cc6bcc6ff5cab320c5e5ae2760549a6c732067d8

PR Diff:

https://github.com/django/django/pull/11337/files#diff-bbed6332ed721c634e1b48b0eddd04a0R917-R918

The third failure concerns the apparent MRO of fields inherited from
abstract
parent classes.

This is the breaking change.

Python MRO:

* For simple inheritance structures, MRO follows a depth-first strategy.
* For complex structures, with diamond-like multiple-inheritance, MRO is
"depth-first-with-pull-up". That is, siblings with shared ancestors are
inserted into the MRO before their ancestors, in violation of a strict
depth-first ordering.

(If anybody ha

Re: Deprecating logout via GET

2020-03-04 Thread Sam Willis

Why not have the logout link take the user to a page asking them to confirm the 
logout, and have it as a POSTed form button from there?

That adds a helpful confirmation page, removes the difficulties of styling a 
button as a link constantly (or changing the header design to a button).

One downside would be the change in behaviour, people will be used to the 
logout link immediately logging them out and so may not read the next page...

I’m sure there is literature in best practices for logout confirmation.

-- 
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/0161eeed-7f9a-4312-9ed5-fc2bafde64ee%40googlegroups.com.

Re: Deprecating logout via GET

If your suggestion is limited to the admin, I think it would be fine, but
it's not necessary. But I don't think there is a compelling reason - there
aren't any difficulties with the CSS since Rene has already written it.

If your suggestion is for all logout views, there's no way to enforce it,
and anyway we don't want to require users to implement a new view in order
to upgrade Django. That can turn a "backend team" task into needing a
design and copy writing. We should document the possibility though.

On Wed, 4 Mar 2020 at 11:13, Sam Willis  wrote:

> Why not have the logout link take the user to a page asking them to
> confirm the logout, and have it as a POSTed form button from there?
>
> That adds a helpful confirmation page, removes the difficulties of styling
> a button as a link constantly (or changing the header design to a button).
>
> One downside would be the change in behaviour, people will be used to the
> logout link immediately logging them out and so may not read the next
> page...
>
> I’m sure there is literature in best practices for logout confirmation.
>
> --
> 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/0161eeed-7f9a-4312-9ed5-fc2bafde64ee%40googlegroups.com
> .
>


-- 
Adam

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

Re: Review needed: Proposed behavior change in Field.contribute_to_class()

+1 from me

Afraid I don't know any of the why.

Also worth noting from the PR description:

Previously: DeferredAttributes would not get stapled onto models where the
> model (or an ancestor) already had an existing *non-falsey* attribute.
>

Non-falsey! I almost spat out my tea.

Thanks for the detailed write up with reference links.

On Wed, 4 Mar 2020 at 11:10, Carlton Gibson 
wrote:

> Hi all.
>
> Especially from those with long memories, can I request thoughts on a
> proposed
> adjustment to `Field.contribute_to_class()`, which affects the manner in
> which
> fields override attributes from parent classes?
>
> The entails a breaking change. As such... 😬 — but I think it's acceptable
> and
> worth it.
>
> I'm posting here to ensure we get sufficient review on that.
>
> Sorry for the long post. I've tried to lay it out as clearly as possible.
> Thank you for your time and effort.
>
> The pull request for all this is here:
>
> https://github.com/django/django/pull/11337
>
> Details
> ---
>
> There are a cluster of tickets pertaining to the behavior of
> `Field.contribute_to_class()`:
>
> * Descriptors not accessible for inherited models.
> https://code.djangoproject.com/ticket/30427
> * Overwriting a property with field during model inheritance.
> https://code.djangoproject.com/ticket/16176
> * Model attributes shouldn't override deferred fields
> https://code.djangoproject.com/ticket/28198
>
> The are all related. Ultimately, they're different versions of the same
> bug.
>
> The essence of it looks like this:
>
> ```
> >>> from django.contrib.auth.models import User
> >>> User.objects.create_user(username='spam', password='eggs',
> is_active=False)
> 
> >>> User.objects.get().is_active
> False
> >>> User.objects.defer('is_active').get().is_active
> True
> ```
>
> Which happens for two reasons:
>
> 1. `AbstractBaseUser` provides a scalar default for the `is_active` field:
>
> class AbstractBaseUser(models.Model):
> ...
> is_active = True
> ...
>
> 2. `Field.contribute_to_class()` will then not set the field descriptor on
> the
>subclass:
>
> if self.column:
> # Don't override classmethods with the descriptor. This means
> that
> # if you have a classmethod and a field with the same name,
> then
> # such fields can't be deferred (we don't have a check for
> this).
> if not getattr(cls, self.attname, None):
> setattr(cls, self.attname, self.descriptor_class(self))
>
> This leads to all the issues above, plus additional problems in the
> eco-system.
> e.g. https://github.com/jazzband/django-model-utils/issues/382
>
> The payoff of the proposed change is fixing all these issues.
>
> §
>
> The history didn't tell me much so, I mailed the list in June last year to
> ask
> if anybody had any recollection of the _Why?_ to that _"Don't override
> classmethods with the descriptor"_.
>
> https://groups.google.com/d/msg/django-developers/zXB0oJ8tD3E/nH8yx_FpBAAJ
>
> Nobody could remember that _Why_.
>
> * One post, saying:
>
> > I’ve run into this a few times, and the current behaviour has felt
> > jarring and unpythonic.
>
> * One post pointing to one of the related tickets above.
>
> Again then, maybe last chance, do you have a long memory? Do you know that
> _Why_? :)
>
> §
>
> Discussing #16176, Carl Meyer made a comment that was never picked up on:
>
> > [The] suggestion to set all fields as class attributes so they override
> > descriptors from a parent class is certainly worth considering, as it
> would
> > make models behave more like regular Python classes. This could result in
> > some backwards-incompatibility; would need to look into it more to get a
> > clearer sense of what cases might cause trouble, but I think it's
> probably
> > acceptable if documented in the release notes.
>
> https://code.djangoproject.com/ticket/16176#comment:6
>
> The idea is to implement that, always setting the descriptor in the `if
> self.column` block:
>
> if self.column:
> setattr(cls, self.attname, self.descriptor_class(self))
>
> §
>
> Implementing that in a PR, leads to **three** failures in the current
> tests.
>
> PR: https://github.com/django/django/pull/11337
>
> Two failures are tests for system checks, which cover edge cases arising
> from
> the existing behavior. I think the tests can be adjusted safely:
>
> * `models.E020`.
>
> Originally added for: `Fixed #23615 -- Validate that a Model
> instance's "check" attribute is a method`
>
> https://github.com/django/django/commit/a5c77417a651c93036cf963e6da518653115be7e
>
> PR Diff:
>
> https://github.com/django/django/pull/11337/files#diff-dc8c55ebf8072120b505dd8dade78efcR289-R294
>
> * `models.E025`.
>
> Originally added for: ` Fixed #28867 -- Added system check for a model
> property that clashes with a related field accessor.`
>
> https://github.com/django/django/commit/cc6bcc6ff5ca

Re: Deprecating logout via GET

Users don't need to confirm a logout. Confirmation is usually when deleting
a profile or making something irreversible. Logging out is reversible and
therefore doesn't need to be confirmed. Just clicking "logout" should log
the user out - whether a regular user or an admin.

אורי
u...@speedy.net


On Wed, Mar 4, 2020 at 1:13 PM Sam Willis  wrote:

> Why not have the logout link take the user to a page asking them to
> confirm the logout, and have it as a POSTed form button from there?
>
> That adds a helpful confirmation page, removes the difficulties of styling
> a button as a link constantly (or changing the header design to a button).
>
> One downside would be the change in behaviour, people will be used to the
> logout link immediately logging them out and so may not read the next
> page...
>
> I’m sure there is literature in best practices for logout confirmation.
>
> --
> 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/0161eeed-7f9a-4312-9ed5-fc2bafde64ee%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/CABD5YeF5D0v%2Bihzn8xjhwJkPresTN_4T%2Bk3VUxrOM%2BrXF2-M3w%40mail.gmail.com.

Re: ngettext_lazy and ngettext

Django developers,

PR #12332 is waiting to be reviewed and approved.

https://github.com/django/django/pull/12332

I would also like to suggest to include this PR, if accepted, into the next
version of 2.2. Otherwise I will not be able to use 2.2 or I will have to
fork Django to use 2.2, and then I will have to apply every patch manually
to my fork, which is a harass and I don't think should be necessary.

אורי
u...@speedy.net


On Tue, Jan 28, 2020 at 7:42 AM Matemática A3K 
wrote:

>
>
> On Fri, Jan 24, 2020 at 2:17 AM Matemática A3K 
> wrote:
>
>>
>>
>> On Fri, Jan 10, 2020 at 8:38 PM Matemática A3K 
>> wrote:
>>
>>> Trying to recap all the discussion done in the mailing list, Trac and
>>> Github:
>>>
>>> The problem that was originally reported in #30439 was about mixed
>>> plural forms in catalogs bundled with Django, which led to broken
>>> translations.
>>>
>>> Then, it added the not announced changes in the plural forms of locales,
>>> which led to break users' translations.
>>>
>>> These problems occur when catalogs gets updated in Django and users
>>> updates their version.
>>>
>>> Michal proposed not merging and doing catalogs look-ups per language,
>>> Claude proposed the "dict-merge" policy (have a dict of merged catalogs
>>> according to their plural forms), which is a variant of Michal's.
>>>
>>> The "dict-merge" policy have the problem of updates in the plural forms
>>> in Django won't reach users' catalogs.
>>>
>>> Whether merge or not merge the catalogs (the merging policy) is about
>>> how to encourage the user to take action, not the fix itself.
>>>
>>> The fix is on the warning of the situation and on the tools for
>>> addressing it.
>>>
>>> The proposed fix is:
>>> 1- Warn the user at a system check level and at run-time
>>> 2- Use the "not-merge" policy to encourage action.
>>> 3- Provide the makemessages --comply-plural-forms tool so both Django
>>> and its users can have consistent plural forms in their catalogs
>>> conveniently.
>>> 4- Provide the LOCALE_ROOT setting and the makemessages
>>> --collect-base-catalogs tool so users can make changes in their plural
>>> forms conveniently and persisted across updates.
>>>
>>> The PR is cluttered with a lot of inconsistencies fixes across all
>>> catalogs bundled with Django and the catalogs used for tests.
>>>
>>> Once a warning is raised when merging (either merging or not), most of
>>> the tests will fail because of that warning, so all bundled catalogs (and
>>> those used for tests) have to be aligned in order to have things working.
>>>
>>> Here are the files of the PR filtered:
>>> https://github.com/django/django/pull/12280/files?file-filters%5B%5D=.py&file-filters%5B%5D=.txt
>>>
>>> For ensuring Django's catalogs consistency, there is a test that will
>>> fail if there is any catalog unaligned. The next time Django's catalogs
>>> will be updated, CI will check the consistency. If not, who will do the
>>> merge has to run "python -m django makemessages --comply-plural-forms" and
>>> "python -m django compilemessages" on the corresponding dir (django.conf,
>>> django.contrib.app or the test locale) to fix it. This way, the messages
>>> from the provider will be retained and the consistency be assured.
>>>
>>> There are valid reasons for users to customize their plural forms, i.e.
>>> fixing a broken one while a fix is in the way or use another implementation
>>> of the standard. Having to modify the source distribution for customizing
>>> is not ideal, besides not being persistent across updates and may not be
>>> possible in some setups. This should be done locally, at the project tree.
>>> This is what the LOCALE_ROOT setting addresses.
>>>
>>> Claude already objected this fix though he did not provide reasons (
>>> https://github.com/django/django/pull/12280#issuecomment-571483273).
>>>
>>> Does anyone see any rationale, design or implementation problem in the
>>> fix? Any comment is welcomed :)
>>>
>>
>> To my surprise, yesterday when I started to work again in this issue - I
>> thought we had agreed for a review after the code was separated in commits
>> - I saw that the ticket was disowned from me.
>>
>> So, I will leave my thoughts here.
>>
>> I think the discussion hasn't been the best, both in constructiveness and
>> fluidity terms, but as I had committed to get this fixed, I have continued
>> working to get the best for it despite the differences.
>>
>> I will write my concerns about the accepted fix ("dict-merge" policy).
>>
>> - Users may be left in an unsatisfactory situation
>>
>> Plural forms only get to the users' catalogs once it is created by
>> makemessages. Once that a catalog is "filled", it is not safe to just
>> update plural forms as it may require content modification.
>>
>> Given that broken (buggy) plural forms have been distributed with Django,
>> those catalogs will remain broken and unnoticed under the "dict-merge"
>> policy.
>>
>> The only rationale that I can think of for justifying this is "If the

Re: GSOC 2020

2020-03-04 Thread Victor Egbe

Very well then.  Thank you for the offer.  However we do not have such need
at the moment.



On Tue, 3 Mar 2020, 10:03 pm Aakash Baranwal,  wrote:

> No! I don't think so, that's exactly why I want to be a mentor.
>
> On Tue, 3 Mar, 2020, 11:26 PM Victor Egbe,  wrote:
>
>> Sorry but do you not think you should be the one to need mentoring from
>> an established organisation?
>>
>> On Tue, 3 Mar 2020, 6:22 pm Aakash Baranwal, 
>> wrote:
>>
>>> Dear Authorities,
>>>
>>> I am Aakash Baranwal from Dayalbagh Educational Institute which is in
>>> Agra, India. I am currently in my final year majoring in Electrical
>>> Engineering with Computer Science.
>>> I am skilled in python and Django and I also have a work experience from
>>> a 5 month internship in a company called Hughes Systique.
>>>
>>> I wish to be a mentor for your organisation in the GSOC 2020.
>>> Kindly let me know about the necessary steps which I need to follow in
>>> order to successfully be a mentor for your organisation.
>>>
>>> Looking forward to hearing from you.
>>>
>>> Thank You
>>>
>>> With Kind Regards
>>> Aakash Baranwal
>>>
>>> --
>>> 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/CALr9hQ2KPoW0KksoNWvegsJ9R92j1iYrMHK7Kaog2ODuN7zc-g%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/CAM-AS-sDQU8zoTm1AQgBwMH6Vx8UpfQMZvy%3D_vaXfqiJgpRVPA%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/CALr9hQ3G0yGYpJp5i2mfk0r0smgQaC6MFY9MnEtstZ2NYX%3D__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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM-AS-ufDMcwvOr27sqqad-yFkghpUksOOWZq3QeLr5xx88MbA%40mail.gmail.com.

LiveServerTestCase - self.client.force_login() when called more than once returns django.db.utils.DatabaseError

2020-03-04 Thread Deep Sukhwani

Hello,

This query is for Django version 1.9 and Python 3.5 with Django Rest 
Framework 3.5.4
*(I know this version is outdated, but moving ahead of this version as of 
now is out of reach for the purpose of solving this query)*

*Exact Error observed:*

self.client.force_login(self.user)
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
, line 608, in force_login
self._login(user)
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
, line 621, in _login
login(request, user)
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/__init__.py"
, line 117, in login
user_logged_in.send(sender=user.__class__, request=request, user=user)
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/dispatch/dispatcher.py"
, line 192, in send
response = receiver(signal=self, sender=sender, **named)
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/models.py"
, line 23, in update_last_login
user.save(update_fields=['last_login'])
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/base_user.py"
, line 74, in save
super(AbstractBaseUser, self).save(*args, **kwargs)
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
, line 708, in save
force_update=force_update, update_fields=update_fields)
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
, line 736, in save_base
updated = self._save_table(raw, cls, force_insert, force_update, using, 
update_fields)
  File 
"/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
, line 805, in _save_table
raise DatabaseError("Save with update_fields did not affect any rows.")
django.db.utils.DatabaseError: Save with update_fields did not affect any 
rows.


*Scenario:*

from django.test import TestCase, LiveServerTestCase

from paths.factories import UserFactory


class ATestClass(LiveServerTestCase):

@classmethod
def setUpClass(cls):
"""
Test Data common across all tests
"""

super().setUpClass()

cls.user = UserFactory(is_staff=False, is_superuser=False)

def test_one(self):
"""
Login and then do some actions
"""
self.client.force_login(self.user)

# do something
self.assertTrue(True)

def test_two(self):
"""
Login and do some actions
"""

self.client.force_login(self.user)

# do something
self.assertFalse(False)


However, if I change the base class from LiveServerTestCase to TestCase, it 
works fine without any errors. I understand this was probably addressed 
in https://code.djangoproject.com/ticket/26823 but can someone help with 
any way in which I can patch this in my tests to avoid raising this issue?

*Why LiveServerTestCase?*

   - My tests need access to live_server_url, hence I am forced to inherit 
   the test class from LiveServerTestCase

*What have I tried?*

   - Logging in in setUp method instead of directly within the test - 
   Doesn't help
   - Disconnecting update_last_login signal by using 
   user_logged_in.disconnect(update_last_login) - Doesn't help
   - Manually setting the last_login field on user object to None before 
   force_login statement - Doesn't help

Thank you,
Deep S

-- 
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/623f7119-d398-4254-b80d-ead27d8f4fbe%40googlegroups.com.

Re: GSOC 2020

Well, hang on... that might be a bit quick. 

I'm just thinking about putting together a call for Mentors this year. 

I'm looking to do it via the Forum, which seems to be working well, 
and we should be able to spread the load.

But we will need people formally in the Mentor role, and the number of 
folks 
we have is the limit on the number of students we can take. 
Someone asked about why we have small numbers each year. This is it. 
We don't have a whole bunch of easy projects, and mentoring requires a time 
commitment.

Having said that... 

Aakash, welcome. 

First off, I'm a little surprised by your question: normally we — scrub 
that — I imagine that mentors would come 
from people who are already active in contributing to Django. Maybe I can 
rethink that (all for the win.)

Can you explain more about what you might bring? You say you're skilled in 
Django, but (again) I'd think a 
knowledge of the internals would be required... do you have that? I— I 
don't necessarily put you off: I'm just 
not immediately seeing how it would work.

One thought: maybe if you could help students with the project management 
side, experienced contributors would be 
able to help with the technical questions... 🤔

Kind Regards,

Carlton

On Wednesday, 4 March 2020 14:19:38 UTC+1, Victor Egbe wrote:
>
> Very well then.  Thank you for the offer.  However we do not have such 
> need at the moment.
>
>
>
> On Tue, 3 Mar 2020, 10:03 pm Aakash Baranwal,  > wrote:
>
>> No! I don't think so, that's exactly why I want to be a mentor.
>>
>> On Tue, 3 Mar, 2020, 11:26 PM Victor Egbe, > > wrote:
>>
>>> Sorry but do you not think you should be the one to need mentoring from 
>>> an established organisation?
>>>
>>> On Tue, 3 Mar 2020, 6:22 pm Aakash Baranwal, >> > wrote:
>>>
 Dear Authorities,

 I am Aakash Baranwal from Dayalbagh Educational Institute which is in 
 Agra, India. I am currently in my final year majoring in Electrical 
 Engineering with Computer Science.
 I am skilled in python and Django and I also have a work experience 
 from a 5 month internship in a company called Hughes Systique.

 I wish to be a mentor for your organisation in the GSOC 2020.
 Kindly let me know about the necessary steps which I need to follow in 
 order to successfully be a mentor for your organisation.

 Looking forward to hearing from you.

 Thank You

 With Kind Regards
 Aakash Baranwal

 -- 
 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/CALr9hQ2KPoW0KksoNWvegsJ9R92j1iYrMHK7Kaog2ODuN7zc-g%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-d...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CAM-AS-sDQU8zoTm1AQgBwMH6Vx8UpfQMZvy%3D_vaXfqiJgpRVPA%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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CALr9hQ3G0yGYpJp5i2mfk0r0smgQaC6MFY9MnEtstZ2NYX%3D__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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/973c31d3-16fa-42ea-b14c-e27ab2341e21%40googlegroups.com.

Re: LiveServerTestCase - self.client.force_login() when called more than once returns django.db.utils.DatabaseError

Hi!

I'm pasting my "wrong mailing list" standard text below. This is a support
query for an old version of Django.

The ticket you linked to was committed in
https://github.com/django/django/commit/eedc88bd4a8468c2a0daa8346c9b57183dd77782
which I can see was released in Django 2.0.

You should really upgrade!

Thanks,

Adam

---

I think you've found the wrong mailing list for this post. This mailing
list is for 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. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Wed, 4 Mar 2020 at 07:04, Deep Sukhwani  wrote:

> Hello,
>
> This query is for Django version 1.9 and Python 3.5 with Django Rest
> Framework 3.5.4
> *(I know this version is outdated, but moving ahead of this version as of
> now is out of reach for the purpose of solving this query)*
>
> *Exact Error observed:*
>
> self.client.force_login(self.user)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
> , line 608, in force_login
> self._login(user)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
> , line 621, in _login
> login(request, user)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/__init__.py"
> , line 117, in login
> user_logged_in.send(sender=user.__class__, request=request, user=user)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/dispatch/dispatcher.py"
> , line 192, in send
> response = receiver(signal=self, sender=sender, **named)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/models.py"
> , line 23, in update_last_login
> user.save(update_fields=['last_login'])
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/base_user.py"
> , line 74, in save
> super(AbstractBaseUser, self).save(*args, **kwargs)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
> , line 708, in save
> force_update=force_update, update_fields=update_fields)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
> , line 736, in save_base
> updated = self._save_table(raw, cls, force_insert, force_update, using
> , update_fields)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
> , line 805, in _save_table
> raise DatabaseError("Save with update_fields did not affect any rows."
> )
> django.db.utils.DatabaseError: Save with update_fields did not affect any
> rows.
>
>
> *Scenario:*
>
> from django.test import TestCase, LiveServerTestCase
>
> from paths.factories import UserFactory
>
>
> class ATestClass(LiveServerTestCase):
>
> @classmethod
> def setUpClass(cls):
> """
> Test Data common across all tests
> """
>
> super().setUpClass()
>
> cls.user = UserFactory(is_staff=False, is_superuser=False)
>
> def test_one(self):
> """
> Login and then do some actions
> """
> self.client.force_login(self.user)
>
> # do something
> self.assertTrue(True)
>
> def test_two(self):
> """
> Login and do some actions
> """
>
> self.client.force_login(self.user)
>
> # do something
> self.assertFalse(False)
>
>
> However, if I change the base class from LiveServerTestCase to TestCase,
> it works fine without any errors. I understand this was probably addressed
> in https://code.djangoproject.com/ticket/26823 but can someone help with
> any way in which I can patch this in my tests to avoid raising this issue?
>
> *Why LiveServerTestCase?*
>
>- My tests need access to live_server_url, hence I am forced to
>inherit the test class from LiveServerTestCase
>
> *What have I tried?*
>
>- Logging in in setUp method inst

Re: ngettext_lazy and ngettext

HI Uri. 

Yes, we know. :) Please don't bump. It's just adds noise. (If you MUST 
bump, a comment on the PR is more than enough, so not everyone of the 
thousands on this list needs a notification.) Thanks. 

Ref backport: it's a possibility but you should phrase it more like, "this 
is serious bug for any user of i18n supporting non-latin languages"[*] — or 
similar. (That one user has a bug wouldn't qualify it.) — It is under 
consideration. 

https://www.goodreads.com/book/show/4865.How_to_Win_Friends_and_Influence_People

(Ch1.)

On Wednesday, 4 March 2020 14:20:10 UTC+1, Uri wrote:
>
> Django developers,
>
> PR #12332 is waiting to be reviewed and approved.
>
> https://github.com/django/django/pull/12332  
>
> I would also like to suggest to include this PR, if accepted, into the 
> next version of 2.2. Otherwise I will not be able to use 2.2 or I will have 
> to fork Django to use 2.2, and then I will have to apply every patch 
> manually to my fork, which is a harass and I don't think should be 
> necessary.
>
> אורי
> u...@speedy.net 
>
>
> On Tue, Jan 28, 2020 at 7:42 AM Matemática A3K  > wrote:
>
>>
>>
>> On Fri, Jan 24, 2020 at 2:17 AM Matemática A3K > > wrote:
>>
>>>
>>>
>>> On Fri, Jan 10, 2020 at 8:38 PM Matemática A3K >> > wrote:
>>>
 Trying to recap all the discussion done in the mailing list, Trac and 
 Github:

 The problem that was originally reported in #30439 was about mixed 
 plural forms in catalogs bundled with Django, which led to broken 
 translations.

 Then, it added the not announced changes in the plural forms of 
 locales, which led to break users' translations.

 These problems occur when catalogs gets updated in Django and users 
 updates their version.

 Michal proposed not merging and doing catalogs look-ups per language, 
 Claude proposed the "dict-merge" policy (have a dict of merged catalogs 
 according to their plural forms), which is a variant of Michal's.

 The "dict-merge" policy have the problem of updates in the plural forms 
 in Django won't reach users' catalogs.

 Whether merge or not merge the catalogs (the merging policy) is about 
 how to encourage the user to take action, not the fix itself.

 The fix is on the warning of the situation and on the tools for 
 addressing it.

 The proposed fix is:
 1- Warn the user at a system check level and at run-time
 2- Use the "not-merge" policy to encourage action.
 3- Provide the makemessages --comply-plural-forms tool so both Django 
 and its users can have consistent plural forms in their catalogs 
 conveniently.
 4- Provide the LOCALE_ROOT setting and the makemessages 
 --collect-base-catalogs tool so users can make changes in their plural 
 forms conveniently and persisted across updates.

 The PR is cluttered with a lot of inconsistencies fixes across all 
 catalogs bundled with Django and the catalogs used for tests.

 Once a warning is raised when merging (either merging or not), most of 
 the tests will fail because of that warning, so all bundled catalogs (and 
 those used for tests) have to be aligned in order to have things working.

 Here are the files of the PR filtered: 
 https://github.com/django/django/pull/12280/files?file-filters%5B%5D=.py&file-filters%5B%5D=.txt

 For ensuring Django's catalogs consistency, there is a test that will 
 fail if there is any catalog unaligned. The next time Django's catalogs 
 will be updated, CI will check the consistency. If not, who will do the 
 merge has to run "python -m django makemessages --comply-plural-forms" and 
 "python -m django compilemessages" on the corresponding dir (django.conf, 
 django.contrib.app or the test locale) to fix it. This way, the messages 
 from the provider will be retained and the consistency be assured.

 There are valid reasons for users to customize their plural forms, i.e. 
 fixing a broken one while a fix is in the way or use another 
 implementation 
 of the standard. Having to modify the source distribution for customizing 
 is not ideal, besides not being persistent across updates and may not be 
 possible in some setups. This should be done locally, at the project tree. 
 This is what the LOCALE_ROOT setting addresses.

 Claude already objected this fix though he did not provide reasons (
 https://github.com/django/django/pull/12280#issuecomment-571483273).

 Does anyone see any rationale, design or implementation problem in the 
 fix? Any comment is welcomed :)

>>>
>>> To my surprise, yesterday when I started to work again in this issue - I 
>>> thought we had agreed for a review after the code was separated in commits 
>>> - I saw that the ticket was disowned from me.
>>>
>>> So, I will leave my thoughts here.
>>>
>>> I think the discussion hasn't been t

Re: LiveServerTestCase - self.client.force_login() when called more than once returns django.db.utils.DatabaseError

2020-03-04 Thread Deep Sukhwani

Thank you, Adam,

Note: For future posts on this topic - Request you to use django-users 
mailing list: 
https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY

I realized that I posted this in the wrong mailing list after posting it 
and so I reposted this in django-users mailing list 
. 
Extremely sorry for this.

Thanks for calling out that we should really upgrade to Django 2.0, 
however, for now, I would love to understand if there is a way to patch 
this in Django 1.9 until we (my organization) are stuck on this version.

*For anyone else, if you have a helpful response - request you to respond 
to it in the django-users mailing list - link to this post: *
https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY

Thank you

On Wednesday, 4 March 2020 19:07:48 UTC+5:30, Adam Johnson wrote:
>
> Hi!
>
> I'm pasting my "wrong mailing list" standard text below. This is a support 
> query for an old version of Django.
>
> The ticket you linked to was committed in 
> https://github.com/django/django/commit/eedc88bd4a8468c2a0daa8346c9b57183dd77782
>  
> which I can see was released in Django 2.0.
>
> You should really upgrade!
>
> Thanks,
>
> Adam
>
> ---
>
> I think you've found the wrong mailing list for this post. This mailing 
> list is for 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. Read more on the mailing 
> lists at https://www.djangoproject.com/community/
>
> For support, please use the NEW Django forum at 
> https://forum.djangoproject.com , django-users mailing list, or IRC 
> #django on Freenode, or a site like Stack Overflow. There are people out 
> there willing to help on those channels, but they might not respond if you 
> don't ask your question well. Stack Overflow's question guide can help you 
> frame it well: https://stackoverflow.com/help/how-to-ask .
>
> Also if you haven't read it, please take a look at Django's Code of 
> Conduct: https://www.djangoproject.com/conduct/ . These are our "ground 
> rules" for working well as a community, and will help you get the most out 
> of Django and our fantastic community.
>
> Thanks for your understanding,
>
> Adam
>
> On Wed, 4 Mar 2020 at 07:04, Deep Sukhwani  > wrote:
>
>> Hello,
>>
>> This query is for Django version 1.9 and Python 3.5 with Django Rest 
>> Framework 3.5.4
>> *(I know this version is outdated, but moving ahead of this version as of 
>> now is out of reach for the purpose of solving this query)*
>>
>> *Exact Error observed:*
>>
>> self.client.force_login(self.user)
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
>> , line 608, in force_login
>> self._login(user)
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
>> , line 621, in _login
>> login(request, user)
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/__init__.py"
>> , line 117, in login
>> user_logged_in.send(sender=user.__class__, request=request, user=user
>> )
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/dispatch/dispatcher.py"
>> , line 192, in send
>> response = receiver(signal=self, sender=sender, **named)
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/models.py"
>> , line 23, in update_last_login
>> user.save(update_fields=['last_login'])
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/base_user.py"
>> , line 74, in save
>> super(AbstractBaseUser, self).save(*args, **kwargs)
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
>> , line 708, in save
>> force_update=force_update, update_fields=update_fields)
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
>> , line 736, in save_base
>> updated = self._save_table(raw, cls, force_insert, force_update, 
>> using, update_fields)
>>   File 
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
>> , line 805, in _save_table
>> raise DatabaseError("Save with update_fields did not affect any 
>> rows.")
>> django.db.utils.DatabaseError: Save with update_fields did not affect 
>> any rows.
>>
>>
>> *Scenario:*
>>
>> from django.test import TestCase, LiveServerTestCase
>>
>> from paths.factories import UserFactory
>>
>>
>> class ATestClass(LiveServerTestCase):
>>
>> @classmethod
>> def setUpClass(cls):
>> """
>> Test Data comm

Re: LiveServerTestCase - self.client.force_login() when called more than once returns django.db.utils.DatabaseError

I should have written: You can fork Django on GitHub, backport that commit
(git cherry-pick) to the stable/1.9.x branch, and install that hash:
https://adamj.eu/tech/2019/03/11/pip-install-from-a-git-repository/ .

On Wed, 4 Mar 2020 at 13:45, Deep Sukhwani  wrote:

> Thank you, Adam,
>
> Note: For future posts on this topic - Request you to use django-users
> mailing list:
> https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY
>
> I realized that I posted this in the wrong mailing list after posting it
> and so I reposted this in django-users mailing list
> .
> Extremely sorry for this.
>
> Thanks for calling out that we should really upgrade to Django 2.0,
> however, for now, I would love to understand if there is a way to patch
> this in Django 1.9 until we (my organization) are stuck on this version.
>
> *For anyone else, if you have a helpful response - request you to respond
> to it in the django-users mailing list - link to this post: *
> https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY
>
> Thank you
>
> On Wednesday, 4 March 2020 19:07:48 UTC+5:30, Adam Johnson wrote:
>>
>> Hi!
>>
>> I'm pasting my "wrong mailing list" standard text below. This is a
>> support query for an old version of Django.
>>
>> The ticket you linked to was committed in
>> https://github.com/django/django/commit/eedc88bd4a8468c2a0daa8346c9b57183dd77782
>> which I can see was released in Django 2.0.
>>
>> You should really upgrade!
>>
>> Thanks,
>>
>> Adam
>>
>> ---
>>
>> I think you've found the wrong mailing list for this post. This mailing
>> list is for 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. Read more on the mailing
>> lists at https://www.djangoproject.com/community/
>>
>> For support, please use the NEW Django forum at
>> https://forum.djangoproject.com , django-users mailing list, or IRC
>> #django on Freenode, or a site like Stack Overflow. There are people out
>> there willing to help on those channels, but they might not respond if you
>> don't ask your question well. Stack Overflow's question guide can help you
>> frame it well: https://stackoverflow.com/help/how-to-ask .
>>
>> Also if you haven't read it, please take a look at Django's Code of
>> Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
>> rules" for working well as a community, and will help you get the most out
>> of Django and our fantastic community.
>>
>> Thanks for your understanding,
>>
>> Adam
>>
>> On Wed, 4 Mar 2020 at 07:04, Deep Sukhwani  wrote:
>>
>>> Hello,
>>>
>>> This query is for Django version 1.9 and Python 3.5 with Django Rest
>>> Framework 3.5.4
>>> *(I know this version is outdated, but moving ahead of this version as
>>> of now is out of reach for the purpose of solving this query)*
>>>
>>> *Exact Error observed:*
>>>
>>> self.client.force_login(self.user)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
>>> , line 608, in force_login
>>> self._login(user)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
>>> , line 621, in _login
>>> login(request, user)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/__init__.py"
>>> , line 117, in login
>>> user_logged_in.send(sender=user.__class__, request=request, user=
>>> user)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/dispatch/dispatcher.py"
>>> , line 192, in send
>>> response = receiver(signal=self, sender=sender, **named)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/models.py"
>>> , line 23, in update_last_login
>>> user.save(update_fields=['last_login'])
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/base_user.py"
>>> , line 74, in save
>>> super(AbstractBaseUser, self).save(*args, **kwargs)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
>>> , line 708, in save
>>> force_update=force_update, update_fields=update_fields)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
>>> , line 736, in save_base
>>> updated = self._save_table(raw, cls, force_insert, force_update,
>>> using, update_fields)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
>>> , line 805, in _save_table
>>> raise DatabaseError("Save with update_fields did not affect any
>>> rows

Re: LiveServerTestCase - self.client.force_login() when called more than once returns django.db.utils.DatabaseError

2020-03-04 Thread Deep Sukhwani

Thank you.

Oh, so this is what *backporting* means. In my attempts to understand
Django internals, I have been browsing around several tickets for some
weeks now and on some of them I read "Backporting " wondering
what that means 🙄

Thanks for helping me out in this regard too 🙂


On Wed, Mar 4, 2020, 20:38 Adam Johnson  wrote:

> I should have written: You can fork Django on GitHub, backport that commit
> (git cherry-pick) to the stable/1.9.x branch, and install that hash:
> https://adamj.eu/tech/2019/03/11/pip-install-from-a-git-repository/ .
>
> On Wed, 4 Mar 2020 at 13:45, Deep Sukhwani  wrote:
>
>> Thank you, Adam,
>>
>> Note: For future posts on this topic - Request you to use django-users
>> mailing list:
>> https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY
>>
>> I realized that I posted this in the wrong mailing list after posting it
>> and so I reposted this in django-users mailing list
>> .
>> Extremely sorry for this.
>>
>> Thanks for calling out that we should really upgrade to Django 2.0,
>> however, for now, I would love to understand if there is a way to patch
>> this in Django 1.9 until we (my organization) are stuck on this version.
>>
>> *For anyone else, if you have a helpful response - request you to respond
>> to it in the django-users mailing list - link to this post: *
>> https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY
>>
>> Thank you
>>
>> On Wednesday, 4 March 2020 19:07:48 UTC+5:30, Adam Johnson wrote:
>>>
>>> Hi!
>>>
>>> I'm pasting my "wrong mailing list" standard text below. This is a
>>> support query for an old version of Django.
>>>
>>> The ticket you linked to was committed in
>>> https://github.com/django/django/commit/eedc88bd4a8468c2a0daa8346c9b57183dd77782
>>> which I can see was released in Django 2.0.
>>>
>>> You should really upgrade!
>>>
>>> Thanks,
>>>
>>> Adam
>>>
>>> ---
>>>
>>> I think you've found the wrong mailing list for this post. This mailing
>>> list is for 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. Read more on the mailing
>>> lists at https://www.djangoproject.com/community/
>>>
>>> For support, please use the NEW Django forum at
>>> https://forum.djangoproject.com , django-users mailing list, or IRC
>>> #django on Freenode, or a site like Stack Overflow. There are people out
>>> there willing to help on those channels, but they might not respond if you
>>> don't ask your question well. Stack Overflow's question guide can help you
>>> frame it well: https://stackoverflow.com/help/how-to-ask .
>>>
>>> Also if you haven't read it, please take a look at Django's Code of
>>> Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
>>> rules" for working well as a community, and will help you get the most out
>>> of Django and our fantastic community.
>>>
>>> Thanks for your understanding,
>>>
>>> Adam
>>>
>>> On Wed, 4 Mar 2020 at 07:04, Deep Sukhwani  wrote:
>>>
 Hello,

 This query is for Django version 1.9 and Python 3.5 with Django Rest
 Framework 3.5.4
 *(I know this version is outdated, but moving ahead of this version as
 of now is out of reach for the purpose of solving this query)*

 *Exact Error observed:*

 self.client.force_login(self.user)
   File
 "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
 , line 608, in force_login
 self._login(user)
   File
 "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
 , line 621, in _login
 login(request, user)
   File
 "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/__init__.py"
 , line 117, in login
 user_logged_in.send(sender=user.__class__, request=request, user=
 user)
   File
 "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/dispatch/dispatcher.py"
 , line 192, in send
 response = receiver(signal=self, sender=sender, **named)
   File
 "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/models.py"
 , line 23, in update_last_login
 user.save(update_fields=['last_login'])
   File
 "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/base_user.py"
 , line 74, in save
 super(AbstractBaseUser, self).save(*args, **kwargs)
   File
 "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
 , line 708, in save
 force_update=force_update, update_fields=update_fields)
   File
 "/Users/

Re: ngettext_lazy and ngettext

Hi Carlton,

I think this issue is important for the Django developers mailing list. I
already commented on the PR about 3 weeks ago. Yes I know that most Django
users use either English, or a language which its plural forms were not
changed recently. But users who use a language whose plural forms changed,
for example Hebrew in Django 2.2, have problems upgrading Django to 2.2
without serious consequences. I don't know how many users like this there
are, except the users who commented on this ticket, which are only about 4
or 5 users as far as I remember. But think about it this way - if the
language affected was English, would you act differently? The ticket is
from 10 months ago (May 2019), since then there is a problem with Django
2.2, and I noticed you released recently a new Django version. I think you
(the Django developers) should take this issue seriously and not like "That
one user has a bug".

אורי
u...@speedy.net

On Wed, Mar 4, 2020 at 3:43 PM Carlton Gibson 
wrote:

> HI Uri.
>
> Yes, we know. :) Please don't bump. It's just adds noise. (If you MUST
> bump, a comment on the PR is more than enough, so not everyone of the
> thousands on this list needs a notification.) Thanks.
>
> Ref backport: it's a possibility but you should phrase it more like, "this
> is serious bug for any user of i18n supporting non-latin languages"[*] — or
> similar. (That one user has a bug wouldn't qualify it.) — It is under
> consideration.
>
>
> https://www.goodreads.com/book/show/4865.How_to_Win_Friends_and_Influence_People
> (Ch1.)
>
> On Wednesday, 4 March 2020 14:20:10 UTC+1, Uri wrote:
>>
>> Django developers,
>>
>> PR #12332 is waiting to be reviewed and approved.
>>
>> https://github.com/django/django/pull/12332
>>
>> I would also like to suggest to include this PR, if accepted, into the
>> next version of 2.2. Otherwise I will not be able to use 2.2 or I will have
>> to fork Django to use 2.2, and then I will have to apply every patch
>> manually to my fork, which is a harass and I don't think should be
>> necessary.
>>
>> אורי
>> 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/CABD5YeGCfRT07uRpM3phmQFpNJz%2BFouKt1N4Ty%3D9tC0-Uz-Bjw%40mail.gmail.com.

#31319 URL dispatcher does not handle multislashes

2020-03-04 Thread Bjoern Boschman

Hi,

I'd like to start a discussion about how django handles multiple slashes.
see: https://code.djangoproject.com/ticket/31319#comment:1

So far I can confirm that nginx, apache and unix folders handle multiple 
slashes the same way (-> they get merged)
What's your (dev) opinion on this?

Cheers
B

-- 
TV Squared Limited is a company registered in Scotland.  Registered number: 
SC421072.  Registered office: CodeBase, Argyle House, 3 Lady Lawson Street, 
Edinburgh, EH3 9DR. 
 
TV Squared Inc (File No. 5600204) is an Incorporated 
company registered in Delaware. Principal office: 1412 Broadway, 22 Fl, New 
York, New York, 10018

TV Squared GmbH is a company registered in Munich. 
Registered number: HRB 236077. Registered office: Oskar-von-Miller-Ring 20, 
c/o wework, 80333 Munchen

This message is private and confidential.  If 
you have received this message in error, please notify us and remove it 
from your system.

-- 
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/0afe6cd9-952e-46a7-b756-10bb04eb70e9%40googlegroups.com.

Re: ngettext_lazy and ngettext

We are taking it seriously Uri. It’s difficult to resolve instantly when
there’s a super long mailing list thread, and several PRs in play, and a
major discussion on the ticket. It’s only recently that the correct
approach has become clear. It’s taken a community effort, from i18n experts
to get there.

Before that there was pressure to quickly merge incorrect solutions.

Then we have security issues to resolve, such as two SQL injection issues
in the last couple of months. These take priority.

Sorry if things go slower than you’d like. There’s more to it than perhaps
there seems. (Not least the danger of introducing regressions, especially
if we do decide to backport, as you’d like.)


On Wed, 4 Mar 2020 at 18:14, אורי  wrote:

> Hi Carlton,
>
> I think this issue is important for the Django developers mailing list. I
> already commented on the PR about 3 weeks ago. Yes I know that most Django
> users use either English, or a language which its plural forms were not
> changed recently. But users who use a language whose plural forms changed,
> for example Hebrew in Django 2.2, have problems upgrading Django to 2.2
> without serious consequences. I don't know how many users like this there
> are, except the users who commented on this ticket, which are only about 4
> or 5 users as far as I remember. But think about it this way - if the
> language affected was English, would you act differently? The ticket is
> from 10 months ago (May 2019), since then there is a problem with Django
> 2.2, and I noticed you released recently a new Django version. I think you
> (the Django developers) should take this issue seriously and not like "That
> one user has a bug".
>
> אורי
> u...@speedy.net
>
>
> On Wed, Mar 4, 2020 at 3:43 PM Carlton Gibson 
> wrote:
>
>> HI Uri.
>>
>> Yes, we know. :) Please don't bump. It's just adds noise. (If you MUST
>> bump, a comment on the PR is more than enough, so not everyone of the
>> thousands on this list needs a notification.) Thanks.
>>
>> Ref backport: it's a possibility but you should phrase it more like,
>> "this is serious bug for any user of i18n supporting non-latin
>> languages"[*] — or similar. (That one user has a bug wouldn't qualify it.)
>> — It is under consideration.
>>
>>
>> https://www.goodreads.com/book/show/4865.How_to_Win_Friends_and_Influence_People
>> (Ch1.)
>>
>> On Wednesday, 4 March 2020 14:20:10 UTC+1, Uri wrote:
>>>
>>> Django developers,
>>>
>>> PR #12332 is waiting to be reviewed and approved.
>>>
>>> https://github.com/django/django/pull/12332
>>>
>>> I would also like to suggest to include this PR, if accepted, into the
>>> next version of 2.2. Otherwise I will not be able to use 2.2 or I will have
>>> to fork Django to use 2.2, and then I will have to apply every patch
>>> manually to my fork, which is a harass and I don't think should be
>>> necessary.
>>>
>>> אורי
>>> 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/CABD5YeGCfRT07uRpM3phmQFpNJz%2BFouKt1N4Ty%3D9tC0-Uz-Bjw%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/CAJwKpyTngRNidxiJXsc7a3McQqtVp-TSjrdWheCq5s6j8r%3DLwg%40mail.gmail.com.

Re: ngettext_lazy and ngettext

Yes, I understand. Don't merge incorrect solutions. But notice that it is a
regression, in the affected languages. Things just stop working after
upgrading Django. If I didn't have the unit tests which failed, I might
have upgraded Django to production and my users would have received
messages in an incorrect language. There is not even an exception raised
when the messages are not translated. It just happens that the language I'm
using is not the most popular language Django users are using, but it is a
regression. It's also not documented in the release notes, as I would
expect it to be documented there.
אורי
u...@speedy.net


On Wed, Mar 4, 2020 at 7:22 PM Carlton Gibson 
wrote:

> We are taking it seriously Uri. It’s difficult to resolve instantly when
> there’s a super long mailing list thread, and several PRs in play, and a
> major discussion on the ticket. It’s only recently that the correct
> approach has become clear. It’s taken a community effort, from i18n experts
> to get there.
>
> Before that there was pressure to quickly merge incorrect solutions.
>
> Then we have security issues to resolve, such as two SQL injection issues
> in the last couple of months. These take priority.
>
> Sorry if things go slower than you’d like. There’s more to it than perhaps
> there seems. (Not least the danger of introducing regressions, especially
> if we do decide to backport, as you’d like.)
>
>
> On Wed, 4 Mar 2020 at 18:14, אורי  wrote:
>
>> Hi Carlton,
>>
>> I think this issue is important for the Django developers mailing list. I
>> already commented on the PR about 3 weeks ago. Yes I know that most Django
>> users use either English, or a language which its plural forms were not
>> changed recently. But users who use a language whose plural forms changed,
>> for example Hebrew in Django 2.2, have problems upgrading Django to 2.2
>> without serious consequences. I don't know how many users like this there
>> are, except the users who commented on this ticket, which are only about 4
>> or 5 users as far as I remember. But think about it this way - if the
>> language affected was English, would you act differently? The ticket is
>> from 10 months ago (May 2019), since then there is a problem with Django
>> 2.2, and I noticed you released recently a new Django version. I think you
>> (the Django developers) should take this issue seriously and not like "That
>> one user has a bug".
>>
>> אורי
>> u...@speedy.net
>>
>>
>> On Wed, Mar 4, 2020 at 3:43 PM Carlton Gibson 
>> wrote:
>>
>>> HI Uri.
>>>
>>> Yes, we know. :) Please don't bump. It's just adds noise. (If you MUST
>>> bump, a comment on the PR is more than enough, so not everyone of the
>>> thousands on this list needs a notification.) Thanks.
>>>
>>> Ref backport: it's a possibility but you should phrase it more like,
>>> "this is serious bug for any user of i18n supporting non-latin
>>> languages"[*] — or similar. (That one user has a bug wouldn't qualify it.)
>>> — It is under consideration.
>>>
>>>
>>> https://www.goodreads.com/book/show/4865.How_to_Win_Friends_and_Influence_People
>>> (Ch1.)
>>>
>>> On Wednesday, 4 March 2020 14:20:10 UTC+1, Uri wrote:

 Django developers,

 PR #12332 is waiting to be reviewed and approved.

 https://github.com/django/django/pull/12332

 I would also like to suggest to include this PR, if accepted, into the
 next version of 2.2. Otherwise I will not be able to use 2.2 or I will have
 to fork Django to use 2.2, and then I will have to apply every patch
 manually to my fork, which is a harass and I don't think should be
 necessary.

 אורי
 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/CABD5YeGCfRT07uRpM3phmQFpNJz%2BFouKt1N4Ty%3D9tC0-Uz-Bjw%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/CAJwKpyTngRNidxiJXsc7a3McQqtVp-TSjrdWheCq5s6j8r%3DLwg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Grou

Re: ngettext_lazy and ngettext

By the way, I also had a regression when upgrading to Django 2.1, which I
was not aware of until after about 4 or 5 weeks after I upgraded. Something
changed with the cookie settings (the default Django setting) and then
login/logout didn't work across 2 of my websites, until I changed cookie
settings (I think it was SESSION_COOKIE_SAMESITE that changed). It is
documented on the release notes but I didn't notice it, no unit tests
failed and I introduced a bug to production. It took me about 4 or 5 weeks
to fix this.
אורי
u...@speedy.net


On Wed, Mar 4, 2020 at 7:22 PM Carlton Gibson 
wrote:

> We are taking it seriously Uri. It’s difficult to resolve instantly when
> there’s a super long mailing list thread, and several PRs in play, and a
> major discussion on the ticket. It’s only recently that the correct
> approach has become clear. It’s taken a community effort, from i18n experts
> to get there.
>
> Before that there was pressure to quickly merge incorrect solutions.
>
> Then we have security issues to resolve, such as two SQL injection issues
> in the last couple of months. These take priority.
>
> Sorry if things go slower than you’d like. There’s more to it than perhaps
> there seems. (Not least the danger of introducing regressions, especially
> if we do decide to backport, as you’d like.)
>
>
> On Wed, 4 Mar 2020 at 18:14, אורי  wrote:
>
>> Hi Carlton,
>>
>> I think this issue is important for the Django developers mailing list. I
>> already commented on the PR about 3 weeks ago. Yes I know that most Django
>> users use either English, or a language which its plural forms were not
>> changed recently. But users who use a language whose plural forms changed,
>> for example Hebrew in Django 2.2, have problems upgrading Django to 2.2
>> without serious consequences. I don't know how many users like this there
>> are, except the users who commented on this ticket, which are only about 4
>> or 5 users as far as I remember. But think about it this way - if the
>> language affected was English, would you act differently? The ticket is
>> from 10 months ago (May 2019), since then there is a problem with Django
>> 2.2, and I noticed you released recently a new Django version. I think you
>> (the Django developers) should take this issue seriously and not like "That
>> one user has a bug".
>>
>> אורי
>> u...@speedy.net
>>
>>
>> On Wed, Mar 4, 2020 at 3:43 PM Carlton Gibson 
>> wrote:
>>
>>> HI Uri.
>>>
>>> Yes, we know. :) Please don't bump. It's just adds noise. (If you MUST
>>> bump, a comment on the PR is more than enough, so not everyone of the
>>> thousands on this list needs a notification.) Thanks.
>>>
>>> Ref backport: it's a possibility but you should phrase it more like,
>>> "this is serious bug for any user of i18n supporting non-latin
>>> languages"[*] — or similar. (That one user has a bug wouldn't qualify it.)
>>> — It is under consideration.
>>>
>>>
>>> https://www.goodreads.com/book/show/4865.How_to_Win_Friends_and_Influence_People
>>> (Ch1.)
>>>
>>> On Wednesday, 4 March 2020 14:20:10 UTC+1, Uri wrote:

 Django developers,

 PR #12332 is waiting to be reviewed and approved.

 https://github.com/django/django/pull/12332

 I would also like to suggest to include this PR, if accepted, into the
 next version of 2.2. Otherwise I will not be able to use 2.2 or I will have
 to fork Django to use 2.2, and then I will have to apply every patch
 manually to my fork, which is a harass and I don't think should be
 necessary.

 אורי
 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/CABD5YeGCfRT07uRpM3phmQFpNJz%2BFouKt1N4Ty%3D9tC0-Uz-Bjw%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/CAJwKpyTngRNidxiJXsc7a3McQqtVp-TSjrdWheCq5s6j8r%3DLwg%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 gr

Re: ngettext_lazy and ngettext

Right, but now we come right back to the beginning: it's not a regression, 
and not judged one by Django i18n team, who are as knowledgeable as anyone 
about these things. I see no value in your continuing to press this point. 

If it had have been it would have been triaged as a Release Blocker. 

As it is, on strictest terms it probably doesn't qualify for a backport, 
but given that it does affect all users of i18n for non-latin languages 
we're considering backporting it the "severity" clause. 

FWIW I'm in favour of the backport, and have argued for that in 
discussions. 

We will get back to the PR again as soon as we can, and will resolve it as 
soon as we can. More than that I cannot say. 

I appreciate that's not as quick as you want. You're welcome to use a 
patched version in the meantime if your schedule demands. (Adam posting 
instructions on how to do that in another thread just today.) 

I'm going to unsubscribe from this thread now.

On Wednesday, 4 March 2020 18:35:32 UTC+1, Uri wrote:
>
> Yes, I understand. Don't merge incorrect solutions. But notice that it is 
> a regression, in the affected languages. Things just stop working after 
> upgrading Django. If I didn't have the unit tests which failed, I might 
> have upgraded Django to production and my users would have received 
> messages in an incorrect language. There is not even an exception raised 
> when the messages are not translated. It just happens that the language I'm 
> using is not the most popular language Django users are using, but it is a 
> regression. It's also not documented in the release notes, as I would 
> expect it to be documented there.
> אורי
> u...@speedy.net 
>
>
> On Wed, Mar 4, 2020 at 7:22 PM Carlton Gibson  > wrote:
>
>> We are taking it seriously Uri. It’s difficult to resolve instantly when 
>> there’s a super long mailing list thread, and several PRs in play, and a 
>> major discussion on the ticket. It’s only recently that the correct 
>> approach has become clear. It’s taken a community effort, from i18n experts 
>> to get there.  
>>
>> Before that there was pressure to quickly merge incorrect solutions. 
>>
>> Then we have security issues to resolve, such as two SQL injection issues 
>> in the last couple of months. These take priority.  
>>
>> Sorry if things go slower than you’d like. There’s more to it than 
>> perhaps there seems. (Not least the danger of introducing regressions, 
>> especially if we do decide to backport, as you’d like.)
>>
>>
>> On Wed, 4 Mar 2020 at 18:14, אורי > wrote:
>>
>>> Hi Carlton,
>>>
>>> I think this issue is important for the Django developers mailing list. 
>>> I already commented on the PR about 3 weeks ago. Yes I know that most 
>>> Django users use either English, or a language which its plural forms were 
>>> not changed recently. But users who use a language whose plural forms 
>>> changed, for example Hebrew in Django 2.2, have problems upgrading Django 
>>> to 2.2 without serious consequences. I don't know how many users like this 
>>> there are, except the users who commented on this ticket, which are only 
>>> about 4 or 5 users as far as I remember. But think about it this way - if 
>>> the language affected was English, would you act differently? The ticket is 
>>> from 10 months ago (May 2019), since then there is a problem with Django 
>>> 2.2, and I noticed you released recently a new Django version. I think you 
>>> (the Django developers) should take this issue seriously and not like "That 
>>> one user has a bug".
>>>
>>> אורי
>>> u...@speedy.net 
>>>
>>>
>>> On Wed, Mar 4, 2020 at 3:43 PM Carlton Gibson >> > wrote:
>>>
 HI Uri. 

 Yes, we know. :) Please don't bump. It's just adds noise. (If you MUST 
 bump, a comment on the PR is more than enough, so not everyone of the 
 thousands on this list needs a notification.) Thanks. 

 Ref backport: it's a possibility but you should phrase it more like, 
 "this is serious bug for any user of i18n supporting non-latin 
 languages"[*] — or similar. (That one user has a bug wouldn't qualify it.) 
 — It is under consideration. 


 https://www.goodreads.com/book/show/4865.How_to_Win_Friends_and_Influence_People
  
 (Ch1.)

 On Wednesday, 4 March 2020 14:20:10 UTC+1, Uri wrote:
>
> Django developers,
>
> PR #12332 is waiting to be reviewed and approved.
>
> https://github.com/django/django/pull/12332  
>
> I would also like to suggest to include this PR, if accepted, into the 
> next version of 2.2. Otherwise I will not be able to use 2.2 or I will 
> have 
> to fork Django to use 2.2, and then I will have to apply every patch 
> manually to my fork, which is a harass and I don't think should be 
> necessary.
>
> אורי
> u...@speedy.net
>
>
 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Djan

Re: #31319 URL dispatcher does not handle multislashes

I'd be against this

Merging multiple slashes is a way of duplicating canonical URL's for
things, something Django actively tries to avoid with APPEND_SLASHES.

If you want this functionality you should be able to create it yourself
with a custom URL converter or URLPattern subclass.

On Wed, 4 Mar 2020 at 14:41, Bjoern Boschman 
wrote:

> Hi,
>
> I'd like to start a discussion about how django handles multiple slashes.
> see: https://code.djangoproject.com/ticket/31319#comment:1
>
> So far I can confirm that nginx, apache and unix folders handle multiple
> slashes the same way (-> they get merged)
> What's your (dev) opinion on this?
>
> Cheers
> B
>
> TV Squared Limited is a company registered in Scotland.  Registered
> number: SC421072.  Registered office: CodeBase, Argyle House, 3 Lady Lawson
> Street, Edinburgh, EH3 9DR.
>
> TV Squared Inc (File No. 5600204) is an Incorporated company registered in
> Delaware. Principal office: 1412 Broadway, 22 Fl, New York, New York, 10018
>
> TV Squared GmbH is a company registered in Munich. Registered number: HRB
> 236077. Registered office: Oskar-von-Miller-Ring 20, c/o wework, 80333
> Munchen
>
> This message is private and confidential.  If you have received this
> message in error, please notify us and remove it from your system.
>
> --
> 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/0afe6cd9-952e-46a7-b756-10bb04eb70e9%40googlegroups.com
> 
> .
>


-- 
Adam

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

Re: #31319 URL dispatcher does not handle multislashes

2020-03-04 Thread Bjoern Boschman

Hi Adam,

APPEND_SLASH only adds a slash at the end of the path
I'm more concerned about having multiple slashes in the middle of the path
I get your point about canonical URLs - I'm just confused why other major 
HTTP servers are handling this different

On Wednesday, 4 March 2020 14:27:19 UTC-5, Adam Johnson wrote:
>
> I'd be against this
>
> Merging multiple slashes is a way of duplicating canonical URL's for 
> things, something Django actively tries to avoid with APPEND_SLASHES.
>
> If you want this functionality you should be able to create it yourself 
> with a custom URL converter or URLPattern subclass.
>
> On Wed, 4 Mar 2020 at 14:41, Bjoern Boschman  > wrote:
>
>> Hi,
>>
>> I'd like to start a discussion about how django handles multiple slashes.
>> see: https://code.djangoproject.com/ticket/31319#comment:1
>>
>> So far I can confirm that nginx, apache and unix folders handle multiple 
>> slashes the same way (-> they get merged)
>> What's your (dev) opinion on this?
>>
>> Cheers
>> B
>>
>> TV Squared Limited is a company registered in Scotland.  Registered 
>> number: SC421072.  Registered office: CodeBase, Argyle House, 3 Lady Lawson 
>> Street, Edinburgh, EH3 9DR. 
>>  
>> TV Squared Inc (File No. 5600204) is an Incorporated company registered 
>> in Delaware. Principal office: 1412 Broadway, 22 Fl, New York, New York, 
>> 10018
>>
>> TV Squared GmbH is a company registered in Munich. Registered number: HRB 
>> 236077. Registered office: Oskar-von-Miller-Ring 20, c/o wework, 80333 
>> Munchen
>>
>> This message is private and confidential.  If you have received this 
>> message in error, please notify us and remove it from your system.
>>
>> -- 
>> 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/0afe6cd9-952e-46a7-b756-10bb04eb70e9%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Adam
>

-- 
TV Squared Limited is a company registered in Scotland.  Registered number: 
SC421072.  Registered office: CodeBase, Argyle House, 3 Lady Lawson Street, 
Edinburgh, EH3 9DR. 
 
TV Squared Inc (File No. 5600204) is an Incorporated 
company registered in Delaware. Principal office: 1412 Broadway, 22 Fl, New 
York, New York, 10018

TV Squared GmbH is a company registered in Munich. 
Registered number: HRB 236077. Registered office: Oskar-von-Miller-Ring 20, 
c/o wework, 80333 Munchen

This message is private and confidential.  If 
you have received this message in error, please notify us and remove it 
from your system.

-- 
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/fce90055-ce46-4704-b81e-afc64bcde358%40googlegroups.com.

Re: #31319 URL dispatcher does not handle multislashes