Re: Django bugfix release: 2.1.1

[Adam Johnson]

I emailed Paulo off list, he was using Python 3.4 which Django 2.1 no
longer supports. pip could give a friendlier message when environment
markers don’t match but there are such versions on PyPI.

On Sun, 2 Sep 2018 at 08:22, Carlton Gibson 
wrote:

> Hi Paulo
>
> It looks like there's something going wrong with your pip:
>
> The install works correctly and PyPI is showing 2.1.1 as the latest
> version.
>
> https://pypi.org/project/Django/
>
>
>
> ```
> Last login: Sun Sep  2 00:07:29 on ttys001
> ~/ve $ mktmpenv
> New python executable in
> /Users/carlton/ve/tmp-a4084573c79e645/bin/python3.6
> Also creating executable in
> /Users/carlton/ve/tmp-a4084573c79e645/bin/python
> ...
> This is a temporary environment. It will be deleted when you run
> 'deactivate'.
> (tmp-a4084573c79e645) ~/ve/tmp-a4084573c79e645 $ pip install Django==2.1.1
> --no-cache-dir
> Collecting Django==2.1.1
>   Downloading
> https://files.pythonhosted.org/packages/ca/7e/fc068d164b32552ae3a8f8d5d0280c083f2e8d553e71ecacc21927564561/Django-2.1.1-py3-none-any.whl
> (7.3MB)
> 100% || 7.3MB 5.2MB/s
> Collecting pytz (from Django==2.1.1)
>   Downloading
> https://files.pythonhosted.org/packages/30/4e/27c34b62430286c6d59177a0842ed90dc789ce5d1ed740887653b898779a/pytz-2018.5-py2.py3-none-any.whl
> (510kB)
> 100% || 512kB 4.0MB/s
> Installing collected packages: pytz, Django
> Successfully installed Django-2.1.1 pytz-2018.5
> ```
>
> Kind Regards,
>
> Carlton
>
>
>
> On Saturday, 1 September 2018 17:30:46 UTC+2, Paulo Maciel wrote:
>>
>> pip install Django==2.1.1
>> Could not find a version that satisfies the requirement Django==2.1.1
>>
>> Em sexta-feira, 31 de agosto de 2018 05:52:28 UTC-3, Carlton Gibson
>> escreveu:
>>>
>>> Details are available on the Django project weblog:
>>>
>>> https://www.djangoproject.com/weblog/2018/aug/31/bugfix-release/
>>>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fd173074-0eed-45d4-963a-c8bdd3d82134%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2C%2B%2BhMXeYuXmFfiqVosKJq9F9diSiZ7AEyckzCQP8cBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django bugfix release: 2.1.1

[Carlton Gibson]

Cool. Thanks 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/42D86F9B-B713-402F-8BB3-0F7AC0394FB7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Fellow Reports -- August 2018

[Carlton Gibson]

Hi all,


Calendar Week 35 -- ending 31 August.


Triaged:

https://code.djangoproject.com/ticket/29723 -- Backwards-incompatible 
change of has_add_permission in 2.1 (Accepted.)
https://code.djangoproject.com/ticket/29714 -- Option to hide cookies in 
error reports (Accepted.) 
https://code.djangoproject.com/ticket/29711 -- One can use as actions 
functions generated only by the first call to another function (Invalid.)


Reviewed:

https://github.com/django/django/pull/10357 -- Fix backwards incompatible 
release note location
https://github.com/django/django/pull/10356 -- Replace snippet:: with 
code-block::
https://github.com/django/django/pull/10355 -- Fixed #29723 -- Fixed crash 
if InlineModelAdmin.has_add_permission() doesn't accept the obj argument.
https://github.com/django/django/pull/10352 -- converted all single line 
comments to multiple line comments
https://github.com/django/django/pull/10342 -- Fixed LayerMapping encoding 
in geodjango tutorial.
https://github.com/django/django/pull/10341 -- Added getattr for 
profilefield in order to be used as the same model
https://code.djangoproject.com/ticket/29243 -- Improve efficiency of 
migration graph algorithm


Released v2.1.1



Kind Regards,

Carlton

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/067c5eb2-934f-46ba-8585-c933e001%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: New Password Validators

[Mehmet Dogan]

