Re: The threat of the incompletely initialized django instance
On Tuesday, April 16, 2013 8:41:26 AM UTC+2, ptone wrote: > > > > On Monday, April 15, 2013 4:51:24 AM UTC-7, Pakal wrote: >> >> (my previous answer disappeared in googlemail, I hope that one will >> survive the sending...) >> >> Thanks for the feedback, >> >> Preston, since ticket #3591 ticket and related discusions are partially >> obsolete compared to your current works, may I just know if your current >> evolution will automatically reproduce the auto init() of the devserver >> (i.e loading models from each installed app) ? Because being able to use >> the same several times, or to set its human name, are cool features, but >> imo the most critical part at the moment is that difference between dev and >> prod inits, which can bite hard the unwary djangoer. >> >> > The approach would be more along the lines of defining a place that is > guaranteed to run at as distinct a time as possible in the startup process > - rather than trying to guarantee that all code gets imported in some > coherent way with the aim to trigger module level import code. The latter > is what we want to move away from. > > -Preston > > OK, I don't understand though in which cases one wouldn't want all his INSTALLED_APPS models to be imported at startup :? Some for the "coherent way" - doesn't python's import mechanism already ensure that modules depending on each other import themselves in a proper order (except if cyclic imports ofc) ? Regards, Pascal -- 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.
[GSoC 2013] contribute to django-deployer for deploying django to PaaS easily
to django-developers: Sorry, I use Google Drive for proposing, and I original tend to copy&paste it to here but found it will get in a mess. so I put my proposal here: http://goo.gl/xJyJ9 My idea is to contribute to django-deployer and make some significant improvements for it. This proposal is still editing, but I pre-post it to prevent I'm thinking it in the wrong way. any questions or any advise are welcome, thank you, I'm really a big Django fan, and I hope I can make it better. cuz seems like there's no #django-dev, so feel free to add my XMPP directly: littleq0...@gmail.com it's open for messaging anytime :D - Colin Su -- 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] contribute to django-deployer for deploying django to PaaS easily
Hi, On Saturday, April 20, 2013 8:03:43 PM UTC+2, LittleQ@NCCU, Taiwan wrote: > > cuz seems like there's no #django-dev, so feel free to add my XMPP > directly: littl...@gmail.com There is #django-dev (sic) on irc.freenode.net. Regards, Florian -- 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.
[GSoC 2013] Improved error reporting
* Hi again. Let’s try analyse the topic Improved error handling a little deeper. I’ve found dozen opened issues related to bad error handling (these are rather *not* from Better Error Messages list). In general most of the bugs demand different approach for each one. 1. django admin https://code.djangoproject.com/ticket/9373 https://code.djangoproject.com/ticket/14642 - maybe patch from last comment will be enough here https://code.djangoproject.com/ticket/14408 https://code.djangoproject.com/ticket/10919 - probably limiting number of displaying modified objects would fix the problem https://code.djangoproject.com/ticket/17417 - it would worth to track and fix or raise suitable error 2. templates: https://code.djangoproject.com/ticket/18995 3. django.db https://code.djangoproject.com/wiki/BetterErrorMessages?version=48#django.db- quite complex problem with high severity https://code.djangoproject.com/ticket/13776 - [related to above] this could be fixed after some core dev will make decision how this code should behave (if it’s worth to pass this task from someone that will understand the problem to someone else) 4. various: https://code.djangoproject.com/ticket/20250 - probably NoneType should be detected in django.db.models.sql.where.as_sql(self, qn, connection) already or even before. If we don’t want to prevent this value to be None or it’s not easily possible, the solution would be to catch None in last function raising some error. Error message could contain tip saying what might solve this problem. https://code.djangoproject.com/ticket/16840 - need to raise an error for unexisting fields https://code.djangoproject.com/ticket/19560 - consider if the warning should be changed into error here https://code.djangoproject.com/ticket/15063 - I don’t fully understand the comment 2 but possibly I could fix it 5. group of tickets “approved” by core developers to produce more verbose message : https://code.djangoproject.com/ticket/18959 https://code.djangoproject.com/ticket/18866 https://code.djangoproject.com/ticket/14343 https://code.djangoproject.com/ticket/12756 https://code.djangoproject.com/ticket/8760 Plan what to do: Fixing most of errors should consist of following steps: 1. Analyse where and why error occurs. 2. Try to reproduce the bug (the best way would be creating a test if it’s not provided) 3. Now take one of actions: a. Just fix error message b. Consult issue with core developer and fix the problem raising error in more proper place or way 4. Create a fix for ticket and submit a patch to review Schedule I thought about splitting the time for few-days intervals (it might be weeks) and assigning that bugs to them. The most important problems should be resolved first. As I said: If i take an easier set of issues - it should be possible to fix a dozen of them. If I’ll take more complex tickets that demand to take some decisions and medium reworks - I should take just few. Taking few sounds more reasonable for me. Committing I’m going to focus on a bunch of small problems so here I propose to do a commit (pull request) per problem. This would be easier to review by other developers and easier to link with problem. Additionally if some of the fixes will need additional changes, it won’t have any influence on the others. Questions 1. Do you guys know some other “known” errors which are confusing to users? 2. Could this task include some things like: https://code.djangoproject.com/ticket/18171 - some steps have been taken but it is still unfixed (and related to raised exception) https://code.djangoproject.com/ticket/17015 - another issue that requires bigger patch and finally causes confusing error message. or I rather shouldn’t touch errors like this? What next? I think finally I should take few or dozen of problems. My proposals here are weekly covering with your exemplary areas except admin area. Am I still on a correct track? There are few tickets related to django admin, maybe focusing on them will be a good direction. Although there are very few opened issues related to errors in templates - it would be hard to find them on myself. Also the group no5 (producing more verbose messages) is tempting to fix. After I will choose issues to fix, I want to specify more precisely how to fix them. PS. I still will be working on choosing issues to resolve/trying to know better presented already. I just wanted to share my first thoughts about this problem. Hopefully someone more experienced will direct me to a more appropriate way. Damian * -- 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/djang
Re: [GSoC 2013] Revamping validation functionality proposal
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 > 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 ex
Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily
thank you, I forgot it LOL On Sunday, April 21, 2013 5:32:43 AM UTC+8, Florian Apolloner wrote: > > Hi, > > On Saturday, April 20, 2013 8:03:43 PM UTC+2, LittleQ@NCCU, Taiwan wrote: >> >> cuz seems like there's no #django-dev, so feel free to add my XMPP >> directly: littl...@gmail.com > > > There is #django-dev (sic) on irc.freenode.net. > > Regards, > Florian > -- 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] contribute to django-deployer for deploying django to PaaS easily
Hi Colin, I've taken a look at your proposal, and I've got some concerns. Firstly, I'm not familiar with Django-deploy; but from a quick inspection of the project page it doesn't appear that anyone in the Django core team is on the committee list. In order for you to have this proposal accepted as part of the GSoC, you'll need to secure agreement from the project maintainers of Django-deploy that they want the help your offering, that your project proposal is sound, and that they're willing to commit to applying any patches you produce. Secondly, you haven't provided any timelines for your proposal. My immediate reaction is that you're proposing a lot of work for a student to complete in 12 weeks. For example, writing a fully tested and documented database backend strikes me as a 12 week project in itself - yet this is apparently just one line item in one part of your project proposal. Lastly, your project proposal is very light on details. You're proposing a lot of ideas, but you haven't really specified anything beyond "I'm going to do it". Are there APIs that need to be specified? If, in the case of something like a database backend, the APi is already specified, are there going to be any complications in satisfying the API? We need a lot more detail before we will be able to judge if you understand the project your proposing, or if you are just proposing a bunch of ideas but haven't given those ideas any more thought than "this sounds interesting" Yours, Russ Magee %-) On Sunday, April 21, 2013, LittleQ@NCCU, Taiwan wrote: > to django-developers: > > Sorry, I use Google Drive for proposing, and I original tend to copy&paste > it to here but found it will get in a mess. > > so I put my proposal here: > http://goo.gl/xJyJ9 > > My idea is to contribute to django-deployer and make some significant > improvements for it. > This proposal is still editing, but I pre-post it to prevent I'm thinking > it in the wrong way. > > any questions or any advise are welcome, thank you, I'm really a big > Django fan, and I hope I can make it better. > > cuz seems like there's no #django-dev, so feel free to add my XMPP > directly: littleq0...@gmail.com 'littleq0...@gmail.com');> > > it's open for messaging anytime :D > > > - Colin Su > > > > -- > 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 'cvml', > 'django-developers%2bunsubscr...@googlegroups.com');>. > To post to this group, send email to > django-developers@googlegroups.com '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. > > > -- 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.
