Re: Ticket #3349 patch review

[Andrew Durdin]

I'm the author of the current patch; I'll just add a bit of
background.

On Dec 12, 10:18 pm, ab  wrote:
>
> 1. Scope -- the patch generalizes the issue and addresses it
> throughout Django. Are people ok with that?

Since the problem of raising new exceptions and losing the original
one seemed systemic throughout much of Django, I thought it
appropriate to make the patch address all known instances of this
class of problem, and not just the one instance in the original
complaint.

> 2. Design -- The wrap_and_raise function needs to be used not only at
> the site of the problem, but also possibly at a deeper level in the
> call stack as well. In this particular case, it needs to be used in
> both `get_library` and `load` to address the original issue.

Correct. It needs to be used wherever Django is catching an exception
arising from user-supplied code and then raising a different
exception.

> 3. Design -- Seeing the ImportError's traceback is indeed helpful in
> identifying the source of the problem. But, it's also kind of weird to
> have the traceback of an ImportError (ending with the line "import
> notthere" or whatever) associated with a different exception.

I'll just clarify for anyone that hasn't applied the patch and tried
it: with the patch in place, the traceback will still show down to the
TemplateSyntaxError, but instead of stopping there will also continue
down to where the ImportError originated. Yes, it's a little weird;
Python 3.0 handles this whole situation much better with "raise ...
from ..." which is intended for use in precisely these situations.

Andrew

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #3349 patch review

[Andrew Durdin]

On Dec 14, 11:00 pm, ab  wrote:
> > `wrap_and_raise()` will appear in the traceback, `raise  
> > wrap_exception(SomeException())` would be cleaner.
>
> I like that

But you must use the three-argument `raise` statement to supply your
own traceback in Python 2.x. You could dispense with the function
entirely if you're happy to repeat `import sys; raise NewException(),
None, sys.exc_info()[2]` instead--although then you lose some
information, see below.


> > Your patch seems to swallow the new exception's traceback now instead
> > of the causing traceback. That might be good in some situations, but
> > generally both should be preserved.

No; the only part of the traceback lost is the `raise` line within
`wrap_and_raise`; the remainder of the traceback which would
correspond to all but the `raise` line of the new exception's
traceback is preserved. But if you weren't using the `wrap_and_raise`
function, you would lose the line of the traceback where the new
exception was raised. Put the following code in a python script and
compare the tracebacks when it calls wrapped(), unwrapped(), or
manually_wrapped():


def wrap_and_raise(new_exception):
  import sys
  exc_class, exc, tb = sys.exc_info()
  if issubclass(exc_class, Exception):
raise new_exception, None, tb
  else:
raise new_exception

def valueerror():
  raise ValueError("This is a ValueError")

def wrapped():
  try:
valueerror()
  except:
wrap_and_raise(StandardError("This error normally hides the
original error"))

def unwrapped():
  try:
valueerror()
  except:
raise StandardError("This error hides the original error")

def manually_wrapped():
  import sys
  try:
valueerror()
  except:
raise StandardError("This error normally hides the original
error"), None, sys.exc_info()[2]

# Try each of these
wrapped()
# unwrapped()
# manually_wrapped()



> > Better yet, make all exceptions that are used to reraise other  
> > exceptions a subclass of WrappingException (pick a better name) that  
> > either takes a `cause=exc` or `wrap=True` kwarg. This way, you don't  
> > have to add imports everywhere.
>
> I don't like that. An invalid template exception might be "wrapping"
> sometimes, but not others.

TemplateSyntaxError is an obvious example. Also, if you do this you're
still not preserving the original traceback.


> Another question: how should the tests for this ticket be written?

I'm not sure (which is why I didn't write any tests originally).
Obviously you'd raise an exception, catch it, and wrap_and_raise
another. I suppose you could examine the output of
`traceback.format_exc()` or one of its other functions to see if the
original exception is now mentioned in the traceback.

Andrew.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #3349 patch review

[Andrew Durdin]

While I think of it: One thing this patch should address is updating
the `contributing` page  to mention calling wrap_and_raise whenever
you are "catching an exception
arising from user-supplied code and then raising a different
exception".

Andrew.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: New Manipulators and Validation Aware models.

[Andrew Durdin]

Brantley Harris wrote:
>
> Here is a sample view using a default CreateManipulator:
> def create_poll(request):
> try:
> m = Poll.CreateManipulator()
> poll = m.process(request)
> return HttpResponseRedirect('/poll/%d/' % poll.id)
> except Form, form:
> return render_to_response('poll/create.html', {'form': form})

Raising the form as an exception is an interesting alternative to the
normal "if posted and everything validates, redirect, else render form"
approach.

I've also embarked on a quest to improve the situation with
manipulators, although I've taken a much more radical approach.  I
intend to do a full writeup in a couple of days when I've filled a few
holes in the code, but here's a quick summary of the path I've taken:

I first wanted a way to easily create forms that were minor variations
on other forms; in particular, to be able to replace one or two widgets
(I've named the form field classes *Widgets to avoid confusion with the
database *Field classes) from the default form for a model class with
other widgets.  So I created a Form class, that is subclassed to allow
a declarative-style form specification. Form subclasses can further be
subclassed to change or add widgets.

The second need I had was to allow forms to easily manipulate data that
wasn't in models.  So the data from Form instances is first saved into
a structure of dicts and lists (a single dict for a form with no nested
subforms). The widget-level validation (e.g. ensuring that the user has
entered the same password in both text input elements) happens on this
data.  Of course, forms that directly manipulate models are important
too: so a model instance can be updated from this data.  The important
feature with all this is that forms can have nested subforms and lists
of subforms that are the equivalent of edit_inline, and updating the
model instance correctly handles foreign keys and many to many
relationships. Of course, all the above uses model validation as well.

The third need I had was to be able to customise the appearance and/or
client-side behaviour of all input elements in a site; so all Widgets
use template-based rendering.  In an individual project, I can then
create new template files that will be used instead of the default
templates.

One final part of all this was the removal of the
AddManipulator/ChangeManipulator dichotomy -- the two are functionally
equivalent, with the only difference being that the form data is
populated from and saved into a newly created model instance vs. one
retrieved from the database.

Because these changes involve removing or rewriting significant
portions of django.forms, and thoroughly break compatibility with the
existing manipulators, I'll be releasing it as a separate module rather
than a patch to django.

Andrew


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

What is the Right Way to handle DECIMAL fields?

[Andrew Durdin]

In a project I am working on, we need to store monetary values in the
database, and we want to avoid floats altogether so that we don't lose
precision or have representation errors. The existing FloatField was
not suitable for use, because it would sometimes return floats and
sometimes decimals, depending on circumstances. I submitted a ticket &
patch, #2365 (http://code.djangoproject.com/ticket/2365) that addresses
this by making FloatField work exclusively with floats, and added
DecimalField (in db. and forms.) that would work with decimal.Decimal
objects. The problem with the latter is that the decimal module is only
in 2.4, and django is targeting 2.3 as the minimum support version of
Python.

To quote from what I wrote in the ticket:

> Finally, this patch should work without the decimal module: if the
> decimal module is available, then models.DecimalField? attributes will
> be decimal.Decimal instances; if not, then they will be strings. If the
> user needs to perform arithmetic, then he can call float() and operate
> within the accuracy limits of floats, but it's safer not to convert
> implicitly.

To which Malcom replied:

> I don't like the implication of the last paragraph of the previous
> comment. It means that every single time you do arithmetic with this
> field, you need to either test that you are running on Python 2.4 or
> call float(). This is a huge burden on the developer. It has to work a
> bit more transparently than that.

So, which is better to do if the decimal module is not available: is it
better to return a string from a DecimalField, sacrificing convenience
for a guarantee of exact representation, or return a float so that the
user can do arithmetic without hassle?

I'm of the opinion that the former is better, as it requires the
developer to explicitly take actions that may result in a loss of
information; and for those cases where the developer either needs
floats or doesn't care as much about the accuracy, he can use
models.FloatField, which will consistently return floats. What do
others think?

Andrew


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

Why doesn't models.Manager implement __iter__?

[Andrew Durdin]

Looking at models.Manager, I noticed that for convenience it implements
many of the public methods of QuerySet, delegating the calls to its
query set.  This obviously allows for more convenient behaviour, such
as writing  MyModel.objects.filter(whatever)  instead of
MyModel.objects.all().filter(whatever).

However, I constantly trip over the fact that it doesn't implement
__iter__, as it seems natural to me to do  for(obj in MyModel.objects).
 Is there a particular reason for not implementing it?  I can
understand that implementing __len__ and __getitem__ would encourage
inefficient code (due to the results not being cached), but is there
any such problem with implementing __iter__?


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

Re: Why doesn't models.Manager implement __iter__?

[Andrew Durdin]

Malcolm Tredinnick wrote:
>
> The consistent design idea at work here is that a manager provides those
> methods that return a Queryset object. That is why we have .all() in the
> first place: it provides a way to convert from a manager object to a
> Queryset without applying any filters or restrictions at all to the
> default.

I guessed that might have been the case, but became less sure when I
saw that Manager implementes iterator()  (which does not return a
QuerySet).  It seemed natural to me to support __iter__ delegating to
iterator(), but from what you say, I guess the latter is an exception
that doesn't set a precedent :)

Cheers,

Andrew.


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

Re: Proposal: Forms and BoundForms

[Andrew Durdin]

I'm sorry to say that I missed the thread "Proposal: Forms and
BoundForms" last month.  I'm very interested in the topic, largely
because, having run out of patience with manipulators, I had written
code to handle form definition, validation, and rendering that is
similar to the proposals described in that thread.  In developing this
library, I was focusing mainly on providing useful integration between
forms and models (including "nested forms"), and customisability of
forms.  I'll describe this here, focusing mostly on the needs or
decisions which haven't been discussed in that thread already.  I hope
that some of this will be of use for the manipulator replacement work
that is in progress.

I was motivated in creating this to fulfill these needs that I had that
manipulators weren't fully suitable for:

A. To allow easy declarative form creation, as well as customisation of
the default form for a model.

B. To unify adding/changing model instances.  Adding and changing are
processed identically, with only the form defaults being different.

C. To allow a form to be easily generated and handled for a model
hierarchy -- i.e. a single model instance, and other instances related
via ManyToManyFields and ForeignKeys in either direction; and
supporting model validation.

D. To make it easy to customise the rendering of a form or form field.

E. To allow forms with validation to be used without being tied to a
model class/instance -- i.e. to work with dicts and lists.


For (A), I implemented the unbound/bound distinction with the natural
class/instance distinction:  a Form subclass defines the form structure
and validation, and an instance of the class is that form, "bound" with
data, and errors (if it has been validated).  Similarly, a Widget
subclass (a form field) defines the widget's attributes (name, size,
choices list), and a Widget instance has data and errors.  All
customisation of forms and widgets is done through subclassing, with an
alter() method providing a convenient helper for small changes.

For example, assume a UserProfile model that has 'username',
'fullname', and 'email' TextFields, and a 'group' ForeignKey.  The
automatically generated default form for this model would have a
TextWidget for the first three fields, and a SelectField for the
group_id, with a list of the available groups.

# Never let the username be edited, and use a custom widget for the
# email field
class EditProfileForm(Profile.default_form):
username = None
email = EmailWidget.alter(maxlength=20)

# Only let admin users edit the group
if not request.user.is_admin():
EditProfileForm = EditProfileForm.alter(group_id=None)

For (B): handling the request involves creating a form instance with
default data, updating that with POST data (if applicable), processing
changes, and rendering the form if unsubmitted or errors.

# If we were adding a profile here, we'd just use Profile()
profile = Profile.objects.get(id=whatever)
form = EditProfileForm(profile)
if request.POST:
form.update_data(convert_post_data(request.POST))
form.process_input_data()
if not form.has_errors():
return HTTPResponseRedirect("/profile/")
return render_to_response("profile.html", {'form': form})

Since the base Form class is ignorant of models (E), and only uses a
dict to store its data, there is a ModelForm subclass that extracts
data from a model instance (and related instances) to fill in the
widgets declared in the form.  A default_form descriptor is added to
the models.Model class to generate a form automatically -- but for
convenience, if a default_form class is declared in the model, it will
be used instead (there were some technical hoops to jump through with
this, but I'll gloss over that).

(C), integration with models, is the trickiest part. as implemented,
there are four distinct types of widget, each corresponding to a
different data structure or relation type:

A simple widget corresponds to a simple data type (int, string) or, for
a model instance, a TextField, IntegerField, etc. -- or the
fieldname_id attribute for a ForeignKey relation.

A widget with its has_form attribute set corresponds to a dict, or the
fieldname attribute for a ForeignKey relation to another model; the
SubForm Widget subclass handles this with another Form class:

class EditProfileForm(Profile.default_form):
home_address = SubForm.alter(form=Address.default_form)
# Now we can render form.address.street in a template, and so on

A widget with its has_list attribute set corresponds to a list, or a
ManyToMany or reverse ForeignKey relation to another model, when
selecting from the existing instances, and not editing them inline.  A
multi-select list widget handles these.

Finally, a widget with both has_list and has_form corresponds to a list
of dicts, or a ManyToMany or reverse ForeignKey relation, edited
inline.  A SubFormList widget is used for this.

Re: New newforms code

[Andrew Durdin]

Mikko Ohtamaa wrote:
>
> I don't see any drawback for template based widgets expect that running
> template engine consumes more CPU cycles. But if that's a problem for
> someone, I am willing to buy him/her a new server :)

Well, that's a handy coincidence, because it's suddenly become a
problem for me :-b

I'm +1 on having widgets template-based also.

Andrew


--~--~-~--~~~---~--~~
 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: Should Django be HTML agnostic?

[Andrew Durdin]

Rob Hudson wrote:
>
> 1. Display code should be separate from logic. Ideally, all HTML would
> be in template files that one could override if need be in their own
> template directory, just like the admin templates. If django.forms did
> this, that would be great.

The forms framework I wrote out of frustration with django.[old]forms
did this.  I ended up with a number of tiny one-line templates. The
template for a TextField, for example, was:



My motivation for this change was less to allow the use of valid HTML
(instead of XHTML), but to allow site-wide customisation of form
elements (i.e. in ways beyond what CSS can do).

> The only consideration I can think of is
> what kind of load would this be to necessitate a file system call to
> pull in the widget template or error template?

I don't think that's generally an issue.  If the Template instance is
cached in the Widget instance, then each widget's template file need
only be loaded and parsed once; and I don't expect the extra rendering
will be a significant issue.

> 4. One of the reasons I've seen touted for the template system not
> having access to Python methods and having it's own language is the
> benefit of separating the programmer from the designer and that
> designers shouldn't need to know Python to create templates in Django.
> But they would if they want to manipulate forms or form error feedback.
> This should be consistent.

This is IMO the best argument for this change.  Being able to have a
custom (but consistent site-wide) display of form labels & errors with
only template overrides would be very nice indeed.

Andrew


--~--~-~--~~~---~--~~
 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: Signed Cookies (ticket #3285)

[Andrew Durdin]

Gulopine wrote:
> I've taken the liberty of writing up a contrib middleware to
> transparently implement signed cookies in a Django app. It autmatically
> signs and validates all cookies on its own, without any other code
> needing to know a thing about it.

Can you explain the reasons why one would want to use signed cookies?
What (presumably security) issues are they intended to overcome?

Andrew


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

Decision on Decimals vs Floats?

[Andrew Durdin]

There are two open tickets regarding decimals vs floats: #200 and
#2365.
The current situation is untenable for anyone with a need for genuine
fixed-point decimal values, as there are too many cases (i.e. at least
one :-) where they might be converted to floats, with a loss of
accuracy.  To summarise the problems:

Floats are a poor choice for dealing with currency values, but the
Decimal class is only standard in python 2.4.  The models.FloatField
class actually refers to a DECIMAL column, and will return a Decimal
instance under 2.4, but a float under 2.3.  Also, the
[old]forms.FloatField is the default form field for models.FloatField,
and will always return a float, never a Decimal instance.

Condensing the various comments to both tickets into a single proposal:

Bundle decimal.py with django as utils._decimal_local (as has been done
with the threading module).
Modify the database wrappers to ensure that decimal columns will return
Decimal instances, and float columns (if supported) will return floats.
Create separate models.FloatField and models.DecimalField.
Create separated forms.FloatField and forms.DecimalField  (in newforms
and presumably in oldforms), and appropriate widgets if needed.

I would like to see this included in Django -- at present I am
maintaining my own fork of Django to support Decimals appropriately,
and that's not a pleasant long-term situation.  As the plan is to have
some API-breaking changes between 0.96 and 1.0, I'd like to propose
this change for inclusion in 1.0.  I will undertake the work required
to produce the patch + docs + tests, but I'd like a decision from the
core devs as to whether they would like to see this in 1.0 or not.

Cheers,

Andrew.


--~--~-~--~~~---~--~~
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: Decision on Decimals vs Floats?

[Andrew Durdin]

Michael Radziej wrote:


a) Would this introduce an incompatible change of an API?


Yes: models.FloatField would always return floats (not Decimals), and
introspection of DECIMAL columns would yield DecimalFields (not
FloatField).  The parameters to FloatField would also change (no
precision, etc.).

I'm raising the issue again at this time because Jacob's comments in
http://groups.google.com/group/django-developers/msg/0c19a63a1e4648e5
about API changes between 0.96 and 1.0 would indicate that this is the
best timeframe for this change to be implemented.



b) Would it hold up 1.0? In other words, is there an agreement about the
general idea and design, and is there a good patch available or to be expected 
soon?


I have the beginnings of a beginnings of a patch in my fork; I will
produce a full patch if the proposal in my previous message is
approved.  It would not take long to do, so should not delay 1.0.



c) How can the decimal module be integrated? Has Adrian agreed?


The decimal module can be integrated by including decimal.py in
django/utils, as has been done with the python implementation of
threading.local (see django/utils/_threading_local.py).  The decimal
module is already made available separately for use with Python 2.3
(see http://www.taniquetil.com.ar/facundo/bdvfiles/get_decimal.html).
To the best of my knowledge, Adrian has not yet commented on this
possibility -- which is actually why I posted this thread.

Andrew


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

Patch for #2365 (was Re: Decision on Decimals vs Floats?)

[Andrew Durdin]

I've added an updated patch for #2365 "models.FloatField should be 
renamed"[1], against revision 4439 of the trunk.

Summary of this patch:

 * The 'decimal' module from 2.4 is included under django.utils, to 
ensure Python 2.3 compatibility
 * db.FloatField handle only floats, and db.DecimalField handle only 
decimals.
 * oldforms.FloatField and oldforms.DecimalField are the defaults for 
the db fields and do the Right Thing validation-wise
 * newforms.FloatField and newforms.DecimalField ditto; but they also 
support max_value and min_value arguments à la newforms.IntegerField

This patch includes tests for both the database fields and the form 
fields.


Important notes:

This patch BREAKS the old behaviour of db.FloatFields with various 
database backends -- this is a good thing, because they were 
inconsistent with different Python versions and also wouldn't handle 
full round trips properly.

I've tested this patch with MySQL 4.1 and Sqlite 3.1.3 under Python 
2.3.5 and 2.4.1 on OS X 10.4.8.  The changes to the MSSQL, Oracle, and 
Postgresql backends have NOT been tested; I don't have an install of 
MSSQL or Oracle available, and was unable to get Postgresql running on 
my machines.

So if anyone has MSSQL, Oracle, or Postgresql running and can try out 
this patch and run the tests[2], please do!  and post the results 
here.  There might be some additional typecasting needed, particularly 
for Python 2.3 compatibility.

Cheers,

Andrew


[1] Come to think of it, the ticket title should be renamed.

[2] The widget tests in forms seem to be broken at the moment with a 
UnicodeDecodeError;  I commented out the widgets half of the forms 
tests so the rest would run.


--~--~-~--~~~---~--~~
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 tests failing under Python 2.3

[Andrew Durdin]

I'm trying to run all the django tests under Python 2.3.5 (on OS X 
10.4.8), and there are lots of failures (see below).
My settings file for the test is just:

DEBUG = True

DATABASE_ENGINE = 'mysql'   # 'postgresql', 'mysql', 'sqlite3' 
or 'ado_mssql'.
DATABASE_NAME = 'test' # Or path to database file if using 
sqlite3.
DATABASE_USER = 'root' # Not used with sqlite3.
DATABASE_PASSWORD = '' # Not used with sqlite3.
DATABASE_HOST = '' # Set to empty string for localhost. 
Not used with sqlite3.
DATABASE_PORT = '' # Set to empty string for default. Not 
used with sqlite3.

ROOT_URLCONF = None


Do these indicate something screwy with my setup, or do other 2.3.5 
users also get these?

here's the test command and the full output:

DJANGO_SETTINGS_MODULE=test_django.settings PYTHONPATH=~/django-
trunk:~/test_django ./tests/runtests.py

==
ERROR: Request a page that is protected with @login, but use bad 
credentials
--
Traceback (most recent call last):
  File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/
models.py", line 101, in test_view_with_bad_login
self.assertFalse(response)
AttributeError: 'ClientTest' object has no attribute 'assertFalse'

==
ERROR: Doctest: regressiontests.forms.tests
--
Traceback (most recent call last):
  File "/Users/andy/Projects/django-trunk/django/test/doctest.py", 
line 2150, in runTest
failures, tries = runner.run(
  File "/Users/andy/Projects/django-trunk/django/test/doctest.py", 
line 1379, in run
return self.__run(test, compileflags, out)
  File "/Users/andy/Projects/django-trunk/django/test/doctest.py", 
line 1267, in __run
got += _exception_traceback(exc_info)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 
254: ordinal not in range(128)

==
FAIL: POST an empty dictionary to a view
--
Traceback (most recent call last):
  File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/
models.py", line 53, in test_empty_post
self.assertEqual(response.status_code, 200)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/unittest.py", line 302, in failUnlessEqual
raise self.failureException, \
AssertionError: 500 != 200

==
FAIL: GET a view that normally expects POSTs
--
Traceback (most recent call last):
  File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/
models.py", line 45, in test_get_post_view
self.assertEqual(response.status_code, 200)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/unittest.py", line 302, in failUnlessEqual
raise self.failureException, \
AssertionError: 500 != 200

==
FAIL: GET a view
--
Traceback (most recent call last):
  File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/
models.py", line 35, in test_get_view
self.assertEqual(response.status_code, 200)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/unittest.py", line 302, in failUnlessEqual
raise self.failureException, \
AssertionError: 500 != 200

==
FAIL: POST some data to a view
--
Traceback (most recent call last):
  File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/
models.py", line 64, in test_post_view
self.assertEqual(response.status_code, 200)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/unittest.py", line 302, in failUnlessEqual
raise self.failureException, \
AssertionError: 500 != 200

==
FAIL: GET a URL that redirects elsewhere
--
Traceback (most recent call last):
  File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/
models.py", line 74, in test_redirect
self.assertEqual(response.status_code, 302)
  File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/unittest.py", line 302, in failUnlessEqual
raise self.failureException, \
AssertionError: 500 != 302

==
FAIL: GET an invalid URL
---

Re: Django tests failing under Python 2.3

[Andrew Durdin]

On Jan 29, 4:50 pm, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> On 1/29/07 10:15 AM, Robert Myers wrote:
>
> > I'm seeing the same amount of errors on python 2.3.4, it appears the @
> > decorator syntax is being used in the modeltests/test-client/views.py.

And I was so used to decorators that I didn't even pick up on that!

A couple of tests use assertFalse / assertTrue which were introduced 
to unittest in 2.4 also;  these should be changed to failIf / 
failUnless respectively.

I couldn't figure out why one widget's test was giving a 
UnicodeDecodeError while other extremely similar tests weren't...


--~--~-~--~~~---~--~~
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: Logging facility for Django

[Andrew Durdin]

On Apr 24, 12:23 am, Vinay Sajip <[EMAIL PROTECTED]> wrote:
>
> > I agree that thread locals would probably be ideal, but it looks like
> > threading.local was only introduced in Python 2.4. To stay aligned
> > with Django, it should really be 2.3 compatible.
>
> Fair point - I'd forgotten that threading.local arrived with 2.4.

However Django includes the _threading_local module from Python 2.4,
so that it is available to Django apps running on 2.3.  Import it like
this:

try:
# Only exists in Python 2.4+
from threading import local
except ImportError:
# Import copy of _thread_local.py from Python 2.4
from django.utils._threading_local import local

Andrew


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

Maintaining a patched Django (was re: Templates: short comments {##} eats text)

[Andrew Durdin]

On Apr 25, 4:46 pm, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> My own patch stack currently comprises 22 patches ... and it's still ok and
> quite manageable. I'm still up to date with svn.

I've been using a patched version of Django for some time, but it's
highly inconvenient (I'm using a "vendor branch" strategy as described
in the subversion book);  so I'm looking for a different way to manage
this sort of thing.

What tools do you use to manage your patched version?

Andrew


--~--~-~--~~~---~--~~
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: Maintaining a patched Django (was re: Templates: short comments {##} eats text)

[Andrew Durdin]

Thanks Michael, Ramiro, and David.  I'll read up on the things you've
suggested.


--~--~-~--~~~---~--~~
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-updates group broken?

[Andrew Durdin]

I was looking at django-updates in google groups , and noticed the most recent
posting from it was from the 18th of March.  It looks like something
is broken there...

Since updates don't seem to be going through there, can I ask that
someone review ticket #3349 ("If an ImportError occurs within a custom
template tag library, a rather confusing error message is produced")?
It was approved before the September sprint, and I wrote a patch at
that time.  I just updated the patch against the current trunk a
couple of days ago, and would like to see it checked in, as I quite
often run into errors that result in a failed import of a view module,
and the tracebacks don't show the original fault without this patch.

Cheers,

Andrew.
--~--~-~--~~~---~--~~
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: Django releases

[Andrew Durdin]

On Jun 8, 1:23 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
>
> Where I work we use 0.96 (though I use trunk on my personal projects).
>  We use 0.96 because we have up to 12 separate Django projects
> rotating through at a time and all at various phases of development.
> We don't have the resources to continuously update all of them to
> trunk and fix the various backward incompatible changes that might
> crop up, and each one can't be on its own trunk release or trying to
> assemble any sort of library would be a nightmare.  Not even
> mentioning having to support various Django releases on our production
> servers.  So we're stuck on 0.96 until 1.0 comes along.

This is much the same where I work.  We're using our own fork of 0.96
with a handful of cherry-picked changes that were particularly
important for us backported from trunk.  I'm really looking forward to
moving to 1.0 when it's released (possibly even when there's a release
candidate), particularly for QSRF and the full unicode support
throughout.

Speaking of sprints, are there any plans to hold a Django sprint
during Europython 2008 (only one month away now)?

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

#4796 - Needs an expert's eye.

[Andrew Durdin]

I was looking into #4796, and submitted a patch that fixes the error
-- and I'm fairly sure that it fixes it in the appropriate spot.
However, I didn't quite grok the runtime interaction between the
__proxy__ objects and the delayed_loader function, so I'd appreciate
it if someone else could cast their eye over this patch.

http://code.djangoproject.com/ticket/4796

Cheers,

Andrew.


--~--~-~--~~~---~--~~
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: #4796 - Needs an expert's eye.

[Andrew Durdin]

On Sep 22, 2:16 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
>
> Thanks, Andrew. That patch looks "intuitively" correct; it's in the
> right area of code that I would have expected to find the problem, etc.
> I'll have a think about it through today to see if there are any
> technical problems, but I think you've nailed it.

Thank goodness for intuition -- that's what led me to the fix, even
though I didn't understand quite why it fixed it at the time.  In the
end it's got nothing to do with fcgi or mod_python, as the following
python script displays identical behaviour:


def delayed_loader(*args, **kw):
def func(*strings):
return u''.join([unicode(s) for s in strings])
g = globals()
g['real_string_concat'] = func
#return func(*args, **kw) # This is the fix
return string_concat(*args, **kw)

real_string_concat = delayed_loader
def _string_concat(*strings):
return real_string_concat(*strings)

class __proxy__(object):
def __init__(self, func, *args, **kw):
self.__func = func
self.__args = args
self.__kw = kw

def __unicode__(self):
return self.__func(*self.__args, **self.__kw)

string_concat = lambda *args, **kw: __proxy__(_string_concat, *args,
**kw)

verbose_name_plural = string_concat('thing', 's')
# verbose_name_plural.__unicode  # In the ticket, this line would
prevent the error
print unicode(verbose_name_plural)


I'm confident now that the patch is correct, as I now understand why
it works:

string_concat returns a __proxy__ that will call _string_concat when
__unicode__ is called, so we expect _string_concat to return a unicode
instance;

but _string_concat calls delayed_loader(), which returns the result of
string_concat, which is another __proxy__ instance, not a unicode
instance.

however, if we called __unicode__ on the __proxy__ instance (so that
we don't care what type it returns, unlike unicode()), before calling
unicode(), then _string_concat will now be calling the true
real_string_concat, not the delayed loader anymore, so it will return,
as expected, a unicode instance.


Nevertheless, I don't understand why string_concat() and friends
should be lazy at all.  Care to explain?

Andrew


--~--~-~--~~~---~--~~
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: #4796 - Needs an expert's eye.

[Andrew Durdin]

On 9/23/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Previously, I've wondered about pulling string_concat out of trans_real
> and into __init__, since it doesn't depend on the USE_I18N setting at
> all. That piece of tidying would avoid some of these problems, too, so I
> think I'll do that as well.

Makes a lot of sense.

> string_concat is the essentially lazy version of Python's standard
> string.join. We don't want the results -- the pieces being joined -- to
> be coerced to unicode or str objects until we are ready to display them,
> because what they produce is dependent on the current locale setting.

Ah, of course.  I hadn't considered the possibility of changing
locales while running.

Cheers,

Andrew.

--~--~-~--~~~---~--~~
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: Ticket #5172 discussion

[Andrew Durdin]

On 9/25/07, vfoley <[EMAIL PROTECTED]> wrote:
>
> SmileyChris added a ticket to propose extending the for loop tag to
> support numerical looping.  I posted a patch that adds such a
> capability and includes a few tests.  Documentation is still lacking.
> Let me know what you think, here are some code examples:
>
> {% for i 1 to 5 %}
> {{ i }}
> {% endfor %}

Wouldn't a filter or two solve this problem equally well?

{% for i in 1|to:5 %}{{ i }}{% endfor %}

{% for i in 5|to:1 %}{{ i }}{% endfor %}

{% for i in 1|to:5|every:2 %}{{ i }}{% endfor %}


@register.filter
def to(start, finish):
start, finish = int(start), int(finish)
if finish > start:
step = 1
else:
step = -1
return range(start, finish + step, step)

@register.filter
def every(seq, step):
return seq[::step]


Andrew

--~--~-~--~~~---~--~~
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: repr for lazy translation

[Andrew Durdin]

On 9/26/07, Wolfram Kriesing <[EMAIL PROTECTED]> wrote:
>
> I ran into the problem while doing this:
>
> >>> from django.utils.translation import gettext_lazy as _
> >>> s = _("my string")
> >>> s += _("my second string")
> Traceback (most recent call last):
>   File "", line 1, in ?
> TypeError: unsupported operand type(s) for +=: '__proxy__' and '__proxy__'

You can use:

from django.utils.translation import string_concat
s = string_concat(_("my string"), _("my second string"))

> is that really the way its thought to work? if so, it breaks BC and
> its not handy and intuitive.

Malcolm Tredinnick explains some of the reasons behind the lazy
evaluation of i18n'd strings in this message:
http://groups.google.com/group/django-developers/msg/9e8d5c6123ad48a4


Cheers,

Andrew

--~--~-~--~~~---~--~~
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: Another urlpatterns proposal (add method column)

[Andrew Durdin]

On 10/3/07, Simon Litchfield <[EMAIL PROTECTED]> wrote:
>
> However, using the new-ish urlpattern url() notation would be the go
> here. Just bung a new kwarg on url.__init__() with a default of
> something like None, ALL or *, that would optionally accept values
> like GET, POST, HEAD, etc.

Note that you'd have to consider how reversing the urls should work
also -- would you have to specify the method when reversing,
defaulting to GET?

Andrew

--~--~-~--~~~---~--~~
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: Adding a hook for pre-runtime setup (ticket #5685)

[Andrew Durdin]

On 10/4/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
>
> I wanted to get a feel for people's opinions on using this approach to
> guarantee that certain code is executed before a request is processed
> (or the interactive shell is loaded).
>
> This is necessary (arguably) to setup a listener to class_prepared to
> act on all models, and can be helpful to ensure that other signal
> listeners are registered (no longer need to put listener registration
> in __init__.py or models.py).

Well, that looks like it'll be great for registering listeners (except
perhaps for pre/post_save/delete).  I've not been happy about doing it
from __init__.py, as it smells a bit (and occasionally has ended up
registering a listener more than once).

It might just help me solve another problem I've been having also -- I
need to have some setup code run after all models have been prepared,
but before the first request;  but if I can successfully hook
class_prepared, I can probably use that instead.

A.

--~--~-~--~~~---~--~~
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: Adding a hook for pre-runtime setup (ticket #5685)

[Andrew Durdin]

On 10/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-10-08 at 09:15 -0400, Benjamin Slavin wrote:
> >
> > My immediate thought is that we could allow pre-model instantiation
> > (as proposed in the ticket) and post-model instantiation hooks
>
> I don't think we want to do this. Signals exist already for exactly this
> purpose. Setting up a way to install functions prior to models being
> imported but after settings are imported allows us to cover all cases
> because you can install class_prepared handlers, as Andrew suggested.

Some months ago I asked whether a signal could be sent after all
models are prepared (but before requests were handled).  The reasons
behind this were complex, but it boiled down to being able to examine
a 'Search' attribute of all models to determine what properties needed
to be stored in a full text index.

This can be done with lazy loading and a class_prepared hook, but I
would much prefer to have the search index configuration happen at a
predictable time.  If this could be done with a post-model signal it'd
be great, but I can't see how such a signal would be possible without
modifying Django's startup rather a bit.

A.

--~--~-~--~~~---~--~~
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: Request exception handling and exception middleware

[Andrew Durdin]

On 10/11/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> I think you're completely right about making the exception handler
> into a plain old view; the signature (request, exception) seems right,
> but I haven't thought it through completely yet.

I'd imagine that (request, exc_class, exception, trace_back) would be
more generally useful -- the last three parameters, naturally, being
taken from the tuple returned by sys.exc_info().

Andrew.

--~--~-~--~~~---~--~~
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: Discussion of #4131: addslashes, javascript string literals, and (new) escapejs

[Andrew Durdin]

On 10/17/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
>   However, there are many strings that can be passed through that
> filter and sill will break javascript string literals.

Specifically, as you point out, strings that contain "" --
the main point here is to reduce the chances of XSS attacks when
embedding user-originated data into scripts.

>   4131 now has a patch (from Andy Durdin) which would introduce a new
> defaultfilter named escapejs.  It does the complete job of escaping
> anything that could break out of a string literal.

Credit where it's due;  The meat of the patch is Jeremy's, I just
tidied it up a tad.

Andrew

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

#2539 - Namespacing template tags and libraries

[Andrew Durdin]

Tick #2539 "Custom tags and filters can be restricted by namespace"
was one of the ones I was going to pick up during the django sprint,
but someone else beat me to it.  However, the other day I noticed that
the patch against it was old, and admitted to be incomplete by its
author.  Since namespacing of tags and libraries is such a honking
great idea :) -- and something I've wanted for quite some time, I
decided to put a complete patch together for it.

The patch adds a few tests and docs; the idea has already been
approved by Adrian, so it just needs a review from someone not me to
say if it's ready for checkin or not.


The patch is described in detail on the ticket, but here's an extract:


All tag libraries have an associated fully qualified name, which looks
like "app_name.tag_library_name"; this fully qualified name can be
used instead of the unqualified library_name in the {% load %} tag:

Normally we'd do

{% load humanize %}

But if another installed app has a 'humanize' tag libary, we might need to do

{% load django.contrib.humanize.humanize %}

If more than one installed app has a tag library with the same name,
then the app closest to the start of the INSTALLED_APPS list will take
precedence if the unqualified name is used.

Correspondingly, templatetags and filters are also namespaced -- by
the name of the tag library as given to {% load %}. So you can do
this:

{% load library %}
{% load otherapp.library %}

{% library.mytag %} # Outputs "A"
{% otherapp.library.mytag %} # Outputs "B"

But not this:

{% load firstapp.library %}
{% library.mytag %} # We've not loaded anything as 'library'


Cheers,

A.

--~--~-~--~~~---~--~~
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: #2539 - Namespacing template tags and libraries

[Andrew Durdin]

On 10/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Selfishly I would like to be able to do:
> {% load firstapp.library as mylib %}
> {{ context_var|mylib.myfilter }}

I don't think this would play nicely with the existing {% load
library1 library2 %} syntax.

A.

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

Should GenericForeignKey really implement m2m_*? (was Re: GenericRelation DROP generation problems)

[Andrew Durdin]

On 10/19/07, jdietrich <[EMAIL PROTECTED]> wrote:
>
> Can someone review the patch I've attached to ticket 3480 and verify
> that it is sane? I think that should close out both #3480 and #3549,
> and it seems a bit more kosher than the patch on #3549

It looks OK to me, rather along the lines of the check in
many_to_many_sql_for_model().

There's a larger issue here, though -- from where they're used, I
gather m2m_db_table, m2m_column_name, and m2m_reverse_name are
intended to refer to the intermediate table belonging to a
ManyToManyField; and I think there are a number of other bugs waiting
to happen with GenericRelation's semantically different
implementation.

For example, django.core.management.sql.django_table_list() will
return duplicate table names if a GenericRelation is used, and the
oracle and postgres backends might have issues with sequences being
created or reset more than once.  And there are other places which
could be hiding similar bugs.

Should GenericRelation really implement m2m_*?  Is there another,
better way to enable its query lookups and joins without requiring an
"if not isinstance" check in all code that examines ManyToMany fields
and relations?

A.

--~--~-~--~~~---~--~~
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: #2539 - Namespacing template tags and libraries

[Andrew Durdin]

On 10/23/07, Bruce Kroeze <[EMAIL PROTECTED]> wrote:
> Why couldn't both coexist, but be mutually exclusive?
>
> {% load firstapp.library as mylib %}
> {% load thislib thatlib theotherlib %}

They could;  it would certainly be convenient, and a simple change to
implement, but at the expense of a slight loss in clarity of the load
tag.

I think it's a good idea, but I'm not going to add it into the
ticket/patch unless it gets the ok from one of the core devs.

A.

--~--~-~--~~~---~--~~
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: Calling All Django Developers !

[Andrew Durdin]

On 10/23/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote:
>
> Siliconbits skrev:
> > We are currently looking for Django developers to join us on a
> > freelance basis.

Please take this discussion to the django-users list.  The
django-developers list is for discussion of the development of django
itself.

A.

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