Hi Christopher, I'd like to echo Jacobs comments here. This is a strong proposal, and I can see this being one that we'd support.
Jacob's feedback is also spot on; he's pretty much flagged the exact concerns that I had when I read it. I'd possibly add one additional point - the potential for confusion between validation of the type you're describing, and "model validation". This isn't a problem of your making - the ambiguity already exists in Django. However, if we're adding API points on fields, which already support the idea of "validators", we need to be careful we don't confuse issues more. To that end, I'd be interested in seeing at least some initial thoughts on how we can structure the API or change the naming so that this issue is controlled. On a practicality issue, I'd also like to see one more piece of detail in your "why me" section. Since your from Poland, English is (I'm guessing) a second language. Your proposal is very clear and shows you have good communications skills. However, what we don't know is how long it took you to write this proposal, and how comfortable you are working in English. If you're not comfortable working in English in "real time" (e.g., on a spoken phone call, or in IRC), then that will alter the way that you and your mentor will interact - you may wish to only communicate via email, for example; and this may slow down the rate of feedback that you can get from your mentor. I'd like to emphasise that I am *not* saying that we intend to give preferential treatment to native English speakers. This is an issue of finding me best possible mentor to match you with, and set expectations for how quickly you will be able to make progress on your project. Yours, Russ Magee %-) On Wednesday, April 17, 2013, Jacob Kaplan-Moss wrote: > Hi Christopher - > > Thanks for the proposal, this is quite good. I really appreciate the > detail; it's clear you've put a lot of thought into this. In general, > I think this is a strong proposal and one I'd support. However, I do > have some comments/feedback: > > 1. We've had some discussions about bringing django-secure into core > as part of a more general "checkdeploy" command. The idea being > something you can run shortly before deployment that'd check for all > the stuff that django-secure checks for -- but also more (outdated > dependencies, debug mode, exposed admin, etc). I think this dovetails > nicely with your proposal: it seems that all these "checks" > (validation, deployment, security) could use a single discovery and > running mechanism. I'd love to see you think about modifying your > proposal to include this sort of unification as well as the bringing > of django-secure into core. > > 2. I think your proposal is a bit too big. I'd general prefer to see a > less ambitious proposal with a high probability of success over a high > risk/high reward. I'd like to see you drop the "django-updates" part > of the proposal, and focus on validation and django-secure. If you end > up with extra time, you can always use it to write more checks. > > 3. You've done a good job breaking up the first half of the project > into one week chucks, which shows me you've thought carefully about > the tasks and steps involved. However, when you get to the second > half, you're a lot more vague. I'd like to see you think more > carefully about your time during that second half. > > 4. Pet peeve alert: "documentation" shouldn't be an afterthought. I > HATE seeing "week X: documentation" -- it implies that you're planning > on *not* writing documentation as you go, but instead saving it for > last. You've been around long enough to know that's not how we do > things; documentation happens alongside code. You'd make me much > happier if you updated your proposal to not imply that you'd leave > documentation for later. > > Again, I want to stress that overall this is a really solid proposal; > don't take my criticism *too* hard. I think it could be an excellent > one, though, so I hope you'll take my suggestions into account. Good > luck! > > Jacob > > On Tue, Apr 16, 2013 at 12:09 PM, Christopher Medrela > <chris.medr...@gmail.com> wrote: > > I would like to participate in Google Summer of Code this year. I've > written > > proposal for "revamping validation functionality" idea. It's available > as a > > gist: https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 . > Below, I'm > > pasting the proposal. Feel free to criticize it. > > > > Table of content > > > > 1. Abstract 1.1 Drawbacks of the existing framework 1.2 Goals 1.3 > Benefits > > 2. The new framework 2.1 Overview 2.2 Advantages > > 3. New features 3.1 django-secure 3.2 django-update > > 4. Schedule and milestones > > 5. Who am I? > > > > 1. Abstract > > > > 1.1 Drawbacks of the existing framework > > > > Django currently has a validation framework, but there are a lot of > problems > > with it. First of all, it is monolithic and developers cannot write > custom > > validation (see [#16905]) or modify the existing functionality (see > > [#12674]); validation lives in a few functions like > > django.core.management.validation.get_validation_errors [1] or > > django.contrib.admin.validation.validate [2]. The validation > functionality > > is not separated from other stuff like printing found errors during > > validating models in get_validation_errors or registering models in admin > > app [3] (see [#8579]); it is sometimes done during first call to an > > important method, i. e. CurrentSiteManager [4] is validated in its > > get_queryset [5] method. > > > > [#12674] https://code.djangoproject.com/ticket/12674 > > [#16905] https://code.djangoproject.com/ticket/16905 > > [1] > > > https://github.com/django/django/blob/master/django/core/management/validation.py#L22 > > [2] > > > https://github.com/django/django/blob/master/django/contrib/admin/validation.py#L14 > > [3] > > > https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L52 > > [#8579] https://code.djangoproject.com/ticket/8579 > > [4] > > > https://github.com/django/django/blob/master/django/contrib/sites/managers.py#L5 > > [5] > > > https://github.com/django/django/blob/master/django/contrib/sites/managers.py#L38 > > > > There are few tests of the validation framework and it is not easily > > testable because validation functions return concatenated error messages > > instead of list of errors (see > > django.tests.invalid_models.invalid_models.models [6]). It also lacks > some > > features like warnings (see [#19126]). Due to this disadvantages lots of > > apps do not have any validation, i. e. they do not check inter-app > > dependencies. > > > > [6] > > > https://github.com/django/django/blob/master/tests/invalid_models/invalid_models/models.py#L366 > > [#19126] https://code.djangoproject.com/ticket/19126 > > > > 1.2 Goals > > > > This proposal is about revamping current validation framework. First of > all, > > we need to write more tests and rewrite existing ones. Then we need an > > consistent API of validating different kinds of objects like models, > fields, > > managers or whole apps so it will be easy to add new kind of object. > > Validation functionality should be separated from other stuff and it > should > > minimize dependencies. We should allow developers to add validation to > their > > apps and any other kind of objects, so custom validation is a must. We > will > > not brea -- You received this message because you are subscribed to the Google Groups "Django developers" 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
