django.template refactoring (again) #7806

The proposal and motivation are essentially the same as in the last thread [1] and the ticket description [2]. I put it on the 1.2 feature list. I tried to split my patch into smaller, more readable commits here: http://github.com/emulbreh/django/tree/master I haven't converted defaulttags,

Re: django.template refactoring (again) #7806

django.template.defaulttags, django.template.loader_tags, django.templatetags.i18n, django.templatetags.cache, django.contrib.comments are now converted. All tests pass. Mostly unmodified: -# Basic filter usage with space between a variable and filter pipe -

Sequence Literals in Templates

I'd like to propose python-like tuple syntax for templates and grouping brackets for filter expressions. {% for x in ("default", var, f|exp) %} ... {% endfor%} {{ x|yesno:("yes", "no", "maybe") }} {% something (1,2,3,4)|slice:(start, stop) %} {% if x|contains:(foo|last) %} ... {% endif %}

Re: Adding signing (and signed cookies) to Django core

How about Signer class? signer = Signer(key=...) assert signer.unsign(signer.sign(value)) == value This way you wouldn't have to pass around key, extra_key, and potential further arguments but a single Signer instance. Plus, you could easyly overwrite hashing, concatenation,

Re: Adding signing (and signed cookies) to Django core

> Would expire_after on the unsign just automatically imply > timestamp=True? There's been a lot of concern raised about parity in > the API, and it reads a little weird with the two different arguments. > I'm not sure it's a problem, but it's just a little funny. Regarding parity, let me

Re: django.template refactoring (again) #7806

Ping. Anyone? --~--~-~--~~~---~--~~ 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

Re: django.template refactoring (again) #7806

>> Variable and FilterExpression will be deprecated as they require the >> caller to know the length of the expression in advance. > > I'm not sure I follow this assertion. I have no problem believing > FilterExpression can be made cleaner, but Variable takes an expression > like

Re: django.template refactoring (again) #7806

Am 29.09.2009 um 04:07 schrieb Russell Keith-Magee: > > On Tue, Sep 29, 2009 at 12:44 AM, Johannes Dollinger > <johannes.dollin...@einfallsreich.net> wrote: >> >>>> Variable and FilterExpression will be deprecated as they require >>>> the >

Re: Adding signing (and signed cookies) to Django core

