Re: Composite Fields

[Rock]

Malcolm,

I strongly concur with the proposed API. It looks like it can be used
to implement future RangeHash partitioning support. Consider:

I have a model to be partitioned that has an IntegerField that will
become the range partitioning value:

week = models.IntegerField() # 1 to 53 depending on the week of
creation

The hash partitioning value is a field that works precisely like "id":

hash_id = models.IntegerField( auto_everything=True ) # (I made
"auto_everything" up as I am not sure precisely what parameters I need
to set in order to make this happen.)

Now I can create my RangeHash partitioning primary key with a
compositeField:

range_hash = models.CompositeField( hash_id, week, primary_key=True )


What I am doing today for my partitioned models is to use the
automatically generated "id" field, but that looks dicey with the
CompositeField since you can't do this:

range_hash = models.CompositeField( id, week, primaryKey=True )

since "id" doesn't exist yet and, by designating this CompositeField
as the primary key, id won't be generated. Rather than try to special
case this situation, ensuring that I can create a field that works
precisely like "id" by hand and then using that seems to be the way to
go.

Rock


--~--~-~--~~~---~--~~
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: I want a pony: Django Cheeseshop

[Tarek]

Great mail !

This has to be published somewhere like Jacob is suggesting.

I'd like to react on the PyPI part:


On 15 sep, 04:52, Kevin Teague <[EMAIL PROTECTED]> wrote:
>
> PyPI
> -
>
> Everyone knows what this is (hopefully!). A small point to note is
> that it was originally called The Cheeseshop, there was a long thread
> started by people who didn't like the name, and it was renamed to PyPI
> and use of the name Cheeseshop is politely discouraged.
>
> While there is only one PyPI, tools that pull packages from here
> (easy_install and buildout) can easily pull from additional package
> repositories. These can be mirrors, local caches, private repos, or
> whatever. Creating your own repo is as easy as dropping a Python
> packaged .tar.gz file into a directory and exposing it using Apache's
> default directory views feature. There are also cool projects recently
> started such as z3c.pypimirror which lets you create a local PyPI
> mirror, but rather than mirror all 4+ GB of PyPI, it will only mirror
> packages *as you request them*, very cool and probably something that
> would be quite neat in a shared hosting environment.

As far as I know (and as I said to Andreas Jung when they created this
package during a sprint lately),
z3c.pypimirror is a *full* mirror. It doesn't allow  you to get only
some packages. It has a name filter,
so you can get for instance all package that starts with "foo." but
this is a non sense because this
package might have a "bar" package in its dependency, it won't grab
it.

So basically it is a rsync, and rsyncing 5 gigas is taking a bit of
time (I think they are taking care of this aspect now, I am not sure
though)

We developed before z3c.pypimirror a package called iw.eggproxy that
is a proxy that will simply get all the package
tools like easy_install or buildout are asking for. So if you work in
a zope environment  it will get only the package you work on.

