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 > <pir...@gmail.com<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 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/ce3822dd-5f87-4d4f-bb64-b4795a0788d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
