Changes between Initial Version and Version 1 of SummerOfCode2011

01/30/2011 07:10:50 AM (9 years ago)
Ramiro Morales

Created page by copying the GSOC '10 and adapting to this year's schedule. Needs more work.


  • SummerOfCode2011

    v1 v1  
     2= Google's Summer of Code 2011 =
     4Django will be once again applying to be a sponsoring organization for the [ 2011 Google Summer of Code]. (Read Google's page for more information on how the program works.)
     6The period for mentoring organizations to register is February 28 - March 11. Google will be announcing the accepted organizations on March 18.
     8== Mentors ==
     10If you're interested in mentoring -- supervising a student in work on Django-related activities -- add your name and email here:
     12 * Your Name (Your Email)
     14== Students ==
     16Student application period opens March 28 and ends on April 8.
     18If you'd like to get started on your proposal early, we'll be looking for a few things. 
     20 * You'll need to have a concrete task in mind (some ideas are below) along with a solid idea of what will constitute "success" (you tell us). 
     21 * If your proposal is a single large feature, you'll need to present a detailed design specification. This proposal should be posted to [ django-developers], where it can be refined until it is accepted by the developer community.
     22 * We'll want to know a bit about you -- links to previous work are great, if any.  If you're proposing something ambitious, you'll need to convince us that you're up to the task.
     23 * You'll also need to provide us with a schedule, including a detailed work breakdown and major milestones so your mentor can know if and when to nag you :)
     25Note that none of the ideas below are good enough to be submissions in their own right (so don't copy and paste)!  We'll want to know not just ''what'' you want to do but ''how'' you plan to pull it off.
     27Don't feel limited to the ideas below -- if you've got a cool project you want to work on, we'll probably be able to find you a mentor.  We plan on approving as many projects as we possibly can.
     29'''Note: we're looking for projects that add value to Django itself - ''not'' application/CMS projects that use Django.'''
     31You should also note that as far as proposals go, we don't make a distinction between a GSoC project and any other proposal for a new feature. When you contribute code, you will be expected to adhere to the same contribution guidelines as any other code contributor. This means you will be expected to provide extensive tests and documentation for any feature you add, you will be expected to participate in discussion on [ django-developers] when your topic of interest is raised. If you're not already familiar with [ Django's contribution guidelines], now would be a good time to read them.
     33== Communication ==
     35The [ django-gsoc] Google Group has been setup to facilitate communication between students and mentors in the GSoC efforts. This list should only be used for GSoC administrative matters. Any discussions on the specifics of a given proposal should be directed to [ django-developers].
     37== Ideas ==
     39Here are some suggestions for projects students may want to propose (lazyweb: please add to this list!). This isn't by any means the be-all and end-all of ideas; please feel free to submit proposals for things not on this list. However, if you're going to propose something that isn't on this list, you might want to check on [ django-developers] to see if there is any interest before you start drafting a full proposal.
     41When developing your proposal, try to scope ideas/proposals to the 4-month timeline -- simply proposing to fix a ticket or two will probably result in your proposal being rejected in favor of a more ambitious one.  The GSoC '''does not cover activities other than coding''', so certain ideas ("Write a more detailed tutorial" or "Create demonstration screencasts" or "[wiki:AddAPony Add a pony]") are not suitable for inclusion here.
     43On the other side, though, be sure to be concrete in your proposal. We'll want to know what your goals are, and how you plan to accomplish them.
     45In no particular order:
     47=== Template compilation ===
     48 * '''Complexity''': High
     50A common criticism of Django's template language is that it is too slow. One reason for this is that the rendering process is handled at a very high level, interpreting a tree of tree nodes that have been generated by parsing the template source file.
     52Other Python-based template languages gain significant speedups by compiling templates directly to Python bytecode. A Django template compiler would allow for similar templating speedups.
     54Issues to consider:
     55 * How does Django's template variable scoping rules map to a compilation scheme?
     56 * Django Template tags are able to modify the context as the template is rendered. How does this affect the compilation process?
     57 * How should we handle the upgrade path when compiled templates are added to trunk?
     59See also:
     60 * [ One proposal to implement template compilation]
     61 * The [source:django/trunk/django/template django.template code module]
     62 * Other template languages, like [ Jinja2] and [ Cheetah]
     64=== Enhanced auth.user ===
     65 * '''Complexity''': High
     67One of the most common class of questions on [ django-users] surrounds issues of customizing Django's User model. For example:
     68 * How can I use an email address as a username?
     69 * I want to use Twitter/OAuth/Facebook to login - why can't I leave the username field empty?
     70 * How can I make the username field N characters longer/shorter?
     71 * How can I allow [insert random character] in usernames?
     72 * How can I have a single "name" field instead of "first_name"/"last_name"?
     74At present, there is no easy answer to these questions. Use of Django User model is not mandatory, but it is a dependency for a lot of Django applications. It is possible to do some of these customizations using some tricks or by manually modifying the contrib.auth source code, but these are not good solutions for novice users.
     76Ticket #3011 describes one approach that has been rejected - the idea of a 'pluggable' User model.
     78'''Note:''' This isn't a problem with an existing worked solution. A successful proposal on this project will require extensive discussion on [ django-developers].
     80Issues to consider:
     81 * How can we represent the generic idea of a User without reducing the user table to little more than an identifying primary key?
     82 * How can we differentiate the ideas of identity, permission and authentication?
     83 * How can we manage the dependencies that exist in contrib.admin (and other parts of Django core and Django.contrib) that rely on the internals of auth.User as currently implemented?
     84 * How can we roll out a new/modified User model without requiring almost every Django application on the planet to undergo a complex database modification?
     86See also:
     87 * #3011, and any discussion on [ django-developers] that references it.
     88 * Discussions on [ django-users] when users have asked the "how do I" questions
     89 * The [source:django/trunk/django/template django.contrib.auth code module]
     91=== ORM Support for non-SQL databases ===
     92 * '''Complexity''': High
     94Django's ORM currently supports exclusively SQL databases.  This project would act to refactor the internals of Django's ORM to add support for alternate databases, and hopefully present a prototype for such a backend.
     96Issues to consider:
     97 * How should a backend respond to an operation that can't be performed at the database level, should it be emulated in Python or an exception raised?
     99=== Improved error reporting ===
     100 * '''Complexity:''' Medium
     102The error messages raised by Django can sometimes be confusing or misleading. This is sometimes due to Django wrapping and re-raising errors when it shouldn't. Sometimes it's due to Django not displaying error information effectively. Sometimes it's simply a matter of not catching the right errors.
     104This should be fixed. Error messages are just as important to the development process as good documentation. This project would address the error reporting issues in Django to ensure that the errors reported by a Django project are as good as they can be.
     106Issues to consider:
     107 * Import errors discovered during application loading during can be masked under certain circumstances.
     108 * Errors in template tags and filters rarely produce helpful error messages.
     109 * Errors in ModelForm and ModelAdmin can raise errors that don't indicate the real problem
     111See also:
     112 * [wiki:BetterErrorMessages The Better Error Messages] proposal page
     113 * Ticket #3349
     115=== Improve annotation and aggregation ===
     116 * '''Complexity:''' Medium
     118The 2009 Summer of Code added the annotate() and aggregate() calls to Django's query arsenal. While these tools work well for simple arithmetic aggregates, they don't work well for date and string based queries. There are also use cases where you may want to annotate data onto a model that *isn't* an aggregate (for example, annotating the sum of two other aggregates).
     120This project would continue where the 2009 GSoC aggregation project left off. This would be an excellent project for anyone wishing to gain an intimate understanding of Django's Query infrastructure.
     122Issues to consider:
     123 * String concatenation and manipulation (e.g., annotate a model with the uppercase version of the first 5 characters of someone's name)
     124 * Grouping of results by date (e.g., show me a count of articles, grouped by day)
     125 * Allowing non-null defaults in aggregation (e.g., when a model has no related objects, use 0 not NULL)
     126 * Aggregates involving generic relations
     128See also:
     129 * [ Trac's list of ORM aggregation tickets]
     130 * The [source:django/trunk/django/db/ Django's QuerySet implementation]
     132=== App loading ===
     133 * '''Complexity:''' Medium
     135Django currently assumes that an application will only ever be loaded once, and that the name of that application will be determined solely by the package name holding the file. However, this has several consequences;
     136 * You can't deploy several instances of the same application
     137 * You can't deploy two applications with the same name
     138 * There is no convenient interface for internationalizing application names
     139 * There is no way to rename an application with a name that isn't helpful from a UI perspective.
     141This project would address these limitations by changing the way applications are loaded. Ticket #3591 contains a description of one proposal.
     143Issues to consider:
     144 * How can we change the app loading mechanism without breaking every existing use of INSTALLED_APPS in the wild?
     145 * How should two instances of the same application be differentiated during runtime -- especially during URL reversal?
     147See also:
     148 * #3591, and any discussion on [ django-developers] that references it.
     149 * [source:django/trunk/django/db/models/ The current app loading mechanism]
     150 * Ideas on a InstalledAppsRevision collected during Pycon 2008 development sprint
     152=== Multiple timezone support for datetime representation ===
     153 * '''Complexity''': Medium
     155Currently The `TIME_ZONE` Django setting allows PostgreSQL-backed installations to run project/application on timezones different from each other and from the system timezone of the server.
     156Also, the information of !DateTime fields is retrieved from the database as naïve Python `datetime` instances and when the DB backend is PostgreSQL the data sent and retrieved to/from the DB is corrected by the `TIME_ZONE` value.
     158But if you need to have:
     160 * date+time data to be entered in different locations using the local time
     161 * such data be displayed in the local time at different locations different from the location where it was originally entered.
     163then more granularity is needed so different instances of date+time inside one application can be handled in a way that takes in account its timezone.
     165An additional possibility would to create an additional presentation layer, where an user location/timezone preference can influence and personalize the display of date+time's (see the Django template filter idea in one of the thread linked below.)
     167Other advantages of a solution to this problem could be: Isolation from daylight saving time political policy changes and isolation from changes on time zones should the hosting of a production application be moved form one geographical location to another.
     169Issues to consider:
     170 * Compatibility with all the DB backend officially supported by Django
     171 * Backwards compatibility: Existing installations shouldn't be affected at all regarding the storage/interpretation of `DateTime` model fields values
     173See also:
     174 * Tickets #2626, #10587 and possibly #1480 and #2447
     175 * A django-dev [ thread]
     176 * Another django-dev [ thread]
     177 * A [ blog post] describing how this was implemented for ''Ruby on Rails'' 2.1
     178 * [ timestamp] PostgreSQL data type documentation
     179 * Django `TIME_ZONE` setting documentation:
     181=== Housekeeping ===
     182 * '''Complexity:''' Minor
     184Django has gone through three recent cycles of rapid change, culminating in the release of versions 1.0, 1.1 and 1.2. These releases have all been feature heavy, which is good for ticking off checkboxes on feature lists, but it does mean that some internal housekeeping and code cleanup tasks have been avoided in order to deliver new features. These housekeeping issues would be well suited to a Summer of Code student wishing to gain a deep understanding of the internal workings of the Django framework.
     186Issues to consider:
     187 * Django's Model._meta class is officially internal API, but in practice, many parts of _meta are in such common use that they couldn't be changed without causing major problems to Django users. The contents of _meta should be surveyed, cleaned up where necessary, documented and tested as part of formal API.
     188 * While the public API for foreign keys and m2m relations in Django is quite elegant, the implementation is anything but. This implementation should be cleaned up.
     189 * There are several internal components (such as the datastructures library) that are heavily used, but have not been extensively profiled to ensure that they are efficient. Profile the Django test suite to find the areas of code that are performance bottlenecks, and optimize them.
     191See also:
     192 * Trac, bugs by component. Any component with lots of bugs is potentially a candidate for inclusion in this project.
     193 * [source:django/trunk/django/db/models/ The Model._meta class definition]
     194 * [source:django/trunk/django/db/models/fields/ The related fields implementation]
     196=== Customizable serialization ===
     197 * '''Complexity:''' Minor
     199Django's current serializer implementation imposes some restrictions that limit the usefulness of the serializers outside of fixture loading. The basic serialization format, for example, can't be changed.
     201The aim of this project would be to deliver a fully customizable serialization framework. Ideally, this would be a class-based structure that allows users to define their own serialization format (including different output structure, including non-model fields, etc). The end goal is that you should be able to output any object (or list of objects), in any format, to any depth, with any additional information that might be relevant in a serialization context.
     203In short, anywhere we have made an arbitrary design decision with Django's existing serializers, that decision should be customizable as an end user.
     205When developing your proposal, the proof of concept is that you should be able to define Django's existing serialization formats using your new serialization format.
     207Issues to consider:
     208 * Serializing nested structures (of arbitrary depth)
     209 * Serializing subsets of model attributes
     210 * Serializing non-database attributes/properties
     211 * Serialized output that doesn't match the current default output format (i.e., a model in JSON doesn't have to be {"pk": XX, "model": "", "fields": {...}} )
     212 * Serialized output format that can change on a per-model basis
     213 * Serialized output format that can change based on where in the output tree the object is located (e.g., output the full User object if it's included from within model X, but only output the username if its included from within model Y)
     214 * In an XML context, control over the tags, namespaces, attributes  and nesting structures in the final XML
     215 * In a JSON/YAML context, control over the use of lists, dictionaries etc, as well as the choice of key names for dictionaries.
     217See also:
     218 * [ Open serialization tickets]
     219 * The [source:django/trunk/django/core/serialization Django's current serializer implementation]
     220 * The [ many past unsuccessful GSoC proposals regarding serialization improvements].
     222=== IPv6 support ===
     223 * '''Complexity:''' Minor
     225Django doesn't currently provide support for IPv6. This project would update Django to provide support for IPv6 wherever Django currently uses IPv4 addresses.
     227Issues to consider:
     228 * Can IPv6 support be added to model fields without adding a new field type? Add ipv6=False kwarg to IPAddressField?
     229 * Is there anywhere in the WSGI/FCGI interface where IPv6 issues exist, but are currently unreported
     230 * Can IPv6 support be added to configuration files (e.g., to specify memcache interfaces) in a transparent fashion?
     232See also:
     233 * #11442
     234 * #7735
     236=== Testing updates ===
     237 * '''Complexity:''' Minor
     239Django's test suite originally consisted almost entirely of doctests; these doctests were used as a supplement to the written documentation. Over time, this supplemental role has been dropped. The doctests have also gotten larger;  in some cases (such as the queries regressiontest) they are now extremely unwieldly. New tests that are added to Django tend to be UnitTests when possible, but the existing legacy of doctests is hard to break in some cases.
     241There is also an artificial distinction between modeltests and regressiontests. In the past, this distiction was used to identify tests that served a documentation purpose; this role has long since disappeared, but the struture persists, leading to confusion over the 'right place' to test certain features represented in both directories.
     243These two tasks indicate a need to refactor Django's test suite. The aim of this project would be to update Django's test framework; migrating as doctests to UnitTests, and merging the modeltests and regressiontests directories.
     245Issues to consider:
     246 * How to maintain the integrity of Django's test suite? Django has spent a lot of effort building a strong regression test suite; how do we ensure that by refactoring the test suite, we don't lose the integrity of that regression set?
     247 * Is there any part of this process that can be automated? If so, How?
     248 * Will migrating from doctests to unittests cause any performance problems? Are there any ways to limit these performance problems?
     250See also:
     251 * [source:django/trunk/tests Django's test suite]
     252 * [source:django/trunk/django/test Django's testing utilities]
     253 * [ Documentation on Django's testing utilities]
Back to Top