Am 25.09.2009 um 22:04 schrieb Simon Willison: > > On Sep 25, 4:44 pm, Johannes Dollinger > <johannes.dollin...@einfallsreich.net> wrote: >> Regarding parity, let me advertise a Signer object again: >> >> signer = signed.Signer( >>

Re: Call for feedback: First GSoC patch ready to land

The m2m-refactor patch breaks ManyToManyFields on abstract models: "AssertionError: ForeignKey cannot define a relation with abstract class A" {{{ class R(models.Model): pass class A(models.Model): r_set = models.ManyToManyField(R, related_name="%(class)s_set") class Meta:

Re: #7539 (ON DELETE support) aka ORM-09 - A call for feedback

Am 10.11.2009 um 17:22 schrieb Michael Glassford: > > I haven't had a chance to look at the patch yet, but what you describe > here sounds good. I don't have any problem with you "hijacking" the > work. > > Did your patch deal at all with the unit tests in my patch that > intentionally failed

Re: #7539 (ON DELETE support) aka ORM-09 - A call for feedback

Am 11.11.2009 um 17:50 schrieb Michael Glassford: > > Johannes Dollinger wrote: >> >> Am 10.11.2009 um 17:22 schrieb Michael Glassford: >> >>> I haven't had a chance to look at the patch yet, but what you >>> describe >>> here sounds

Re: Template Caching - Ticket #6262

Am 16.11.2009 um 15:31 schrieb Russell Keith-Magee: > On Mon, Nov 16, 2009 at 10:04 PM, Alex Gaynor > wrote: >> On Mon, Nov 16, 2009 at 8:58 AM, Russell Keith-Magee >> wrote: >>> On Thu, Nov 12, 2009 at 9:15 AM, Mike Malone

What's the expected behavior of (cached) instances of deleted objects?

QuerySet.delete() currently sets the primary key and all nullable foreign keys (to deleted objects) of instances passed to signal handlers to None. No cache is updated. Model.delete() will do the same, but as these instances are collected by traversing related object descriptors all reverse

Re: What's the expected behavior of (cached) instances of deleted objects?

Am 26.11.2009 um 12:09 schrieb Russell Keith-Magee: > On Thu, Nov 26, 2009 at 5:39 PM, Johannes Dollinger > <johannes.dollin...@einfallsreich.net> wrote: >> >> Am 26.11.2009 um 03:47 schrieb Russell Keith-Magee: >> >>> On Thu, Nov 26, 2009 at 12:04 AM,

Re: Multiple database support: Request for feedback and testing

Am 05.12.2009 um 06:36 schrieb Russell Keith-Magee: > [...] >> What if the admin was instead fixed >> by providing facilities for the more general case outlined above? >> >> What would this look like? I'm picturing another setting (bleh) that >> maps apps and/or models to specific databases.

Re: #7539 (ON DELETE support) aka ORM-09 - A call for feedback

Ping. Since it's a non-trivial patch and there has been (almost) no feedback, is it save to assume that #7539 is not in scope for 1.2 ? Am 07.11.2009 um 01:31 schrieb Johannes Dollinger: > > There's a new patch on the ticket[1], based on Michael Glassford's > work, that solves a few

Re: Ticket #3349 patch review

Am 14.12.2009 um 10:53 schrieb 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? >

Re: Ticket #3349 patch review

Am 15.12.2009 um 19:57 schrieb 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

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

There's a small bug in b64_decode(), the padding should be r = len(s) % 4 pad = '=' * (r and 4 - r or 0) I'd like some more kwargs to Signer and TimestampSigner. Mostly what's in http://dpaste.com/136418/ (except the `separator` kwarg, which was a bad idea as it depends on

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

Am 22.12.2009 um 08:20 schrieb Simon Willison: > On Dec 22, 12:52 am, Johannes Dollinger > <johannes.dollin...@einfallsreich.net> wrote: >> I'd like some more kwargs to Signer and TimestampSigner. Mostly >> what's >> inhttp://dpaste.com/136418/(except the `separa

Re: Abstract models and their managers

Hi Steve, Multiple inheritance with abstract models works, and mostly did since the feature was added afaict. I use it regulary. Just stay away from diamond inheritance and multi-multi-table inheritance. Regarding your managers: couldn't you just use inheritance explicitly? class

Re: Class based generic views in 1.3?

Am 17.06.2010 um 18:23 schrieb Ian Lewis: The example he provided isn't terribly good but you don't need an view instance per request (the example will work unless you start adding stuff to self or overwriting self.qs etc). Only shared state is stored at the class level and view customization

Re: #6735 -- Class based generic views: call for comment

Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: > I've just added a summary of the last thread on class-based views [1]. > This summary isn't 100% complete -- any contributions from interested > parties are welcome. Try to keep opinions to a minimum; this page is > about documenting the

Re: #6735 -- Class based generic views: call for comment

Am 01.10.2010 um 18:07 schrieb Luke Plant: > On Fri, 2010-10-01 at 12:16 +0200, Johannes Dollinger wrote: >> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: >>> I've just added a summary of the last thread on class-based views >> [1]. >>> This summary isn't 1

Re: combining querysets with isnull

Am 14.10.2010 um 23:07 schrieb Dan Watson: > There seems to be some inconsistent behavior when combining querysets > that use isnull on a ForeignKey. I'm not sure how to explain it well > in plain english, so here's a boiled-down example: > > # Models > > class Item (models.Model): >title

Re: Feature proposal: escape hatch for colliding template syntax in django templates

Am 20.10.2010 um 10:40 schrieb Andrew Godwin: > On 20/10/10 02:40, Stephen Kelly wrote: >> Sorry. Sent too early. All thumbs today. Consider these examples: >> >> {% verbatim "%} %}" %} >> >> (That is, "%} %}" in a verbatim-no-end tag) >> >> {% verbatim %} %} %} {% endverbatim %} >> >> (That

Re: Composite primary keys

I would be nice if support for composite primary keys would be implemented as a special case of general composite fields. There would be no need for new Meta options: class Foo(Model): x = models.FloatField() y = models.FloatField() coords = models.CompositeField((x, y),

Re: Composite primary keys

Am 21.03.2011 um 08:33 schrieb Christophe Pettus: > I'd like to make one more pitch for a slightly different implementation here. > My concern with CompositeField isn't based on the fact that it doesn't map > one-to-one with a field in the table; it's that it doesn't have any of the >

Re: Single Table Inheritance

Am 29.03.2011 um 20:46 schrieb Shawn Milochik: > They can create a custom manager on the abstract class that would > return an iterable, perhaps using itertools.chain() of the querysets. > > It depends on what they expect to do with the output of this custom > manager, and they'd obviously lose

Re: [GSoC] Composite fields: proposal, part 1

Am 06.04.2011 um 02:45 schrieb Michal Petrucha: [snip] > unique and db_index > ~~~ > Implementing these will require some modifications in the backend code. > The table creation code will have to handle virtual fields as well as > local fields in the table creation and index

Re: [GSoC] Composite fields: proposal, part 1

Am 06.04.2011 um 23:29 schrieb Michal Petrucha: > On Wed, Apr 06, 2011 at 06:22:33AM +0200, Johannes Dollinger wrote: >> >> Am 06.04.2011 um 02:45 schrieb Michal Petrucha: >> >> [snip] >> >>> unique and db_index >>> ~~~ >

Re: #14891, a.k.a. "related managers don't work how we claim they do"

Am 17.04.2011 um 01:30 schrieb Carl Meyer: > So - do we (A) fix the behavior to match our documented semantics, note > it in the release notes, and hope for the best? Or (B) bow to > backwards-compatibility and change the documentation to match the actual > behavior? Or (C) find some middle

Re: ModelForm validation - a better way?

Am 29.04.2011 um 04:13 schrieb Carl Meyer: > Hi all, > > We have a number of tickets open (at least #12028, #13249, #13091, > #15326, and #15860 -- #13091 is the active one) reporting problems with > unique_together constraints in our attempts to validate arbitrary > partial models, when

Re: math tag

Am 03.05.2011 um 18:27 schrieb Phui Hock: > Or, in a sane world: > > if x = {{ x }}, y = {{ y }}, {{ x }} + {{ y }} = {{ x_plus_y_res }} > if x = {{ x }}, y = {{ y }}, {{ x }} * {{ y }} = {{ x_star_y_res }} > > and so on. > > While it is a common consensus that logic should never be in the

Re: ManyRelatedManager with explicit intermediary model

Am 20.09.2011 um 15:57 schrieb Łukasz Rekucki: > On 20 September 2011 15:52, Roald de Vries wrote: >> Hi all, >> >> Is there a fundamental reason that I'm missing (other than "nobody's taken >> the trouble of writing it") that I can't do the following? If there isn't >>

Re: prefetch_related - new feature suggestion

Am 27.09.2011 um 05:18 schrieb Luke Plant: > On 27/09/11 03:23, Alex Gaynor wrote: > >> I'm not a fan of this, for a few reasons, firstly: because it feels >> wrong for a QuerySet to execute multiple queries. This isn't a deal >> breaker, just something that struck my conceptually initially.

Feature proposal: Q.push(...) and QuerySet.filter(relfield=Q(...))

The aim of this proposal is to reuse Q objects for models that are related through FK or M2M fields. A simplified example would be a Q object like >>> is_blue = Q(blue=True) >>> Thing.objects.filter(is_blue) that should be reused to filter the owners of things: >>>

Re: Feature proposal: Q.push(...) and QuerySet.filter(relfield=Q(...))

Am 03.10.2011 um 20:01 schrieb Javier Guerra Giraldez: > On Fri, Sep 30, 2011 at 4:37 PM, Johannes Dollinger > <emulb...@googlemail.com> wrote: >> The aim of this proposal is to reuse Q objects for models that are related >> through FK or M2M fields. > > i really

Where should I start? (#2539, #3544, #6915, #7154, #7215, #7312)

Hello, I'm quite new to django (first real project) and stumbled across several bugs/features that I'd like to see in trunk. And I'm willing and hopefully able to help. Here they are: #2539, #3544, #6915, #7154, #7215, #7312, and (cosmetic) #5537. The following should probably be split into

Model.delete() vs QuerySet.delete() / Model.save() vs QuerySet.update()

Currently, QuerySet.delete() ignores custom Model.delete() methods (#6915 [1]). I'd like to discuss possible solutions - foo.delete() should be equivalent to Foo.objects.filter(pk=foo.pk).delete(). 1. Disallow custom Model.delete() methods, offer signals only. That's easy, but no real option

#3591: add support for custom app_label (and verbose_name?)

As proposed by mrts, I'd like to take the discussion from #3591 [1] here. A note on InstalledAppsRevision [2]: I like most of it (especially `db_prefix`) but cannot see the value of having multiple instances of the same app. Is there an example that illustrates why this is needed

Re: The Model.default_manager concept

rs anyway. [1] http://code.djangoproject.com/ticket/7154 Am 31.05.2008 um 19:16 schrieb Johannes Dollinger: > > I'd like to propose a change of the Model.defaul_manager concept. My > first concern was the inability to control the default_manager when > subclassing a Model that already provides a d

Re: The Model.default_manager concept

If you're just want different querysets you can use something like this: http://dpaste.com/53948/. Things.live.all() vs Things.objects.live(). Am 16.06.2008 um 16:37 schrieb James Bennett: > > On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger > <[EMAIL PROTE

Re: The Model.default_manager concept

Am 16.06.2008 um 18:49 schrieb James Bennett: > > On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger > <[EMAIL PROTECTED]> wrote: >> If you're just want different querysets you can use something like >> this: http://dpaste.com/53948/. > > Or I can use manag

Re: The Model.default_manager concept

> So then what is the difference between a Manager and a QuerySet? > > Nearly everything would work identically if Manager were simply: > > class Manager(QuerySet): > pass > > (except actually keeping the magic that connects it to the model > class.) Utility methods in managers wouldn't make

Re: The Model.default_manager concept

Am 16.06.2008 um 20:56 schrieb James Bennett: > It'd also hurt the reusability of managers (which is a big advantage I > and others have taken advantage of), because you wouldn't be able to > keep methods specific to a single model separate from methods which > aren't, at least not without

Re: The Model.default_manager concept

ering, so > > Article.objects.filter(category=cat).create(title=title, > content=content) > > doesn't do what you'd expect. (Though `cat.article_set.create` should > work.) Has that actually confused anyone? > > -Ken > > > On Jun 16, 2:57 pm, Johannes Dollinger > <[EMAIL PROTE

django.template feature proposals

I'd like to propose the following changes to django.template. Some of them are partially or fully implemented in my patch[1] for #3544. Which of these have a chance to land in 1.0 (assumed I provide a patch, docs and tests)? 1.) Allow recursive includes, #3544 [2] 2.) Add a template_cache

Re: about templatetag namespaces

+1 for the main proposal and subproposal (modulo concrete syntax). Decoupling template library imports from app_label would also be good for #3591. Get rid of as many app_label dependencies as possible. Beautiful languages such as php and c have flat namespaces - don't go there.

Re: Is URL template tag's syntax going to change?

I'd prefer treating unquoted parameters as variables. If that's not possible make url accept a quoted view name and deprecate unquoted view names. Especially unquoted non-ascii strings (as in test url05) are ugly and would require hacks or re.LOCALE in my approach in #7806. Am 20.07.2008

Re: Is URL template tag's syntax going to change?

Am 20.07.2008 um 21:48 schrieb Malcolm Tredinnick: >> Especially unquoted non-ascii strings (as in test url05) are ugly > > Subjective; not a technical reason. Non-ASCII strings look just the > same > as ASCII strings. In fact, many non-Latin scripts are much prettier > than > the Latin

RFC: django.template refactoring (#7806)

Why should django.template be refactored? Filter and Variable parsing is inconsistent. Many ad hoc parsers in defaulttags are fragile. Whitespace handling is ungraceful. The patch provided in #7806[1] splits __init__.py into separate modules[2] and introduces a TokenStream class that

Re: RFC: django.template refactoring (#7806)

> Would @register.tag(token_stream=True) work instead, or am I missing > something? Yes, that would work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send

Re: Concrete django.template Suggestions

Am 19.09.2008 um 18:08 schrieb Armin Ronacher: [snip] > > What's harder to fix is how the i18n integration translates filter > arguments or gettext constants (those _("foo") thingies). Currently > that happens very often at node/object creation rather than node/ > object evaluation. A good

Proposal: Let Context handle template loading (#7815)

#7815[1]: * Adds a loader kwarg to Context which should be something with a get_template(name) function. Default would be django.template.loader. * Provides get_template() and select_template() methods on Context. These are used in {% include %}, {% extends %} and inclusion_tag. * Caches

Re: Optimizations on templates

Am 25.09.2008 um 00:39 schrieb Manuel Saelices: > > It's a different aproach. I consider my cache attempt a optimization > like URL dispatcher cache, without considering django cache system, > like url resolvers cache, _join_cache in orm or other many cases. > Also, I'm not sure that #6262

Re: Proposal: Let Context handle template loading (#7815)

le marcos if Context allowed external population of its cache: {% sub "braces.sub" %} {% templatetag openbrace %} {{ content }} {% templatetag closebrace %} {% endsub %} {% include "braces.sub" %} or with #7817: {% include "braces.sub" with foo as content %

Template-04's scope

I'm aware that #7806 propably does too much at once. I'd like to hear what's in scope for 1.1 and what you believe doesn't belong in django. Why the patch still does that/too much: * The code shuffling is purely cosmetic, it just feels wrong to stuff everthing in __init__.py. It's already

Re: Template-04's scope

Am 25.11.2008 um 17:28 schrieb Jacob Kaplan-Moss: > I'm actually pretty happy with the general idea you've taken here -- > django.template needs some cleanup, and a holistic approach that > addresses the multiple issues at once is going to produce better code > than multiple patches all stacked

Re: Template-04's scope

Am 25.11.2008 um 19:45 schrieb Steve Holden: > > Jacob Kaplan-Moss wrote: >> On Tue, Nov 25, 2008 at 10:11 AM, Johannes Dollinger >> [...] >>> * I always felt the API for custom tags is too verbose. >>> >> >> There's almost universal agreement

Re: Template-04's scope

>> However, that's no reason not to have a better API on top that >> third-party tags can use -- as long as internal tags don't break. > > That should be entirely possible, using either an additional decorator > for parser functions [EMAIL PROTECTED] or [EMAIL PROTECTED]($new_api=True)`, > or >

Re: Default manager

I like the `objects` convention as well as explict default manager declarations. I proposed both in http://groups.google.at/group/django-developers/browse_thread/thread/3e1a668ac84328b6/ce36cbe46276d807 . Advertisement: My radical "solution" is to never modify the initial