Re: [GSoC 2013] Revamping validation functionality proposal
Thank you for your feedback. I really appreciate every comment because that let me improve my proposal. 1. First of all, I noticed that the license of django-secure is copyright. Google forces us to release code under one of approved license [1], so a question to Carl Meyer: do you mind changing license? 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. > > 2. Last year and this year I attended FCE conversation class, so my English level isn't worse than FCE. I guess that I'm not ready to speak in real time, but I can talk in real time at IRC. But you know, it's hard to judge your own skills. 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. > > 3. I tried to find discussions about the additional functionality expected from django-secure (you mentioned checking outdated dependencies, debug mode and exposed admin), but I didn't succeed. Could you point me to any discussion on this mailing list or in the ticket tracker or anywhere else? 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. > > 4. It looks like changing validate into validate_all solves the problem. We also have to emphasise the difference between those two mechanisms in documentation. 5. I said that I won't have any trip during GSoC, but I forget about my holiday after September 6. This is not backpacking-trip, I will live in a hotel with net access, but I won't be able to work full time. I hope that you won't disqualify my proposal on this basis -- that can be considered as an advantage because I will be highly motivated to finish before time. 6. I've updated my proposal. I'm not repasting it here -- that would be too much mess. If you want to see the new version, look at the gist [2]. Changes to the proposal in short: - *Rewriting the second part of the proposal*. The proposal is not finished, it lacks the "improving django-secure" part. - *Changing schedule of the first half* -- removing "write documentation" week. - *Minor changes.* Changing solution -> hint. Changing validate -> validate_all. Changed app validation rules: the file validation.py won't be created by default for new apps; if the file exists but it misses validate_all or validate_models functions, then the default ones are used. [1] http://opensource.org/licenses/ [2] https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 -- 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.
Re: [#20291] Add method to reload `AppCache`
> > I'll confirm that #20291 is a duplicate of #3591. However, I'll also agree > that the connection isn't obvious. You need to know this history, and see > the big picture. > > #3591 has become, over time, the holding ticket for a bigger issue known > as the "app refactor". The underlying issue is that Django doesn't > currently have any place to store app-related configuration, and doesn't > have any guaranteed order for performing that app-related configuration. As > a related issue, this means that the app cache needs to be refactored to > allow for reliable ordering. > > Bringing it back to #20291, in order to test these new capabilities means > adding features to clean up and reset the app cache. > [...] on #20291 -- this is a duplicate of #3591, and I'd rather see effort > concentrated on fixing that ticket. > > Now I got it, absolutely clear and seems the right way to do it. However, just as a suggestion: perhaps it would be better not to close related tickets that define new requirements for work in progress, but reassign them instead? Personally, if working on such complex issue I would prefer to have all the ideas and use cases in once place. It may be hard to get the same people to write comments and reviews again. I'll get in touch with Preston and ask if there's anything I can be useful for. Cheers, Robert -- 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.
Re: Changing deferred model attribute behavior
On Friday 26 April 2013, Alex Gaynor wrote: > Sorry, I misunderstood the original request. Yes, you're right Anssi and > Adrian, finding them on demand is reasonable. > Reasonable, but not entirely necessary for this. I have code that requires something like that; when it is time to "undefer" the object, I just load it up anew from the db. I think this covers Adrian's use case well, except (perhaps) for the part where it is triggered by attribute access. (my own use case is going through a list of objects and serializing all of them; deferring is necessary because the query that selects the objects needs to use distinct(), and some objects have TextFields -- which would make the "distinct" so non-performant, that Oracle simply forbids it). Shai. -- 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.
Re: [GSoC 2013] Revamping validation functionality proposal
On Fri, Apr 26, 2013 at 8:54 AM, Christopher Medrela wrote: > Thank you for your feedback. I really appreciate every comment because that > let me improve my proposal. > > 1. First of all, I noticed that the license of django-secure is copyright. > Google forces us to release code under one of approved license [1], so a > question to Carl Meyer: do you mind changing license? > The license is BSD 3-clause: https://github.com/carljm/django-secure/blob/master/LICENSE.txt Cheers Tom -- 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.
Re: Changing deferred model attribute behavior
On 26 huhti, 00:59, I wrote: > Now, if there would be some way to avoid the dynamic model subclassing > used by deferred loading then storing the set of deferred fields per > instance would be more than welcome. One possibility might be defining > Model.__getattr__. If you end up in __getattr__ and the value isn't > present in the model's __dict__ but the attname is present in the > model._state.deferred_fields, then you know to load it from DB. I > assume there are some reasons why this wasn't done in the first > place... Maybe descriptors for custom fields would break or the above > mentioned direct __dict__ access case would fail? I tried the above approach. It works, but there are some potential problems: 1. There is a need to alter __init__ signature (added a __loaded_fields kwarg). 2. There is now __getattr__ for Model, this will cause slowdown for attribute access and hasattr in case the attribute searched isn't found. For cases where the attribute is found there is no speed difference (as __getattr__ is only called for no-found cases). 3. Potential problems for descriptors: the descriptors need to be programmed defensively, if the attribute isn't found from the instance's __dict__, then AttributeError will need to be raised instead of KeyError. See changes in fields/subclassing.py for an example. 4. Doing del obj.someattr or obj.__dict__.pop(someattr) then accessing the same attr again will result in reload from DB instead of AttributeError. But on the other hand you get totally rid of the ugly dynamic subclassing used by deferred loading. This will resolve some longstanding bugs (like signals not working when using deferred models). No 1. above seems like the biggest problem. Personally I don't see overridden __init__ methods very useful in the first place. This is because there is no way to know if load from DB happened, or if this was a regular init. And in addition the semantics of __init__ is strange. The initialization might happen through *args, or through **kwargs, or through both, and missing kwargs might be deferred or not. This is maybe going out of topic, but I would actually like to add a new _from_db class method which does model construction by direct __dict__ assignment. So, model loading from DB wouldn't go through __init__ at all. The reasoning for this is to get rid of the weird __init__ semantics. Another reason is that load from DB is just a form of deserialization, and deserialization shouldn't go through __init__, instead the object should be constructed manually. This is how normal Python pickling works. Finally, this way is much faster, up to around 4x faster for deferred loading (see https://code.djangoproject.com/ticket/19501 for some performance numbers). Unfortunately this change is hard to do with any kind of backwards compatibility period. Here is the work-in-progress patch: https://github.com/akaariai/django/compare/defer_getattr. Unfortunately I don't have time to work on this more until start of June or so... - Anssi -- 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.
Newbie: import start end edit an existing django project
Hi, I am a complete newbie to Django but not to Python and I have to edit a few lines of code in an existing Django project within the next few days. Of corse, I have to do so not in the production- but in a separate development environmet. I have: 1. a running Django server - the development environmet 2. an export of the existing existing Django project which I have copied into the django_projects folder I also followed the tutorial https://docs.djangoproject.com/en/dev/intro/tutorial01/ . I have created the "mysite" demo project, I have - as far as the console tells me - successfully started it - but I can't see it. All I have to to is get the existing project to run on another machine change a few lines, check it in the browser and be done with it. Any help would be very much apprecíated. Thanks in advance Horst Am 26.04.2013 um 12:11 schrieb Tom Evans: > On Fri, Apr 26, 2013 at 8:54 AM, Christopher Medrela > wrote: >> Thank you for your feedback. I really appreciate every comment because that >> let me improve my proposal. >> >> 1. First of all, I noticed that the license of django-secure is copyright. >> Google forces us to release code under one of approved license [1], so a >> question to Carl Meyer: do you mind changing license? >> > > The license is BSD 3-clause: > > https://github.com/carljm/django-secure/blob/master/LICENSE.txt > > Cheers > > Tom > > -- > 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. > > -- Horst Jäger h.jae...@medienkonzepte.de Medienkonzepte http://www.medienkonzepte.de/ Schaafenstr. 25, 50676 Köln, Germany Tel +49 221 93187015 / Fax +49 221 93187029 -- 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.
Re: Newbie: import start end edit an existing django project
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 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.
Re: [GSoC 2013] Revamping validation functionality proposal
On Fri, Apr 26, 2013 at 3:54 AM, Christopher Medrela wrote: > 1. First of all, I noticed that the license of django-secure is copyright. > Google forces us to release code under one of approved license [1], so a > question to Carl Meyer: do you mind changing license? django-secure is licensed under the same BSD license that Django itself uses, so there's no problem. I've also talked with Carl in the past about merging django-secure into core, and he's fine with that. So we're OK both legally and procedurally. > 3. I tried to find discussions about the additional functionality expected > from django-secure (you mentioned checking outdated dependencies, debug mode > and exposed admin), but I didn't succeed. Could you point me to any > discussion on this mailing list or in the ticket tracker or anywhere else? I believe that most of these discussions have been in IRC or in real-life, so there aren't records, sorry. However, I don't think your proposal needs to included these sorts of new checks -- unless there are ones you specifically find interesting or exciting. They're more along the lines of things we could add in the future if we had a good framework to do so. > 5. I said that I won't have any trip during GSoC, but I forget about my > holiday after September 6. This is not backpacking-trip, I will live in a > hotel with net access, but I won't be able to work full time. I hope that > you won't disqualify my proposal on this basis -- that can be considered as > an advantage because I will be highly motivated to finish before time. That's totally fine. As long as you work your holiday into your proposed timeline and are realistic about what you can get done given your schedule, we're fine. Jacob -- 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.
