Re: Proposal: Signal connection via "my_app.MyModel"

[Yo-Yo Ma]

Is there anyone else out there who doesn't like having to import models from 
app X into app Y just so that app Y can connect post save signals to them?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/_vcka4fdtPUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3: should we apply unicode_literals everywhere?

[Simon Meers]

It's a shame we couldn't skip straight to Python 3.3 and take
advantage of PEP414...

On 22 August 2012 07:32, Adrian Holovaty  wrote:
> On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin
>  wrote:
>> In my opinion, option (2) is a logical move at this point. However I
>> believe it deserves a public discussion (or at least an explanation).
>> What do you think?
>
> I prefer option 2 as well, because it seems like the Right Thing To
> Do. Of course, there's no rush to do everything -- we can just nibble
> off bits here and there.
>
> I'll have some free time soon and would be happy to help out migrating
> code. (Relatively) mindless refactoring like this is one of my
> favorite things to do. :-)
>
> Adrian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3: should we apply unicode_literals everywhere?

[Adrian Holovaty]

On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin
 wrote:
> In my opinion, option (2) is a logical move at this point. However I
> believe it deserves a public discussion (or at least an explanation).
> What do you think?

I prefer option 2 as well, because it seems like the Right Thing To
Do. Of course, there's no rush to do everything -- we can just nibble
off bits here and there.

I'll have some free time soon and would be happy to help out migrating
code. (Relatively) mindless refactoring like this is one of my
favorite things to do. :-)

Adrian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Can someone help me on how to handle this scenario ?

[Karen Tracey]

Please ask questions about using Django on django-users. The topic of this
list is the development of Django itself.

Thanks,
Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Can someone help me on how to handle this scenario ?

[Nirmal Sharma]

--This is the Model definition

FEEDBACK_CHOICES = (
(1, 'FOR'),
(-1, 'AGAINST'),
(0, 'NEUTRAL'),
)


class user (models.Model):
user_name  = models.CharField(max_length=150)


class comments (models.Model):
comment  = models.CharField(max_length=1000)   
root_comment =  models.ForeignKey('self', null=True, blank=True, 
related_name="children")
user_id = models.ForeignKey(user)


class comment_feedback (models.Model):
feedback_user_id = models.ForeignKey(user)
comment_id =   models.ForeignKey(comments)
feedback_type_id =  models.CharField(max_length=20, 
choices=FEEDBACK_CHOICES)
class Meta:
unique_together = [("feedback_user_id", "info_id")]



We are trying build a html page that will do the following.
Once a user logs in, he can write a new comment (that would result in an 
insert into comments table)
Alternatively he can do one of the following:
select a comment of some other user and give his feedback (that would 
result in an insert into comment_feedback table)
select a comment and write his own comment with a feedback on the 
original comment (that would result in an insert into comments table with 
root_comment as the original comment and an insert into comment_feedback 
table for the original comment)

We tried doing this inlineformset_factory and nested formsets. However we 
are quite confused on how to proceed with this. Also the comment_feedback 
table has 2 foreign keys.
How do we handle this at the form and template level? 

Regards
~Nirmal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WbkXtO4s99kJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3: should we apply unicode_literals everywhere?

[Anssi Kääriäinen]

On 21 elo, 13:46, Aymeric Augustin
 wrote:
> Hello,
>
> The first steps of porting Django to Python 3 was to switch on
> unicode_literals, as explained here [1]. This change was discussed in
> ticket #18269 [2] and committed in changeset 4a103086d5 [3].
>
> This changeset added `from __future__ import unicode_literals` only
> where necessary, ie. in modules that contained explicit unicode
> literals. This choice absolutely makes sense. Switching
> unicode_literals on everywhere in Django would have resulted in tons
> of b"" prefixes and/or in an incredible number of changes. Both
> options were unrealistic.
>
> However, it has an unfortunate side effect. In master, some modules
> have unicode_literals and others don't. I find myself constantly
> checking which mode is in effect.
>
> So we have two options at this point.
>
> (1) The status quo
>
>     Pros:
>         - less work in the short term
>         - avoiding the cons of solution (2)
>
>     Cons:
>         - check-top-of-file syndrom
>         - different behavior in Python 2 and Python 3 in some modules
>         - different behavior between some modules and others (eg.
> moving code isn't safe)
>         - cognitive overhead
>
> (2) Progressively turn unicode_literals on throughout the codebase. If
> we do it in small steps, it becomes easier to ensure that the change
> from str literals to unicode literals doesn't result in regressions on
> Python 2. That's how we handled the entire Python 3 port and it worked
> well — several regressions were quickly caught and fixed.
>
>     Pros:
>         - consistent codebase, easier to maintain in the long term
>         - avoiding the cons of solution (1)
>
>     Cons:
>         - "native strings" have to be expressed as str("...") in
> modules that need them
>         - more changes, higher risk of regressions on Python 2
>
> In my opinion, option (2) is a logical move at this point. However I
> believe it deserves a public discussion (or at least an explanation).
> What do you think?
>
> Best regards,

I did some benchmark runs some time ago, and it seems the
unicode_literals caused a small performance regression in many
queryset related benchmarks. The only one I have available is this:
http://users.tkk.fi/~akaariai/djbench/queryannotate.html

I remembered doing the benchmarks when reading this post, and thought
to mention this. The regression is small and I don't have any ideas
how to solve them. It might be it is just a testing artefact. So, this
is in no way a complaint against unicode_literals, just something I
though to share.

BTW if there happens to be some unused hardware available I could
automate such benchmarks as above. The hardware needs to be dedicated,
and a virtual machine will not do. Benchmarking on shared/virtual
machine will lead to inaccurate results. However the performance of
the HW isn't important at all, actually an older machine might be
better for this purpose...

For the actual question: I vote we move every non-empty file to
unicode_literals. If we use smaller steps we can bisect breakages
easier.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Python 3: should we apply unicode_literals everywhere?

[Aymeric Augustin]

Hello,

The first steps of porting Django to Python 3 was to switch on
unicode_literals, as explained here [1]. This change was discussed in
ticket #18269 [2] and committed in changeset 4a103086d5 [3].

This changeset added `from __future__ import unicode_literals` only
where necessary, ie. in modules that contained explicit unicode
literals. This choice absolutely makes sense. Switching
unicode_literals on everywhere in Django would have resulted in tons
of b"" prefixes and/or in an incredible number of changes. Both
options were unrealistic.

However, it has an unfortunate side effect. In master, some modules
have unicode_literals and others don't. I find myself constantly
checking which mode is in effect.

So we have two options at this point.

(1) The status quo

Pros:
- less work in the short term
- avoiding the cons of solution (2)

Cons:
- check-top-of-file syndrom
- different behavior in Python 2 and Python 3 in some modules
- different behavior between some modules and others (eg.
moving code isn't safe)
- cognitive overhead

(2) Progressively turn unicode_literals on throughout the codebase. If
we do it in small steps, it becomes easier to ensure that the change
from str literals to unicode literals doesn't result in regressions on
Python 2. That's how we handled the entire Python 3 port and it worked
well — several regressions were quickly caught and fixed.

Pros:
- consistent codebase, easier to maintain in the long term
- avoiding the cons of solution (1)

Cons:
- "native strings" have to be expressed as str("...") in
modules that need them
- more changes, higher risk of regressions on Python 2

In my opinion, option (2) is a logical move at this point. However I
believe it deserves a public discussion (or at least an explanation).
What do you think?

Best regards,

-- 
Aymeric.


[1] https://docs.djangoproject.com/en/dev/topics/python3/#unicode-literals
[2] https://code.djangoproject.com/ticket/18269
[3] 
https://github.com/django/django/commit/4a103086d5c67fa4fcc53c106c9fdf644c742dd8

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoC Check-in: Security Enhancements

[Andrew Godwin]

Thanks for your work during the GSOC, Rohan - don't worry about not
achieving everything, it looks like there's still some useful code there!

Hopefully we can get some of the code merged, especially centralised
tokenisation if it's so near completion, as it looks like a nice bit of
cleanup code!

Andrew

On Mon, Aug 20, 2012 at 2:49 PM, Rohan Jain  wrote:

> Hi,
>
> Today is the 'pencils down' date for this GSoC project. Past 4 months
> have been a great learning experience from me. Just being in the
> context of security side of the web has been really beneficial. Moving
> around in a very well written code base is also delightful.
> Meanwhile, I did get to work on multiple sections of the code base.
> But compared to the expectations at the initial phase of the program,
> I myself am a little disappointed about the output I was able to
> generate out of the time - specially regarding CSRF.
> This can be attributed to my being unable to give consistent attention
> to the project through the duration and to solicit feedback. Also, the
> project comprised of multiple discreet tasks, so not enough
> consideration was there for each task.
>
> This is a overview of various complete/incomplete topics I worked on.
>
> Centralized Tokenization:
> This was about integrating a central tokenization api throughout the
> django project. I tracked this at [centralized-tokenization][0] branch
> of my fork on github. This is near completion, and also has a
> documentation[1] of the API with basic usage examples.
>
> Improvements to sessions:
> My first task, related to some improvements to the sessions framework.
> Includes signing and session cleanup based on the engine. Tracked at
> [sessions-improvements][2] branch.
>
> CSRF Enhancements:
> It occupied most of my time through the project. I tried multiple ways
> to solve the issues under this. Tracked at [csrf-enhancements][3].
> First up, I started with using the origin header for doing a CSRF
> check. One implementation with some tests is at
> [csrf-origin-checking][4]. Recently I started on the idea of
> implementing moduler checkers for each kind of CSRF check, but
> haven't got anything useful out of it yet. While progressing, it
> seemed like I was virtually writing a middleware per checker, so now I
> have moved on to attempt on CSRF cookie store. Basically something
> which should seamlessly switch Session/Cookie for storage based on the
> availability of session.
>
> I'll try to hang around the django bug tracker and submit some
> patches.
>
> --
> Thanks
> Rohan Jain
>
> [0]: https://github.com/crodjer/django/tree/centralized-tokenization
> [1]:
> https://github.com/crodjer/django/blob/centralized-tokenization/docs/topics/tokenization.txt
> [2]: https://github.com/crodjer/django/tree/sessions-improvements
> [3]: https://github.com/crodjer/django/tree/csrf-enhancements
> [4]: https://github.com/crodjer/django/tree/csrf-origin-checking
> [5]: https://github.com/crodjer/django/tree/csrf-moduler-checkers
>
> On 01:57 +0530 /  7 Aug, Rohan Jain wrote:
> > Hi,
> >
> > Sorry for the delay in getting back. I was meanwhile working on
> > centralized tokenization for few days, while still trying to figure
> > something better for CSRF.
> >
> > On 03:52 -0400 / 25 Jul, Alex Ogier wrote:
> > > On Tue, Jul 24, 2012 at 11:37 PM, Rohan Jain 
> wrote:
> > > >
> > > > I had one more idea, "Pluggable CSRF checkers".
> > > >
> > > > Currently, the CSRF middleware has two kinds of checks, referer (for
> > > > https) and secret validation token (common). These with origin header
> > > > based checker (if we add it) come in conditional blocks, making
> > > > switching them difficult. So what I propose to do is decouple their
> > > > logic from CSRF middleware and each of them provide a checker. It
> goes
> > > > like this:
> > > >
> > > > A setting for configuring global CSRF checkers:
> > > >
> > > > CSRF_CHECKERS = {
> > > > 'django.middleware.csrf.checkers.OriginChecker',
> > > > # This one can be strict for https and lax for http
> > > > 'django.middleware.csrf.checkers.RefererChecker',
> > > > # contrib.sessions could provide a csrf checker maintained
> > > > # with sessions. This stores the token in session data.
> > > > 'django.contrib.sessions.csrf_checkers.SessionChecker'
> > > > }
> > > >
> > >
> > > I don't think this is a good idea. If you enumerate security features
> > > in settings.py, then later additions won't be picked up by default. If
> > > Django add a new CSRF checking mechanism, we want everybody to take
> > > advantage of it with no modifications.
> > >
> > > Ordinarily I agree with you, explicit is better than implicit.
> > > However, in the case of security features, I think this is inverted:
> > > Django sites should be implicitly enrolled in all security mechanisms
> > > if possible, and should be able to explicitly opt out if necessary.
> > > Almost 

Re: ModelForm.Meta.overrides

[Jannis Leidel]

Simon,

> A couple of months ago Jannis closed #/17924 [1] as wontfix, stating "I'm 
> violently -1 on the whole topic "meta programming form fields after they've 
> been instantiated", it's a mess. Yes it would be more DRY, but also much 
> harder to know how the hell the form fields are composed as. Just override 
> the form field, it's not a huge deal code wise and much easier to grok." This 
> has since been contested [2] (though for invalid reasons in my opinion).
> 
> I'm not sure that Jannis and I were talking about the same thing; the 
> solution I had in mind did not involve changing form-fields after their 
> instantiation, but rather providing a more elegant and flexible mechanism 
> that works in a similar way to ModelForm.Meta.widgets and formfield_callback.

Yup, we're talking about the same thing. No matter how you turn it, whether 
changing attributes of form fields after they've been instantiated *or* 
providing an "override" for arguments passed to the __init__ of those forms 
fields it's still unintuitive and not Pythonic.

We added the widgets option to the model form Meta class to allow overriding 
the widgets without having to specify the whole field again. It helped us solve 
a annoying bit of reusability of form fields without increasing the number of 
places users need to be aware of when they write model forms. That works well 
with widgets since they are clearly defined pieces of code with just one 
purpose.

Opening up the Meta class to be a place where you can define the arguments 
passed to the form fields' __init__ method would be a step in the wrong 
direction because it increases the number of places users need to look for 
initial arguments of form fields. It's a bad idea to allow users to shoot 
themselves in the foot like that. We want to promote standard Python behavior, 
not add more magic to save a couple lines of code.

Jannis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.