>
> Django really needs to update their PyPI page - it hasn't been updated
> since 0.91! And it's not classified under the Frameworks::Django trove
> either:
>
> http://pypi.python.org/pypi/Django/
>
> As far as "flooding" PyPI with packages, Zope2+Zope3+Plone has 1,236
> packages on PyPI right now. There have been one or two grumbles about
> this (it would seem people will grumble about just about anything),
> but I'm pretty sure the consensus is if the number of packages becomes
> unwieldly, the solution is to improve PyPI itself and not "start more
> PyPIs".
>
> The only valid grumbles about heavy PyPI usage are: packages with
> really sparse classification and documentation, releasing -dev
> packages onto PyPI (don't do this!), and especially *don't remove a
> older packages* (really please, please don't do this!).
>
> Plone add-ons were released to the Plone Software Center before PyPI
> existed. Tarek Ziade has done awesome work at making it possible to
> seamlessly release Plone add-ons to both plone.org and PyPI. This way
> a package can have additional Plone-specific metadata, but still have
> a PyPI presence without creating a bunch of extra maintenance work for
> the add-on developer.

I tried to use PyPi software at first but it was hard to reuse.

I have created this PloneSoftwareCenter extension in order to be able

- to make plone.org accept eggs through distutils calls, like you said
(otherwise the products section of plone.org is doomed, facing pypi's
one)
- to run my own PyPI for private packages

But there's a very important point about this work: I don't want PyPI
to be a single point of failure. PyPI server is pretty robust,
but I don't want my developers to depend on it while they are working.

It happened in the past that we couldn't work because of that, because
zc.buildout grabs a myriad of eggs at pypi to build Plone,
and because we are building and upgrading buildouts all day long. (We
have mirrors and caches everywhere now ;) )

Our strategy for the future on this will be to be able to use
distutils/setuptools and zc.buildout with several packages indexes
(pypi, plone.org or any other), and
to push packages on several places and sometimes with extra metadata
like you said (plone.org will have a rating system)

I have changed Python 2.6 for that (http://tarekziade.wordpress.com/
2008/05/12/the-new-pypirc-format-in-python-distutils/) so you
can deal with several pypi-like servers and I have a patch in
setuptools that is pending, so easy_install can play with several
servers as well/

So basically, a developer will be able to push any package to any
server, and a tool like zc.buildout or easy_install
will be able to get a package from a list of pypi-enabled servers.
(and if one of them is down , the package might be in to another one)

So if you decide to deploy Django like zope, at pypi, I would
encourage you to set up your own community pypi-like server, like we
are going to do on plone.org.

The work done on python, setuptools, zc.buildout and Plone.org to make
this possible in Plone

Re: Inline formsets unique(_together) validation problems

[[EMAIL PROTECTED]]

I'll take a look at this, the reason the second part didn't go in
originally(yeah, we thought of it), was that it was considered to be
in a different scope then the rest of the work on unique validation.

On Sep 16, 7:14 am, mrts <[EMAIL PROTECTED]> wrote:
> A bug in 1.0 makes unique_together constraints fail at database level
> (resulting in exceptions) instead of being caught at form validation
> level.
>
> The bug is detailed inhttp://code.djangoproject.com/ticket/8882
>
> I expect that the model validation implementation problems Honza has
> are also related to this:http://code.djangoproject.com/ticket/6845#comment:30
>
> Another problem is the unique constraint -- if the inline formset
> contains several forms with an colliding unique field that does not
> yet exist in the db, validation fails as the uniqueness checks are
> done before saving them in bulk (i.e. no validation in between the
> individual forms).
>
> Before I dig into this deeper, is someone already working on this or
> does have an idea how to tackle this? Brosner?
--~--~-~--~~~---~--~~
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: I want a pony: Django Cheeseshop

[mrts]

On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-09-16 at 00:16 -0700, mrts wrote:
> > Let me try to wrap this up:
>
> > * there seems to be a general consensus that amending setuptools to
> > create Django-specific extensions is not required
> > * a separate repository is not required, apps should be published to
> > PyPi Famework :: Django category but a central site that tracks the
> > apps there to further classify, rate and enhance them would be useful
> > (like djangoplugables.com)
> > * app naming and namespace issues should be resolved (should all apps
> > have a django-prefix, the de facto standard? should they live in
> > django.apps namespace?)
>
> As others have pointed out, this isn't necessary and would be bad
> practice. Everybody should feel free to use whatever namespace they like
> to avoid clashes and so that we avoid lowering the quality of the Django
> brand (as soon as somebody installs a few low-quality "packages" and
> they misbehave in any way, it's going to be "Django is a pile of
> rubbish" because it's all coming from the Django namespace).

Another issue I have with this: we grab generic toplevel names like
"tagging", "registration" etc for apps that are coupled to Django.
Semantic names that clearly state the purpose of a package help to
make code more readable are of course good. But what if TurboGears
people want to name their tagging app "tagging" as well (instead of
Tasty as it's named now)? Ideally, I'd like to see code like this:

from djc import tagging # or `from django.apps import tagging`

def foo():
tagging.do_bar() # OK, at a glance I can see that this line
relates to tagging

instead of

import tasty # `import tasty as tagging` *can* be done, but oh well...

def foo():
tasty.do_bar() # What is tasty?! *Waste time for looking it up*
Aha, this line is for tagging


Also, there may be differences in toplevel generic `frobnicate`
(usable in Python in general) and `django.apps.frobnicate` (coupled to
Django and packaged as django-frobnicate) that adapts the former to
Django.
--~--~-~--~~~---~--~~
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: Proposal: Enhanced simple-tag decorator #1105

[Simon Willison]

On Sep 16, 1:03 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> This is a call to review ticket #1105. The proposed patch is fully
> functional, backwards-compatible and contains tests and 
> documentation.http://code.djangoproject.com/ticket/1105
>
> Currently it is not possible to access the context from within a
> simple_tag, and there is no "simple" way to create block tags. Both of
> these tasks imply using some boilerplate code to parse the tokens,
> manage variables, etc.

+1, I love it. I've been using this in my own projects for ages.

Cheers,

Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Proposal: installmedia command - A story for distributing media with apps

[Brian Beck]

Distributing media with apps could be a lot easier.  Currently this
requires copying or linking files manually (possibly each time the app
is updated), and this encourages developers to put CSS and JavaScript
inline in their templates.  I propose a management command to make
this easier:

$ python manage.py installmedia appname [appname ...]

The command is "dumb."  It goes like this:

- Read MEDIA_ROOT from settings.py.
- Look for a 'media' directory in the app.
- Copy or link everything in there to MEDIA_ROOT.

This simple command saves you quite a bit of typing.  Some
possibilities...

- Switches like --copy, --link, --overwrite, etc.
- Just like with templates, it could become best practice for apps to
have their media structured like so:
  media/
  media/appname/
  media/appname/css/
  ...
- Or in the simple case:
  media/
  media/css/appname.css
  media/css/appname.js

This should make it easier for apps to make assumptions about where
their media is located relative to MEDIA_URL (this is currently ad
hoc).  Thoughts?

--~--~-~--~~~---~--~~
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: Proposal for 1.1: Extend inclusion tag syntax to allow custom templates (#9093)

[Brian Beck]

On Sep 16, 8:37 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote:
> I don't think anyone will complain that they have to type less, as its
> still understandable. +1 for allow_override.

Changed to allow_override.  See patch #4 at: 
http://code.djangoproject.com/ticket/9093
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Install over old level produces mutant

[Karen Tracey]

We've had at least three people run into a problem (#9090) after installing
1.0 over an old level.  Now, we do document that before installing you
should remove any old level.  But I find the results when you don't rather
odd. It's not just old files renamed/deleted in the new level that wind up
being 'leftover' in the site-packages directory. Rather, some files that
exist in both levels, and changed between the two, are not updated by
install.  So you wind up with a mixture of 0.96.x and 1.0 level files, which
is pretty confusing and subject to odd failures.

Does anyone know if there is something we could do to prevent this
situation?  I'm not very familiar with Python installation procedures.  It
seems like it would be better, though, if our installer flat-out refused to
install over a pre-existing installation or offered to delete the
pre-existing install before continuing with the new install.  What's the
norm for Python packages?

Karen

--~--~-~--~~~---~--~~
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: Install over old level produces mutant

[[EMAIL PROTECTED]]

We could definately have it do the check pretty easily just by shoe
horning some stuff at the top of setup.py, actually offering to
uninstall might be more complicated, although it could probably be
done in the same way.

On Sep 16, 1:20 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> We've had at least three people run into a problem (#9090) after installing
> 1.0 over an old level.  Now, we do document that before installing you
> should remove any old level.  But I find the results when you don't rather
> odd. It's not just old files renamed/deleted in the new level that wind up
> being 'leftover' in the site-packages directory. Rather, some files that
> exist in both levels, and changed between the two, are not updated by
> install.  So you wind up with a mixture of 0.96.x and 1.0 level files, which
> is pretty confusing and subject to odd failures.
>
> Does anyone know if there is something we could do to prevent this
> situation?  I'm not very familiar with Python installation procedures.  It
> seems like it would be better, though, if our installer flat-out refused to
> install over a pre-existing installation or offered to delete the
> pre-existing install before continuing with the new install.  What's the
> norm for Python packages?
>
> Karen
--~--~-~--~~~---~--~~
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: Install over old level produces mutant [solved!]

[Steve Holden]

Karen Tracey wrote:
> We've had at least three people run into a problem (#9090) after
> installing 1.0 over an old level.  Now, we do document that before
> installing you should remove any old level.  But I find the results
> when you don't rather odd. It's not just old files renamed/deleted in
> the new level that wind up being 'leftover' in the site-packages
> directory. Rather, some files that exist in both levels, and changed
> between the two, are not updated by install.  So you wind up with a
> mixture of 0.96.x and 1.0 level files, which is pretty confusing and
> subject to odd failures.
>
> Does anyone know if there is something we could do to prevent this
> situation?  I'm not very familiar with Python installation
> procedures.  It seems like it would be better, though, if our
> installer flat-out refused to install over a pre-existing installation
> or offered to delete the pre-existing install before continuing with
> the new install.  What's the norm for Python packages?
>
> Karen
>

I suspect what's happening is that the install keeps the distribution
dates on the .py files, but that the people who see the problems have
installed (or at least recompiled) the older versions more recently, so
the interpreter doesn't require an overwrite of the 0.96 files.

I've just done an install of 1.0 on my Python 2.6 alpha2 distribution
and I see, for example, that .../django/views/static.py is dated
12/17/2007. In this case there wasn't a previous installation, so I
can't verify that the compilation won't take place if there's an
existing .pyc file. However I *did* verify that a clean re-install
(after deletion of the appropriate build subdirectories) did *not*
change the creation time of the .py file.

So the answer is to put another step in the build process that touches
all files before bundling them up for distribution. Obviously this is
best done outside the version control system.

regards
 Steve


--~--~-~--~~~---~--~~
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: Install over old level produces mutant [solved!]

[Steve Holden]

Steve Holden wrote:
[...]
> I've just done an install of 1.0 on my Python 2.6 alpha2 distribution
> and I see, for example, that .../django/views/static.py is dated
> 12/17/2007. In this case there wasn't a previous installation, so I
> can't verify that the compilation won't take place if there's an
> existing .pyc file. However I *did* verify that a clean re-install
> (after deletion of the appropriate build subdirectories) did *not*
> change the creation time of the .py file.

Sorry, that should have been ".pyc file".
> 
regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--~--~-~--~~~---~--~~
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: Admin area and user permissions bug?

[Ca-Phun Ung]

Martin Diers wrote:
> This is not a bug. It is how the permissions system works. So far as  
> the Admin goes, it is model granular, not row granular or field  
> granular, meaning that if you grant a user full access to the User  
> object, as you did, they can do anything to that table, including  
> change permission levels. The permissions system does not have the  
> concept of a hierarchy of permissions.
>
> Suggest you read the docs, and direct any questions to the users list:
> http://docs.djangoproject.com/en/dev/topics/auth/
>   
Thanks for the reply. I filed a bug report and got pretty much the same 
answer. I understand there is no support for granular permissions at the 
moment and this is something post-1.0. Though thinking logically most 
people will consider this a bug because by giving other users permission 
to add/edit other users you implicitly make them a superuser which means 
they also gain access to other area that should be restricted. I don't 
want to start a fight here and I am happy to wait for the granular 
permissions system to be set in place.

Btw, I posted this in the user list initially but was ignored, hence 
this list is the next best thing!

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

RFC: django.template refactoring (#7806)

[Johannes Dollinger]

Why should django.template be refactored? Filter and Variable parsing  
is inconsistent. Many ad hoc parsers in defaulttags are fragile.  
Whitespace handling is ungraceful.

The patch provided in #7806[1] splits __init__.py into separate  
modules[2] and introduces a TokenStream class that allows parsing of  
literals, vars (called lookups) and filter expressions.

Here's how it would work:

@register.tag
@uses_token_stream
def mytag(parser, bits):
 expr = bits.parse_expression(required=True)
 return MyNode(expr)

`uses_token_stream` replaces the Token argument to the parser  
function with a TokenStream object.
If the token is not fully parsed, a TemplateSyntaxError is raised.
For better examples, have a look at the patched version of  
`django.template.defaulttags`.


TokenStream API (first stab)

``def __init__(self, parser, source)``
parser: a django.template.compiler.Parser instance
source: a string or a django.template.compiler.Token instance

TokenStream tokenizes its source into "string_literal",  
"numeric_literal", "char", and "name" tokens, stored in self.tokens  
as (type, lexeme) pairs. Whitespace will be discarded.
You can "read" tokens via the following methods, the current position  
in self.tokens is maintained in self.offset.

A "char" token is a single character in ':|=,;<>!?%&@"\'/()[]{}`*+-'.  
A name is any sequence of characters that does contain neither "char"  
characters nor whitespace and is not a string or numeric literal.

 >>> TokenStream(parser, r'"quoted\" string"|filter:3.14 as  
name').tokens
[('string_literal', '"quoted\\" string"'), ('char', '|'), ('name',  
'filter'), ('char', ':'), ('numeric_literal', '3.14'), ('name',  
'as'), ('name', 'name')]
 >>> TokenStream(parser, r' "quoted\" string" | filter : 3.14  as  
name').tokens
[('string_literal', '"quoted\\" string"'), ('char', '|'), ('name',  
'filter'), ('char', ':'), ('numeric_literal', '3.14'), ('name',  
'as'), ('name', 'name')]

Low level API
-
``def pop(self)``
Returns a pair (tokentype, lexeme) and offset+=1; tokentype is one of  
"string_literal", "numeric_literal", "char", "name".

``def pop_lexem(self, match)``
Returns True and offset+=1 if the next token's lexeme equals `match`.  
Returns False otherwise.

``def pop_name(self)``
Returns the next token's lexeme and offset+=1 if its tokentype is  
"name". Returns None otherwise.

``def pushback(self)``
offset-=1


High level API
--
These methods raise TokenSyntaxError and leave offset untouched if  
the expected result cannot be parsed.
Each accepts a boolean required=False kwarg which turns  
TokenSyntaxErrors into TemplateSyntaxErrors if True.

``def parse_string(self, bare=False)``
Returns the value of the following string literal. If bare=True,  
unquoted strings will be accepted.

``def parse_int(self)``
Returns the value of the following numeric literal, if it is an int.

``def parse_value(self)``
Returns an Expression that evaluates the following literal, variable  
or translated value.

``def parse_expression(self)``
Returns an Expression that evaluates the following value or  
filterexpression.

``def parse_expression_list(self, minimum=0, maximum=None, count=None)``
Returns a list `e` of expressions; minimum <= len(e) <= maximum.  
count=n is a shortcut for minimum=maximum=n.


I'm unhappy with the naming of TokenStream and uses_token_stream  
(using_token_stream?). And I just noticed the english spelling of  
lexeme has a trailing "e".


[1] http://code.djangoproject.com/ticket/7806
[2] See [1] for details. Yes, this is orthogonal to the concern of  
the ticket. I gave up splitting the patch when I stumbled upon the  
first circular dependency issue - a half-assed effort - and decided  
it's not worth it.


--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Rajeev J Sebastian]

On Tue, Sep 16, 2008 at 9:56 PM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> Distributing media with apps could be a lot easier.  Currently this
> requires copying or linking files manually (possibly each time the app
> is updated), and this encourages developers to put CSS and JavaScript
> inline in their templates.  I propose a management command to make
> this easier:
>
> $ python manage.py installmedia appname [appname ...]

I have already implemented this in our in-house django-based
framework. If interested, I can provide it. As you said, it really
does make things very simple.

Regards
Rajeev J Sebastian

--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Erik Allik]

> I have already implemented this in our in-house django-based
> framework. If interested, I can provide it. As you said, it really
> does make things very simple.
>

Please do, I'd be interested even if it doesn't make it to the trunk.

Erik

--~--~-~--~~~---~--~~
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: Proposal: user-friendly API for multi-database support

[mengel]

On Sep 10, 12:53 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> For those who weren't at DjangoCon, here's the state of play with
> regards to multi-db support: Django actually supports multiple
> database connections right now: the Query class (in django/db/models/
> sql/query.py) accepts a connection argument to its constructor, and
> the QuerySet class (django/db/models/query.py) can be passed an
> optional Query instance - if you don't pass it one, it will create a
> Query that uses the default django.db.connection.

Hmm.. so to the first layer of the onion, that statement is true...
But now, how
does one get a custom connection?  Altnernate connection info  needs
to be
able to be  passed in to the DatabaseWrapper constructors, so that you
can
call them with different database information; and then when
BaseDatabaseWrapper.cursor() calls _cursor() it should pass in a
*copy* of
the global settings overridden with anything passed in as kwargs to
BaseDatabaseWrapper.__init__()
(which is already saved in self.options) .   That is,  instead of
def cursor(self):
from django.conf import settings
cursor = self._cursor(settings)
if settings.DEBUG:
return self.make_debug_cursor(cursor)
return cursor

We should do:

 def cursor(self):
from django.conf import settings
mysettings = settings.copy().update(self.options)
cursor = self._cursor(mysettings)
if settings.DEBUG:
return self.make_debug_cursor(cursor)
return cursor

And then we can do something like
 from django.db.backends.mysql.base import DatabaseWrapper as
OracleDatabaseWrapper
 myconnection =
OracleDatabaseWrapper(DATABASE_HOST='somwhere.example.com',
 
DATABASE_USER='tiger',

  ...

  )
   and then you could use myconnection in your Manager subclass, etc.

Anyhow, that seems to me like it is a stab at addressing the simple
"some
model classes talk to a different database" approach. One could
make a
ManagerWithAlternateConnection class that is a subclass of Manager and
takes a
database connection as a parameter and does that.
--~--~-~--~~~---~--~~
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: RFC: django.template refactoring (#7806)

[Brian Beck]

On Sep 16, 2:36 pm, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> Why should django.template be refactored? Filter and Variable parsing
> is inconsistent. Many ad hoc parsers in defaulttags are fragile.
> Whitespace handling is ungraceful.
>
> The patch provided in #7806[1] splits __init__.py into separate
> modules[2] and introduces a TokenStream class that allows parsing of
> literals, vars (called lookups) and filter expressions.

Regardless of how it happens, I did notice when writing a patch for
#9093 that django.template really could use some refactoring. +1
--~--~-~--~~~---~--~~
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: [Fwd: Documentation: Google-foo lost]

[Don Spaulding]

On Mon, Sep 15, 2008 at 10:29 PM, Russell Keith-Magee <
[EMAIL PROTECTED]> wrote:

>
> It would be
> fantastic if such a mapping existed, and I don't think you'd get any
> objections from the core developers if such a mapping were to
> magically materialize.
>

poof!

I took a shot at finding redirects for the top 50 results on google for
site:djangoproject.com/documentation/ that weren't 0.9x specific.  Most were
fairly obvious, so I dropped them into a text file that's formatted similar
to
http://code.djangoproject.com/browser/djangoproject.com/django_website/apps/docs/urls.py.
 There's two that I wasn't sure about:

/documentation/models/many_to_one/ :
http://docs.djangoproject.com/en/dev/topics/db/models/  OR
http://docs.djangoproject.com/en/dev/topics/db/queries/
/documentation/admin_css/:
http://docs.djangoproject.com/en/dev/obsolete/admin-css/  OR
http://docs.djangoproject.com/en/dev/faq/admin/

Hope it's useful!

Don

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

(r'^contenttypes/$',   
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/')),
(r'^pagination/$', 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/pagination/')),
(r'^i18n/$',   
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/i18n/')),
(r'^shortcuts/$',  
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/http/shortcuts/')),
(r'^distributions/$',  
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/misc/distributions/')),
(r'^form_wizard/$',
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/')),
(r'^tutorial02/$', 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial02/')),
(r'^testing/$',
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/testing/')),
(r'^databases/$',  
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/databases/')),
(r'^outputting_pdf/$', 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/outputting-pdf/')),
(r'^files/$',  
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/files/')),
(r'^tutorial04/$', 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial04/')),
(r'^modelforms/$', 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/forms/modelforms/')),
(r'^unicode/$',
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/unicode/')),
(r'^authentication/$', 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/auth/')),
(r'^fastcgi/$',
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/deployment/fastcgi/')),
(r'^transactions/$',   
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/db/transactions/')),
(r'^api_stability/$',  
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/misc/api-stability/')),
(r'^upload_handling/$',
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/http/file-uploads/')),
(r'^faq/$',
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/faq/')),
(r'^serialization/$',  
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/serialization/')),
(r'^models/$', 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/db/models/')),
(r'^redirects/$',  
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/redirects/')),
(r'^databrowse/$', 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/')),
(r'^tutorial03/$', 
Http

Re: [Fwd: Documentation: Google-foo lost]

[Don Spaulding]

On Tue, Sep 16, 2008 at 2:20 PM, Don Spaulding <[EMAIL PROTECTED]>wrote:

>
> Hope it's useful!
>


and of course it isn't.  I forgot my lambdas.  Doh!

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

(r'^contenttypes/$',   lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/')),
(r'^pagination/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/pagination/')),
(r'^i18n/$',   lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/i18n/')),
(r'^shortcuts/$',  lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/http/shortcuts/')),
(r'^distributions/$',  lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/misc/distributions/')),
(r'^form_wizard/$',lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/')),
(r'^tutorial02/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial02/')),
(r'^testing/$',lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/testing/')),
(r'^databases/$',  lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/databases/')),
(r'^outputting_pdf/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/outputting-pdf/')),
(r'^files/$',  lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/files/')),
(r'^tutorial04/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial04/')),
(r'^modelforms/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/forms/modelforms/')),
(r'^unicode/$',lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/unicode/')),
(r'^authentication/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/auth/')),
(r'^fastcgi/$',lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/deployment/fastcgi/')),
(r'^transactions/$',   lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/db/transactions/')),
(r'^api_stability/$',  lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/misc/api-stability/')),
(r'^upload_handling/$',lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/http/file-uploads/')),
(r'^faq/$',lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/faq/')),
(r'^serialization/$',  lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/serialization/')),
(r'^models/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/db/models/')),
(r'^redirects/$',  lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/redirects/')),
(r'^databrowse/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/')),
(r'^tutorial03/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial03/')),
(r'^tutorial01/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial01/')),
(r'^legacy_databases/$',   lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/legacy-databases/')),
(r'^outputting_csv/$', lambda r: 
HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/o

Re: Composite Fields

[David Cramer]

I think that will work Malcom. One thing we'll need to deal with,
is .name, .attname, etc on these. It should act the same way on the pk
as it does on the multi-column field (because after all, this will be
just a wrapper). Right now .pks is just an alias for .pk.as_tuple or
something. I had it throwing errors if you tried accessing .pk.name if
there were multiple fields in it, as name is the field name, and the
field name becomes multiple.

I will post up what I have done later tonight.

On Sep 16, 9:36 am, Rock <[EMAIL PROTECTED]> wrote:
> Malcolm,
>
> I strongly concur with the proposed API. It looks like it can be used
> to implement future RangeHash partitioning support. Consider:
>
> I have a model to be partitioned that has an IntegerField that will
> become the range partitioning value:
>
> week = models.IntegerField() # 1 to 53 depending on the week of
> creation
>
> The hash partitioning value is a field that works precisely like "id":
>
> hash_id = models.IntegerField( auto_everything=True ) # (I made
> "auto_everything" up as I am not sure precisely what parameters I need
> to set in order to make this happen.)
>
> Now I can create my RangeHash partitioning primary key with a
> compositeField:
>
> range_hash = models.CompositeField( hash_id, week, primary_key=True )
>
> What I am doing today for my partitioned models is to use the
> automatically generated "id" field, but that looks dicey with the
> CompositeField since you can't do this:
>
> range_hash = models.CompositeField( id, week, primaryKey=True )
>
> since "id" doesn't exist yet and, by designating this CompositeField
> as the primary key, id won't be generated. Rather than try to special
> case this situation, ensuring that I can create a field that works
> precisely like "id" by hand and then using that seems to be the way to
> go.
>
> Rock
--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Ivan Sagalaev]

Brian Beck wrote:
> Distributing media with apps could be a lot easier.  Currently this
> requires copying or linking files manually (possibly each time the app
> is updated), and this encourages developers to put CSS and JavaScript
> inline in their templates.  I propose a management command to make
> this easier:
> 
> $ python manage.py installmedia appname [appname ...]

Oh, yes! I was trying to invent some way to distribute media (apart from 
documenting copying it in a README) but with no luck. Yet your solution 
is so simple and beautiful!

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

incorrect field type for object_pk in contrib.comments?

[smcoll]

Looking at contrib.comments admin, i noted that the Object ID input is
a textarea.  i thought that was strange, since i expceted an input
(type="text").  Turns out, in the model, this is a TextField, rather
than a CharField.  
http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/models.py#L23
Is there a reason this should be a TextField, or is that a mistake?

--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Don Spaulding]

On Tue, Sep 16, 2008 at 11:26 AM, Brian Beck <[EMAIL PROTECTED]> wrote:

>
> $ python manage.py installmedia appname [appname ...]
>
> The command is "dumb."..


Could it be a little smarter, and in the absence of specific apps, iterate
over all INSTALLED_APPS, and install their media automagically?

--~--~-~--~~~---~--~~
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: Install over old level produces mutant

[Fredrik Lundh]

Karen Tracey wrote:

> We've had at least three people run into a problem (#9090) after 
> installing 1.0 over an old level.  Now, we do document that before 
> installing you should remove any old level.  But I find the results when 
> you don't rather odd. It's not just old files renamed/deleted in the new 
> level that wind up being 'leftover' in the site-packages directory. 
> Rather, some files that exist in both levels, and changed between the 
> two, are not updated by install.  So you wind up with a mixture of 
> 0.96.x and 1.0 level files, which is pretty confusing and subject to odd 
> failures.

does that apply to PY files, or is it just that you may have PYC files 
from 0.96.x but PY files from 1.0?   (Python only looks at the timestamp 
when deciding whether to recompile a PY file, so if your PYC files for 
0.96.x were created later than the corresponding 1.0 file, Python will 
pick up the wrong file).

is the installer you're referring to here "setup.py", or something else?




--~--~-~--~~~---~--~~
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: Install over old level produces mutant

[Steve Holden]

Fredrik Lundh wrote:
> Karen Tracey wrote:
>
>   
>> We've had at least three people run into a problem (#9090) after 
>> installing 1.0 over an old level.  Now, we do document that before 
>> installing you should remove any old level.  But I find the results when 
>> you don't rather odd. It's not just old files renamed/deleted in the new 
>> level that wind up being 'leftover' in the site-packages directory. 
>> Rather, some files that exist in both levels, and changed between the 
>> two, are not updated by install.  So you wind up with a mixture of 
>> 0.96.x and 1.0 level files, which is pretty confusing and subject to odd 
>> failures.
>> 
>
> does that apply to PY files, or is it just that you may have PYC files 
> from 0.96.x but PY files from 1.0?   (Python only looks at the timestamp 
> when deciding whether to recompile a PY file, so if your PYC files for 
> 0.96.x were created later than the corresponding 1.0 file, Python will 
> pick up the wrong file).
>
> is the installer you're referring to here "setup.py", or something else?
>
>   
See ticket #9112 for a purported explanation.

regards
 Steve


--~--~-~--~~~---~--~~
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: incorrect field type for object_pk in contrib.comments?

[[EMAIL PROTECTED]]

It's intentional, usually you see an object_pk as an integer field,
however that means it won't work with any field with a custom primary
key, specifically those with string type pks.  And a textfield offers
the flexibility to work with all of those.

On Sep 16, 3:42 pm, smcoll <[EMAIL PROTECTED]> wrote:
> Looking at contrib.comments admin, i noted that the Object ID input is
> a textarea.  i thought that was strange, since i expceted an input
> (type="text").  Turns out, in the model, this is a TextField, rather
> than a CharField.  
> http://code.djangoproject.com/browser/django/trunk/django/contrib/com...
> Is there a reason this should be a TextField, or is that a mistake?
--~--~-~--~~~---~--~~
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: Install over old level produces mutant

[Karen Tracey]

On Tue, Sep 16, 2008 at 5:23 PM, Steve Holden <[EMAIL PROTECTED]> wrote:

>
> Fredrik Lundh wrote:
> > Karen Tracey wrote:
> >
> >
> >> We've had at least three people run into a problem (#9090) after
> >> installing 1.0 over an old level.  Now, we do document that before
> >> installing you should remove any old level.  But I find the results when
> >> you don't rather odd. It's not just old files renamed/deleted in the new
> >> level that wind up being 'leftover' in the site-packages directory.
> >> Rather, some files that exist in both levels, and changed between the
> >> two, are not updated by install.  So you wind up with a mixture of
> >> 0.96.x and 1.0 level files, which is pretty confusing and subject to odd
> >> failures.
> >>
> >
> > does that apply to PY files, or is it just that you may have PYC files
> > from 0.96.x but PY files from 1.0?   (Python only looks at the timestamp
> > when deciding whether to recompile a PY file, so if your PYC files for
> > 0.96.x were created later than the corresponding 1.0 file, Python will
> > pick up the wrong file).
> >
> > is the installer you're referring to here "setup.py", or something else?
> >
> >
> See ticket #9112 for a purported explanation.
>
>
I do not believe the description/explanation in that ticket is correct.  It
says the new .py files will be copied but .pyc files will not be created,
which is not what I have observed.  What I have seen is that new .py files
are not copied at all.  The tree is left with a mixture of old and new .py
files.  (And to answer Fredrik's question yes, I'm talking about 'setup.py
install'.)

It does seem to have been caused by inconsistent file dating during the
release process over time.  One problematic file is django/utils/dates.py.
This file was last modified in SVN on 7/4/2007 at 8:11AM, and that is the
date/time on the file when extracted from the 1.0 release tar file.

However, going back to the 0.96.2 tarball, the date on its
django/utils/dates.py file is 10/29/2007.  I'm not sure where that date came
from.  0.96.2 was announced on django-announce on 5/14/2008, so it's not
when 0.96.2 came out.  The actual revision level for the file is [2912],
which was checked in on 5/16/06.  And there's the problem -- it's an earlier
level of the file than what's in 1.0, but it appears based on the date to be
more recent.

Going back to the 0.96.1 tarball (yes I'm a packrat), the date on its
django/utils/dates.py is 10/26/2007, which is the same date as 0.96.1 was
announced.

So the problem seems to be that some of the older tar files for releases
used tar file creation date (or ? since I'm not sure about the 0.96.2 one)
for files contained in the release, while 1.0 somehow put last-modified in
SVN dates on the files (I didn't know SVN would even do that, actually).
Seems it would be safer to use tarfile creation date always.

That still leaves potential problems for people doing install-overs.  Old
files that have been renamed/deleted won't get deleted, and that can cause
problems.  Even though we say you should first delete old levels, and even
if the release process is adjusted to fix up the dates, I think it would be
a good idea to refuse to install if an old level is detected.

Karen

--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Julien Phalip]

On Sep 17, 7:09 am, "Don Spaulding" <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at 11:26 AM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> > $ python manage.py installmedia appname [appname ...]
>
> > The command is "dumb."..
>
> Could it be a little smarter, and in the absence of specific apps, iterate
> over all INSTALLED_APPS, and install their media automagically?

+1 for some sort of media.autodiscover().
It would have to be optional though, as that might break backwards-
compatibility.

Also, there's an issue about the way files are served. For example, in
my projects I make Apache serve 'admin_media' files independently.
What would be an approach to make that serving configuration happen
for custom apps?
--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Brian Beck]

On Sep 16, 6:29 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> > Could it be a little smarter, and in the absence of specific apps, iterate
> > over all INSTALLED_APPS, and install their media automagically?
>
> +1 for some sort of media.autodiscover().
> It would have to be optional though, as that might break backwards-
> compatibility.

I think he meant making "python manage.py installmedia" (no app names
provided) install media for all INSTALLED_APPS, not something that
will happen without running any commands -- so no backwards-
compatibility will be affected.  And I agree with Don's idea.

> Also, there's an issue about the way files are served. For example, in
> my projects I make Apache serve 'admin_media' files independently.
> What would be an approach to make that serving configuration happen
> for custom apps?

Serving is totally orthogonal -- everyone is already serving up
MEDIA_ROOT in their projects somehow anyway, and this just copies
files to MEDIA_ROOT.
--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Brian Beck]

On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> Serving is totally orthogonal -- everyone is already serving up
> MEDIA_ROOT in their projects somehow anyway, and this just copies
> files to MEDIA_ROOT.

Sorry, I guess that's not totally true -- everyone who uses more than
just the admin app has set up static file serving for MEDIA_ROOT.
--~--~-~--~~~---~--~~
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: I want a pony: Django Cheeseshop

[Malcolm Tredinnick]

On Tue, 2008-09-16 at 05:06 -0700, mrts wrote:
> Both of these arguments are valid, but will not help to resolve the
> problem: smooth experience in distributing and using pluggable
> applications and some order in the current chaos.
> 
> On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > On Tue, 2008-09-16 at 00:16 -0700, mrts wrote:
> > > Let me try to wrap this up:
> >
> > > * there seems to be a general consensus that amending setuptools to
> > > create Django-specific extensions is not required
> > > * a separate repository is not required, apps should be published to
> > > PyPi Famework :: Django category but a central site that tracks the
> > > apps there to further classify, rate and enhance them would be useful
> > > (like djangoplugables.com)
> > > * app naming and namespace issues should be resolved (should all apps
> > > have a django-prefix, the de facto standard? should they live in
> > > django.apps namespace?)
> >
> > As others have pointed out, this isn't necessary and would be bad
> > practice. Everybody should feel free to use whatever namespace they like
> > to avoid clashes and so that we avoid lowering the quality of the Django
> > brand (as soon as somebody installs a few low-quality "packages" and
> > they misbehave in any way, it's going to be "Django is a pile of
> > rubbish" because it's all coming from the Django namespace).
> 
> Lets not use the `django` namespace then -- `djangoapps`, `djc` (as
> django community, mimicking z3c), whatnot. Do you think the
> introspection and media arguments are irrelevant? These would provide
> practical gain apart from the general feel of coherence I'm trying to
> advocate.
> 
> As for coherence: standardized toplevel namespace would help to
> discern at a glance which bits of a project are Django-related and
> which are not, just by looking at the imports in a .py. Everybody
> should feel free to use whatever namespace or namespace hierarchy they
> like *under* that namespace.
> 
> As for the brand, the existing practice for naming packaged Django
> apps is to use the 'django-' prefix anyway. Should that be discouraged
> (which doesn't sound good to me)?
> 
> > > * dependencies should be handled with setuptools facilities
> >
> > As an option, only. This can't be a requirement, since setuptools will
> > often download random stuff from the internet, doesn't support signed
> > packages as a rule, doesn't integrate well with existing packaging
> > systems such as rpm and apt (which includes the fact that it downloads
> > random extra stuff without asking) and doesn't make it easy to validate
> > the source code at a later date. In other words, it's insecure by design
> > and therefore inappropriate for large system installs. People might be
> > happy to use it on their laptops or whatever, but a lot of system
> > administrators should rightly feel very nervous about using setuptools.
> 
> apt and rpm don't mix with project-specific packages and versioning
> (virtualenv/buildout). It is just not feasible (or even possible if
> something is built against django-0.96 and something else against
> django-1.0)

Don't tell that to my laptop and some systems I admin which have
completely parallel installation of Python 2.4 and everything else I
need to do Plone work, all managed by rpms, then. They don't like being
told that what they're doing is apparently impossible. :-)

Yes, it doesn't work trivially with virtualenv, but so what? It's not
part of the use-case of virtualenv and buildout which are targeted at an
different audience and use-case. Sandboxed development environments have
been in use for years and they work very well when you're developing.
They're also not how you deploy things to dozens of machines at once in
a very large installation. At that point you use the sandboxed
environment to build packages that work with the system they're being
installed on and which install in parallel. Not every sandbox
environment is designed to do that and that is fine.

>  to dump everything into the global package space if you
> have diverse projects hosted on a single server.
> 
> setuptools is a necessary evil for the agile developer who frequently
> tracks updates for the bits he relies upon. Hopefully it will be
> improved (the clamor around it is ever-ongoing), but unless we want to
> do it ourselves, we have to accept the state of things.

Wow. You just said we should entirely ditch security because it isn't
convenient. That's exactly the attitude that has made Microsoft the
laughing stock of the professional IT community for the last 15 years.

If my original mail had said "nobody should ever use setup tools" or
anything like that, you reply might be valid. Go back and read it. I
said "optional", not "forbidden". There are multiple audiences here. If
Django ever had a hard dependency on setuptools for using third-party
packages it would make it very difficult for system administrators to
use Django because of the large le

Re: Special case: DateTimeField and SplitDateTimeWidget

[Tai Lee]

I've just had another thought. With `SplitDateTimeWidget` validation
coupled to `DateTimeField`, it's no longer easy to subclass
`DateTimeField` for use with your own `MultiValueWidget`. When you
call `super` for the DateTimeField validation, it will run
`DateTimeField.clean` which will return an invalid error if your own
widget doesn't return date and time in two parts. The user would have
to re-write the entire `DateTimeField.clean` method, but *without* the
`SplitDateTimeWidget` validation.

Even more so now I think this validation should be de-coupled from
`DateTimeField`.


--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Julien Phalip]

On Sep 17, 8:49 am, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> > Serving is totally orthogonal -- everyone is already serving up
> > MEDIA_ROOT in their projects somehow anyway, and this just copies
> > files to MEDIA_ROOT.
>
> Sorry, I guess that's not totally true -- everyone who uses more than
> just the admin app has set up static file serving for MEDIA_ROOT.

I really like the idea. However, I think there should also be a way to
configure it to not copy to MEDIA_ROOT but to somewhere else.

It would also be good to get that deployment system play nicely with
custom file storage (if you're hosting your media on S3 for example).

Also, instead of just copying the media files, it should also do some
cleanup. Say, if you're tracking trunk for a given app, when you SVN
update that app you want stale media files to be removed.

Just some thoughts.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

bug in forms

[Diego Andrés Sanabria Martin (diegueus9)]

Hi,

I find a bug in forms of django, i know i have report a ticket but the
bug is very small,
in the file django/forms/models.py in line 236:
if name in self.cleaned_data and f.unique and not is_null_pk:
and in the doc, the variable self.cleaned is now self.clean_data

thanks

-- 
Diego Andrés Sanabria
Ingeniería de Sistemas Universidad Distrital
blog trágico mágico cómico musical: http://diegueus9.blogspot.com
blog geek: http://pyautoservicio.blogspot.com
cel 3015290609

http://www.el-directorio.org/Diegueus9
El sitio de linux y el Software Libre en Colombia

"Hay pecados cuya fascinación está más en el recuerdo que en la
comisión de ellos." Oscar Wilde

--~--~-~--~~~---~--~~
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: bug in forms

[Collin Grady]

On Tue, Sep 16, 2008 at 4:27 PM, Diego Andrés Sanabria Martin
(diegueus9) <[EMAIL PROTECTED]> wrote:
> if name in self.cleaned_data and f.unique and not is_null_pk:
> and in the doc, the variable self.cleaned is now self.clean_data

You are incorrect. The variable was clean_data in 0.96 but changed to
cleaned_data shortly after to avoid conflicts with validation
functions for a field named "data" - you are reading old examples
and/or docs.

-- 
Collin Grady

--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Brian Beck]

On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I really like the idea. However, I think there should also be a way to
> configure it to not copy to MEDIA_ROOT but to somewhere else.

Sure - a --destination flag, defaulting to MEDIA_ROOT, would work.

> Also, instead of just copying the media files, it should also do some
> cleanup. Say, if you're tracking trunk for a given app, when you SVN
> update that app you want stale media files to be removed.

This is getting into package management system territory ;) -- this
problem is mostly solved by linking a directory instead of copying all
the files, which I think should be the default behavior (linking, not
copying).
--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Justin Lilly]

Not sure if you guys are aware, but this seems a very likely candidate
for django-exensions which extends manage.py like functionality.

http://code.google.com/p/django-command-extensions/

-justin

On Tue, Sep 16, 2008 at 7:22 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> On Sep 17, 8:49 am, Brian Beck <[EMAIL PROTECTED]> wrote:
>> On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>>
>> > Serving is totally orthogonal -- everyone is already serving up
>> > MEDIA_ROOT in their projects somehow anyway, and this just copies
>> > files to MEDIA_ROOT.
>>
>> Sorry, I guess that's not totally true -- everyone who uses more than
>> just the admin app has set up static file serving for MEDIA_ROOT.
>
> I really like the idea. However, I think there should also be a way to
> configure it to not copy to MEDIA_ROOT but to somewhere else.
>
> It would also be good to get that deployment system play nicely with
> custom file storage (if you're hosting your media on S3 for example).
>
> Also, instead of just copying the media files, it should also do some
> cleanup. Say, if you're tracking trunk for a given app, when you SVN
> update that app you want stale media files to be removed.
>
> Just some thoughts.
> >
>



-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.com

--~--~-~--~~~---~--~~
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: bug in forms

[Diego Andrés Sanabria Martin (diegueus9)]

i found this:
Changed in Django 1.0: The cleaned_data attribute was called
clean_data in earlier releases.

in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index

I make a mistake?

On Tue, Sep 16, 2008 at 18:29, Collin Grady <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at 4:27 PM, Diego Andrés Sanabria Martin
> (diegueus9) <[EMAIL PROTECTED]> wrote:
>> if name in self.cleaned_data and f.unique and not is_null_pk:
>> and in the doc, the variable self.cleaned is now self.clean_data
>
> You are incorrect. The variable was clean_data in 0.96 but changed to
> cleaned_data shortly after to avoid conflicts with validation
> functions for a field named "data" - you are reading old examples
> and/or docs.
>
> --
> Collin Grady
>
> >
>



-- 
Diego Andrés Sanabria
Ingeniería de Sistemas Universidad Distrital
blog trágico mágico cómico musical: http://diegueus9.blogspot.com
blog geek: http://pyautoservicio.blogspot.com
cel 3015290609

http://www.el-directorio.org/Diegueus9
El sitio de linux y el Software Libre en Colombia

"Hay pecados cuya fascinación está más en el recuerdo que en la
comisión de ellos." Oscar Wilde

--~--~-~--~~~---~--~~
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: bug in forms

[Collin Grady]

On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin
(diegueus9) <[EMAIL PROTECTED]> wrote:
> i found this:
> Changed in Django 1.0: The cleaned_data attribute was called
> clean_data in earlier releases.
>
> in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index
>
> I make a mistake?

That line also says what I said - it *used to be* clean_data in 0.96,
but it *is* cleaned_data now.

So if the line of code had clean_data, it would be wrong, but it has
cleaned_data, so it is right.

-- 
Collin Grady

--~--~-~--~~~---~--~~
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: RFC: django.template refactoring (#7806)

[Malcolm Tredinnick]

On Tue, 2008-09-16 at 20:36 +0200, Johannes Dollinger wrote:
> Why should django.template be refactored? Filter and Variable parsing  
> is inconsistent. Many ad hoc parsers in defaulttags are fragile.  
> Whitespace handling is ungraceful.
> 
> The patch provided in #7806[1] splits __init__.py into separate  
> modules[2] and introduces a TokenStream class that allows parsing of  
> literals, vars (called lookups) and filter expressions.

As was pointed out the first time you brought this up, keep in mind that
there still need to be ways to manually control the lexing phase. Not
every template tag has the same requirements there.

Also, since the Variable class is part of the public API (we document
how to write custom template tags), you need to preserve backwards
compatibility. For example, anything written according to
custom-template-tags.txt should continue to work unchanged. There are
possibly some reasonable other methods in template/__init__.py that
should continue to remain available as well.

That being said, I'm completely in favour of a bit of shuffling in those
files to make things easier to understand and fix a bunch of little
inconsistencies. However, I'd encourage doing it in slightly smaller
steps than the original patches I read so that we can see that backwards
compatibility is maintained and do the smallest number of changes
necessary to tidy things up. Basically, keep the refactoring and the
feature/API addition portions distinct.

For example, it's useful (and necessary) to make the Variable class be a
lot more consistent with respect to also resolving the effect of apply
filters to variables (right now, anything using Variable doesn't have
filter effects applied, which was probably just an oversight
originally).

Helper methods that make it easy for the common cases to say "I expect
three paramters matching the 'x y as z' pattern where x and z are
strings and y must be an integer" would be very handy. This is where
method like your parse_int and parse_string methods are additions that
would be useful. Things like parse_expression is probably overkill for a
high-level API, since resolving the effect of filters should really just
be a natural part of Variable.resolve_context(). I'm not sure I see the
use-case at the moment for parse_expression; perhaps you could elaborate
with an example.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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: Recursive inlines in admin?

[James Smagala]

Hey All,

First off, I am a relatively new Django user, and certainly not a
developer at this point, and most of this post is pure speculation.
With that disclaimer, I'll share my situation and opinion:

>From DoctorMO:
> Well I've seen far more normalised models that don't match how simple
> data entry people's minds expect the forms to be presented. Binding
> them back together using in-lines is one method of having a complex
> set of models editable as one entry form.

This is exactly the problem that I am running into right at the
moment.  My data entry people will pitch a fit if I make them use the
current setup, which would require at least two levels for my site,
with very awkward transitions (save this object, go add a related
object, search for the first object using a raw id lookup, then
finally edit the related inlines).  This is painful.  But...

>From Adrian:
> This has come up a number of times over the years, and I still haven't
> wrapped my head around why somebody would need this functionality...
> Surely one could just use the "standard" admin for the third-level
> objects, then use two-level inlines for the first- and second-level
> objects?

I started writing a long email about why I want this functionality,
then changed my mind.  Adrian's 'just use the standard admin' response
would get me *very* close to what I want, with just a few
enhancements.  Here's how:

I just watched to 'I want a pony' session from DjangoCon, and I
noticed two points that fit this discussion:

1. Raw ids are 'too raw'.  Let's do some sort of search/select instead
of a drop down.

2. Databrowse is cool, but outdated.  Databrowse integrated into Admin
would kick ass.

I'll add one more:

3. With the Admin refactor, it should be easy to create *both* an
inline *and* a stand-alone admin object for the same model, and
register both.

I'm assuming you have a layout something like this (a simplified look
at my database layout):

A <-- B <-- [X, Y, Z]

A is your main table, B has a few entries for each A, and X, Y and Z
all point B.  I *think* this will generalize pretty nicely, but I
haven't thought my way through any really complicated relations yet.

---

My proposal is this.  The cool thing databrowse does is link between
related objects.  To get databrowse-like functionality with only a
little work, do this:

1. Implement an option to search/select in place of raw ids or drop-
down/select on the stand-alone admin.

While I'm not much of a UI guy, it seems to me that I can already have
most of the search functionality I need set up in the Admin site for
my related object.  So, keep the raw id idea, but display a string
representation of the object instead of its id?

2. Create an Admin object for A, and inline B.  Also create a stand-
alone Admin object for B, and inline X, Y and Z.

3. If both inline and stand-alone Admin objects are registered for B,
add links from one to the other.

Text links would be fine, or a small go-to-this-object-arrow icon.

3a. If you don't register both admin objects, the link could instead
go to a typical databrowse page to let you look at the related object,
and what objects are related to it.

This is not critical for this discussion, but it does seem to be an
easy way to start integrating databrowse functionality into the admin.

---

Now my workflow looks like this:  Add an A, and add a B inline, save.
Now link to my newly created B, and edit X, Y and Z objects inline,
and save.  And if I'm creating a B in the stand-alone admin, I can
easily search for my related A, then navigate to that related object
by clicking a link.  This is the visual equivalent of the way that
Django's query API works.

This would mean I could train my users to save the first object, then
follow a link.  That's a pretty easy thing to do, and it is
significantly less painful than the first workflow I described using
the current admin setup.

How hard would this actually be to accomplish?  Are there any glaring
errors in my thinking?  Complex relationships that hose the whole
idea?

James

--~--~-~--~~~---~--~~
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: bug in forms

[Diego Andrés Sanabria Martin (diegueus9)]

sorry, you have reason, my english is bad and i am tired, but i have this error:
>>> form.clean()
Traceback (most recent call last):
  File "", line 1, in ?
  File "/home/felipecastel/django1.0_src/django/forms/models.py", line
208, in clean
self.validate_unique()
  File "/home/felipecastel/django1.0_src/django/forms/models.py", line
236, in validate_unique
if name in self.cleaned_data and f.unique and not is_null_pk:
AttributeError: 'IdeaForm' object has no attribute 'cleaned_data'
>>>
and i read the doc over and over again and i cant use the forms.

On Tue, Sep 16, 2008 at 18:35, Collin Grady <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin
> (diegueus9) <[EMAIL PROTECTED]> wrote:
>> i found this:
>> Changed in Django 1.0: The cleaned_data attribute was called
>> clean_data in earlier releases.
>>
>> in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index
>>
>> I make a mistake?
>
> That line also says what I said - it *used to be* clean_data in 0.96,
> but it *is* cleaned_data now.
>
> So if the line of code had clean_data, it would be wrong, but it has
> cleaned_data, so it is right.
>
> --
> Collin Grady
>
> >
>



-- 
Diego Andrés Sanabria
Ingeniería de Sistemas Universidad Distrital
blog trágico mágico cómico musical: http://diegueus9.blogspot.com
blog geek: http://pyautoservicio.blogspot.com
cel 3015290609

http://www.el-directorio.org/Diegueus9
El sitio de linux y el Software Libre en Colombia

"Hay pecados cuya fascinación está más en el recuerdo que en la
comisión de ellos." Oscar Wilde

--~--~-~--~~~---~--~~
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: bug in forms

[Michael]

On Tue, Sep 16, 2008 at 7:35 PM, Collin Grady <[EMAIL PROTECTED]>wrote:

> On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin
> (diegueus9) <[EMAIL PROTECTED]> wrote:
> > i found this:
> > Changed in Django 1.0: The cleaned_data attribute was called
> > clean_data in earlier releases.
> >
> > in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index
> >
> > I make a mistake?
>
> That line also says what I said - it *used to be* clean_data in 0.96,
> but it *is* cleaned_data now.
>
> So if the line of code had clean_data, it would be wrong, but it has
> cleaned_data, so it is right.
>
> --
> Collin Grady
>
> Perhaps the ticket should be opened to correct the passive (and therefore,
more difficult to translate) voice in that sentence?

--~--~-~--~~~---~--~~
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: Composite Fields

[Malcolm Tredinnick]

On Tue, 2008-09-16 at 13:37 -0700, David Cramer wrote:
> I think that will work Malcom. One thing we'll need to deal with,
> is .name, .attname, etc on these. It should act the same way on the pk
> as it does on the multi-column field (because after all, this will be
> just a wrapper). Right now .pks is just an alias for .pk.as_tuple or
> something. I had it throwing errors if you tried accessing .pk.name if
> there were multiple fields in it, as name is the field name, and the
> field name becomes multiple.

The name attribute can return a tuple for CompositeFields. I've actually
added a multicolumn attribute to the Field class so that one isn't stuck
have to do isinstance() calls all the time; we can key off
field.multicolumn (True or False), although I've got a fixme to think
about calling that something less fiddly to type and less
database-specific. Once we start treating them like proper fields that
can have sequence values, I think it all falls intro place fairly
easily.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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: RFC: django.template refactoring (#7806)

[Simon Willison]

On Sep 16, 7:36 pm, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> @register.tag
> @uses_token_stream
> def mytag(parser, bits):
>      expr = bits.parse_expression(required=True)
>      return MyNode(expr)
>
> `uses_token_stream` replaces the Token argument to the parser  
> function with a TokenStream object.

I'm completely in favour of some refactoring in django.template, but
I'm not at all keen on that decorator syntax. Nested decorators get
ugly quickly in my opinion, especially considering our need to keep
supporting Python 2.3 syntax.

Would @register.tag(token_stream=True) work instead, or am I missing
something?

Cheers,

Simon
--~--~-~--~~~---~--~~
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: Proposal: app objects

[John D'Agostino]

I started working on a patch 6 months ago to implement App objects,
but unfortunately never got to finish it because at the time I was
swamped at work.
Because of the all the work which has happened on trunk the code is
pretty much useless.

> The following can be addressed with app objects.
>
> 1. Allow multiple instances of an app object to exist

Can you explain how this can be achieved (in regards to API)?

I am currently can't figure out a clean solution or a use case which
would require two installations of the same application.

For example, someone for some reason wants to django.contrib.comments
more than once, so they add to entries to the settings.py
INSTALLED_APPS tuple.

INSTALLED_APPS = (App('django.contrib.comments', name='comments'),
  App('django.contrib.comments', name='comments2',
db_prefix='comments2'))

syncdb works, and the two apps are installed. All is well. But for you
to make use of the two applications, all views must become application
aware.

Does the urlpatterns take into account an App instance?

urlpatterns = patterns('',
  url(r'^comments/', include('django.contrib.comments.urls'),
app=get_app('comments2')),
)

Does it still require the view to somehow check the application
instance? For example a simple view;

def my_view(request):
  comments = Comment.objects.all()
  render_to_response("comments/template.html", {"comments":
comments})

How does the view know which app it is? Is it 'comments' or
'comments2'?

Or am I completely confused to what this requested feature is trying
to achieve?
--~--~-~--~~~---~--~~
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: bug in forms

[Collin Grady]

On Tue, Sep 16, 2008 at 4:40 PM, Diego Andrés Sanabria Martin
(diegueus9) <[EMAIL PROTECTED]> wrote:
> sorry, you have reason, my english is bad and i am tired, but i have this 
> error:
 form.clean()
> Traceback (most recent call last):
>  File "", line 1, in ?
>  File "/home/felipecastel/django1.0_src/django/forms/models.py", line
> 208, in clean
>self.validate_unique()
>  File "/home/felipecastel/django1.0_src/django/forms/models.py", line
> 236, in validate_unique
>if name in self.cleaned_data and f.unique and not is_null_pk:
> AttributeError: 'IdeaForm' object has no attribute 'cleaned_data'

> and i read the doc over and over again and i cant use the forms.

This sounds like more of a usage question then (for instance I see you
calling form.clean() manually for some reason), so you should take it
to django-users :)

-- 
Collin Grady

--~--~-~--~~~---~--~~
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: I want a pony: Django Cheeseshop

[Steve Holden]

Malcolm Tredinnick wrote:
> On Tue, 2008-09-16 at 05:06 -0700, mrts wrote:
>   
> [...]
>> setuptools is a necessary evil for the agile developer who frequently
>> tracks updates for the bits he relies upon. Hopefully it will be
>> improved (the clamor around it is ever-ongoing), but unless we want to
>> do it ourselves, we have to accept the state of things.
>> 
>
> Wow. You just said we should entirely ditch security because it isn't
> convenient. That's exactly the attitude that has made Microsoft the
> laughing stock of the professional IT community for the last 15 years.
>
>   
Which, sadly, hasn't affected either their profits or their market
dominance.
> If my original mail had said "nobody should ever use setup tools" or
> anything like that, you reply might be valid. Go back and read it. I
> said "optional", not "forbidden". There are multiple audiences here. If
> Django ever had a hard dependency on setuptools for using third-party
> packages it would make it very difficult for system administrators to
> use Django because of the large level of security uncertainty and extra
> overhead that comes with using it. So, again, it's fine for people who
> want to to use setuptools and virtualenv and buildout and eggs and
> rinky-dinky-tool-of-choice. People use things knowing that there are
> always trade-offs and compromises. It's bad once policy starts being
> enforced on something that is simply unusable in certain environments.
>   
Yes, anyone looking for "the one true way" is doomed to disappointment.
You only have to review recent correspondence on python-dev to realize
that no one person is aware of all the requirements of the various
platforms for which modern applications must be packaged.

I don't much like the pejorative implication of matching
"rinky-dinky-tool-of-choice" with the other listed alternative, however.
Personally I think virtualenv is a good solution to a tricky problem.

The thing that bugs me most of all is Python developers who assume that
the answer to all Python distribution problems is the assumption that a
single Python installation can support all required applications. In
this day and age it's quite practical to look at distributing the
required interpreter as a component of your application or framework.
There is no reason why your Python program and mine need have any
components in common, and increasingly less reason to enforce this
requirement to save disk space.

Having said which, Django and other frameworks don't have that luxury:
if I'm running Django on 2.4 then every app my Django installation
supports also has to run on 2.4.

regards
 Steve


--~--~-~--~~~---~--~~
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: Proposal: refactoring URL resolution

[Malcolm Tredinnick]

On Mon, 2008-09-15 at 14:10 -0700, Ken Arnold wrote:
> I previously brought up a URL resolution refactoring (http://
> groups.google.com/group/django-developers/browse_thread/thread/
> e16bcd24f9e27062/a84b8e58fe2e7786), and was wisely told to hold off on
> it. I thought this might be a good time to bring it up again.
> 
> I'm just going to suggest the simplest thing that might possibly work;
> please comment.
> 
> URL resolver interface:
> - resolve(path) returns (view_function, args, kwargs), just like
> existing interface
> - reverse(name, *a, **kw) returns URL path
> 
> That's not new. Here's the difference: a URL configuration /is/ a
> resolver. We just abstract the special case about importing a module.
> For example, an AdminSite is a resolver. It can just inherit from
> RegexURLResolver (or whatever). Instead of the ad-hoc resolver in
> 'root', it has a 'resolve' method that maybe checks a few special
> cases and then calls super.resolve.

You don't mention what problem are you trying to solve with this change?
Sure, we could do this and certainly make it fully backwards compatible,
but why is it needed?

You can already put any object you like that has a resolve() method into
urlpatterns(). That object can see every single pattern that passes
through if it is matched for the pattern ''. We have to *some* kind of
root object and it happens to be RegexURLResolver.

Right now, in various pieces of client code, I've written classes that
variously (a) implements Joe Gregorio's URL patterns, (b) adds support
for "name=" prefixes on included URL patterns and (c) looks up the URL
correspondence via an external script to determine where to dispatch to.

All three of these were written to meet various client needs and work
quite happily as part of urlpatterns(). I can't think of a case where
I've needed something above that. You clearly have something in mind, so
time to spill the beans (please).

Regards,
Malcolm


--~--~-~--~~~---~--~~
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: I want a pony: Django Cheeseshop

[Kevin Teague]

> > apt and rpm don't mix with project-specific packages and versioning
> > (virtualenv/buildout). It is just not feasible (or even possible if
> > something is built against django-0.96 and something else against
> > django-1.0)
>
> Don't tell that to my laptop and some systems I admin which have
> completely parallel installation of Python 2.4 and everything else I
> need to do Plone work, all managed by rpms, then. They don't like being
> told that what they're doing is apparently impossible. :-)

Yes, it's perfectly possible to use Buildout and rpms in conjunction.
Zope Corp, who created Buildout, even uses Buildout for development
and production deployments using rpms:

http://mail.python.org/pipermail/distutils-sig/2007-August/008158.html

> setuptools is a necessary evil for the agile developer who frequently
> tracks updates for the bits he relies upon. Hopefully it will be
> improved (the clamor around it is ever-ongoing), but unless we want to
> do it ourselves, we have to accept the state of things.

Only a small (and arguably non-evil) slice of the setuptools package
is a necessary evil. It would be nice if the namespace support and the
"include more metadata about our Python packages" parts of setuptools
were separate from the rest of setuptools, so that the distinction
between using easy_install and using eggs was a lot clearer. Eggs are
just a packaging format, and one that can work complementary to
packaging formats such as rpms and dpkgs.

Buildout only uses a small slice of functionality from setuptools.
It's egg-installation code lives outside setuptools and Buildout
entirely in the zc.recipe.egg package (http://pypi.python.org/pypi/
zc.recipe.egg). If someone doesn't like the way zc.recipe.egg handles
the install of egg-based packages, it's perfectly possible create a
recipe which does things the way you desire.

--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[sciyoshi]

On Sep 16, 7:31 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > I really like the idea. However, I think there should also be a way to
> > configure it to not copy to MEDIA_ROOT but to somewhere else.
>
> Sure - a --destination flag, defaulting to MEDIA_ROOT, would work.

There's also the issue of the application knowing where its media will
be installed,
so that it can access it from templates. Let's say I just did

manage.py installmedia myapp

and all of myapp's media got copied into MEDIA_ROOT/myapp/{css,js}/.
Should I assume
in my templates that the files are available at {{ MEDIA_URL }}/myapp/
{css,js}/? Or maybe
there should be a settings variable, something like

APP_MEDIA_URLS = {
'myapp': 'some/other/path',
...
}

so that the app can use {{ APP_MEDIA_URLS.myapp }}/myapp/{css,js}/.
This doesn't seem like
a great solution though, because there's no real "standard" for which
{% blocks %} to override in
an app to add css/js; maybe this configuration step should just be
left to the person using the app.
--~--~-~--~~~---~--~~
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: Proposal: installmedia command - A story for distributing media with apps

[Rajeev J Sebastian]

On Wed, Sep 17, 2008 at 7:47 AM, sciyoshi <[EMAIL PROTECTED]> wrote:
>
> On Sep 16, 7:31 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>> On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
>>
>> > I really like the idea. However, I think there should also be a way to
>> > configure it to not copy to MEDIA_ROOT but to somewhere else.
>>
>> Sure - a --destination flag, defaulting to MEDIA_ROOT, would work.
>
> There's also the issue of the application knowing where its media will
> be installed,
> so that it can access it from templates. Let's say I just did

This is not really a problem, since the media will always be under
//..

A problem would be referencing images, and media in css/js files.
Currently, in all our projects we use /site_media/ as the MEDIA_URL,
so this not a problem. But for a true solution, there should be a
preprocessor for css/js to use the MEDIA_URL within it.

Another problem which we havent solved, is overrides. E.g., when we
use a "plugabble"/reusable app with its own media, and we want to
override this in our project, how should the collect media command
work ?

Anyway, I've attached our media app (with the command, etc). If you
want any changes to be included, please do tell me.

Regards
Rajeev J Sebastian

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



dynamo_media.tar.bz2
Description: BZip2 compressed data

Re: Proposal: installmedia command - A story for distributing media with apps

[Brian Beck]

On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
wrote:
> A problem would be referencing images, and media in css/js files.
> Currently, in all our projects we use /site_media/ as the MEDIA_URL,
> so this not a problem. But for a true solution, there should be a
> preprocessor for css/js to use the MEDIA_URL within it.

CSS can refer to images by their path relative to the CSS file, so if
your media tree looks like:

media/css/base.css
media/images/icon.png

Then base.css can do: background-image('../images/icon.png')

...so no preprocessing needed there.  But referring to *another app's*
images is another story.  And JavaScript... well, don't reference
images in JavaScript.

> Another problem which we havent solved, is overrides. E.g., when we
> use a "plugabble"/reusable app with its own media, and we want to
> override this in our project, how should the collect media command
> work ?

I imagined this working just like templates.  By *convention* apps can
lay out their media directories like media/appname.  So there's
nothing stopping your app from including, say, media/anotherapp/css/
base.css, and we can say that whichever app is in INSTALLED_APPS first
wins, just like with templates.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

django.VERSION changes

[James Bennett]

A while back I proposed changing the way the ``django.VERSION`` tuple
is set up. That discussion petered out a bit, until I brought it up
with Jacob just before the 1.0 release. At the time, we felt it wasn't
possible to do it before we rolled 1.0 (this was, due to my
absent-mindedness, about ten minutes before we tagged the release, so
it's my fault this didn't happen prior to 1.0), but now I'd like to
revisit this and get it done so we have something a bit more sensible
going forward.

I'm writing this mostly as an explanation of what I plan to do; if
there aren't any well-founded objections, I'll make the necessary
changes and commit them before we create the 1.0.x branch.


The problems with the current scheme


Right now, ``django.VERSION`` is a 3-tuple whose format has been known
to vary wildly according to what we're doing at a given moment. This
has led to two major problems:

1. Because the third item in the ``VERSION`` tuple has been used for
   qualifiers like 'pre', 'beta', etc., we only have two items
   available for the actual version number. This has been known to
   cause hilarious results in the case of releases like, say, 0.96.3,
   which has to be (0, 96.3, None) (stop and think about how IEEE
   floats get printed, and you'll see the issue here).

2. That third item has never followed any really predictable format,
   except for the period of the 1.0 alpha/beta releases. This makes it
   difficult to tell what sort of Django codebase you're looking at
   without thinking about it and possibly doing some archaeology.

I don't see any good way to deal with these issues while retaining the
current 3-tuple, so...


The format of ``django.VERSION`` going forward
==

Based on a good suggestion from Steve Holden, I'm going to change
``django.VERSION`` to follow, as closely as possible, the format of
Python's own ``sys.version_info``. This means it will become a
5-tuple, whose elements are, in order: major version, minor version,
micro version, release level, serial.

The Python docs don't actually define these terms clearly, but for
Django's use I'm going to lay out what these mean and what values they
can take, inferring at times from how Python's done it (I've been
reading the history of Include/patchlevel.h to get a feel for the way
that's evolved over time... fun fun). So here goes:

"major"
The major version number of the Django release, e.g., 1 for the
1.x releases.

"minor"
The minor version number of the Django release, e.g., 0 for the
1.0.x releases, 1 for the 1.1.x release, etc.

"micro"
The micro version number of the Django release, e.g., 1 for a
release number 1.0.1, 2 for a release number 1.0.2, etc.

"release level"
A short string describing the type of release. Value will be one
of: "alpha", "beta", "rc" (for release candidates, "final".

"serial"
For situations where we do more than one release of a given level,
the incremental number of the release (e.g., 1 for "alpha 1", 3
for "beta 3", etc.).


How this will work
==

For the most part, this all works pretty simply and intuitively. Let's
consider the case of the eventual 1.1 release and, for sake of
example, assume we do two alpha releases, two beta releases, one
release candidate and then the final 1.0. During that process, the
``VERSION`` tuple would evolve as follows:

* For Django 1.1 alpha 1: (1, 1, 0, 'alpha', 1).

* For Django 1.1 alpha 2: (1, 1, 0, 'alpha', 2).

* For Django 1.1 beta 1: (1, 1, 0, 'beta', 1).

* For Django 1.1 beta 2: (1, 1, 0, 'beta', 2).

* For Django 1.1 release candidate 1: (1, 1, 0, 'rc', 1).

* For the final 1.1 release: (1, 1, 0, 'final', 0).

The only tricky bit is what to do immediately after a release; for
example, after we release 1.1, what happens to ``django.VERSION`` in
trunk as we gear up development for 1.2? Taking a cue once again from
Python, the answer is that we go from this, which is 1.1 final::

(1, 1, 0, 'final', 0)

to this, which denotes dev work in trunk for 1.2 prior to any alpha
release::

(1, 2, 0, 'alpha', 0)

In other words, a release level of "alpha" and a serial of 0 indicates
we're working toward the release specified by the rest of the tuple,
but have not yet reached the point of issuing alpha versions of it.

The ``django.get_version()`` function will be rewritten to piece this
together as follows:

* For a "real" release like, say, 1.1, the tuple (1, 1, 0, 'final', 0)
  will become the printed string "1.1 final".

* For an alpha, beta or RC, a tuple like (1, 1, 0, 'beta', 2) will
  become the printed string "1.1 beta 2". (1, 1, 0, 'rc', 1) will
  become "1.1 rc 1".

* For the one special case of checkouts from trunk prior to the
  beginning of alpha releases, a tuple like (1, 2, 0, 'alpha', 0) will
  become the printed string "1.2 pre-alpha".

In all cases, if we're on an SVN checkout we append the revision
number, e.

Re: Proposal: installmedia command - A story for distributing media with apps

[Samuel Cormier-Iijima]

On Sep 16, 11:05 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
> wrote:
>
> > A problem would be referencing images, and media in css/js files.
> > Currently, in all our projects we use /site_media/ as the MEDIA_URL,
> > so this not a problem. But for a true solution, there should be a
> > preprocessor for css/js to use the MEDIA_URL within it.
>
> CSS can refer to images by their path relative to the CSS file, so if
> your media tree looks like:
>
> media/css/base.css
> media/images/icon.png
>
> Then base.css can do: background-image('../images/icon.png')
>
> ...so no preprocessing needed there.  But referring to *another app's*
> images is another story.  And JavaScript... well, don't reference
> images in JavaScript.

We use the convention that there should be a Javascript variable
called MEDIA_URL defined somewhere in a base template that lets
Javascript access it; seems like this might be a useful convention to
adopt.

> > Another problem which we havent solved, is overrides. E.g., when we
> > use a "plugabble"/reusable app with its own media, and we want to
> > override this in our project, how should the collect media command
> > work ?
>
> I imagined this working just like templates.  By *convention* apps can
> lay out their media directories like media/appname.  So there's
> nothing stopping your app from including, say, media/anotherapp/css/
> base.css, and we can say that whichever app is in INSTALLED_APPS first
> wins, just like with templates.

For CSS, there's a couple ways that this might possible. Let's say
myapp wants to distribute some default CSS; then it could actually
provide two separate files:

myapp/media/myapp/css/style_base.css:

#myapp div.something {
/* custom styles for the app */
}

myapp/media/myapp/css/style.css:

@import url(./style_base.css);

This way, the project using the app can customize the CSS or replace/
exclude it completely (by excluding the import line), without having
to change anything inside myapp proper. django-compress might be
useful in this situation; it could automatically parse the @imports in
CSS and generate a compressed version including the right files.

I'm not sure though that all of this is worth it; it seems like we're
trying to optimize for the case where somebody a user simply drops an
app into their project, runs installmedia, and never customizes
anything beyond that. In reality, the templates and CSS are most
likely going to be customized (although JS is another story), so maybe
this sort of "inheritance" isn't really needed.

Which reminds me - I think it would be really nice if there was some
sort of script/style manager in Django (similar to the django.forms
media):

{% extends 'base.html' %}

{% css 'myapp/css/stuff.css' 'myapp/css/morestuff.css' %}
{% js 'myapp/js/stuff.js' %}

{% block content %}
   ...
{% endblock %}

and then in the base template



{% css %}
{% js %}


{% block content %}{% endblock %}



Django could then even check in a list of directories to find the
appropriate files (similar to the way template lookups work now) and
include the first one found.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---