Am 12.10.2011 um 03:35 schrieb Steven Cummings:
> Finally got around to these simple changes:
>
> *
> https://github.com/estebistec/django/commit/b48a87afc324f5546b6654fa7638e406b397c0d6
> *
> https://github.com/estebistec/django/commit/28ace32980b370fd17ae35019bfe8d055c673684
>
> If the core
Am 03.10.2011 um 20:01 schrieb Javier Guerra Giraldez:
> On Fri, Sep 30, 2011 at 4:37 PM, Johannes Dollinger
> wrote:
>> The aim of this proposal is to reuse Q objects for models that are related
>> through FK or M2M fields.
>
> i really want to have this feature! s
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:
>>> User.objects.filt
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. S
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
>> I'll create a ticket for
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 t
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 validat
Am 19.04.2011 um 00:03 schrieb Carl Meyer:
> Hi Johannes,
>
> On 04/18/2011 01:45 PM, Johannes Dollinger wrote:
>> Deprecate `use_for_related_fields` and always use the default manager
>> for related managers. Then add the possibility to specify custom
>> mange
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 groun
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
>>> ~~~
>&g
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 crea
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
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
> semanti
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), db_index=Tru
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
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 =
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 is
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 strengt
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 is
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 Manager
Am 22.12.2009 um 08:20 schrieb Simon Willison:
> On Dec 22, 12:52 am, Johannes Dollinger
> wrote:
>> I'd like some more kwargs to Signer and TimestampSigner. Mostly
>> what's
>> inhttp://dpaste.com/136418/(except the `separator` kwarg, which was
>
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 enco
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 supply your
> own trace
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?
>
> Since the problem of
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, tha
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. Nam
Am 26.11.2009 um 12:09 schrieb Russell Keith-Magee:
> On Thu, Nov 26, 2009 at 5:39 PM, Johannes Dollinger
> wrote:
>>
>> Am 26.11.2009 um 03:47 schrieb Russell Keith-Magee:
>>
>>> On Thu, Nov 26, 2009 at 12:04 AM, Johannes Dollinger
>>> wrote:
>>
Am 26.11.2009 um 03:47 schrieb Russell Keith-Magee:
> On Thu, Nov 26, 2009 at 12:04 AM, Johannes Dollinger
> wrote:
>> QuerySet.delete() currently sets the primary key and all nullable
>> foreign keys (to deleted objects) of instances passed to signal
>> handlers to N
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
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
>>> wrote:
Sup,
I've been working on template cachi
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
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
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:
Am 25.09.2009 um 22:04 schrieb Simon Willison:
>
> On Sep 25, 4:44 pm, Johannes Dollinger
> wrote:
>> Regarding parity, let me advertise a Signer object again:
>>
>> signer = signed.Signer(
>> key=settings.SECRET_KEY,
>
Am 29.09.2009 um 04:07 schrieb Russell Keith-Magee:
>
> On Tue, Sep 29, 2009 at 12:44 AM, Johannes Dollinger
> wrote:
>>
>>>> Variable and FilterExpression will be deprecated as they require
>>>> the
>>>> caller to know the length of the e
>> 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 'article.section'
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
django-
> 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 advert
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,
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 %}
This
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
-'filter-s
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,
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 QueryS
>> 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
>
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 agree
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
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 to
Am 27.09.2008 um 04:40 schrieb Malcolm Tredinnick:
> On Wed, 2008-09-24 at 16:34 +0200, Johannes Dollinger wrote:
> [...]
>> tpl.render(Context({}, loader=PrefixLoader(['a', 'b', 'c'])))
>> }}}
>>
>> This would fix #2949, #3544, #4278, #
mple
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 conten
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 consi
Am 25.09.2008 um 00:10 schrieb Manuel Saelices:
>
> Hi,
>
> one week ago I've made a little change in template rendering engine to
> get a huge performance improvement, in template rendering:
>
> http://code.djangoproject.com/ticket/9154
>
> The optimizations where two:
> 1) cache loaded templa
#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 temp
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 exam
> 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 emai
Am 17.09.2008 um 01:37 schrieb Malcolm Tredinnick:
> As was pointed out the first time you brought this up, keep in mind
> that
> there still need to be ways to manually control the lexing phase. Not
> every template tag has the same requirements there.
>
> Also, since the Variable class is pa
Why should django.template be refactored? Filter and Variable parsing
is inconsistent. Many ad hoc parsers in defaulttags are fragile.
Whitespace handling is ungraceful.
The patch provided in #7806[1] splits __init__.py into separate
modules[2] and introduces a TokenStream class that allows
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 alpha
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 u
+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.
Concerning
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 to
filtering, 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
> &
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 introd
> 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
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
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 PROTECTED]>
t
using multiple managers 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 M
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
(everyth
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
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 default_manager (the base
class' manager will be added before the subclass' manager).
This could be solved by
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
70 matches
Mail list logo