Re: Prospective GSOC applicant for 2015

[Tim Graham]

Hi Acho,

You'll need to research the various questions posed in the project 
description and come up with a proposal. It'll be easier to give you 
further guidance after that. You might want to take a look at the existing 
Trac tickets under the "Testing framework" component for related issues to 
consider.

Tim


On Sunday, March 8, 2015 at 8:41:57 AM UTC-4, Acho Arnold wrote:
>
>
> Good day,
>
> My name is Acho Arnold Ewin and I am a junior student studying Software 
> Engineering in the University of Buea in Cameroon (West Africa). I have 
> been  developing websites/webapps for 3+ years now. I'm very much 
> interested in how technology can be used to change human lives especially 
> in a less developed world where I live and where people still see 
> technology as *"white man's" magic.*
>
> I am interested in the Test framework cleanup (
> https://code.djangoproject.com/wiki/SummerOfCode2015#Testframeworkcleanup) 
> Project idea in the GSOC page for 2015.  I'm always looking for an 
> opportunity to improve my skills as a web developer and I believe this 
> project will help me to archive this goal.
>
> I will like to find out more information about the status of this project 
> so I can pitch in with my contributions. 
>
>
> Thanks and I hope to work with you guys soon.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/be7db588-788a-4556-b228-f9f6ab4ae00d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Gsoc 2015: SQLAlchemy / NoSQL integration

[Daniel Pyrathon]

Hi Abhishek,

I am the GSOC 2014 student who refactored the Meta API, please contact me
if you need any details on my work, or if you want to know more about
implementation and/or design of the new Meta API. You can also find me on
IRC as pirosb3.

Good luck!
Daniel

2015-03-02 1:32 GMT+01:00 Russell Keith-Magee :

>
> Hi Abhishek,
>
> On Sun, Mar 1, 2015 at 1:16 PM, Abhishek Kumar 
> wrote:
>
>> Hi,
>>
>> I am Abhishek and am interested in the project titled "SQLAlchemy / NoSQL
>> integration". I am good at data-structures and algorithms and have
>> worked with C,C++, PHP, Python,C#, Javascript and Mysql. I have an
>> internship experience at Microsoft, India.
>>
>> I have some questions which will help me in understanding the tasks
>> involved in this project better.
>>
>> 1)What was the formalised meta that came out of the 2014 soc project..?
>> Where to find the details of it..?
>>
>
> The new Meta interface is documented as part of Django 1.8:
>
> https://docs.djangoproject.com/en/1.8/ref/models/meta/
>
>
>> 2) I am new to Django. So i would be learning about it. Please let me
>> know what things i should focus more on w.r.t this project.
>>
>
> The most important part is probably Django's query language - you need to
> get comfortable with how you construct queries, and what those queries
> "mean" - both in the sense of the SQL they generate, and the underlying
> "idea" that the query is trying to capture.
>
> It would also be worth becoming familiar with Django's Admin interface -
> especially with regard to what queries it generates, and when.
>
>
>> 3) Before beginning to work for the project, what things i need to do to
>> make me eligible for it..? Bug fixes..?
>>
>
> The only hard requirement is to write a project proposal. However, if you
> get involved with the community, that may improve your chances, as we will
> get a chance to know you; if there are some details lacking in your
> proposal, we might be willing to overlook them if we have a better
> understanding of who you are, and how you interact with the community.
>
> Yours,
> Russ Magee %-)
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq848ra-rbFzLZgktfMaU%3D%3DuYQstDSu1NFjD-XwG374401%2BQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*

PirosB3

https://github.com/PirosB3

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOmo0o93%2B3KwAxBNW7zOnE0AeQ0t088Q%2BP_BUip84YD2ZLJf_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF cipher in xor + base64 or Vignere cipher

[Adam Brenecki]

To be fair to the Vigenère cipher algorithm, it is insanely simple; I think
when I wrote the implementation in that pull request, I was probably
inappropriately using lambdas and generator expressions, and in doing so
making it look more complicated than it really is.

A neater, more readable Vigenère cipher (that is still logically equivalent
to the first one) might look like this:
https://gist.github.com/adambrenecki/3b4d75ba039e6e455f7c .

On 7 March 2015 at 23:31, Erik Romijn  wrote:

> Hello,
>
> In the context of a one time pad on the CSRF token, I don’t see a security
> advantage to either cipher here. If I read correctly, the argument for
> Vignere is that it can already produce output suitable for inclusion in
> form values, not requiring base64 encoding of the one time pad.
>
> I’ve looked up the current implementations that have been contributed:
> Here’s the XOR+base64 implementation:
>
> https://github.com/django/django/compare/66285eb2a7a6fb3e6ec0eec0bbc15a5e94215872#diff-a3be722ce2831a8d11438021d44cedf1R62
> And the Vignere implementation:
>
> https://github.com/django/django/pull/1477/files#diff-a3be722ce2831a8d11438021d44cedf1R40
>
> Though the Vignere implementation means that base64 is not required and is
> significantly shorter, it seems considerably more complex and error prone.
> I can’t instantly see whether this implementation is correct. The
> XOR+base64 implementation, on the other hand, is straight forward and
> obvious. Therefore, if the current implementations are a proper measure for
> the complexity of implementing either option, XOR+base64 is my strong
> preference. Slightly more work, but substantially simpler, reducing the
> risk of overlooked implementation errors.
>
> Erik
>
> On 07 Mar 2015, at 13:31, Asif Saifuddin  wrote:
>
> Hi,
>
> Just start working on this ticket
> https://code.djangoproject.com/ticket/20869
>
> wondering what should be the preferred way ?
>
> using XOR or Vignere Cipher?
>
>
> Reagrds
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3d23b87e-c153-4035-a838-331d5bc9cd1d%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/10CE5813-C1DA-4231-8721-36A2AEEB8748%40solidlinks.nl
> 
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPkdtoz3%2B7bz6D7PKJu2V_KEOQjR6kuwamPzRmKcvS5oDqiyfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Erik Romijn]

Hello Simon and Raphael,

Thanks for your input. I’ve adopted all your suggestions into the PR.

For the settings, I’ve now mirrored the TEMPLATE structure. I entirely agree 
that adding a new structure is an unnecessary burden on our users. I’m not too 
fond of Simon’s suggestion, as I’d like to have some basic configurability for 
each validator, without having to create an instance and store it somewhere 
yourself. That is still an option for advances customisation.

Erik

> On 08 Mar 2015, at 18:04, charettes  wrote:
> 
> Hi Erik,
> 
> This looks promising. I like how the validators can be chained and the whole 
> simplicity of the patch.
> 
> Here's some comments I also left on the PR;
> I think the settings should be name AUTH_PASSWORD_VALIDATORS since it's being 
> use by the auth contrib app;
> I would avoid mixing the backend and validators terminology. e.g 
> `get_password_validators` sounds like a more consistent name then 
> `get_password_backends`;
> I would either make `help_text` a property of rename the method to 
> `get_help_text`.
> Like Raphael I also think we should avoid introducing a new way of defining 
> settings. I suggest we use a list of path to instances of password validators 
> instead:
> 
> 
> AUTH_PASSWORD_VALIDATORS = [
> 'django.contrib.auth.password_validators.min_eight_chars_validator',
> ]
> 
> And document MinimumLengthPasswordValidator so you can create your own 
> instances and point the setting to it.
> 
> Simon
> 
> Le dimanche 8 mars 2015 10:48:00 UTC-4, Erik Romijn a écrit :
> Hello all,
> 
> I've taken another stab at 16860[1]: having a password validation/policy in 
> Django. I've made an initial simple PR[2] to show the approach I'd like to 
> use - no tests or documentation yet, the example validators are not very 
> nice, possibly bad naming, etc. But this should be sufficient to show how I 
> would like to tackle this. There's quite a few decisions to take, influencing 
> the later possibilities, which I'll try to outline below.
> 
> Users choosing awful passwords is a serious security issue. Although password 
> validation can only go so far - especially to the extent that we can 
> implement in Django itself - to me it seems part of our responsibility in 
> helping Django developers to build safer websites.
> 
> First, let me briefly describe my approach: we add a new setting to define 
> zero or more password validator classes. Optionally, a class can be provided 
> with custom arguments to it's constructor. Each validator class has a 
> help_text() method and a validate(password, user) method. The former produces 
> a translatable sentence to be included in the form field's help text. The 
> validate method validates a certain password, optionally taking the context 
> of a user into account and passes its judgement on the password. If a 
> validator considers a password insufficient, it raises a ValidationError.
> 
> This is tied to the validation and form field setup in SetPasswordForm and 
> AdminPasswordChangeForm. An obvious choice seems to be to tie this to 
> User.set_password(). However, I intentionally did not include that step, as I 
> feel this validation should primarily take place on the user frontend site 
> with forms. This mirrors the way we typically handle this in Django. Should 
> someone feel different, and want to tie this to set_password() as well, this 
> is possible with a custom user object. Tying this validation into any other 
> place is also trivial: just adding a single line.
> 
> I decided not to go for standard Django validators, as I felt this would 
> offer insufficient flexibility and configurability - as was already raised in 
> previous discussions on this issue.
> 
> In the ticket, Shai described a few particular goals for this feature:
> 
> - Informing the user of the various password requirements: this is possible 
> by each validator providing a description, which can be dependent on it's 
> configuration, of it's requirements. Independent sentences from different 
> validators are now concatenated, an approach which will not always yield the 
> prettiest language.
> - Allowing policies to chain together smoothly: multiple validators can be 
> run sequentially, stopping after the first failure.
> - Provide flexibility for complex requirements (some may include their own 
> models): this is entirely possible within the design.
> - Backwards compatibility: the default setting is to have no validators, 
> which means no change and no modifications in help text. I do suggest we 
> include some reasonable defaults in the standard project template.
> - Javascript validation assistance or HTML5 support: not implemented 
> currently, but this could be added in a similar way as help texts.
> - Prevent using email, username or other user attributes as (part of) 
> passwords: where possible, the user object is passed to the validator. 
> There's a (not pretty) example of this in the PR.
> - Prevent 

