Re: Doc. patch

On Nov 17, 10:10 am, Luke Plant wrote: > Well, if your ticket hasn't received the attention you think it > deserves, then it is, but you waited less than 10 minutes from filing > the ticket! Agreed, perhaps a bit hasty :) But in any case, I just committed it. -- You

Re: RFC: Add a "needinfo" state to triaging

On Nov 14, 5:52 am, Daniel Moisset wrote: > In most cases we sent a reply back > to the submitter asking for more details about their problem, but the > ticket remains in the "Unreviewed" state, still taking the time of > other triagers looking for tickets to review. > >

Re: custom function for autoescape

Thanks for following up, Luke. I understand your point of view, but personally, I'm fine with an "all bets are off using built-in filters/tags" clause on a custom escape method. While you'd expect that addslashes would just work, I'd take the opposite expectation and assume that any filter / tag

Re: custom function for autoescape

Hi Will, I've reopened the ticket, because that's elegant enough for me. I remember having this discussion in IRC either with you or someone else a while back and couldn't come up with any negatives to providing this, as long as obvious caveats of tags/filters potentially relying on the original

Re: staticfiles defaults broke my site

On Nov 3, 1:47 am, Carl Karsten <c...@personnelware.com> wrote: > On Oct 28, 9:45 pm, SmileyChris <smileych...@gmail.com> wrote: > > > My suggestion is that StaticFilesHandler only does its magic if > > 'django.contrib.staticfiles' is found in INSTALLED_APPS.

Re: Git-using core devs: preference for merge vs. rebase?

On Nov 3, 5:58 am, "Tom X. Tobin" wrote: > Do the Git-using core developers have a preference for merge vs. > rebase for updating an upstream-tracking branch?  I prefer to rebase > to keep the changes in question at the branch HEAD, especially if the > branch hasn't been

Re: contrib.staticfiles and runserver

On Oct 29, 2:45 pm, SmileyChris <smileych...@gmail.com> wrote: > doing it by default seems pretty backwards incompatible, even if we I was a bit terse, let me expand. STATICFILES_URL defaults to '/static/'. The StaticFilesHandler (which is now what is used by runserver) swallows

contrib.staticfiles and runserver

It's cool that runserver takes away the hassle of needing to add in your static url (is this documented? I didn't find it in my skim) but doing it by default seems pretty backwards incompatible, even if we are just talking about the dev server. My suggestion is that StaticFilesHandler only does

Re: Ticket #7817: Extending "with" and "include" tags.

On Oct 27, 5:35 am, Łukasz Rekucki wrote: > I would like to bring this up again, because this is something that > would really improve readability of my templates. I'm mainly > interested in ticket #7817 (the include tag changes), but extending > "with" tag (ticket 9456) would

Re: Smart extends

On Oct 16, 8:35 am, Łukasz Rekucki wrote: > Which "x.html" should be chosen ? the one from admin or the one from > external app "A" ? Both are valid uses. There is a dangerous > temptation to say "next that would be loaded after this", but that > depends on loaders and

Re: Smart extends

On Oct 16, 2:09 am, Andrew Godwin wrote: > So, from what I can work out, this is a proposal for an {% extends %} > tag which allows you to extend from the parent template of the same name Just to chime in, I like this proposal. IMO: If a designer wants to override a third

Re: variable view name in url tag

Just throwing the idea out there, it would be possible to keep the tag completely backwards compatible by using a slightly different syntax for variables. Standard non-variable access stays the same: {% url home %}, {% url edit-profile profile.pk %} Variable access is done via a "var=" first

Re: making queryset.delete issue only a single SQL query

On Sep 11, 1:12 pm, Tobias McNulty wrote: > Hi All, > > I may be missing something, but queryset.delete() seems oddly implemented in > Django.  It does a select to get all the IDs to be deleted, and then deletes > them, in blocks of 100 I believe, by ID. It's because

Re: memcached-based-cache - timeout=0 does not work as intended by memcached

On Jul 27, 9:22 pm, Carl Meyer wrote: > The common thread, of course, is making it possible to write reusable > caching code without special-casing particular backends. I agree with Carl. We have an abstracted api - having a property with different meanings for different