Scot,

This is nice, thank you for sharing. I think something like this + an up to 
date black list should be good enough. 

Mehmet

From: Scot Hacker
Sent: Saturday, September 1, 2018 8:38 PM
To: Django developers (Contributions to Django itself)
Subject: Re: New Password Validators

Rather than enforce an arbitrary set of password construction rules, I prefer 
systems that gauge password strength as an overall entropy score, then let  
sites establish the minimum overall strength they require. How that strength is 
achieved is up to each user - uou can either go short and random, or long and 
memorable. Length trumps pretty much all other factors, especially if you 
disallow strings such as the user's own username, email, company name, etc.). 
Dropbox created a system like this called zxcvbn and open sourced it.  It was 
then ported to python. 

https://github.com/dropbox/zxcvbn
https://github.com/dwolfhub/zxcvbn-python

I use a "roll your own" solution on top of zxcvbn-python in some of my projects 
(in order to show dynamic strength meters in the UI as user types), but others 
have converted it to work as a Django password validator.

https://github.com/Pierre-Sassoulas/django-zxcvbn-password-validator

If Django were to bundle any additional validators, this or something like it 
would have my vote.

./s

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/Xlovt28QIDo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/de03b9dd-ef24-4ee6-a7fd-287e79304465%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5b8bf02a.1c69fb81.84d1a.1c4e%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

OneToOneField not updating relationship with reverse relation after refresh_from_db()

[Shivam Jindal]

I have the following model

class Member(models.Model):
user = models.OneToOneField(User, null=True, blank=True)

*Operation sequence*

m = Member.objects.get(id=4) # This objects has attached user
m.user # Print user objects successfully
m1 = Member.objects.get(id=4) # Fetch same object from db
m1.user = None
m1.save() # Remove user object from above member

*m.user.refresh_from_db()*
*m.user.member* # It is printing the member object which was linked
previously, but the user object should not have attached member object
because the relationship should had been updated by calling
*refresh_from_db()*

-- 
*Shivam Jindal*
*Software Developer* | *Josh Technology Group*
shivam.jin...@joshtechnololygroup.com

-- 
CONFIDENTIALITY
 NOTICE: The information contained in this e-mail is for 
the intended 
recipient(s) alone. It may contain privileged and 
confidential 
information that is exempt from disclosure under applicable 
law. If you 
have received this email in error, please notify the sender of 
the error
 and delete this message immediately.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOU9VRa477v3_pkPPYvJXa%2B47zTkbjt1xdLRjbZ9%2BXWtAYb6rQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Serializer as a project

[doctormo]

Dear django-devs,

I've been reading a lot about the state of dumpdata and loaddata
commands in dango. The bug reports that I've found tend to focus
improvements to either cosmetic improvements or to a total rewrite of
the functionality and pointing discussions to this list.

I've pondered this for a few weeks. Mulled it over.

In a fit of foolish bravery, I'm proposing that we look seriously at
doing that total rewrite project suggested. Or at least scope it out so
we know what it's trying to do for our users.

Firstly let's say it's a clean slate, created some different command
names. This means it could be handled structurally as a separate
project first, maybe moved into contrib later after much vetting. I'd
run away and make this now, but I know other django-devs are filled
with wisdom and past context, hence my request here for advice before
committing to code.

I'd like to develop proper user stories, but these are the uses I can
think up at the moment:

 * Test suite fixtures
 * Site initialization data
 * Horizontal data sharing (usually chunks of data)
 * Moving between database types
 * Backing up data?

These are the issues:

 * No relationship control (missing relationships, no user handling)
 * No migration state (and no migration for fixtures)
 * No difference between whole and part data
 * Default inclusion of auto generate content (permissions, etc)
 * No rules for handling conflicts, duplication, merging.
 * No handling for media files (included or linked)
 * No meta-data about user data handling, licensing or ownership.

I won't put together a solution to any of these because I think there's
probably some more refinement of the problem first. Please do rip these
apart and let me know if you've encountered anything else.

Thanks for reading.

With Regards, Martin Owens

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/45f6db3904013760b8ba591df96c791bfa5ca5e2.camel%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: OneToOneField not updating relationship with reverse relation after refresh_from_db()

[Ian Foote]