Re: Password validation in Django revisited

[charettes]

Hi Erik,

This looks promising. I like how the validators can be chained and the 
whole simplicity of the patch.

Here's some comments I also left on the PR;

   1. I think the settings should be name AUTH_PASSWORD_VALIDATORS since 
   it's being use by the auth contrib app;
   2. I would avoid mixing the backend and validators terminology. e.g 
   `get_password_validators` sounds like a more consistent name then 
   `get_password_backends`;
   3. I would either make `help_text` a property of rename the method to 
   `get_help_text`.

Like Raphael I also think we should avoid introducing a new way of defining 
settings. I suggest we use a list of path to instances of password 
validators instead:

AUTH_PASSWORD_VALIDATORS = [
'django.contrib.auth.password_validators.min_eight_chars_validator',
]

And document MinimumLengthPasswordValidator so you can create your own 
instances and point the setting to it.

Simon
Le dimanche 8 mars 2015 10:48:00 UTC-4, Erik Romijn a écrit :
>
> Hello all, 
>
> I've taken another stab at 16860[1]: having a password validation/policy 
> in Django. I've made an initial simple PR[2] to show the approach I'd like 
> to use - no tests or documentation yet, the example validators are not very 
> nice, possibly bad naming, etc. But this should be sufficient to show how I 
> would like to tackle this. There's quite a few decisions to take, 
> influencing the later possibilities, which I'll try to outline below. 
>
> Users choosing awful passwords is a serious security issue. Although 
> password validation can only go so far - especially to the extent that we 
> can implement in Django itself - to me it seems part of our responsibility 
> in helping Django developers to build safer websites. 
>
> First, let me briefly describe my approach: we add a new setting to define 
> zero or more password validator classes. Optionally, a class can be 
> provided with custom arguments to it's constructor. Each validator class 
> has a help_text() method and a validate(password, user) method. The former 
> produces a translatable sentence to be included in the form field's help 
> text. The validate method validates a certain password, optionally taking 
> the context of a user into account and passes its judgement on the 
> password. If a validator considers a password insufficient, it raises a 
> ValidationError. 
>
> This is tied to the validation and form field setup in SetPasswordForm and 
> AdminPasswordChangeForm. An obvious choice seems to be to tie this to 
> User.set_password(). However, I intentionally did not include that step, as 
> I feel this validation should primarily take place on the user frontend 
> site with forms. This mirrors the way we typically handle this in Django. 
> Should someone feel different, and want to tie this to set_password() as 
> well, this is possible with a custom user object. Tying this validation 
> into any other place is also trivial: just adding a single line. 
>
> I decided not to go for standard Django validators, as I felt this would 
> offer insufficient flexibility and configurability - as was already raised 
> in previous discussions on this issue. 
>
> In the ticket, Shai described a few particular goals for this feature: 
>
> - Informing the user of the various password requirements: this is 
> possible by each validator providing a description, which can be dependent 
> on it's configuration, of it's requirements. Independent sentences from 
> different validators are now concatenated, an approach which will not 
> always yield the prettiest language. 
> - Allowing policies to chain together smoothly: multiple validators can be 
> run sequentially, stopping after the first failure. 
> - Provide flexibility for complex requirements (some may include their own 
> models): this is entirely possible within the design. 
> - Backwards compatibility: the default setting is to have no validators, 
> which means no change and no modifications in help text. I do suggest we 
> include some reasonable defaults in the standard project template. 
> - Javascript validation assistance or HTML5 support: not implemented 
> currently, but this could be added in a similar way as help texts. 
> - Prevent using email, username or other user attributes as (part of) 
> passwords: where possible, the user object is passed to the validator. 
> There's a (not pretty) example of this in the PR. 
> - Prevent reuse of old passwords: it is possible in the design for a 
> validator to store all passwords it saw. I have doubts on whether this 
> would be a good approach though. 
>
> So I think this design makes it simple to have sane defaults for new 
> projects, extensive configurability while keeping simple scenarios simple 
> to configure, and easy extensibility with third party password validators 
> (zxcvbn comes to mind). I'd love to hear any feedback and ideas you may 
> have. 
>
> Erik 
>
>
> [1] https://code.djangoproject.com/ticket/16860 
> [2] 