Re: Proposal: Revised form rendering

On Jul 15, 1:14 am, Russell Keith-Magee wrote: > We need to be able to define templates for: > >  a) The layout for a single widget (e.g., a DateWidget) >  b) The layout for a single row of a form >  c) The layout for an entire form (top errors, fields, hidden fields) >

Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...

On Jul 13, 9:10 pm, Margie wrote: > Yes, I know from tickets I have posted that modifying exclude > dynamically is "not allowed". Why wouldn't you just modify self.fields? -- You received this message because you are subscribed to the Google Groups "Django

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

On Jul 11, 12:14 am, Russell Keith-Magee wrote: > > So you can't put reverse now in settings.py unless there is some > > late-binding construct, like > > > LOGIN_URL = RevLink('accounts:login', account_type='user') > > You shouldn't have to put reverse() calls into

Re: natural keys and dumpdata

On Jul 10, 1:47 am, Stijn Hoop wrote: > Hi, > > I am trying to use the 'natural keys' feature of django to make a sort > of "future proof" fixture loading possible. > [...] > With the patch linked below[1] I have successfully used dumpdata and > loaddata for a .json export of my

Re: 1.1.2 admin form regression

On May 18, 5:41 pm, Karen Tracey <kmtra...@gmail.com> wrote: > On Tue, May 18, 2010 at 12:45 AM, SmileyChris <smileych...@gmail.com> wrote: > > Can't investigate too much more until tomorrow, but it's a pretty big > > regression so I thought I'd bring it up

1.1.2 admin form regression

Can't investigate too much more until tomorrow, but it's a pretty big regression so I thought I'd bring it up here for discussion as well as starting a ticket. http://code.djangoproject.com/ticket/13556 -- You received this message because you are subscribed to the Google Groups "Django

Re: Process discussion: reboot

:13 am, SmileyChris <smileych...@gmail.com> wrote: > In a similar vein, it'd also be great if under the ticket summary, > some "hooks" based on the current ticket state could be added. -- You received this message because you are subscribed to the Google Groups "Django

Re: Pass Thru Image Proxy Patch Interest?

Yes, I was thinking the other day that it would be a cool solution for serve() to be able to use storage backends On Apr 16, 7:09 am, Kevin Howerton wrote: > Why not just use the backend feature that already exists? > > I have an S3 backend that does this... > > It

Re: Template Compilation

Would whitespace handling be identical to the current template system? -- 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

Re: IfEqualNode is missing a get_nodes_by_type method

On Feb 27, 3:06 am, Russell Keith-Magee wrote: > I'm a little confused by this ticket. > > The original report was about something that is clearly a bug -- the > inconsistency between block handling for {% if %} and {% ifequal %}. > I'm 100% in agreement that this

Re: 404 debug pages should show the name of the tried urlpattern - #9310

olunteer triage team, they haven't been able to keep > up with the backlog. We either need more volunteers to do triage, or > we need to accept as a community that progress isn't going to be as > fast as we may like. More volunteers! Come one people! *SmileyChris blows his triage trumpet* &

IfEqualNode is missing a get_nodes_by_type method

My ticket in #6510 [1] deals with this, along with a nice abstraction of common recursive nodelist gathering patterns. Although the ticket description, comments (and even tests in my patch) mention {% block %}, this has *nothing* to do with conditional inheritance. If the patch is deemed too

Re: How about adding a noop {% csrf_token %} tag to the Django 1.1 branch

Bah! Yes, just like that. However, it would be nice to release a 1.1.2 containing this for those who use released versions as opposed to svn branches before 1.2 hits. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Re: EmailField max_length of 75 characters should be 256 acccording to RFC 5321

> Addressing the limitations of the builtin auth.User is something I > hope to look at in the 1.3 timeframe. In that case, would it be reasonable to have an open ticket for the specific request of being able to customize the length of the email field in the contrib.auth User object? I'm guessing

How about adding a noop {% csrf_token %} tag to the Django 1.1 branch

