[Probably BUG] set_password and check_password accept values other than string as parameters

[Dawid Czeluśniak]

Hi all,

I've noticed that both set_password and check_password methods accept 
values other than str as parameters. For example I'm able to set password 
to boolean values:

In [1]: u.set_password(True)

In [2]: u.save()

In [3]: u.refresh_from_db()

In [4]: u.check_password(True)
Out[4]: True

In [5]: u.check_password('True')
Out[5]: True

What is even weirder, I'm able to set password as Exception class:

In [1]: u.set_password(Exception)

In [2]: u.save()

In [3]: u.refresh_from_db()

In [4]: u.check_password(repr(Exception))
Out[4]: True

and the User instance itself:

In [1]: u.set_password(u)

In [2]: u.save()

In [3]: u.refresh_from_db()

In [4]: u.check_password(u)
Out[4]: True

In [5]: u.check_password(str(u))
Out[5]: True

IMHO this is not correct behaviour especially because Django documentation 
implies that these methods accept strings.

set_password(raw_password)
> Sets the user’s password to the given *raw string*, taking care of the 
> password hashing. Doesn’t save the User object.
>
> check_password(raw_password)
> Returns True if the given *raw string* is the correct password for the 
> user. (This takes care of the password hashing in making the comparison.)


Please let me know if this is reproducible on your side.

Dawid

-- 
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/0429a2cd-a16c-429f-98b5-938629073ca5%40googlegroups.com.

Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

[Javier Buzzi]

Hey guys, looks like gowtham added  a new PR, can you guys add some insight?

https://github.com/django/django/pull/12558
https://code.djangoproject.com/ticket/31123

The question of what to call the flag that will add this functionality has 
come up, I'm hoping one of you has a better name.

Thanks.

On Saturday, January 4, 2020 at 12:00:11 PM UTC-5, Jon Dufresne wrote:
>
> An optional command line argument makes sense to me. +1
>
> On Thu, Jan 2, 2020 at 2:11 PM Adam Johnson > 
> wrote:
>
>> I guess an optional kwarg would be okay then.
>>
>> On Thu, 2 Jan 2020 at 03:08, Javier Buzzi > > wrote:
>>
>>> @adam I agree with your points, about data loss, but this can still see 
>>> this as being beneficial, perhaps the approach was just too harsh. Perhaps 
>>> adding a flag in the management command would get everyone on board? The 
>>> flag being off by default and only turns on if you know what you’re doing 
>>> and enable it. At any rate i believe from what i can i see in the code it 
>>> will still prompt you to delete the items it finds unless you added the 
>>> ——no—input which prevents helps with data loss.
>>>
>>> -- 
>>> 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/5c55fdaa-8d89-4baa-a08d-68b0e84c610c%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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM3Hu_ZKWUj46%3D0BYN8XECG0OT_kMLNUgaopKXhJOEfJ5Q%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/7312db0c-cd6b-49a6-9123-82c545304692%40googlegroups.com.

Re: Psycopg3 Redesign

[Andrew Godwin]

I am particularly excited for native async support arriving - that's
something I'd love to have and ship support for from our side when it's
done. The rest looks quite sensible too.

Andrew

On Wed, Mar 11, 2020 at 3:39 AM Jure Erznožnik 
wrote:

> His proposed changes look awesome to me!
>
> IMHO, the biggest issue going async with current implementation was
> connection pooling for async code. I feared that we might need huge numbers
> of connections in certain scenarios, especially if the code required
> altering the connections themselves. The proposed changes look like they
> eliminate the issue altogether and I'm not referring to direct async
> support alone.
>
> LP,
> Jure
>
>
> On 11/03/2020 09:28, Asif Saif Uddin wrote:
>
> Hi,
>
> As this library is used by django, I thought it would be good to share
> with django internals deveopers?
>
> https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/
>
> Hope it is useful.
>
> ./auvipy
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/faea6068-ec43-4da6-9780-1beaedaf0b16%40googlegroups.com
> 
> .
>
> --
> 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/110c8328-c0ea-e32e-081a-ca42657193b7%40gmail.com
> 
> .
>

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

Re: Proposal for better managed raw SQL migrations

[Adam Johnson]

Hi Petr

I too often end up managing some database objects like triggers, normally
in order to support database migrations. I have always been happy using
RawSQL migration operations though.

What types of database objects are you mostly using? And how?

I think django-migrate-sql is a neat idea, but since it requires full
authorship of the SQL it doesn't provide the most ORM-like experience. It's
also not backend agnostic, which is something preferable for anything we
add to Django. I'd be more interested in implementing classes that
represent the underlying object type, like Models represent tables, and
translating changes to them into migration operations.

Thanks,

Adam

On Wed, 11 Mar 2020 at 09:04, Petr Přikryl  wrote:

> In our apps we have a lot of database objects which are hard to manage in
> classic Django migrations. Next, we clean our migrations time to time to
> speed up deployment process. And it would be awesome if Django would have
> system for raw SQL "models" and handle migrations and dependencies
> automatically in makemigrations and migrate commands like
> django-migrate-sql-deux https://pypi.org/project/django-migrate-sql-deux/.
> What do you think?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c078a0ae-9643-4d5c-b1de-f82cec2a7f33%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/CAMyDDM02yEMRP5tvwWEY9mwK4Xn6z%3Dr%3Dw05_D1RxWRKUQ4gjpA%40mail.gmail.com.

Proposal for better managed raw SQL migrations

[Petr Přikryl]

I have only proposal for making Django migrations better handling raw SQL 
migrations. I like the way how django-migrate-sql do that 
https://github.com/festicket/django-migrate-sql. And it would be interested 
if Django has this feature build-in.

We use a lot of raw SQL objects in our apps and time to time we are 
cleaning migrations so storing to SQL itself in migrations isn't right way 
for us. I like the idea, looking on SQL objects like on models and generate 
migrations for them automatically based on their definition changes. What 
do you think?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1382459f-7d54-479c-9e38-0e4a434ad379%40googlegroups.com.

Proposal for better managed raw SQL migrations

[Petr Přikryl]

In our apps we have a lot of database objects which are hard to manage in 
classic Django migrations. Next, we clean our migrations time to time to 
speed up deployment process. And it would be awesome if Django would have 
system for raw SQL "models" and handle migrations and dependencies 
automatically in makemigrations and migrate commands like 
django-migrate-sql-deux https://pypi.org/project/django-migrate-sql-deux/. 
What do you think?

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

Re: Psycopg3 Redesign

[Jure Erznožnik]

His proposed changes look awesome to me!

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


LP,
Jure


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

Hi,

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


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

Hope it is useful.

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


--
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/110c8328-c0ea-e32e-081a-ca42657193b7%40gmail.com.

Psycopg3 Redesign

[Asif Saif Uddin]

Hi,

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

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

Hope it is useful.

./auvipy

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