Re: Django & memcache hashing

[Ludvig Ericson]

On Nov 20, 2008, at 05:20, Ivan Sagalaev wrote:
> What concerns me is that this will break the usage of memcached  
> without
> Django's cache API. I had the need a couple of times to do plain
> instantiation of memcache.Client and work with it. If it won't see the
> cache the same way as Django does it would be that very issue, hard to
> debug, that started this thread.

True, but that's because python-memcached for some reason still uses its
own hashing algorithm (pure CRC32) while other libraries are more or  
less
unified in their hashing algorithm. (Wouldn't know about libmemcached.)

*ugh* Why can you never eat the pie and have it. :(

- Ludvig

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

Re: Proposal: Composite Foreign Keys

[Hanne Moa]

On Wed, Nov 19, 2008 at 19:12, David Cramer <[EMAIL PROTECTED]> wrote:
> You guys are really bad about keeping on topic. :)

Good way to prevent a discussion from entering Godwin-territory :)

I should perhaps have mentioned something along the lines of  "this is
an example of where there is (perhaps) an unnecessary need for a
primary key". After all, the fewer places that *must* have x, the
easier it is to change the underlying structure of x.

To go back off track (wouldn't do to stay on it for long), maybe we
need an official place to discuss the use of legacy databases in
Django.


HM

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

Re: Post about django optimizations

[vivek]

l agree with david that you should at least highlight your points
here.

You have already corrected your post about paginator, for rest of the
point you mentioned  all I can say is if you had read the django
book , specially chapter 20 at: http://www.djangobook.com/en/1.0/chapter20/
you probably wouldn't have to write the blog post ;)

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

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

[zvoase]

I have an idea which may solve the issue of render_to_response using a
RequestContext.
Why not have render_to_response as a shortcut in django.shortcuts (as
it is now), and then add a 'render' method to the request instance
which would do render_to_response but with a RequestContext instead.
That seems logical to me, so that views could do something like this:

# Using RequestContext
def myview(request, *args):
# some code here...
request.render('template_name.html', {...})

# Using normal Context
from django.shortcuts import render_to_response
def myview(request, *args):
# some code here...
render_to_response('template_name.html', .)

That just seems logical to me. Rather than (potentially) break
backwards compatibility, let things be as they are right now and just
add a method to the request.

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

Re: Django & memcache hashing

[Eric Holscher]

Just wanted to say that we ran into this exact issue at work the other day
as well. We had the C and Python versions of memcache running, and it was
hashing things differently (to different servers or something as I
understand it). This caused us a good couple hours of confusion. We
eventually figured it out and made sure that each of our boxes had the same
version of memcache.


On Thu, Nov 20, 2008 at 3:01 AM, Ludvig Ericson <[EMAIL PROTECTED]>wrote:

>
> On Nov 20, 2008, at 05:20, Ivan Sagalaev wrote:
> > What concerns me is that this will break the usage of memcached
> > without
> > Django's cache API. I had the need a couple of times to do plain
> > instantiation of memcache.Client and work with it. If it won't see the
> > cache the same way as Django does it would be that very issue, hard to
> > debug, that started this thread.
>
> True, but that's because python-memcached for some reason still uses its
> own hashing algorithm (pure CRC32) while other libraries are more or
> less
> unified in their hashing algorithm. (Wouldn't know about libmemcached.)
>
> *ugh* Why can you never eat the pie and have it. :(
>
> - Ludvig
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]

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

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

[Rajeev J Sebastian]

On Wed, Nov 19, 2008 at 4:10 AM, Nathaniel Whiteinge
<[EMAIL PROTECTED]> wrote:
>
> Out of curiosity, for those who want RequestContext added to
> render_to_response, is there a reason you don't like using
> direct_to_template instead? I see the two as being functionally
> equivalent (minus the addition of RequestContext, of course), but this
> debate crops up every so often -- is there something I'm missing? In
> other words: my Python-foo is not strong, is there a reason I should
> avoid using direct_to_template in 99% of my views?

I use direct_to_template everwhere! I always try to "delegate" to the
generic views.

Regards
Rajeev J Sebastian

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

Re: order_by with distinct behavior in orm

[Adam Nelson]

A way that might satisfy everybody is to use GROUP BY() and drop
DISTINCT.  That's a more robust method anyway.

So, for a distinct, instead of:

SELECT DISTINCT name, (SUBSTRING(name, 1, 3)) AS short_name FROM thing
WHERE is_ok = 1 /* Which produces the incorrect values stated above */

Use:

SELECT (SUBSTRING(name, 1, 3)) AS short_name FROM thing WHERE is_ok =
1 GROUP BY short_name

I think this solution is much more powerful programmatically as it can
be extended more easily (i.e. for multi-column uniqueness, aggregate
methods).


On Wed, Nov 19, 2008 at 7:23 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Malcolm Tredinnick wrote:
> [...]
> > Hopefully, MySQL will fix their bug one day. That's the way to resolve
> > this.
> >
> Just so long as nobody holds their breath waiting ...
>
> regards
>  Steve
> --
> Steve Holden+1 571 484 6266   +1 800 494 3119
> Holden Web LLC  http://www.holdenweb.com/
>
> >

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

patch review wanted (ticket #9433)

[rndblnch]

hi all,

i've recently encounter a bug, submitted a ticket, was asked to solve
the problem myself in an initial comment :)
i submitted a patch that fix the bug, and could be potentially adapted
to fix another one (see discussion in ).
i didn't get feedback for the past 4 weeks and the last django release
reverted my path on my own install :(.

so, could someone have a quick look (it's a very short patch) ?
i know the problem it fix is rather uncommon (it concerns file upload
on a macosx box on a volume mounted through afp), but i'm sure i'm not
the only one facing it :)

thanks for any feedback !

the ticket :


renaud

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

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

[Jeremy Dunck]

On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote:
...
> # Using RequestContext
> def myview(request, *args):
># some code here...
>request.render('template_name.html', {...})
...
>
> That just seems logical to me. Rather than (potentially) break
> backwards compatibility, let things be as they are right now and just
> add a method to the request.

Except that it couples request and response objects to templates.

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

Explicit default managers?

[mrts]

Currently, "the first manager declared is the default manager".

However, given the following hierarchy:

---
class PublishedObjectManager(models.Manager):
def get_query_set(self):
return super(PublishedObjectManager, self).get_query_set()\
.filter(is_published=True)

class PublicationBase(models.Model):
...
objects = models.Manager()
published_objects = PublishedObjectManager()

class Meta:
abstract = True

class ToplevelPageManager(PublishedObjectManager):
def get_query_set(self):
return super(ToplevelPageManager, self).get_query_set()\
.filter(parent=None)

class PageBase(PublicationBase):
...
toplevel_pages = ToplevelPageManager()

class Meta:
abstract = True
---

all classes inheriting from `PageBase` get `toplevel_pages` as their
default manager.
To make `objects` default, repetition is necessary:

---
class PageBase(PublicationBase):
...
objects = models.Manager()
toplevel_pages = ToplevelPageManager()

class Meta:
abstract = True
---

only to specify the default manager. IMHO, a way to explicitly say
"this is the default manager that should be honoured throughout the
inheritance hierarchy" would be appropriate. Also, the '_' in front of
_default_manager implies that it is an implementation detail and
accessing default managers is not documented. But all reusable app
writers should really use model._default_manager instead of
model.objects for any foreign models they must handle.

Generally, there should be an explicit, documented way to set and get
the default manager.

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

Re: Feature reviews for 1.1

[Bob]

Apologies to JKM if you got this already . . . I thought I emailed you
directly, but I can't find it in my sent mail folder.

What happened to "integrate databrowse into admin" and a few other
features? They were on the 1.1 list right before you re-organized it,
so I didn't know if they were unintentionally lost or intentionally
rejected:

http://code.djangoproject.com/wiki/Version1.1Features?version=101

Also, I added my votes here:
https://spreadsheets.google.com/ccc?key=pIaJn09D1vqW1yJjl3wGUeg
(not sure if you're counting non-committer votes or not)

Thanks.
-Bob

On Nov 13, 2:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi folks --
>
> I've reorganized the 1.1 feature list
> (http://code.djangoproject.com/wiki/Version1.1Features) and added "short
> codes" so we can have a quick shorthand as we review features.
>
> I've also reviewed most of the features on the list. I'll talk about the
> review process -- and how y'all can contribute -- below, but if you just wanna
> see my thoughts, they're 
> here:http://spreadsheets.google.com/ccc?key=pSqnCvef6OXmGWQ9qbEVMeA.
>
> I'd like to ask committers and anyone else to send me their own rankings. The
> easiest way is just to copy the spreadsheet and send it to me when you're
> done, but if you're anti-google just email me something I can read with codes,
> scores, and any notes. I'll add other folks' rankings to the master page as I
> get 'em.
>
> Committers: please get me your thoughts ASAP.
>
> Please use the standard +1/+0/-0/-1 ranking. In this case the scores
> have some additional meaning:
>
> +1 -- "Yes!"
>
>     For "must-have" features.
>
>     A +1 from a committer means that s/he will champion the feature, guide
>     the implementor (or implement it personally), review the patch, and commit
>     the feature personally.
>
>     A +1 from a non-committer is an offer to personally work on the feature,
>     or to help the person working on it by reviewing the patch, testing, etc.
>
> +0 -- "OK"
>
>     For features that are a "good idea".
>
>     A +0 from a committer means that s/he will not stand in the way of the
>     feature, but also won't personally invest much effort in it.
>
> -0 -- "Meh"
>
>     For features that don't seem all that hot.
>
>     A -0 from a committer indicates disapproval, but that s/he won't argue
>     against the feature if another committer approves it.
>
> -1 -- "No!"
>
>     A strong vote against.
>
>     A -1 from a committer essentially is a veto. No features will be checked
>     in with a -1 vote from a committer; only if s/he gets talked up to a -0
>     or better will the feature happen.
>
> Using these votes, we'll make lists of "must-have", "nice-to-have", and
> "deferred", and "rejected" features. These lists will be based on the
> following criteria, but remember there's a holistic aspect to this process.
> We'll use the votes to draft a feature list, but we'll also open up the list
> for discussion and make changes accordingly.
>
> "Must-have" features:
>
>     * +1s from multiple committers.
>
>     * A committer who can work on the feature, or a lieutenant (or more than
>       one) willing and able to implement the feature.
>
>     * No votes from committers worse than +0.
>
>     * Unfinished features on this list will delay the release. Thus,
>       no single committer can be the sole champion for more than a
>       couple-three features. That means the maximum size of this list is about
>       15-20 features, and will likely be closer to 10-12.
>
> "Nice-to-have" features:
>
>     * At least one +1 from a committer.
>
>     * A lieutenant or committer who'll work on the feature.
>
>     * No votes from committers worse than -0.
>
>     * These will be the focus of work after the must-haves.
>
> "Deferred" features:
>
>     * No +1 votes, but no -1 votes either, or features that lack a
>       implementor.
>
>     * This list will likely be full of good ideas that we'll look at again for
>       the 1.2 release.
>
> "Rejected" features
>
>     * No +1 votes from committers, few +0s, and at least one -1. Think an
>       average of worse than -0.
>
>     * We'll reject these features, and wontfix any related tickets.
>
>     * This doesn't, though, mean "rejected for all eternity" -- folks who feel
>       strongly can bring up these features again during another feature review
>       process.
>
> Thanks!
>
> Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Feature reviews for 1.1

[David Durham, Jr.]

On Thu, Nov 20, 2008 at 1:38 PM, Bob <[EMAIL PROTECTED]> wrote:
> Also, I added my votes here:
> https://spreadsheets.google.com/ccc?key=pIaJn09D1vqW1yJjl3wGUeg
> (not sure if you're counting non-committer votes or not)

You're -1 on SessionWizard is partially invalid.  I tried to
anticipate the need for multiple instances of the same wizard per
session.  From the patch:

400 +# typically overriden methods #
401 +def get_wizard_data_key(self, request):
402 +"""
403 +Return a session key for this wizard.  The provided
request could be
404 +used to prevent overlapping keys in the case that someone needs
405 +multiple instances of this wizard at one time.
406 +"""
407 +return 'session_wizard_data'

-Dave

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

DRAFT 1.1 roadmap posted

[Jacob Kaplan-Moss]

Hi folks --

I've posted a draft of the 1.1 roadmap, incorporating the feedback
gathered here over the last week:
http://code.djangoproject.com/wiki/Version1.1Roadmap

Discuss.

Jacob

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

Re: patch review wanted (ticket #9433)

[Malcolm Tredinnick]

On Thu, 2008-11-20 at 07:10 -0800, rndblnch wrote:
> hi all,
> 
> i've recently encounter a bug, submitted a ticket, was asked to solve
> the problem myself in an initial comment :)
> i submitted a patch that fix the bug, and could be potentially adapted
> to fix another one (see discussion in  ticket/9433>).
> i didn't get feedback for the past 4 weeks and the last django release
> reverted my path on my own install :(.
> 
> so, could someone have a quick look (it's a very short patch) ?
> i know the problem it fix is rather uncommon (it concerns file upload
> on a macosx box on a volume mounted through afp), but i'm sure i'm not
> the only one facing it :)

It has been getting some review -- I've been thinking about it quite a
bit. It's not clear that your proposed solution is a good one, since it
makes file saving unsafe. It might, in fact, be preferable to just say
you cannot save to filesystems that don't support proper file locking
semantics, for example. That's obviously not ideal and I'm trying to
think of a more intermediate approach. Just ignoring locking errors is
very sub-optimal, though, since they can occur for other reasons, and
that's essentially what your patch is doing (for example, the NFS case
that was reported and which you've tried to bundle up as "solved" by the
same problem is almost certainly an actual bug in the NFS client/server
configuration being reported, since NFS does support POSIX locking. So
ignoring the problem there is bad).

Getting this right is important. We have so far had exactly one report
of the problem -- you. So I'm not going to be putting AFP into the list
of "most commonly used filesystems" just yet. Fixing that bug will be
useful. Fixing it properly without inadvertent side-affects that harm
(or disguise) other setups is paramount, however.

Regards,
Malcolm



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

Re: DRAFT 1.1 roadmap posted

[Malcolm Tredinnick]

On Thu, 2008-11-20 at 17:28 -0600, Jacob Kaplan-Moss wrote:
> Hi folks --
> 
> I've posted a draft of the 1.1 roadmap, incorporating the feedback
> gathered here over the last week:
> http://code.djangoproject.com/wiki/Version1.1Roadmap
> 
> Discuss.

I'm not so sure the final phases of that process worked out smoothly. I
thought there'd be a brief round, at least within the maintainers group
(and maybe this thread is it) where we reconcile the comments. Like most
people (hopefully), I rated without looking at others and then went back
at the end (yesterday) to see what was washing out. A couple of
thoughts, then (and, yeah, this is going to be a disaster of a thread
because of me, since there's multiple things here. Sorry :-( ):

(1) For ORM "identity" mapping, I suspect we're probably closer than it
seems, so we might just be able to hash it out quickly to get a concrete
scope.

(2) But either way, this indicates something to work on in the process:
there's no period for resolving those sorts of scope differences. I was
quite annoyed about the massive thread starting up for "app refactoring"
when all the votes weren't in. It felt like we were being pushed to make
all these justifications when the process was still winding to a
conclusion. As it turned out, there was fairly reasonable consensus
amongst the maintainers, so some angst might have been saved there. But
we either need to add a period for resolving small differences, or
people need to bring up each of their particular favourite issue
beforehand, which is going to get fairly tiring as a maintainer to have
to read all the threads (there would have been 80+ threads in the lead
up to 1.1) and indicate a decision beforehand -- when it might not be
necessary if, as here, it turns out we were all mostly of one mind
anyway. Having the "coming together; realising we're apart" portion only
on the ones that are strangely polarised would save some resources and
that can only happen after the vote.

(3) I was trying to avoid being +1 on 15 - 20 items, so I tried to
second-guess a little bit (hoping that somebody else would step up for
some of the obvious ones), but that backfired. For things like
distinct_on() and select_for_update(), we're all mostly +0, so I'm happy
to take it on, time permitting. It's not technically too challenging,
with one exception in both cases (i.e. there's one significant problem
to solve and then it's downhill sledding all the way across the
multi-lane freeway and into the wall). My point: let's call those things
"maybe", since there's no obvious objection to them and it would be
silly to reject them just because three months out nobody wanted to
stake their reputation on them, but we might still get to them. Sure, we
get the "must haves" done first, but then see. I'm thinking of, in
particular:

- select_for_update() (seven +0 votes)

- distinct_on() (four +0, three -0)

- allowing option for autocommit in PostgreSQL backend (five +0)

- signals for ManytoMany (five +0, three -0) -- this is the kind
of thing that takes half a day to implement and commit if you
work slowly. It's not going to not get done because of the
difficulty, so long as we're in agreement as to the worthiness.

- refactor django template (Seven +0, one -0). We have to at
least fix a bunch of the bugs that are in templates in any case,
and whether that involves a lot of internal changes or minimal
remains to be seen, but those patches are a good start. I'm
personally not that motivated about all the new bells and
whistles, but I want to fix the bugs anyway. I think I put +1
against only one of the template things, but generally I want to
fix all the template tag bugs, since they're mostly all
individual cases of a few, smaller, broader problems.

- the SafeForm feature (eight +0). Personally, I suspect we
should stop trying to second-guess form features for a bit, but
if somebody came up with the perfect code, there's no real
reason to defer that one (it got 8 +0 votes and nothing else, so
we're only lanking a champion). I can imagine a period where I'd
just go through a bunch of things like that and gave thumbs up
or thumbs down to code and committed it if it was of high enough
quality.

All of those are "want"-positive, often by huge margins and are just
lacking anybody committing to getting it into the tree. Surely that's
what "maybe" means.

I suspect there's partly a slight flaw in the voting scheme for a
maintainer particularly, as +1 can mean either/both of "I'll do the
work", "I'll shepherd it through". I had a few in both baskets (some I'm
willing to shepherd, but not do the work; others, I'll commit to doing
the implementation).

All in all, I think it's once again interesting how alike all the
maintainers think

Re: DRAFT 1.1 roadmap posted

[Jacob Kaplan-Moss]

Hey Malcolm --

On Thu, Nov 20, 2008 at 6:23 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> I'm not so sure the final phases of that process worked out smoothly. I
> thought there'd be a brief round, at least within the maintainers group
> (and maybe this thread is it) where we reconcile the comments.

Sorry, yeah, I'd hoped this would be that thread. I'm really busy
right now and I skipped a few bits. I'd thought we'd talk over what
ended up where based on the raw votes and revise stuff to reflect the
more intagible aspects of this process. I'd wanted to do it over here
instead of just among the maintainers in the interest of transparency,
and also because there's a few folks (Honza comes to mind) who have
"skin in the game" but aren't committers.

I totally forgot to list the "need a champion" features -- stuff that
received lots of +0s, no -1s, but no +1s either. I'll add those to the
draft shortly, but you listed most of 'em. As far as I'm concerned,
those should be some sort of "second-tier" maybe -- if someone steps
up they can go in, but if everyone's opinion remains "meh" they'll get
deferred.

Also -- and I know you know this, so this is for the benefit of those
who don't -- even once we "finalize" the draft it won't be the end of
the story. If deferred features get finished, there's no reason *not*
to check 'em in; the idea behind the feature list is to give us some
help with focus, not to prevent work.

So mea culpa on screwing the pooch as process goes. I'm tired and
stressed and not communicating well right now. Meh.

Couple of specific things you talked about I should address:

> (1) For ORM "identity" mapping, I suspect we're probably closer than it
> seems, so we might just be able to hash it out quickly to get a concrete
> scope.

Yeah, I agree. Let's start a separate thread on that to try to come to
a conclusion. I think if we can decide something within a month or so
we'll have plenty of time to get it in. I'll add a note to the draft
about it being a somewhat special case. I think it's fine, BTW, to
have features not fully fledged at this point: if we come to a
consensus and get done, it goes in; otherwise it waits. No big deal
either way (I hope).

> But we either need to add a period for resolving small differences,

Again, I'd intended to explain that this is the time to do that.

> I suspect there's partly a slight flaw in the voting scheme for a
> maintainer particularly, as +1 can mean either/both of "I'll do the
> work", "I'll shepherd it through". I had a few in both baskets (some I'm
> willing to shepherd, but not do the work; others, I'll commit to doing
> the implementation).

I agree. Let's think about a better way to express these
related-but-not-always-identical thoughts and use it next time around?

> But you might have come down a bit hard
> on the "defer" side of the defer/maybe line when it probably doesn't
> cost us anything to keep a few of those things on the radar.

Yeah, that was deliberate -- lots of stuff I want ended up there.
Again, if it gets done there's no reason *not* to check it in. I'd
rather under-promise and over-deliver, of course!

OK, so I'm going to add the "lots of +0" stuff to the draft, and the
note about ORM aggregation, and hopefully the rest of my comments here
will help better explain WTF I'm smoking tonight.

Jacob

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

Re: DRAFT 1.1 roadmap posted

[Jacob Kaplan-Moss]

On Thu, Nov 20, 2008 at 6:46 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> OK, so I'm going to add the "lots of +0" stuff to the draft, and the
> note about ORM aggregation,

 that should have read "ORM identity map".

OK, draft updated; hopefully it's a bit more sane now.

Also, one other thing I forgot to mention: I've deliberately not
bothered with the "who's going to champion/implement/commit this
feature" part since I don't want to arbitrarily "assign" folks to
work. Once we have a fairly nailed-down version of the roadmap I'd
planned to throw up a similar table to the one on
http://code.djangoproject.com/wiki/VersionOneRoadmap and ask folks to
stick their names into the appropriate slots.

Jacob

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

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

[Yuri Baburov]

On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote:
> ...
>> # Using RequestContext
>> def myview(request, *args):
>># some code here...
>>request.render('template_name.html', {...})
> ...
>>
>> That just seems logical to me. Rather than (potentially) break
>> backwards compatibility, let things be as they are right now and just
>> add a method to the request.
>
> Except that it couples request and response objects to templates.

But render_to_response also does that?
You want request and response to be loosely coupled? Does it make
sense? Aren't they coupled in render_to_response and response
processing code anyway?

Please explain your point a bit more.

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [EMAIL PROTECTED]

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

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

[Waylan Limberg]

On Thu, Nov 20, 2008 at 10:23 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>>
>> On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote:
>> ...
>>> # Using RequestContext
>>> def myview(request, *args):
>>># some code here...
>>>request.render('template_name.html', {...})
>> ...
>>>
>>> That just seems logical to me. Rather than (potentially) break
>>> backwards compatibility, let things be as they are right now and just
>>> add a method to the request.
>>
>> Except that it couples request and response objects to templates.
>
> But render_to_response also does that?
> You want request and response to be loosely coupled? Does it make
> sense? Aren't they coupled in render_to_response and response
> processing code anyway?
>
> Please explain your point a bit more.
>

render_to_response is a "shortcut" that makes a few assumptions to
cover a common use case and helps keep your views DRY. If you changed
your template system or various other pluggable components, you would
either need to write your own version of render_to_repsonse or repeat
yourself often in your views. However, by making render a method of
the request, we are now taking those assumptions another level and
forcing them on the request object itself. That's bad.

You see, anyone can use Django any way they want and don't have to use
any of the "shortcut" helper functions. However, everyone has to use
the request and response objects, so the code needs to make as few
restrictive assumptions as possible in those objects. And yes, making
it easy for someone to use a different template system is a feature
that we want to keep.



-- 

Waylan Limberg
[EMAIL PROTECTED]

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

Features for 1.1? Tickets #8274, #3400

[Cornbread]

Are these slated to be in 1.1?

#8274 would provide one of the more useful features by sites with many
users. Where we could use email addresses as username. Would be nice
just like you can set the pk in your model to be able to provide a
field that is_username.

#3400 I believe will provide functionality for user profiles as an
inline to user. Currently this is possible but not friendly as you are
unable to filter or sort_by any of those inline fields. if you want to
filter your users by a boolean or sort by their city etc.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---