I was thinking that it would help third-party apps to be able to work across both 1.1 and 1.2 installations without workarounds if the 1.1 branch had a csrf_token tag, just to stop templates choking with a "Invalid block tag: 'csrf_token'" message. Does this fit within the policy for supporting

Re: Possible bug in messages framework?

Looking around, this looks like a problem for other frameworks too (see http://trac.turbogears.org/ticket/1164) If we're to accept that turbogears example, it sounds like we're not properly encoding the cookie in core, rather than patching messages. On Jan 23, 2:23 am, Tobias McNulty

Re: Message level API awkwardness

On Jan 11, 2:12 pm, Russell Keith-Magee wrote: > I concur. get_level()/set_level() sounds like a reasonable change to > me. Can I have that in the form of a ticket and patch? :-) http://code.djangoproject.com/ticket/12575 -- You received this message because you are

Re: Message level API awkwardness

On Jan 6, 11:09 pm, Jeremy Dunck wrote: > I realize I'm very late giving feedback on the API, sorry and feel > free to ignore if I'm too late. > > That said, from the docs, the API to set the effective messaging level > is awkward: > > == > # Change the messages level to

Re: Possible contrib.humanize addition

On Jan 5, 9:24 pm, harrym wrote: > I'm working a templatetag that determines whether to use 'a' or 'an' > in front of English words. My particular use case for this is in a > tumblelog app I'm developing - many different types of entry may be > added (link, html, quote,

Re: Call for feedback: django.utils.signed and signed cookies

On Dec 22, 1:52 pm, Johannes Dollinger wrote: > There's a small bug in b64_decode(), the padding should be >         r = len(s) % 4 >         pad = '=' * (r and 4 - r or 0) Or even simpler: pad = '=' * (-len(s) % 4) -- You received this message because

Re: What do people think about the get_absolute_url proposal?

On Dec 17, 8:57 am, Alex Gaynor wrote: > On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote: > > How's that different than the current situation, where we return an > > absolute URL reference that can be converted into an absolute URL > > using

Re: smart if tag

Because that link intrigued me, I challenged myself to write my own generic lexer & parser based on what I had read: http://gist.github.com/250128 On Dec 6, 2:07 pm, Luke Plant wrote: > On Saturday 05 December 2009 20:09:21 Luke Plant wrote: > > > I'm not likely to able

Re: Should docs.djangoproject.com link to 1.1 frozen docs by default, not SVN dev docs?

This should be a high priority fix. Anyone new to Django and using the installation of 1.1.1 (which the download page recommends over trunk) will currently be unable to follow the tutorial. I was having a face to face meeting today with someone who had exactly this problem. On Nov 6, 1:53 am,

Re: Session/cookie based messages (#4604)

I applied and pushed all but your final whitespace revision. When Tobias reads this thread again, I'm sure he'll give you commit. The fail_silently sounds good, and yes these failures were a rather big oversight. On Dec 2, 10:35 am, Luke Plant wrote: > I've been going

Single lines between top level classes & functions

Prompted by Luke's whitespace removal patch for django-contrib- messages, I thought I'd bring this up. The Django contributing guide says "Unless otherwise specified, follow PEP 8." Should new code use two lines between top level classes & functions, like PEP 8 suggests, or should the

Re: smart if tag

On Dec 1, 6:08 am, Luke Plant wrote: > Given that the 'Null' stuff has now been removed, we could > move back to your way to reduce the code a bit, but I'm not sure it is > worth it. I'd say reduce the code again. And I think you missed adding some files in your repo?

Re: smart if tag

On Dec 1, 6:08 am, Luke Plant wrote: > > I was with you right up until the equality comparisons (Null == > >  Null -> False etc). As noted by Alex, it conflicts with the answer > >  given by {% ifequal %}; it also differs with Python's behavior. > > Yeah, I hadn't thought

Re: smart if tag

On Nov 29, 6:40 am, Luke Plant wrote: > Hi all, > > I started work replacing Django's if with the "smart-if" template tag > by Chris Beaven (http://www.djangosnippets.org/snippets/1350/) Neat! I'm assuming you'll be posting this to your bitbucket soon? :) > 1) Handling

Re: Enhanced debug output colors: django code is green, user code is red.

Just chiming in that I'm also +1 to visual distinction, -1 to current colors. On Nov 3, 4:27 pm, Tobias McNulty wrote: > I'm not a big fan of the red/green either.  They imply that Django code is > "bad" and user code is "good".  What about something more subtle, like >

Re: shortcut proposal

Interestingly, I made a snippet [1] two years ago something like this. Granted, it was a bit more convoluted: you build a decorator and use that everywhere (I was a bit anal about DRY, so you can render a prefix template path for that decorator) Personally, I just use direct_to_template for

Re: shortcut proposal

On Oct 17, 1:51 am, Jacob Kaplan-Moss wrote: > I'd like this shortcut to be (similar to?) Simon's TemplateResponse > (http://code.google.com/p/django-openid/source/browse/trunk/django_ope...). +1 btw --~--~-~--~~~---~--~~ You received this

Re: Session/cookie based messages (#4604)

On Oct 16, 2:04 pm, Tobias McNulty wrote: > Just to make sure I understand this correctly, let me try to summarize > what this would mean: > >  * the proposed app controls {{ messages }} and is responsible for > retrieving anything set in the Message model Thanks to

Re: Session/cookie based messages (#4604)

On Oct 16, 12:03 pm, SmileyChris <smileych...@gmail.com> wrote: > > class LegacyFallbackStorage(FallbackStorage): >     storage_classes = (UserMessageStorage, CookieStorage, > SessionStorage) Here's a working implementation even: http://code.google.com/p/django-notify/

Re: Session/cookie based messages (#4604)

On Oct 16, 5:56 am, Tobias McNulty wrote: > On Wed, Oct 14, 2009 at 10:27 AM, Jacob Kaplan-Moss > wrote: > > I'm trying to avoid having two incompatible messaging systems in > > Django. I agree that linking messages to sessions makes more sense > >

Why does Django make it hard to debug tags?

http://code.djangoproject.com/ticket/11461 DebugNodeList catches all exceptions, sticks them in a TemplateSyntaxError, and stuffs the original exception in the new exception. I'm not sure why this is done, but it breaks debugging and exception handling. What is the advantage of swallowing the

Adding "required" & "error" CSS classes to form rows in as_* methods

It's time for an annual review of http://code.djangoproject.com/ticket/3512 I know that the as_* methods are spat at, but I still find them useful - this is one of the things that would make them that bit more usable. The latest patch (albeit 10 months old) still seems to make sense to me. Bar

ModelAdmin manager

There are currently inconsistencies with how ModelAdmin decides on what query set (i.e. manager) it's using. Issue 1: The change list it uses ModelAdmin.queryset() while the change view uses ModelAdmin.model._default_manager Issue 2: Also, when searching, ChangeList uses the base QuerySet model

Re: Cache and GET parameters

On Nov 2, 2:52 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > Assuming vary_on_get() with no parameters means no variance (other > than the HTTP Vary headers), then [...] That seems confusing - the decorator name seems to imply that it would vary on any get attribute (even though this is the

Re: Proposal: Optional {% default %} clause for the {% for %} template tag

Note, that this is actually a dupe of #3481. Regarding, {% else %}, see what Malcolm said about it - http://code.djangoproject.com/ticket/3481#comment:2 On Oct 29, 1:18 pm, oggie rob <[EMAIL PROTECTED]> wrote: > > {% for item in grocery_list %} > >   {{ item }} > > {% default %} > >   Nothing to

Re: RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)

processors.auth() function a lazy entity so it only hits any > session/DB/messages/etc,etc when 'called' from inside a template or > view. > > bo > > On Oct 27, 6:58 pm, SmileyChris <[EMAIL PROTECTED]> wrote: > > > This is exactly why my patch i

Re: Proposal: Decouple messages from contrib.auth

On Oct 29, 5:50 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote: > From the looks of it, the patch onhttp://code.djangoproject.com/ticket/4604 > is heading this direction > re: backwards compatible and part of contrib.sessions. > > Maybe SmileyChris can speak to both

Re: RequestContext + Auth.middleware 'Accesses the Session' (aka LazyUser ain't that lazy)

This is exactly why my patch in the session messages ticket [1] makes the messages lazy. [1] http://code.djangoproject.com/ticket/4604 On Oct 28, 1:59 pm, bo <[EMAIL PROTECTED]> wrote: > Actually i've found that the issue lies with the > TEMPLATE_CONTEXT_PROCESSORS > >

Re: Proposal: Decouple messages from contrib.auth

I think that auth messages are the wrong way to do it most of the time they are used (including django core code) anyway. They are usually used to inform that an action worked (or didn't) -- this should be done as session messages, not user messages.

Re: Declarative syntax for widgets in ModelForm

Bah, it was just prototype code but point taken ;) I do feel like it leads to slippery slope though. LikeMichael said, "why stop at widgets?" I often need to change labels and help text too. On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > SmileyChris wrote: &

Re: Declarative syntax for widgets in ModelForm

On Sep 28, 1:13 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Joseph Kocherhans wrote: > > On Sun, Jul 6, 2008 at 6:27 AM, Ivan Sagalaev > > <[EMAIL PROTECTED]> wrote: > >> ## Proposal > > >> To fix this I was thinking along the lines of: > > >>     class ArticleForm(ModelForm): > >>        

Re: Template inheritance and {% include %} tags

On Sep 19, 9:17 am, Simon Willison <[EMAIL PROTECTED]> wrote: > 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

Re: QuerySetPaginator object_list type check?

Although, as Alex points out, it should be obvious by the name of the model that it should be passed a QuerySet, I think that the fact that a list has a "count" method means that a sanity check could be helpful for debugging. It's a dead easy change with minimal overheads so go ahead and open a

Re: More secure user password reset

On Jun 29, 9:42 am, Simon Willison <[EMAIL PROTECTED]> wrote: > 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

Re: URL Resolvers: a little refactoring goes a long way

I know that a URL resolver refactor is on Malcolm's neverending todo list. When he starts getting back into it, feel free to remind him of it. :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers"

Re: Paginator Backwards Compatibility Post

You were using a new feature (albeit the wrong one) so that's not really a backwards incompatible issue, is it? On May 6, 1:55 pm, David Cramer <[EMAIL PROTECTED]> wrote: > Can someone add it to the BackwardsIncompatibeChanges page? > > I saw the warning, and briefly skimmed over the page and

"One-to-one semantics changing"

In the db-api docs under "one-to-one relationships", it still reads: The semantics of one-to-one relationships will be changing soon, so we don’t recommend you use them. Is this still relevant after qs-rf? It seems like it is just more "undocumented" than "changing semantics" now.

newforms NullBooleanField / BooleanField

The current behaviour of BooleanField kind of negates the need for NullBooleanField. Contrary to the docs (and I'm pretty sure there's a ticket for it) a BooleanField(required=True) doesn't actually fail validation if a widget. Personally, I like this behaviour better. Would we be losing any

Re: GSoC 2008: Rewrite the Django Comments framework - Django Newcomments

On Apr 22, 1:15 pm, Thejaswi Puthraya <[EMAIL PROTECTED]> wrote: > Hello Django Developers, > > I plan to assist Jacob complete a major portion of the ToDo [1] list > that he has at the current moment. Hopefully by the end of this > summer, the django-newcomments framework will be able to make

Re: #1443: strftime for date and datetime before 1900

On Apr 8, 10:46 am, Mike Axiak <[EMAIL PROTECTED]> wrote: > but if Django were to "support" pre-1900 > dates, then it stands to reason code wouldn't break if written like > this:: > > instance.field.strftime("%Y-%m-%d") Actually, I've backpedalled a bit in my new patch (uploaded just now).

Re: New documentation outline (was: Refactoring the documentation)

I'd suggest moving install to a how-to rather than a topical guide. Perhaps deployment could go under there, too? They seem closely related. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: extends headaches

On Feb 6, 9:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > It already results in a broken site, we're now just being a lot clearer > about that. Actually, it only resulted previously in a broken site if the extended template was being used in more than one depth of inheritance. > >

Session save every request

Just wanted to point out a discussion in django-users which is a bit of a worry regarding session behaviour: http://groups.google.com/group/django-users/browse_thread/thread/f7d7f737a5a76fa4/434e0ae7641153d9#434e0ae7641153d9 Anyway, I'm off on a holiday for two weeks, so I expect to come back to

needs_autoescape property on methods

Haven't really thought about this too much, just wanted to throw the idea out (mainly for Malcolm) Currently, widgets are conditionally escaped [1]. Malcolm points out that "This still isn't perfect behaviour (since it's unaware of the current context's auto-escaping setting)..." If the

Re: Reconsider ADMIN_MEDIA_PREFIX default?

What I find mildly amusing is Malcolm's comment in the ticket [1] which is pretty much the opposite of what he's saying now. In his defence, he did say he would have to think about it for a bit longer ;) In any case, before I wrote the backwards-incompatible patch, I wrote one that is pretty

Reconsider ADMIN_MEDIA_PREFIX default?

http://code.djangoproject.com/ticket/2891 was marked as a wontfix by jacob after "discussion with Malcolm". Neither Collin or myself (or several others on IRC) can see a reason why that this would cause any big disruption. Mr Trier even mentions it on his blog today as an example of a silly

Re: lazy (in utils.functional) is broken

On Dec 17, 6:52 pm, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote: > SmileyChris wrote: > > I've been working on a new version of the session messages ticket and > > was looking at making the "messages" context variable lazy - it seems > > silly how

Re: Better Support for static file serving via django

On Dec 13, 9:19 am, "Robert Coup" <[EMAIL PROTECTED]> wrote: > On 13/12/2007, Thomas Güttler <[EMAIL PROTECTED]> wrote: > > > How can you check that only authorized users can access > > some files? Thomas, you might want to try out http://code.djangoproject.com/ticket/3583 It needs some

Re: Undocumented backwards incompatible change

On Dec 11, 1:01 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I suspect is_active should be False for those users (since they > cannot log in and that's the point of is_active). So I'd probably be +1 > for changing is_active to False on AnonymousUser. Ok,

Re: Fixing app_label

On Dec 10, 2:41 pm, Gary Wilson <[EMAIL PROTECTED]> wrote: > The current app_directories template loader has always bugged me because it > is: > > 1) inefficient - all application template directories are added as global > template directories and are searched each time by the template loader.

Undocumented backwards incompatible change

Changeset 6299 [1] added some "useful" methods and attributes to AnonymousUser. One of these attributes is is_active = True This is a change in functionality, because previously if you used (like I was) {% if user.is_active %}, it would be only true for real users who were active. Now it's true

Re: lazy (in utils.functional) is broken

On Dec 5, 2:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > It only just works :P > > it's called Fit For Purpose. You've yet to demonstrate somewhere in > Django we need all these extra levers of which you speak. The lazy __proxy__ class is full of magical bits, which I don't really

Re: lazy (in utils.functional) is broken

On Dec 4, 4:39 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > lazy() is complex enough without adding things we don't need. I guess this is my point. It seems that lazy() has been made overly complex for little gain. > If there's a legitimate case where Django core needs this extra >

Re: lazy (in utils.functional) is broken

On Dec 3, 6:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > What method? lazy() Maybe I just don't get how it is supposed to work, but the setattr line seems wrong, at least for setting special method names. Also confusing is that the docstring says "Results are not memoized; the

lazy (in utils.functional) is broken

I tried actually using lazy today for something and couldn't get it to work. It seems to me that the current implementation is basically broken. For example, I was trying to do lazy(my_function, list) __proxy__.__init__ tries to setattr(self, k, [promise]), but that won't actually work for any

Re: DB API - the limiting syntax, is it magic?

On Dec 1, 5:00 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > To a python developer who is unfamiliar with django's magic limiting > syntax, the slice there looks unnecessary. If/when we get a __nonzero__ method, it will be unnecessary. --~--~-~--~~~---~--~~

Re: Django 1.0 features -- the definitive list

On Dec 1, 5:24 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > On the issue of what to call 1.0, I like Max Battcher's idea of adopting an > Ubuntu-like date-based version. Puts some useful information (how old is > it?) into the release name and avoids preconceived notions of >

Re: is_safe problem

On Nov 29, 12:29 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Drop them in a ticket and I'll commit them. http://code.djangoproject.com/ticket/6049 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django

Re: is_safe problem

On Nov 29, 9:28 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I've fixed it, after a fashion, in r6721. Why no tests? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this

Re: Proposal of adding default templates argument to admin view functions.

Hi Atsushi, First, if you are going to post code, you should be creating a ticket in our bug management system [1] rather than just putting them in an email here. Second, you can already override admin templates, as explained in the second step of the templates [2] and the exact details are

Re: is_safe problem

On Nov 22, 10:48 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > P.S. However I think you try to shoot yourself in the foot by tying > general unicode representation of an object to work only for HTML. I'd > rather leave it to some special filter. Probably. I'm definitely being lazy ;) But the

Re: django ORM

On Nov 23, 8:18 am, Goutham DL <[EMAIL PROTECTED]> wrote: > Hi, > Iam new to this community. I would like to know more about the django > ORM(i.e its internal workings). Can someone provide some good links > for this? Hi Goutham, If you're new to the community, ensure you have a good

Re: is_safe problem

On Nov 22, 8:46 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > SmileyChris wrote: > > The problem is, that it still gets double-escaped. Django's > > FilterExpression checks to see if the incoming object is SafeData, but > > at this stage it is a Model object - it

Re: is_safe problem

PS: I've never even noticed the built-in `capfirst` filter until just now, but mine was pretty much identical. The built-in one doesn't solve this problem either. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups

is_safe problem

So my template looks like: {{ group|caps }} (`group` is a Model object and the `caps` filter just capitalizes the first letter) and I'm stuck with double escaping. The problem is, that it still gets double-escaped. Django's FilterExpression checks to see if the incoming object is SafeData, but

Re: one django command (was: Re: django-admin.py can't access user-supplied commands, even if --settings option is provided)

On Nov 15, 6:02 pm, Gary Wilson <[EMAIL PROTECTED]> wrote: > Would it be crazy if we got rid of django-admin.py and manage.py and replaced > them with one "django" command to rule them all? Sounds great to me! --~--~-~--~~~---~--~~ You received this message

Should string constants in template filters should be marked safe?

Just noticed an escaped string in my template due to: {{ image.caption|default:"No caption" }} It seems like to me that we should trust that string constants in template variable tags are safe since they are directly in the template author's realm, yes? The only way I could figure out how to

Re: An addendum to the escaping proposals

On Nov 15, 7:55 am, Luke Plant <[EMAIL PROTECTED]> wrote: > You would have to change the middleware so that it does > its 'rejection' business in process_view() instead of > process_request() -- it would check the view for the flag, and require > the CSRF token if it wasn't found. > > To me, this

auth messages should be lazy

It seems silly that currently the auth message system calls get_and_delete_messages for every request context (assuming you have the auth context processor enabled, like it is by default). 1. You lose messages if you don't actually check for them 2. If you didn't check for it, and therefore

Re: form_for_instance and form argument, empty form?

On Nov 8, 4:30 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > When you pass in a subclass of Form, it's already got its fields in > the right place, but more importantly, it triggers that syntax > checking again, where it looks for new fields. It basically copies > fields from a parent class,

newforms SortedDictFromList needed still?

[6506] fixed #5744. Do we still need django.newforms.forms::SortedDictFromList? The only thing which the newforms code has extra is its own copy function which uses deepcopy. I'm at a loss to see why we're using it there and not on the main SortedDict copy method.

newforms required/error CSS decoration

We have two independent approaches to the problem: #3512 [1] and #3515 [2]. IMO 3512 handles the problem better, but then I'm biased because I provided a patch for that one :) Could we have a committer's design decision on the overall issue? How (if at all yet) is this handled in

  1   2   3   >