Re: Composite fields

[Michael Manfre]

On Sun, Mar 8, 2015 at 12:12 PM, Thomas Stephenson 
wrote:

> @Aymeric
>
> Here's why I think the `isnull` column is necessary.
>
> Say you've got a custom field implementation:
>
> class Point(models.CompositeField):
>  x = models.IntegerField()
>  y = models.IntegerField()
>  # etc.
>
> and you use this to define a coordinate system to locate objects in your
> models. You justify that whenever you provide a point, you'll want both an
> x and y coordinate, so you make both of the subfields non-null.
>
> But then you come across a model which may or may not have a location.
> You'd like to say
>
> class MaybeLocatable(models.Model):
>point = Point(null=True)
>
> but you can't, because both of your subfields are non-nullable, so you
> define a nonsensical condition to apply to your Point
> "If I don't have an x-coordinate, then the point value should be
> considered null"
> so you update the Point field appropriately (and apply all the necessary
> migrations).
>

If a point can be nullable, then the subfields should be nullable.
Enforcing that both x and y have a value should be handled with a
constraint and/or validators. I really don't like "_isnull" subfield. It
doesn't result in good table design and adds restrictions/complication to
the ORM/migrations.


> You then want to query for all `MaybeLocatable` objects that are
> considered null. You can query for point__isnull=True (which is supposed to
> be supported). How does one define the lookup transformation for that?
>
> If there was an implicit 'isnull' column added, then the lookup
> transformation for both `point__isnull=True` and `point=None` become a
> lookup for the database column `point__isnull = True`. If you don't add
> that extra column, how does the framework what transform to make? It could
> query for both `point__x__isnull` and `point__y__isnull`, but that wouldn't
> match the semantics for the column.
>

The ORM would do the translation based upon the Composite field being
nullable. E.g. "point__isnull=True" and "point=None" would result in
"[point].[x] IS NULL AND [point].[y] IS NULL"


> And you also can't say "well, look at the field definition and if a column
> is nullable, then use it as a marker, because what if you instead had:
>
> class Point(models.CompositeField):
>x = models.IntegerField(null=True)
>y = models.IntegerField()
>z = models.IntegerField(null=True)
>
> as your original class? `x` could still be used as the "marker" column,
> but any transformation you'd make with the above rule. So the framework
> can't actually define a workable `isnull` query (or an 'exact' query when
> the python value is `None`). The whole issue of the "marker" column is
> fraught anyway, because it breaks all the NOT NULL constraints on other
> columns anyway.
>
>
If the composite field is nullable, then all subfields should be nullable.
We can add checks to identify any invalid configurations.


> So instead of all that, the user decides that they're going to solve the
> problem with
>
> class MaybeLocation(models.Model):
>has_point = models.BooleanField()
>point = models.Point(default=Point(0,0))
>
> which is exactly the same solution as including the implicit `isnull`
> field when the field is created with `null=True`, except the user has to do
> it explicitly, and implement the logic surrounding the definition
> themselves.
>

