Re: about ticket 28588- has_perm hide non-existent permissions

2017-10-02 Thread moshe nahmias 
Thanks for the corrections and input.

If I will keep the check and return False if the permission doesn't exist,
will it be OK?
If yes I think I have a good solution, I will return on the check if perm
in Permission.all()
So instead of:
return True
we will have:
return perm in Permission.objects.all()

What do you think?

If this seems reasonable I will make the PR in the next few days.

On Sat, Sep 30, 2017 at 1:45 PM, Florian Apolloner 
wrote:

> Hi,
>
> On Friday, September 29, 2017 at 7:00:41 PM UTC+2, moshe nahmias wrote:
>>
>> 3. Return False if the permission doesn't exist means that we go through
>> the same path as a regular user, since (at least on
>> auth.backends.ModelBackend) we check already if the user is superuser and
>> if so we return all the permissions (I suppose it's only permissions that
>> exist) it means we only need to remove the check at the start to see if the
>> user is superuser.
>>
>
> Removing this check would be highly backwards incompatible for 3rd party
> permission backends.
>
> ​I don't think the performance will be that much of a problem, but since
>> you think it might I think i will need to check it and report the results
>> back unless there is a preference for one of the other solutions. either
>> way it will be a good thing to check.​
>>
>
> There will probably not be a big performance drop for the builtin ones,
> but we do not know anything about 3rd party (ie ldap etc)
>
> --
> 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/e14b6ff5-598d-4605-9e76-
> 26df86971366%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/CACf8pw7joMt29d%2Br9y3E6Kxfj9Jvm3g5J%2B1gqw6vmDWz1H5h2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: about ticket 28588- has_perm hide non-existent permissions

2017-10-02 Thread Florian Apolloner 
Hi,

On Monday, October 2, 2017 at 2:24:31 PM UTC+2, moshe nahmias wrote:
>
> If yes I think I have a good solution, I will return on the check if perm 
> in Permission.all()
>

Where exactly do you propose to do that?  Here: 
https://github.com/django/django/blob/master/django/contrib/auth/models.py#L263 
? You are not allowed to access the model there since there is no gurantee 
that an auth backend uses a database backed storage…

Cheers,
Florian

-- 
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/c2d685bf-e4ce-4cec-a3f8-628ee729895c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding support for postgres 10

2017-10-02 Thread Tim Graham 
Do you want to implement something specific? Generally, whoever wants to 
implement something will offer a plan.

On Sunday, October 1, 2017 at 7:39:42 AM UTC-4, Amir Reza Ghods wrote:
>
> Postgres 10 is coming with some exciting features such as native 
> partitioning. Would it be a good idea to plan for supporting these new 
> features in Django?

-- 
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/d7510b49-3da8-41c8-9a7a-9d0f0b3013a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Refactoring the autoreloader

2017-10-02 Thread François Freitag 

Hi Tom,

Thank you for the great summary.

> 2. Add support for the "watchdog" library as a replacement for
> pyinotify. Watchdog implements file system notifications for all major
> platforms using a fairly simple API, so we can remove polling and have
> instant reloading. Also support Watchman, a notification Daemon from
> Facebook.

Filesystem polling is required for some setup, such as mounting code 
using NFS or rsync, for example using vagrant synced folders[1]. 
Although it does not prevent from using the watchdog library, which 
provides a PollingObserver[2], I think it's worth keeping that use case 
in mind. The PR has a StatReloader which seem able to handle filesystem 
polling, I would suggest either keeping it or delegating the polling to 
watchdog.


[1] https://www.vagrantup.com/docs/synced-folders/nfs.html
[2] 
https://pythonhosted.org/watchdog/api.html#module-watchdog.observers.polling


Cheers,
François

On 09/29/2017 12:03 PM, Tom Forbes wrote:

Hello,
I've been thinking on and off about how to improve the autoreloader 
implementation and I wanted to gather some feedback on potential solutions.


For some background, Django uses a fairly basic autoreload 
implementation that simply polls the last modified time for loaded 
Python files once a second. While this isn't the most efficient, it does 
work and has worked quite well for a long time. When running manage.py 
runserver, the autoreloader will launch a child "manage.py" with the 
same arguments and this child process actually runs Django and serves 
requests. To reload, the child process exits with exit code 3 and the 
parent restarts it. The code is some of the oldest in Django, with a 
fair bit of it not touched in 9-12 years.


While it works (and I'm a believer in "if it isn't broke don't fix it") 
there are some architectural and performance issues with the current code:


- Polling every second is not very efficient
- Detecting when the child process has exited during startup (i.e 
problem in settings.py) is problematic and the code is rather nasty
- i18n files are 'reloaded' when they change in a rather hacky way 
(resetting private attributes in another module)
- There is limited support for extending the current implementation, and 
there are cases during development where the parent autoreloader will 
terminate.


I don't want this email to be too long, so I'm going to summarize what I 
think would be a good approach to tackling these problems.


1. Refactor the current implementation by removing `pyinotify`, 
redundant python 2 checks and implement a 'file_changed' signal so other 
parts of Django can react to file changes (i.e the i18n module can 
handle resetting it's own state).
2. Add support for the "watchdog" library as a replacement for 
pyinotify. Watchdog implements file system notifications for all major 
platforms using a fairly simple API, so we can remove polling and have 
instant reloading. Also support Watchman, a notification Daemon from 
Facebook.
3. Add support for more advanced features, like proper handing of 
startup errors and socket sharing.


I've got a merge request that implements all three stages as a proof of 
concept, but I think it's far too much a change to be done at once and 
should be done carefully stage by stage. One and two are fairly simple 
to implement, but three requires see careful consideration as to the 
best approach (this message is long enough already, I don't want to 
describe them here).


Does anyone have any feedback on these ideas? Is it worth persuing even 
if the current implementation works ok-ish?


--
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/CAFNZOJMT9qDk-4pKKXSJysEQCmd6CGxMZBYZs_7BQs_WbAqL6g%40mail.gmail.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/d