On 02/09/18 17:58, Shivam Jindal wrote:
> I have the following model
> 
> class Member(models.Model):
>     user = models.OneToOneField(User, null=True, blank=True)
> 
> *Operation sequence*
> 
> m = Member.objects.get(id=4) # This objects has attached user
> m.user # Print user objects successfully
> m1 = Member.objects.get(id=4) # Fetch same object from db 
> m1.user = None
> m1.save() # Remove user object from above member
> 
> *m.user.refresh_from_db()*
> *m.user.member* # It is printing the member object which was linked
> previously, but the user object should not have attached member object
> because the relationship should had been updated by calling
> *refresh_from_db()*  
> 

Hi Shivam,

I don't believe this is actually a bug. You're refreshing m.user, not m
itself, so as far as m is concerned m.user hasn't changed. If you use
m.refresh_from_db() instead you should see m.user updated to None.

Hope this helps,
Ian

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8df15e03-4d44-225d-7116-6954d0821362%40feete.org.
For more options, visit https://groups.google.com/d/optout.

Re: OneToOneField not updating relationship with reverse relation after refresh_from_db()

[Shivam Jindal]

Hi Lan,

*m.user.refresh_from_db()* is sam as

*u = m.user*
*u.refresh_from_db()*

So If I am refreshing u, it should update all relationship and property of
*u*(including reverse relation). Should It not?

On Mon, Sep 3, 2018 at 12:24 AM, Ian Foote  wrote:

> On 02/09/18 17:58, Shivam Jindal wrote:
> > I have the following model
> >
> > class Member(models.Model):
> > user = models.OneToOneField(User, null=True, blank=True)
> >
> > *Operation sequence*
> >
> > m = Member.objects.get(id=4) # This objects has attached user
> > m.user # Print user objects successfully
> > m1 = Member.objects.get(id=4) # Fetch same object from db
> > m1.user = None
> > m1.save() # Remove user object from above member
> >
> > *m.user.refresh_from_db()*
> > *m.user.member* # It is printing the member object which was linked
> > previously, but the user object should not have attached member object
> > because the relationship should had been updated by calling
> > *refresh_from_db()*
> >
>
> Hi Shivam,
>
> I don't believe this is actually a bug. You're refreshing m.user, not m
> itself, so as far as m is concerned m.user hasn't changed. If you use
> m.refresh_from_db() instead you should see m.user updated to None.
>
> Hope this helps,
> Ian
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/8df15e03-4d44-225d-7116-6954d0821362%40feete.org.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*Shivam Jindal*
*Software Developer* | *Josh Technology Group*
shivam.jin...@joshtechnololygroup.com

-- 
CONFIDENTIALITY
 NOTICE: The information contained in this e-mail is for 
the intended 
recipient(s) alone. It may contain privileged and 
confidential 
information that is exempt from disclosure under applicable 
law. If you 
have received this email in error, please notify the sender of 
the error
 and delete this message immediately.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOU9VRbLOek7jL5pK74nU4RGHi8tbZKZNrm8R68G40AdYSHx8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: OneToOneField not updating relationship with reverse relation after refresh_from_db()

[Ian Foote]

On 02/09/18 19:59, Shivam Jindal wrote:
> Hi Lan,
> 
> *m.user.refresh_from_db()* is sam as 
> 
> *u = m.user*
> *u.refresh_from_db()*
> 
> So If I am refreshing u, it should update all relationship and property
> of *u*(including reverse relation). Should It not?
> 

Hi Shivam,

As far as I can tell, u.refresh_from_db() only cares about making sure
u's state is in sync with the database. It doesn't care about the state
of any related objects, like m.

I suspect that cascading the sync to related objects would be difficult
to get right and might be unexpected behaviour to other users. I'm still
not convinced this is a bug and even if it is, I think it would require
a deprecation cycle to change, so I don't think it would be worth it.
Just calling m.refresh_from_db() instead seems sufficient to me.

Ian

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cdd0e68f-64e8-ef1c-5022-9ecab4ba604e%40feete.org.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: relationships based on arbitrary predicates

[Alexander Hill]

Hi Simon,