The more I think about it, my opinion is shifting solidly toward -1 on
implicit database fields in general. I can't think of any situations when
the benefit outweighs the extra complexity and standard support issues when
things are implicit. There are a lot of negatives to saving 1 line of code
in a model (or composite field) definition).

Your MaybeLocation example also imposes an extra database column on the
user for each nullable composite field they define, even if it may be
redundant for their data. For the below example, Publication would have
three implicit "isnull" fields added, even if "status" defines the business
rules about when deliverable, report, and poster fields are required.

class Publication(models.Modle):
status = model.CharField(max_length=20)
deliverable = MyDeliverableCompositeField(null=True)
report = MyReportCompositeField(null=True)
poster = MyPosterCompositeField(null=True)



> They also can't define a new CompositeField like
>
> class MaybePoint(...):
>has_point = models.BooleanField()
>point = Point()
>
> because of the inheritance limitations (which I might have to lift in the
> medium-long term anyway, but which I'd like to preserve for as long as
> possible to keep the initial implementation and API simple).
>
> The point is (no pun intended) that I can't really think of a good way to
> map a python None to the values of a composite field _without_ the extra
> implicit column. It's not the nicest solution in the world, but it works.
>

I'd argue that not being able to have a hierarchy of Composite 

Re: Composite fields

[Thomas Stephenson]

ps. There's a third option which I just thought of:

class Point(...):
   x = models.IntegerField()
   y = models.IntegerField()
   z = models.IntegerField(null=True)

   def __init__(self, null=False, **kwargs):
   if null:
 x.null = y.null = True
  super(Point, self).__init__(**kwargs)

   def deconstruct(self):
  # etc.

The framework could handle this and mandate "If a composite field has
`null=True`, then all subfields are forced into the state `null=True`
etc.", applying the `__init__` and `deconstruct` stuff itself.

Yep -- I like this solution better.

Thomas


On 9 March 2015 at 03:12, Thomas Stephenson  wrote:

> @Aymeric
>
> Here's why I think the `isnull` column is necessary.
>
> Say you've got a custom field implementation:
>
> class Point(models.CompositeField):
>  x = models.IntegerField()
>  y = models.IntegerField()
>  # etc.
>
> and you use this to define a coordinate system to locate objects in your
> models. You justify that whenever you provide a point, you'll want both an
> x and y coordinate, so you make both of the subfields non-null.
>
> But then you come across a model which may or may not have a location.
> You'd like to say
>
> class MaybeLocatable(models.Model):
>point = Point(null=True)
>
> but you can't, because both of your subfields are non-nullable, so you
> define a nonsensical condition to apply to your Point
> "If I don't have an x-coordinate, then the point value should be
> considered null"
> so you update the Point field appropriately (and apply all the necessary
> migrations).
>
> You then want to query for all `MaybeLocatable` objects that are
> considered null. You can query for point__isnull=True (which is supposed to
> be supported). How does one define the lookup transformation for that?
>
> If there was an implicit 'isnull' column added, then the lookup
> transformation for both `point__isnull=True` and `point=None` become a
> lookup for the database column `point__isnull = True`. If you don't add
> that extra column, how does the framework what transform to make? It could
> query for both `point__x__isnull` and `point__y__isnull`, but that wouldn't
> match the semantics for the column.
>
> And you also can't say "well, look at the field definition and if a column
> is nullable, then use it as a marker, because what if you instead had:
>
> class Point(models.CompositeField):
>x = models.IntegerField(null=True)
>y = models.IntegerField()
>z = models.IntegerField(null=True)
>
> as your original class? `x` could still be used as the "marker" column,
> but any transformation you'd make with the above rule. So the framework
> can't actually define a workable `isnull` query (or an 'exact' query when
> the python value is `None`). The whole issue of the "marker" column is
> fraught anyway, because it breaks all the NOT NULL constraints on other
> columns anyway.
>
>
>
> So instead of all that, the user decides that they're going to solve the
> problem with
>
> class MaybeLocation(models.Model):
>has_point = models.BooleanField()
>point = models.Point(default=Point(0,0))
>
> which is exactly the same solution as including the implicit `isnull`
> field when the field is created with `null=True`, except the user has to do
> it explicitly, and implement the logic surrounding the definition
> themselves.
>
> They also can't define a new CompositeField like
>
> class MaybePoint(...):
>has_point = models.BooleanField()
>point = Point()
>
> because of the inheritance limitations (which I might have to lift in the
> medium-long term anyway, but which I'd like to preserve for as long as
> possible to keep the initial implementation and API simple).
>
> The point is (no pun intended) that I can't really think of a good way to
> map a python None to the values of a composite field _without_ the extra
> implicit column. It's not the nicest solution in the world, but it works.
>
> Thomas
>
> On 8 March 2015 at 16:29, Aron Podrigal  wrote:
>
>> Hi Thomas, I replied earlier before you posted, looks like my message got
>> sent actually a lot later.
>>
>> having a function like  *models.constrain(x, y, unique=True) *makes
>> sense for inline declarations.
>>
>> About null handling, If all columns on the database are null=True and all
>> columns have a null value, then the composite field value would be  `None'.
>> Otherwise it would be a dict mapping to the subfields, and a query needs to
>> specify the subfields it queries against.
>>
>>
>> Aron.
>>
>> On Saturday, March 7, 2015 at 11:16:12 PM UTC-5, Thomas Stephenson wrote:
>>>
>>> Aymeric,
>>>
>>> Thanks for your input. I feel some of your concerns have been addressed
>>> in the DEPs I made, which have included quite a bit of input from this
>>> thread along with the original design. That said, some of the points you've
>>> raised are new and haven't been raised by other people, so I'll give you a
>>> full reply.
>>>
>>> 1) 

Re: Password validation in Django revisited

[Raphael Michel]

Hi Erik,

Am Sun, 8 Mar 2015 15:47:27 +0100
schrieb Erik Romijn :
> I've taken another stab at 16860[1]: having a password
> validation/policy in Django. I've made an initial simple PR[2] to
> show the approach I'd like to use - no tests or documentation yet,
> the example validators are not very nice, possibly bad naming, etc.
> But this should be sufficient to show how I would like to tackle
> this. There's quite a few decisions to take, influencing the later
> possibilities, which I'll try to outline below.

I really like this a lot, both the idea of the ticket and the way
you're proposing to implement it.

However, I'm not quite sure whether I like the style you chose to pass
constructor arguments in the PASSWORD_VALIDATORS setting you proposed. I
believe it might be worth considering to design the PASSWORD_VALIDATORS
setting in a similar fashion to the new TEMPLATES setting.

I understand why you chose this style and it might really be the best
way to do this one thing, but I fear it adds complexity because it
behaves differently than all other settings variables and thus makes it
harder to remember how Django's settings work.

Raphael

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150308172841.3775a4df%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpI3LsGgFZcH.pgp
Description: Digitale Signatur von OpenPGP

Re: Composite fields

[Thomas Stephenson]

@Aymeric

Here's why I think the `isnull` column is necessary.

Say you've got a custom field implementation:

class Point(models.CompositeField):
 x = models.IntegerField()
 y = models.IntegerField()
 # etc.

and you use this to define a coordinate system to locate objects in your
models. You justify that whenever you provide a point, you'll want both an
x and y coordinate, so you make both of the subfields non-null.

But then you come across a model which may or may not have a location.
You'd like to say

class MaybeLocatable(models.Model):
   point = Point(null=True)

but you can't, because both of your subfields are non-nullable, so you
define a nonsensical condition to apply to your Point
"If I don't have an x-coordinate, then the point value should be considered
null"
so you update the Point field appropriately (and apply all the necessary
migrations).

You then want to query for all `MaybeLocatable` objects that are considered
null. You can query for point__isnull=True (which is supposed to be
supported). How does one define the lookup transformation for that?

If there was an implicit 'isnull' column added, then the lookup
transformation for both `point__isnull=True` and `point=None` become a
lookup for the database column `point__isnull = True`. If you don't add
that extra column, how does the framework what transform to make? It could
query for both `point__x__isnull` and `point__y__isnull`, but that wouldn't
match the semantics for the column.

And you also can't say "well, look at the field definition and if a column
is nullable, then use it as a marker, because what if you instead had:

class Point(models.CompositeField):
   x = models.IntegerField(null=True)
   y = models.IntegerField()
   z = models.IntegerField(null=True)

as your original class? `x` could still be used as the "marker" column, but
any transformation you'd make with the above rule. So the framework can't
actually define a workable `isnull` query (or an 'exact' query when the
python value is `None`). The whole issue of the "marker" column is fraught
anyway, because it breaks all the NOT NULL constraints on other columns
anyway.



So instead of all that, the user decides that they're going to solve the
problem with

class MaybeLocation(models.Model):
   has_point = models.BooleanField()
   point = models.Point(default=Point(0,0))

which is exactly the same solution as including the implicit `isnull` field
when the field is created with `null=True`, except the user has to do it
explicitly, and implement the logic surrounding the definition themselves.

They also can't define a new CompositeField like

class MaybePoint(...):
   has_point = models.BooleanField()
   point = Point()

because of the inheritance limitations (which I might have to lift in the
medium-long term anyway, but which I'd like to preserve for as long as
possible to keep the initial implementation and API simple).

The point is (no pun intended) that I can't really think of a good way to
map a python None to the values of a composite field _without_ the extra
implicit column. It's not the nicest solution in the world, but it works.

Thomas

On 8 March 2015 at 16:29, Aron Podrigal  wrote:

> Hi Thomas, I replied earlier before you posted, looks like my message got
> sent actually a lot later.
>
> having a function like  *models.constrain(x, y, unique=True) *makes sense
> for inline declarations.
>
> About null handling, If all columns on the database are null=True and all
> columns have a null value, then the composite field value would be  `None'.
> Otherwise it would be a dict mapping to the subfields, and a query needs to
> specify the subfields it queries against.
>
>
> Aron.
>
> On Saturday, March 7, 2015 at 11:16:12 PM UTC-5, Thomas Stephenson wrote:
>>
>> Aymeric,
>>
>> Thanks for your input. I feel some of your concerns have been addressed
>> in the DEPs I made, which have included quite a bit of input from this
>> thread along with the original design. That said, some of the points you've
>> raised are new and haven't been raised by other people, so I'll give you a
>> full reply.
>>
>> 1) That's still something I have to do, but more time consuming than
>> other parts of creating the proposal and I've put it off until I have a
>> while to do it. The original implementation was done without too much
>> consideration of prior attempts, because I was more interested in getting
>> something working than I was in learning from the past.
>>
>> 2) I agree. The new syntax I've proposed is to add one or more
>> class-level methods to the django.db.models API. The new syntax for
>> "inline" fields is:
>>
>> class MyModel(models.Model):
>> x = models.IntegerField()
>> y = models.IntegerField()
>> point = models.constrain(x, y, unique=True)
>>
> good
>
>>
>> The reason for not using the CompositeField constructor is that a lot of
>> the options which make sense for standalone field constructors (and all the
>> 

Password validation in Django revisited

[Erik Romijn]

Hello all,

I've taken another stab at 16860[1]: having a password validation/policy in 
Django. I've made an initial simple PR[2] to show the approach I'd like to use 
- no tests or documentation yet, the example validators are not very nice, 
possibly bad naming, etc. But this should be sufficient to show how I would 
like to tackle this. There's quite a few decisions to take, influencing the 
later possibilities, which I'll try to outline below.

Users choosing awful passwords is a serious security issue. Although password 
validation can only go so far - especially to the extent that we can implement 
in Django itself - to me it seems part of our responsibility in helping Django 
developers to build safer websites.

First, let me briefly describe my approach: we add a new setting to define zero 
or more password validator classes. Optionally, a class can be provided with 
custom arguments to it's constructor. Each validator class has a help_text() 
method and a validate(password, user) method. The former produces a 
translatable sentence to be included in the form field's help text. The 
validate method validates a certain password, optionally taking the context of 
a user into account and passes its judgement on the password. If a validator 
considers a password insufficient, it raises a ValidationError.

This is tied to the validation and form field setup in SetPasswordForm and 
AdminPasswordChangeForm. An obvious choice seems to be to tie this to 
User.set_password(). However, I intentionally did not include that step, as I 
feel this validation should primarily take place on the user frontend site with 
forms. This mirrors the way we typically handle this in Django. Should someone 
feel different, and want to tie this to set_password() as well, this is 
possible with a custom user object. Tying this validation into any other place 
is also trivial: just adding a single line.

I decided not to go for standard Django validators, as I felt this would offer 
insufficient flexibility and configurability - as was already raised in 
previous discussions on this issue.

In the ticket, Shai described a few particular goals for this feature:

- Informing the user of the various password requirements: this is possible by 
each validator providing a description, which can be dependent on it's 
configuration, of it's requirements. Independent sentences from different 
validators are now concatenated, an approach which will not always yield the 
prettiest language.
- Allowing policies to chain together smoothly: multiple validators can be run 
sequentially, stopping after the first failure.
- Provide flexibility for complex requirements (some may include their own 
models): this is entirely possible within the design.
- Backwards compatibility: the default setting is to have no validators, which 
means no change and no modifications in help text. I do suggest we include some 
reasonable defaults in the standard project template.
- Javascript validation assistance or HTML5 support: not implemented currently, 
but this could be added in a similar way as help texts.
- Prevent using email, username or other user attributes as (part of) 
passwords: where possible, the user object is passed to the validator. There's 
a (not pretty) example of this in the PR.
- Prevent reuse of old passwords: it is possible in the design for a validator 
to store all passwords it saw. I have doubts on whether this would be a good 
approach though.

So I think this design makes it simple to have sane defaults for new projects, 
extensive configurability while keeping simple scenarios simple to configure, 
and easy extensibility with third party password validators (zxcvbn comes to 
mind). I'd love to hear any feedback and ideas you may have.

Erik


[1] https://code.djangoproject.com/ticket/16860
[2] https://github.com/django/django/pull/4276

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/DC7E0945-5FC9-43CA-97C5-FE5872A05DE1%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Prefix use in reversing urls

[Bas Peschier]

Hi all,

currently the reversing mechanism for urls accepts a prefix-kwarg [1], 
which is not documented [2].

It seems like this prefix is used to prefix the entire generated url and 
make script_name possible, to which it defaults. It is not used in the 
entire code base except for tests which can directly test prefixes without 
going through set_script_name. So in basis: prefix is whatever 
get_script_name gives you.

What is curious about how Django handles it, is that it treats the prefix 
as possibly containing regular expressions [3]. Is there any history or 
documentation that this can be anything other than a valid path?

Removing that mechanism (it simplifies escaping the prefix, which was the 
original problem in #24013 [4] and a whole chain of previous tickets) 
unearths tests that don't actually test the correct thing, but overall it 
runs fine™. Since escaping the reversed url is sensitive security-wise, I 
would like a couple of eyes on it.

PR is here: https://github.com/django/django/pull/4272

Bas

[1]: 
https://docs.djangoproject.com/en/1.8/_modules/django/core/urlresolvers/#reverse
[2]: 
https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#django.core.urlresolvers.reverse
[3]: 
https://github.com/django/django/blob/master/django/core/urlresolvers.py#L448
[4]: https://code.djangoproject.com/ticket/24013

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e77e916-62f6-4a3a-bfab-a289902236fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to run django in window 8

[严超]

I think you should ask https://groups.google.com/forum/#!forum/django-users
Here is a django-developers  mailing list.

*Best Regards！*


*Chao Yan--About me ： http://about.me/chao_yan
*

*My twitter： @yanchao727 *
*My Weibo： http://weibo.com/herewearenow *
*--*

2015-03-08 10:06 GMT+08:00 Alok Rodhiya :

> i spend the overnight in installing django but i am unable to get it
> plz someone post the .exe of django so i can install it nd get my work
> started
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/eadcf6aa-80bc-4d75-9f90-a227f11d9262%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALAMvO-G%3D%3Dyc1-D6XZSf-1RqiPQDirnONcACymaDr%2B1PQp7OnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Prospective GSOC applicant for 2015

[Acho Arnold]

Good day,

My name is Acho Arnold Ewin and I am a junior student studying Software 
Engineering in the University of Buea in Cameroon (West Africa). I have 
been  developing websites/webapps for 3+ years now. I'm very much 
interested in how technology can be used to change human lives especially 
in a less developed world where I live and where people still see 
technology as *"white man's" magic.*

I am interested in the Test framework cleanup (
https://code.djangoproject.com/wiki/SummerOfCode2015#Testframeworkcleanup) 
Project idea in the GSOC page for 2015.  I'm always looking for an 
opportunity to improve my skills as a web developer and I believe this 
project will help me to archive this goal.

I will like to find out more information about the status of this project 
so I can pitch in with my contributions. 


Thanks and I hope to work with you guys soon.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/63735618-4c4b-4a2b-ad30-67386a75b539%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

how to run django in window 8

[sarad mohanan]

What is the problem you are facing while installing django on windows. As far 
as remember its just a piece of cake.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d13e976a-4dcd-4075-be11-72aa5d688cdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.