Hi Russel, Sorry for getting back now (I did not have notifications set up!). Thank you very much for the suggestions, I will have a look at models/options.py right away.
Regards, Daniel Pyrathon On Thursday, March 6, 2014 12:03:04 AM UTC, Russell Keith-Magee wrote: > > Hi Daniel, > > On Wed, Mar 5, 2014 at 11:48 PM, Daniel Pyrathon > <[email protected]<javascript:> > > wrote: > >> Hi, >> >> My name is Daniel Pyrathon. I am currently a third year BSc student in >> Computer Science at the University of Plymouth. >> >> I love programming and I have always been active in the Open Source >> community (especially Python). In the past years I have written lots of >> Python, Javascript, Ruby, Java, and I am currently using C++ for many >> university projects. I have attended the last 3 EuroPython conferences and >> I have been a staff member of the conference for the last 2 years. >> >> I am currently looking for a way to contribute to Django. Working on >> Django would increase my knowledge of the framework as well as let me share >> my own experience. >> >> Reading the ideas list I found 2 of them that are very interesting for >> me, and so the reason behind this post is not only to present myself but >> also to discuss their feasibility. >> >> Formalizing the Meta object >> >> This task is very challenging because it digs in the internals of Django. >> I feel that I could learn a lot from it because I am very committed to >> refactoring and write most of my code in TDD. I have also experience with >> backwards compatibility. >> >> Do you have any resources (code) I should read to get up to date and to >> understand better how it is currently implemented? >> > > Unfortunately not; at least, not other than just trying to untangle the > mess that is django/db/models/options.py and the things that depend on it > (ModelForms and Admin in particular). This project really is the very model > of untangling a ball of string. The reason it's listed as a potential > project is specifically *because* there are no resources we can point you > at. > > If, after looking at the code, you feel it's a little "thin" for 12 weeks, > one way to bulk it out is to build a proof of concept alternate > implementation of Meta. Aside from the "it would be good to document this" > aspect, the practical reason for wanting to formalise Meta is that it would > allow people to build duck-typed implementations of Meta. If you can build > an alternate implementation of the Meta interface, then you should be able > to deploy your "duck" into a Django project and build a ModelForm, or > browse it in Admin. > > So, for example, you could build a wrapper around a NoSQL store, or around > an LDAP or email store, that *looked* like a Django model from the outside. > This means you could view your NoSQL data, or LDAP records, or emails in > Admin without needing to go through a SQL database. > > The aim of proof of concept wouldn't be to commit something to Django's > core - it would be to build an external, standalone proof-of-concept, > demonstrating that your documentation was complete and correct. Depending > on what backend you choose, it might turn into a fully viable project on > it's own. > > >> Improved error reporting >> >> The idea of making people’s lives better by improving error messages is >> fundamental. There would be a lot to discuss: what type of imports would we >> want to mask? I have read BetterErrorMessages and would be happy to get >> started soon. My idea behind this task would be to expand on this ticket: >> what would be great is to add a web console with live REPL support, similar >> to what Werkzeug debugger does. This could be a great starting point and >> would lead to a better use of Django. >> > > This is an interesting idea; however, I see two problems: > > 1) It would involve reinventing the wheel. Werkzeug exists, and does its > job well; a GSoC project to "duplicate Werkzeug" doesn't strike me as a > good use of GSoC resources. However, a project to integrate Werkzeug's live > debugging capabilities into Django might be more viable. > > 2) Security implications. Unfortunately, more than one site has been > launched with debug=True accidentally left on; all you need to do then is > stimulate a server error, and you have REPL shell access to the server. > This strikes me as a remarkably effective foot-gun :-) Before you get too > involved in the implementation, I'd want to know the security issues have > been locked down. > > >> Said this, I have to be very honest. I have never contributed to Django >> up till now and I want to hear your feedback on which proposal would suit >> me best. However I learn a lot through experience and I am attracted by >> new and challenging tasks. >> > > My suggestion would be that the Meta project is probably better suited to > a newcomer. The Error reporting project is a little vague - it relies on > someone having a bit of experience with Django to know when the errors that > are being returned are unhelpful. A "green" Django user *could* do this, > but they're going to spend a lot more time trying to find problems that > need to be fixed. > > Approaching the project from the Werkzeug angle is an interesting idea, > but you're not starting with a pre-blessed project -- your first step is to > convince the core team that the idea is worth pursuing. Given the > compressed timeframe for submitting applications, it might not be possible > to get this blessing before your application is due. > > >> Also, it would be nice if I could have some suggestions on what to read >> and if there are some specific parts of the code I should be directed to. >> > > The best advice I can give is to dig in and get your hands dirty. Start > small. Look for a little bug; preferably one that is tangentially related > to your area of interest (try and fix a bug in ModelForms, for example). > Every little bit of experience will help, and along the way, you'll get to > know people in the development community, and Django's development process. > > Best of luck with you GSoC application! > > Yours, > Russ Magee %-) > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/ce3822dd-5f87-4d4f-bb64-b4795a0788d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