Thanks for looking at this and for providing some context - I had looked at
FilteredRelation but I hadn't seen reverse-unique. It makes me more
confident that this is a good direction to take. I've reimplemented
ReverseUnique using Relationship [0] and the tests pass, with the only code
carried over that for discovery of the FK link.

> I'm not totally sold on the API but having an analog of what
ForeignObject is to ForeignKey for ManyToManyField would definitely be
useful.

I'm not tied to the API, but I think passing a Q as a predicate makes sense
especially given that it's what both FilteredRelation and ReverseUnique do.
The core of the idea is that we can express a relationship as a combination
of predicate and arity. In practise I don't think this would be used all
that much by users directly - more by third-party apps like mptt, and
perhaps Django internally.

> From what I can see in relativity.fields[0] most of the additional logic
revolves around the extra filtering capabilites through Restriction.

Yeah that's what it boils down to. We return no columns to join against,
and return a compilable Restriction from get_extra_restriction to provide
all the ON conditions. The rest of it is making the descriptors, rels,
prefetch, etc work.

> Do you have an idea of what the fields.related inheritance chain would
look like if it was part of core?

The least intrusive, and probably a good starting point, would be to
introduce Relationship alongside the other relation fields as a standalone
feature, modifying the ORM to allow the implementation to be less hacky. It
would remain a subclass of ForeignObject (or perhaps RelatedField - I'll
give that a try).

In the future there's potential for a nice refactor of the ORM to
generalise join conditions from key-equality to arbitrary predicates of
which key equality is just one case, at which point Relationship could sit
comfortably as a base class of all the other relations. The assumption that
join==key-equality is pervasive and I think that's an unnecessarily large
chunk of work to take on at this point - it would be better to get the
feature in, then have a release cycle or so to think about the best way to
approach that problem and if we even want to.

I would be happy to write up a DEP expanding on an implementation plan and
potential future work.

Thanks,
Alex

[0]
https://github.com/AlexHill/django-reverse-unique/blob/624c8b19406a40b8e1a2c969c23a6b45bed5a896/reverse_unique/fields.py






On Fri, 31 Aug 2018 at 12:12 am, charettes  wrote:

> Hello Alex!
>
> Thanks for your work on this project, this is definitely something that I
> believe would be useful in Django's core based on the number of times I
> implemented a filtered queryset getter on Models.
>
> I'm not totally sold on the API but having an analog of what ForeignObject
> is to ForeignKey for ManyToManyField would definitely be useful.
>
> From what I can see in relativity.fields[0] most of the additional logic
> revolves around the extra filtering capabilites through Restriction.
>
> Do you have an idea of what the fields.related inheritance chain would
> look like if it was part of core? I feel like having
> Relation(RelatedField), ForeignObject(Relation), ManyToManyField(Relation)
> and adding the filtering logic to Relation could work but I'd be interested
> to hear what you think here. FWIW Anssi implemented something similar[1]
> for reverse unique relationship before FilteredRelation() was introduced.
>
> In a sense Relation would be form of virtual field like ForeignObject
> since it's not in charge of any database field handling.
>
> Simon
>
> [0]
> https://github.com/AlexHill/django-relativity/blob/3802608c64e86c62ab6268efc37a3f5ca8539221/relativity/fields.py
> [1] https://github.com/akaariai/django-reverse-unique
>
>
>
> Le jeudi 30 août 2018 11:38:16 UTC-4, Alex Hill a écrit :
>>
>> Hi all,
>>
>> I've run into many situations during my time using Django where I've
>> wanted to be able to express relations based on some other criteria than
>> foreign key equality. A few examples:
>> - descendants or children of a node in a tree structure
>> - saved search terms to search results
>> - a model containing a date range to timestamped items falling within
>> that date range
>>
>> Currently to do this kind of thing, you might write a getter which
>> returns a queryset - think for example mptt's get_descendants(). But you
>> don't get any of the nice things a real relation field gives you - you
>> can't use that relationship in filters, you can't select/prefetch_related()
>> or values(), there's no reverse relationship, etc.
>>
>> I've written a Relationship field[0] that lets you define relations in
>> terms of arbitrary Q filters containing objects of a new type, L. An L is
>> like an F, but represents a field on the "local" or "left" side of the
>> relation, where the Q is filtering against the remote "to" side of the
>> relation. For example, in a materialised path tree, this