A highly profitable system?
RSpence Life is for living Knowledge is the key to success! http://www.forex-killer.com/?hop=rspence1 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: On aggregates
Reporting is quite common in my area of work at the moment and most of the time some form of aggregation is required to build meaningful reports. (For such case I have substantially more custom/native queries then standard ones.) -Alen (PS. if there is a need to give some real example with regards to this I could put some up.) On Fri, May 9, 2008 at 6:46 AM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On Fri, May 9, 2008 at 5:38 AM, Nicolas E. Lara G. > <[EMAIL PROTECTED]> wrote: >> >> Currently there is support for both aggregate and annotate on the >> simplest level. Some tests might be found under tests/modeltests/ >> aggregation/ of the current state of the project. They can probably do >> as documentaion in the early stages of the project (i.e. now :p ) >> >> Any comments or sugestions are more than welcome! :-) > > As a hint to the community - one of the best suggestions we can have > at this stage of the project is a set of interesting problems to > solve. This would give us a set of concrete 'problems' that we can use > to evaluate potential solutions. It may not be possible to find a > solution for every problem, but we won't know that until we have a > list of real problems to work with. > > So, if you have an interesting use case for aggregates (i.e., > aggregate queries that you would like to make, but currently need to > use raw SQL or an .extra() hack), let us know. If you can phrase that > query using the Author/Publisher/Book/Store model space that the new > aggregation model test defines, all the better. > > Here's a few suggestions to get the ball rolling (with some reasoning > on why they are interesting): > > * Does Author X have any friends? > (aggregate on a related object) > > * Give me a list of all Books with more than 2 authors > (Query over the count of objects in a m2m relationship) > > * Give me a list of all Authors that have no friends > (Query that counts when rows that don't exist in the m2m table) > > * Give me a list of all publishers that have published more than 10 books > (Query over the reverse direction of a FK) > > * Give me a list of all publishers that have published more than 10 > books this year > (Query over the reverse direction of a FK, with a filter on the related > object) > > * Give me a list of all Books that were written by X and one other author. > (Query that checks a count of m2m objects, plus membership of the m2m set) > > * Give me a list of all Authors that have published a book with at > least one other person > (Filters over a count generated on a related object) > > * Give me the average price of all Books that were written by X and > one other author. > (Aggregate over objects discovered using membership of the m2m set) > > Yours, > Russ Magee %-) > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: On aggregates
On Fri, May 9, 2008 at 3:58 PM, Alen Ribic <[EMAIL PROTECTED]> wrote: > > Reporting is quite common in my area of work at the moment and most of > the time some form of aggregation is required to build meaningful > reports. (For such case I have substantially more custom/native > queries then standard ones.) > > -Alen > (PS. if there is a need to give some real example with regards to this > I could put some up.) That's really what we're looking for. I would be highly surprised if aggregates weren't used for reporting purposes - the standing question is "what types of reports do people find interesting?" The goal is not necessarily to enable _every_ aggregate query to be expressed using the Django ORM, but we do want the most common queries to be expressed easily. If your examples are extraordinarily complex, they may be outside the scope of what we're looking to achieve, but we won't know what is possible until we know what people want to do. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
IIS, pyisapie, and DJANGO_SETTINGS_MODULE
So I have setup Django on IIS using PyISAPIe and am happy with the
performance so far. On my dev box running IIS 5.1, I am getting ~170
requests per second processed for the simple poll application.
Django is running as a WSGI application. I have reconfigured the
PyISAPIe files to look for a default configuration file in a virtual
directory. Therefore, each virtual directory and/or website can have
its own python configuration file. My intent was to be able to
specify a different Django project for multiple different virtual
directories/websites. The configuration file per virtual directory
looks like this:
### START CODE
import os, sys
sys.path.append('D:/system_data/development/python/django')
from django.core.handlers.wsgi import WSGIHandler as DjangoHandler
from Http.WSGI import RunWSGI
import inspect, string
#
# The main request handler.
#
def Request():
os.environ['DJANGO_SETTINGS_MODULE'] = 'dgtutorial2.settings'
return RunWSGI(DjangoHandler())
### END CODE
The problem, which is documented on both the Django Wiki and in the
PyISAPIe documentation is that even though DJANGO_SETTINGS_MODULE is
being reset each time a page is being requested, it doesn't seem to
affect how Django is running.
I realize this probably has something to do with the fact that the
Django settings are being stored at the process level, so even though
the environment variable is being reset each time a request is made,
Django isn't actually reloading the settings.
Can someone help me by giving me a high-level overview of how Django
is working and how/why the settings are being stored at the process
level? What would have to happen to get Django to re-process the
settings file each time a URL was requested?
In the end, my goal is to get a decently performing solution for
multiple installations of Django on an IIS server. I am happy to put
some time and effort into working on a solution for this if someone
can help point me in the right direction.
Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: On aggregates
Here is one of my current real-world, common, examples: Monthly maintenance costs - Report custom_sql_query = """ SELECT c.id, p.short_title, sum(f.amount) FROM manager_contract c, manager_financialtransaction f, manager_property p WHERE f.pub_date >= '%s' and f.pub_date <= '%s' GROUP BY p.short_title, f.transaction_type, c.property_to_be_letted_id, p.id, f.contract_id, c.id HAVING f.transaction_type='M' AND f.contract_id=c.id AND c.property_to_be_letted_id=p.id ORDER BY c.id, p.short_title """ % (from_date, to_date) 1. Sum of maintenance costs per Contract are printed on this report. (Contract ref number + Property Short title are printed with the total amounts for cost of maintenance for the given data range.) 2. User also has a date range filter which defaults to [1st of current month to the last day of this month]. -Alen Ribic On May 9, 10:12 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Fri, May 9, 2008 at 3:58 PM, Alen Ribic <[EMAIL PROTECTED]> wrote: > > > Reporting is quite common in my area of work at the moment and most of > > the time some form of aggregation is required to build meaningful > > reports. (For such case I have substantially more custom/native > > queries then standard ones.) > > > -Alen > > (PS. if there is a need to give some real example with regards to this > > I could put some up.) > > That's really what we're looking for. I would be highly surprised if > aggregates weren't used for reporting purposes - the standing question > is "what types of reports do people find interesting?" > > The goal is not necessarily to enable _every_ aggregate query to be > expressed using the Django ORM, but we do want the most common queries > to be expressed easily. If your examples are extraordinarily complex, > they may be outside the scope of what we're looking to achieve, but we > won't know what is possible until we know what people want to do. > > Yours, > Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-Table Inheritance and fixtures
The problem is that the parent object is saved, and then child object is saved. When the child model is saved it attempts to create the parent object again. It then fails constraints. After playing around with it a bit, it makes sense that the fix shouldn't be in the model.save(). However, it would mean that in the deserialization process, any parent models would have to be 'held back' from being saved until the children are saved. Afterwards, parent models would need to be compared to the parent models created by the children to see if there are any redundant models, which would then be discarded. This sounds kind of kludgy though. The alternative fix that I was thinking about was to change model.save() to do something special for onetoone's where it would,instead of creating a parent, associate itself to an existing parent that matches what it's actual parent would be. Upon finding a parent that already has a child, it would die. This one also sounds a bit forced to. And it sounds like there's a whole list of complications that would come attached to that which would make it one hairy thing to deal with. Any other ideas? I'm currently unaware of any elegant solutions. On Thu, May 8, 2008 at 9:53 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On Fri, May 9, 2008 at 7:17 AM, Ziling Zhao <[EMAIL PROTECTED]> wrote: > > I filled a bug here about multi-table inheritance problems and fixtures: > > http://code.djangoproject.com/ticket/7202 > > > > In the case that it is valid, I decided to look through the core code to > see > > where a fix could be placed. > > I've looked through it for a bit and it seems like it makes the most > sense > > in .save() but I'm unsure of that. > > > > Does fixing it in model.save() makes the most sense? > > It depends on exactly what the problem is. I haven't looked into the > problem in detail, but I'd be surprised if the solution lies in > model.save(). > > You have encountered this problem as part of the deserialization > process. The only way that the solution will lie in model.save() is if > you have found a problem with model saving itself - i.e., the problem > isn't with deserialization, but with the way models are saved. The > test for this - is it possible to generate this error _without_ using > loaddata? Can you stimulate the same error with normal > "object.property = foo; object.save()" calls? > > If the answer is yes, then the solution may lie in model.save(). > Otherwise, you'll be looking in the deserializer (or serializer) for > the solution. > > Yours, > Russ Magee %-) > > > > -- ~Ziling Zhao --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Callable context variables do not get called during resolution.
Short version:
Callable context variables do not get called during resolution. If
invoked as a simple variable they return something like . If used in a for loop, they blow up the template. I'm
running trunk:7374
Longer version:
In order to delay a *very* expensive DB operation, I decided to put it
in a function and pass the function as a context variable. The
template uses fragment caching with vary_on, so only if the template
fragment is stale would the function be called and invoke the heavy
lifting.
Sounded great to me ... but it blows up with a 500 error.
Simple example:
=
def some_view(request):
def foo():
return [1, 2, 3]
return render_to_response('some_template.html', {'foo': foo, })
some_template.html:
{{foo}} ==>> yields
{% for x in foo %}{{x}}{% endif %} ==>> 500 error
=
The problem seems to be in (or is related to)
template.__init__.Variable._resolve_lookup.
[...]
current = context
for bit in self.lookups:
try: # dictionary lookup
current = current[bit]
## the following fixed the problem (but needs error handling?)
if callable(current):
current = current()
##
except (TypeError, AttributeError, KeyError):
try: # attribute lookup
current = getattr(current, bit)
if callable(current):
if getattr(current, 'alters_data', False):
current =
settings.TEMPLATE_STRING_IF_INVALID
else:
try: # method call (assuming no args
required)
current = current()
[...]
Note there is a check for callable, but only if it's a method. Is
there some reason why callability is OK in some context variables/
expressions and not others?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Callable context variables do not get called during resolution.
BTW, I tried to add a comment on this to http://code.djangoproject.com/ticket/7153, but got "Internal Server Error (Submission rejected as potential spam)", which struck me as rather rude. :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Callable context variables do not get called during resolution.
On Saturday 10 May 2008 03:23:39 Peter Rowell wrote: > BTW, I tried to add a comment on this to > http://code.djangoproject.com/ticket/7153, but got "Internal Server Error > (Submission rejected as potential > spam)", which struck me as rather rude. :-) > I was just gonna point you to #7153. I don't know why it was decided only object methods should be called. I'm waiting for the review of the patch. Regards --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Callable context variables do not get called during resolution.
On Fri, May 9, 2008 at 8:12 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > [snip] > In order to delay a *very* expensive DB operation, I decided to put it > in a function and pass the function as a context variable. The > template uses fragment caching with vary_on, so only if the template > fragment is stale would the function be called and invoke the heavy > lifting. > [snip] QuearySets are lazy and, as I understand it, don't get evaluated until they are called in the template. Therefore, if a quearyset call is wrapped in an if statement in the template that evaluates to false, the query should never happen. What are you trying to accomplish that is any different? On Fri, May 9, 2008 at 8:23 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > > BTW, I tried to add a comment on this to > http://code.djangoproject.com/ticket/7153, > but got "Internal Server Error (Submission rejected as potential > spam)", which struck me as rather rude. :-) > Well, spam littered tickets would be worse. It's the lesser of two evils. You can register [1] for an account and bypass the spam filter -- Or, if you don't what to register, create a session [2] to get the spam filter to go easy on you. [1]: http://www.djangoproject.com/accounts/register/ [2]: http://code.djangoproject.com/settings -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Callable context variables do not get called during resolution.
> QuerySets are lazy [...] What are you trying to accomplish that is any > different? I'm working around the fact that Django's templates can't take arguments. So I'm calling formatting functions which *do* take arguments, one of which is a QuerySet. Of course, I can't pass args to a function in the template system, so to avoid premature evaluation of the expensive large-query/format I'm currying the function and trying to pass *that* as a context variable. And that's when it hit the fan. After this site I swear I'm going with either Jinja2 or Mako templates. I'm all for not confusing non-programming designers with nasty programming concepts, but my very good designer runs screaming from the room when I try to teach her the simplest template things. Therefore, I'm the one having to deal with the crippled templating system. It's great to keep app-logic out of the templates, but Django makes a lot of *presentation logic* almost impossible (or extremely clumsy) to implement. "ifequal foo bar" instead of "if foo == bar"? With a different end tag? Can't combine and's and or's in a single if? Give me a break. Now that Malcolm has subclassable models working, my number one complaint is the templating system. Number two is single DB, but I can work around that more easily. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Callable context variables do not get called during resolution.
On Fri, May 9, 2008 at 9:01 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > Now that Malcolm has subclassable models working, my number one > complaint is the templating system. Number two is single DB, but I can > work around that more easily. You probably should take a look at the ORM code. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Callable context variables do not get called during resolution.
> You probably should take a look at the ORM code. OK, I'll bite. I kind of doubt he rewrote the templating system in the ORM, so you must be inferring that multiple database support was part of the qs-refactoring. I just checked out trunk and I'll admit I'm working with a one-beer-handicap at the moment, but nothing jumped out and said "MULTIPLE DATABASE SUPPORT!!!" Please, make my day. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Callable context variables do not get called during resolution.
On Fri, May 9, 2008 at 9:27 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > OK, I'll bite. I kind of doubt he rewrote the templating system in the > ORM, so you must be inferring that multiple database support was part > of the qs-refactoring. I just checked out trunk and I'll admit I'm > working with a one-beer-handicap at the moment, but nothing jumped out > and said "MULTIPLE DATABASE SUPPORT!!!" Once again, there's no high-level support, but qsrf added some infrastructure which will make an eventual high-level implementation easier, and which makes writing a manual implementation right now a bit less tedious. Look at the constructor of django.db.models.sql.query.Query for the "connection" argument. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Callable context variables do not get called during resolution.
> Look at the constructor of django.db.models.sql.query.Query for the > "connection" argument. You know, I grepped on that but didn't see anything interesting. Now with a two-beer-handicap, I'll go with Blanche DuBois -- Tomorrow is another day. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
UNIQUE in PK declaration of refactored OneToOneField
I notices that refactored OneToOneField creates artificial primary key as UNIQUE, whereas all other primary keys generated by Django omits such declaration, because it is inherent (at least on MySQL) Setting kwargs['unique'] = False in OneToOneField constructor supresses this, but I don know if there are no other dependencies... Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
DatabaseFeatures reflecting version of underying SQL server
Is there a way the DatabaseFeatures would supply different values for different versions of configured SQL server? Thanks, Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: On aggregates
Hello,
The choice of using Decimal was not mine but that of the modules that
connect to the backends (postgres in this case), and this is one of
the problems I am facing right now. Different backends return the
results in different formats (Postgres: Decimal, SQLite: float... etc)
I am looking into a way of normalizing the results to the same format.
The issue of the datastructure that represents the results is only one
part of the problem. Due to the inner representation of numbers and
other factors of the different backends, the numeric results might be
different, for example, postgres might return 34.7321987 while sqlite
returns something like 34.732211 (rounding differentely the results).
I believe we should not tamper with the results since we should trust
our backend calculations, but then the tests would pass depending on
the backend used (And this might even change according to tha
backend's versions but I haven't tried that).
I will look into this problem in depth and then write back when I come
up with some solutions.
On Thu, May 8, 2008 at 10:51 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> I haven't had a ton of time to look over everything(just read the
> tests so far), but why did you choose to return things as decimals in
> place of a float?
>
> On May 8, 4:38 pm, "Nicolas E. Lara G." <[EMAIL PROTECTED]> wrote:
>> For those that are interested the aggregation project is hosted
>> inhttp://code.google.com/p/django-aggregation/
>>
>> The code is basically an up to date copy of trunk patched with the
>> aggregation support and the relevant tests and doc.
>>
>> Currently there is support for both aggregate and annotate on the
>> simplest level. Some tests might be found under tests/modeltests/
>> aggregation/ of the current state of the project. They can probably do
>> as documentaion in the early stages of the project (i.e. now :p )
>>
>> Any comments or sugestions are more than welcome! :-)
>>
>> Nicolas
> >
>
--
Nicolas Lara
Linux user #380134
Public key id: 0x152e7713 at http://keyserver.noreply.org/
# Anti-Spam e-mail addresses:
python -c "print '@'.join(['nicolaslara', '.'.join([x for x in
reversed( 'com|gmail'.split('|') )])])"
python -c "print '@'.join(['nicolas', '.'.join([x for x in reversed(
've|usb|labf|ac'.split('|') )])])"
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: On aggregates
It is not possible yet. But it will after the first stage (basic
stuff) is working correctely.
A great help would be, as Russell suggests, providing some complex
cases of aggregates (the actual plain english problems that want to be
solved with aggregates) so we can see if the proposed functionalities
adapt well to our needs
On Thu, May 8, 2008 at 10:56 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> And a second question, does filtering on an annotated field work, for
> example:
> Tag.objects.all().annotate(num_articles=Count('articles')).filter(num_articles__gt=2)
> which return all tags who have more than 2 articles.
>
> On May 8, 4:51 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>> I haven't had a ton of time to look over everything(just read the
>> tests so far), but why did you choose to return things as decimals in
>> place of a float?
>>
>> On May 8, 4:38 pm, "Nicolas E. Lara G." <[EMAIL PROTECTED]> wrote:
>>
>> > For those that are interested the aggregation project is hosted
>> > inhttp://code.google.com/p/django-aggregation/
>>
>> > The code is basically an up to date copy of trunk patched with the
>> > aggregation support and the relevant tests and doc.
>>
>> > Currently there is support for both aggregate and annotate on the
>> > simplest level. Some tests might be found under tests/modeltests/
>> > aggregation/ of the current state of the project. They can probably do
>> > as documentaion in the early stages of the project (i.e. now :p )
>>
>> > Any comments or sugestions are more than welcome! :-)
>>
>> > Nicolas
>>
>>
> >
>
--
Nicolas Lara
Linux user #380134
Public key id: 0x152e7713 at http://keyserver.noreply.org/
# Anti-Spam e-mail addresses:
python -c "print '@'.join(['nicolaslara', '.'.join([x for x in
reversed( 'com|gmail'.split('|') )])])"
python -c "print '@'.join(['nicolas', '.'.join([x for x in reversed(
've|usb|labf|ac'.split('|') )])])"
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
