On Sep 18, 6:39 pm, Michael Elsdörfer <[EMAIL PROTECTED]> wrote:
> I remember this coming up on django-users and IRC once or twice, and
> never thought too much about it, but currently, template inheritance
> and includes don't work together at all:
>
> * Blocks included in a parent template
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
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
On Sep 12, 7:45 pm, Brent Hagany <[EMAIL PROTECTED]> wrote:
> As far as I can tell, the argument about being portable is a good one,
> and if that ends up being the reason this doesn't get in right away,
> then I can't complain. However, the part about the single server
> making this more
On Sep 12, 10:46 pm, TP <[EMAIL PROTECTED]> wrote:
> > This means an ORM object should have a
> > special property on it recording which database connection it was
> > loaded from. It also presumes we won't ever want to support the case
>
> I apologize for my ignorance as to how django DB
On Sep 12, 5:11 pm, mengel <[EMAIL PROTECTED]> wrote:
> > obj = Article.objects.using('master').get(pk = 4)
> > obj.name = 'Hello'
> > obj.save(using = 'master')
>
> Shouldn't the object remember the database used to fetch it, and
> save() should save it back there? Then you would only have to
On Sep 10, 10:55 pm, ab <[EMAIL PROTECTED]> wrote:
> For the api to accept a DSN, alias, or connection anywhere would add
> similar code in multiple places. I propose that the aliases are mapped
> into django.db.connections. For your example, you could use
> django.db.connections.archive.
I'm
On Sep 10, 10:44 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Well... To be sure save() should always go to master because on slaves
> you just don't have permissions to save anything. So a parameter to
> save() is redundant.
It's redundant in the case of a single master, but there are other
On Sep 10, 10:24 pm, "Mike Malone" <[EMAIL PROTECTED]> wrote:
> At Pownce, for example, we stick users to the master database for some
> period of time (a couple of seconds, usually) after they post a new note.
> The problem here (as Malcolm pointed out) is that related managers use the
> default
On Sep 10, 10:15 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Simon Willison wrote:
> > * Simple master-slave replication: SELECT queries are distributed
> > between slaves, while UPDATE and DELETE statements are sent to
> > the master.
>
> It won't work
On Sep 10, 9:18 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Oh, please, no! Registration is a very fragile process. It simply
> doesn't work very well. It's a bit disappointing that it's the way we
> have to do things that way in places in Django and if we can avoid it
> elsewhere that'd
On Sep 10, 5:29 pm, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> To avoid adding yet another setting (unless it's warranted here) can
> the setting of a doctype in a template tag set a value in
> django.conf.settings that django.forms can then check (with a
> reasonable default)?
>
> I recall seeing
On Sep 10, 7:17 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Also, as a general thing here, did you go back and read the various
> discussions we had about API when the multi-db Summer of Code project
> was running? If not, that would be worth doing and incorporating, since
> we debated a
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
On Sep 10, 3:32 am, Ville Säävuori <[EMAIL PROTECTED]> wrote:
> About the {% doctype %} tag, should we then maintain a (potentially
> long?) list of different doctypes and/or should there be a way to
> define your own?
I think we should maintain a list of doctypes - there really aren't
that
On Sep 8, 6:03 am, akaihola <[EMAIL PROTECTED]> wrote:
> I couldn't find a ticket for this issue yet. Simon, mind if I create a
> ticket and dump your description of the issue there?
I've filed it here:
http://code.djangoproject.com/ticket/9002
On Sep 10, 12:24 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> OK, enough noise on the naming.
(I really like metronome)
> Let's talk about what it should be and what should be measured. :)
> (I suspect some devs already have a sketch regarding this stuff.
> Please share.)
>
> Do we want it
Back in March there was a discussion about providing a way to output
django.forms widgets as HTML (at the moment they always use XHTML,
which leads to nastyness on sites using an HTML doctype):
http://groups.google.com/group/django-developers/browse_thread/thread/5f3694b8a19fb9a1/
On the plane
On Sep 8, 5:36 am, Erik Allik <[EMAIL PROTECTED]> wrote:
> I'm glad this came up, because I would also like to recommend
> considering an admin interface for models that use django-mptt. I know
> django-mptt is an external project but I think many people are using
> django-mptt as it's
On Sep 8, 2:46 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I don't think this would be too hard to implement either. The URL
> routing would have to be redesigned though, as it is currently not
> very flexible. Maybe something like the following to edit multiple
> objects on the same
On Sep 7, 10:03 pm, akaihola <[EMAIL PROTECTED]> wrote:
> I couldn't find a ticket for this issue yet. Simon, mind if I create a
> ticket and dump your description of the issue there?
Go for it!
--~--~-~--~~~---~--~~
You received this message because you are
I wrote up a work-around for this issue a while ago. If you need to be
able to over-ride your "base.html" template with a new template also
called "base.html" you can do it by adding an overall parent directory
to your TEMPLATE_DIRS setting which allows you to provide a fully
qualified path to
On Aug 19, 1:39 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> (And you know, I still think we'd be better off with
> "django-YES-THIS-ONE" and "django-NO-THE-OTHER-ONE". Or perhaps a tad
> more seriously, something like "django-community" and "django-core" —
> otherwise we'll be fighting this
On Jun 28, 11:21 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> MD5 is 8 chars shorter. Do we really need SHA-1? If I understand
> correctly, the only known vulnerability with MD5 is the ability to
> force collisions, but that will not help an attacker in this case.
> The only thing that an
On Jun 28, 10:01 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> If you add the timestamp into both the hash and the token then you can
> achieve a more granular expiration policy.
That's the approach I use for djangopeople.net - the problem is that
including the timestamp lengthens the URL yet
On Jun 28, 12:29 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> https://example.com/reset/34-7127f83ebf8ce7ed22bdc50a50572a30
>
> i.e.
>
> https://example.com/reset/{uid}-{hash}
I've been playing with this a bit and the one thing that was
concerning me is that the UID on large sites can end up
On Jun 28, 7:58 pm, "Adi J. Sieker" <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> > That's absolutely ingenious - that approach gets my vote. I think I'll
> > switch DjangoPeople over to that.
>
> and to have the token expire you could add the date of the following day
> into the
On Jun 28, 1:39 am, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> I don't think it's necessary to implement this in such a way that additional
> server state is stored. Instead, you could let the confirmation token be a
> hash of the internal user state -- including, most importantly, the user
>
On Jun 28, 1:12 am, Luke Plant <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] said the following:
> > I'd suggest making the code to change the password a one-use-only
> > item though, so that even if someone did sniff the code, it'd be
> > useless after that.
>
> The problem with this is it
On Jun 26, 8:14 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Documentation of the new features is can be found in
> ``docs/upload_handling.txt``
> orhttp://code.djangoproject.com/git/?p=django;a=blob_plain;f=docs/uploa
Just a small thing:
"""
Like any data supplied by the user, you
On Jun 16, 10:00 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I have just added a patch that allows a simple_tag to receive the
> context as first argument, like inclusion_tag already does. It is
> backward compatible.
>
> I'd like to get some feedback on the code, so feel free to check it
>
On Jun 14, 12:26 am, Devin <[EMAIL PROTECTED]> wrote:
> So to integrate Selenium tests with the test framework already in
> place, I've added live server support for TestCase for ticket
> 2879.http://code.djangoproject.com/ticket/2879#comment:27
That's pretty cool. Any chance you could provide
On Jun 1, 8:20 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> So, how about an idea of adding request, object, and action to
> ModelAdmin instances in newforms-admin code rather than in user code
> and refactoring newforms-admin code based on this decision?
We've used that exact trick recently
On May 29, 12:21 am, "Honza Král" <[EMAIL PROTECTED]> wrote:
> We had some discussions during PyCon in Chicago, the biggest issue we
> have with the hooks is the amount of code needed to change the widgets
>
> we talked with Joseph about something like widget-sets, a mapping prom
> either field,
We (GCap, large commercial radio company in the UK) have been
developing against the newforms-admin branch for a few months now, and
based on that experience I have a number of suggestions for simple
hooks that could be added to make it easier to customise.
1. Provide a custom template for a
On May 22, 6:53 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Simon Willison wrote:
> > Thankfully Ivan Sagalaev's confusingly named mysql_cluster
>
> BTW does anyone have a suggestion how to rename it? I've picked
> mysql_cluster simply because I didn't know that there
I have to admit I'm slightly worried about the multi-database
proposal, because at the moment it doesn't seem to solve either of the
multi-db problems I'm concerned about.
The proposal at the moment deals with having different models live in
different databases - for example, the Forum
On May 15, 11:36 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> I've been using twill integrated into Django unit tests (as described
> here:http://www.djangosnippets.org/snippets/665/), but came across
> the problem that exceptions are hidden by Django's exception
> handling, so it's very difficult
On May 14, 3:51 pm, Ken Arnold <[EMAIL PROTECTED]> wrote:
> 4. Other tags and filters, like include, ssi, and truncatewords (from
> a quick scan) that perform some function that could fail, should mark
> that failure very clearly in the output. (Those two currently do, but
> the error string is
On May 14, 3:02 pm, George Vilches <[EMAIL PROTECTED]> wrote:
> On May 14, 2008, at 9:58 AM, Simon Willison wrote:
> > Silent errors are bad. If we were to remove them, how much of a
> > negative impact would it have on the existing user base?
>
> I suspect that a
Hi all,
Some time in late 2003, Adrian and I decided that errors in templates
were best handled silently - the idea was that it would prevent
untrained template editors from being able to 500-error a site with a
typo.
Is it too late to reconsider this decision, four and a half years
later? I
if you have any more
questions.
http://groups.google.com/group/django-users/browse_thread/thread/1d3cd3bcd0bb3e6b
Best regards,
Simon Willison
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&quo
On Apr 27, 6:37 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> - The slow operation is resetting the database. As far as I know,
> there isn't much that can be done about this. No matter which way you
> do it, deleting a whole lot of data then re-establishing database
> structure is an
On Apr 27, 1:59 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Its mostly there as a convenience for the really simple cases. There
> some duplication in typing annotate(avg_height=Avg('height'), so the
> shortcut is a convenience. IMHO, this is the sort of thing could be
> easily
On Apr 27, 4:04 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I merged queryset-refactor into trunk just now. This was changeset
> r7477.
Fantastic! Congratulations, and thank you.
One of my favourite new features is the ability to more easily see the
SQL that is going to be run against
On Apr 26, 12:33 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> So - here's a slightly modified proposal. Last time this topic came up
> on django-dev, Justin Fagnani made an interesting suggestion which I
> think will answer your objections, and leaves open some interesting
>
On Apr 26, 7:34 am, "Ian Kelly" <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 25, 2008 at 11:40 PM, Russell Keith-Magee
>
> <[EMAIL PROTECTED]> wrote:
> > > Have you considered syntax that looks like this instead? :
> > > >>> Students.objects.all().aggregate({'average_height': 'height__avg})
> >
On Apr 20, 11:23 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> -1 for the reasons that James Bennett stated above. That it crashes
> and burns in production is actually a feature in this case.
If we want to crash and burn if you use DEBUG=True in production we
should do that explicitly,
On Apr 17, 5:04 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> Middleware is easy to set and forget. Is there a reason not to make
> SecureForm the default, and InsecureForm for people using Ajax? ;-)
I'm pretty sure we can handle the Ajax case by not doing CSRF token
checks if
I've noticed that a LOT of people get bitten by the problem where
every SQL statement is logged if DEBUG=True, resulting in huge memory
consumption after a while. This problem seems particularly common for
import scripts, which are often run in development (hence with DEBUG
on) and can involve
Here's something that has been quietly bugging me about Django for /
years/:
Context() is an implementation detail of the template engine. Having
to instantiate a Context just to pass it to render() is unnecessary
boilerplate (and means you have to import another symbol as well).
http://code.djangoproject.com/ticket/6776
newforms-admin raises an AlreadyRegistered exception if you attempt to
register a model with admin.site twice. Unfortunately, due to the
different places and ways in which a models.py file can be imported
it's extremely easy to trigger this accidentally,
On Apr 7, 8:19 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Mon, Apr 7, 2008 at 9:09 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I'm also mostly in agreement here.
>
> As am I. Syntax is tough, of course; here's my two cents::
>
> form = ModelForm(model=Person,
On Apr 7, 2:15 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > I'd still like to see form_for_model stay (or be replaced by the above
> > or similar) rather than being deprecated.
>
> Personally I don't see much call for it; dynamically building a
> ModelForm is easy enough, and maintaining
On Apr 7, 2:15 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > I'd still like to see form_for_model stay (or be replaced by the above
> > or similar) rather than being deprecated.
>
> Personally I don't see much call for it; dynamically building a
> ModelForm is easy enough, and maintaining
On Apr 7, 1:05 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> I suppose I could dynamically
> construct a ModelForm subclass at runtime (any pointers on how to do
> that, including dynamically creating the inner class called "Meta",
> would be welcome) bu
form_for_model is marked as deprecated but ModelForm does not appear
to be a full replacement for it. Given an arbitrary model class (i.e.
one that is defined at runtime, not at "compile" time) there is no
clear way of creating a form from it using the ModelForm mechanism.
Here's what I am doing
't seem to have made any
changes that would result in a substantial speed increase.
Cheers,
Simon Willison
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this grou
On 17 Dec 2007, at 08:08, James Bennett wrote:
> This means the default implementation can happily use
> django.contrib.auth and the existing is_staff flag and permission
> system, but that using something else is as easy as subclassing and
> overriding the right methods. And with a little
On 8 Dec 2007, at 20:14, Kevin Menard wrote:
> Shifting to a more personal stance, I never cared much for the term
> "Web 2.0". It seems too gimmicky. That's largely the impression I
> get with a Django 2.0 without a prior Django 1.0.
The other problem with Django 2.0 is that Rails just
On 4 Dec 2007, at 13:26, bobj wrote:
> Simon - These are GREAT!!! Ideas. The regular expression based URL
> dispatching replacement has been something I personally have been
> thinking about for some time. I would be interested in helping with
> this If you put together a proposal. One URL
On 3 Dec 2007, at 08:15, James Bennett wrote:
> At that point I'd wonder why Django had any machinery for
> request/response processing, middleware, etc., given that what you're
> describing is more neatly handled by just writing a WSGI application
> and taking advantage of the existing tools.
On 3 Dec 2007, at 15:45, Malcolm Tredinnick wrote:
> -1 from me.
>
> I've already responded at least three times on the users list why this
> wouldn't be a good idea. We should indeed do a release after that
> stuff
> is merged. It will be called 1.0 (or 2.0 or whatever).
Ta, should have
It's fantastic that 1.0 (or whatever it ends up being called) is now
under serious discussion, but are there any plans for a numbered
release before then? I've been asked by a few people if they should
be running svn or a numbered release - with auto-escaping now in
trunk it seems a new
On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> What am I forgetting?
It's probably too big a feature to start talking about now, but I'd be
really interested in seeing Django applications (in particular the
URLconf part) unified with the concept of a Django view, so a Django
On Dec 1, 2:02 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> Here's an idea that's been kicking around in the back of my head for
> far too long: Django Enhancement Proposals, or DEPs.
For further context it's worth reading PEP 1, which describes PEPs and
how they work:
http://ww
Here's an idea that's been kicking around in the back of my head for
far too long: Django Enhancement Proposals, or DEPs. At the moment,
large changes to Django (auto escaping, queryset refactor etc) are
discussed in quite an ad-hoc way - if you want to stay completely up
to date on them you need
On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I think we ought to call the release 2.0.
I'm -0.5 on this (if that's possible). I understand the thinking
behind it, but "1.0" isn't an arbitrary version number - it has a very
specific meaning: "the APIs are frozen, it's safe
On Aug 2, 9:39 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Yuck, clients that don't speak HTTP correctly make me angry.
>
> Reading the RFC, though, I see that since HTTP 1.0 made "charset"
> optional, it remains so in HTTP 1.1, and we're supposed to "guess" and
> use ISO-8859-1 like
On Aug 1, 7:56 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> Set autoescaping on by default for anything ending in ``.html`` (and,
> perhaps, ``.htm``), and off otherwise.
I've been thinking about this a bit, and it seems like it could work
well if it was done the other way round - basically,
On May 25, 1:25 pm, "Clint Ecker" <[EMAIL PROTECTED]> wrote:
> Should they be every week regardless of whether there were 1 or 10
> worthy developments, or should the author wait until X number of good
> links have been culled until a post is made, no matter the time in
> between posts. I might
On May 11, 4:23 pm, Niels <[EMAIL PROTECTED]> wrote:
> > Or you could use the traditional
> > Unix password invalidator -- "!" -- which might be more mnemonic for
> > some people and is easier to pick out of a data dump than a space (and
> > will also never be a valid string, since we use '$' as
On May 11, 3:40 pm, Martin Winkler <[EMAIL PROTECTED]> wrote:
> > Certainly Oracle treats them empty string as equal to NULL. But does
> > that mean you can't put an empty string in a "not NULL" column in
> > Oracle?
>
> Exactly. If you want to insert something meaningless into a column that
>
On May 11, 7:50 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > At the moment, django.contrib.auth does not support creating a user
> > account without setting a password.
>
> Why not generate a random one? It won't break an ability to authenticate
> using OpenID or any other backend for that
I'm working on a new component for my Django OpenID package which will
provide support for associating one or more OpenIDs with a
django.contrib.auth User. As part of this, I want to include the
ability to register for a new user account using an OpenID instead of
a password.
At the moment,
James Bennett wrote:
> On 8/9/06, Jason Huggins <[EMAIL PROTECTED]> wrote:
> > I can see how a policy like that is "tricky"... What's to keep an evil
> > blackhat from subscribing to the very same list so he he knows when to
> > get busy cracking sites using the same information?
>
> I've been
On 28 Jul 2006, at 13:06, Todd O'Bryan wrote:
> What if we deprecated {{ }} and replaced it with an escape tag and a
> raw tag? It would keep backward compatibility, but would encourage
> people to use escaped strings unless they have a reason to use raw
> ones. I suppose we don't really have
On 28 Jul 2006, at 01:50, Ahmad Alhashemi wrote:
> Default escaping couples the Django templates with HTML. I don't think
> that this is a good idea, even if HTML is, incidentally, the most
> commonly used language in templates, for the time being.
Here's an idea I don't think anyone has
On 27 Jul 2006, at 21:01, Tom Tobin wrote:
> From what I recall of conversations on the subject, default behavior
> will not be changed to auto-escape. Auto-escaping, under whatever
> proposal is accepted, will require some form of action to enable.
I like to think that's not set in stone yet.
On 19 Jul 2006, at 15:43, David Larlet wrote:
> I'd like to know if it's possible to have access to django slides of
> Simon's conf at Europython 2006.
I've uploaded my slides to the conference site:
http://indico.cern.ch/contributionDisplay.py?
contribId=26=9=44
They're a 22 MB PDF file.
On 19 Jul 2006, at 15:30, Ivan Sagalaev wrote:
> I just thought that may be they shouldn't. If META is a reflection of
> CGI's environment that is derived from HTTP environment that is
> essentially in byte strings then I think META being unicode is may be
> useless and misleading.
>
> Instead
On 19 Jul 2006, at 14:37, Gábor Farkas wrote:
> 1. request.META should contain raw bytestrings (like it's currently)
> 2. request.META should contain unicode strings. for QUERY_STRING, we
> should convert it to unicode using the 'ascii' charset. and we should
> not url-decode it.
request.META
On 19 Jul 2006, at 13:19, Ivan Sagalaev wrote:
> Talking about QUERY_STRING... While the string itself is in ASCII
> it has
> urlencoded data and there the encoding matters. As fas as I can see in
> practice browsers tend to encode those data in the same encoding as
> the
> page from where
On 18 Jul 2006, at 23:30, gabor wrote:
> 1. django publishes the whole environ dictionary as request.META. the
> environ dictionary is a normal byte-string dictionary. so, should we
> convert it to unicode so that the request.META dictionary only
> contains
> unicode strings?
>
> 1.a: if yes,
On 18 Jul 2006, at 16:19, Tyson Tate wrote:
> Is there any way I can get a response on this? I really hate to be
> annoying and pedantic, but the following problems are literally show-
> stopper problems for my Django projects and they're holding up what
> is otherwise a working project. I
On 14 Jul 2006, at 03:05, Malcolm Tredinnick wrote:
> Is there any alternative to creating an escaped_unordered_list tag?
> (Any
> better name for this tag? It's too long)
Yes. Implementing the auto escape proposal.
> [Note: useful responses to this question do not include "auto-escaping
>
On 12 Jul 2006, at 02:28, Malcolm Tredinnick wrote:
> I approached things from a different direction, though, more
> concentrating on how to unit test templates and views (as in not
> requiring a full end-to-end application setup in order to test
> them). So
> it's actually a orthogonal to
On 5 Jul 2006, at 15:21, Jacob Kaplan-Moss wrote:
> Er, no -- that PEP was actually rejected. My impression is that the
> str/unicode distinction won't be eliminated until Py3k.
Guido's keynote at EuroPython confirmed that - one of the big changes
in Py3K (which is now planned for an
On 6 Jul 2006, at 05:09, SmileyChris wrote:
> Does the template source *need* to provide information on what is
> escaped or not?
>
> The view is handling a lot of the output format anyway, I personally
> don't see a problem with looking there to see how a template is being
> escaped.
>
> Then
On 28 Jun 2006, at 17:45, Malcolm Tredinnick wrote:
> But I wanted to find out if there was a reason for this behaviour
> in the
> original design (Adrian? Jacob? Simon?). Did you have something in
> mind
> to work around it? Or was it a case of "never came up before"?
I can't think of any
On 28 Jun 2006, at 15:32, Adrian Holovaty wrote:
> The only big problem I see is that it could confuse the (unfortunately
> large) mass of programmers who don't understand Unicode yet. That is a
> big potential pitfall.
That's very true. The documentation overhead will be considerable. It
On 28 Jun 2006, at 14:43, Andrey Golovizin wrote:
> Unicode awareness may seem not a big issue for English-speakers
> (for whom
> plain ASCII is perfectly enough :)), but for others (like me) it's
> of crucial
> importance.
I don't think that's true. On today's Web there's no guarantee at
On 26 Jun 2006, at 11:51, Daniel Poelzleithner wrote:
> What i still missing is a possibility to use other values to find the
> right view (most likely the http host header).
> I suggested http://code.djangoproject.com/ticket/1192 but Adrian
> doesn't
> like it for some reason I can't
On 26 Jun 2006, at 11:04, Malcolm Tredinnick wrote:
> Another thing we need to document better here, because this claim
> is not
> quite correct (didn't you help write this?).
D'oh. No, the pattern prefixing stuff was nothing to do with me. Not
sure how I missed that trick!
Cheers,
Simon
I've been playing around with making the URL resolver accept a
callable in addition to accepting 'module.blah' strings, and I think
it's a big improvement.
The change itself is very simple - when a URL is resolved, callable
(callback) is used to decide if the callback is already a callable
On 22 Jun 2006, at 04:50, James Bennett wrote:
>> following that, I think Django should, of the two options, cover the
>> majority, which I believe is "escape by default" and allow {%
>> autoescape off %}. For the sake of security, I'm really hoping to see
>> escaping automatically turned on.
>
On 22 Jun 2006, at 08:48, James Bennett wrote:
> For given values of "validate", yes. It is, however, easy to write
> validator functions which will reject anything that looks like HTML,
> and HTML is the most important threat.
I disagree that it's easy to write that kind of validator function
On 20 Jun 2006, at 16:25, James Bennett wrote:
> Security by annoyance is security that people learn to hate and turn
> off as soon as they can, so in the end it doesn't really make them any
> more secure than they were before.
Agreed - which is why I want to try it in a branch and see if it's
On 20 Jun 2006, at 15:11, Michael Radziej wrote:
> But, looking at the recent bugs in the Admin:
>
> 2006, __str__() output not escaped in breadcrumbs and filters
> 2152, username was not escaped
>
> Perhaps neither of this would be fixed with auto-escaping. But I
> want to
> emphasize that
On 20 Jun 2006, at 12:15, Michael Radziej wrote:
> Perhaps it's also a good idea to add an attribute `raw` to the
> class `escaped`, so that
> you can always access the raw string when it is necessary. In some
> circumstances, such
> as when you pass a complete html table in the context,
101 - 200 of 256 matches
Mail list logo
