Re: Can you add a build-in template tags?

[butterhuang]

On 10月19日, 下午4时34分, "Michael P. Jung"  wrote:
> > There is a templatetags {% include 'x.html' %}, it's very nice.  may a
> > templatetags like {% include no-parse "x.html"} is needed. It's so
> > powerful to improve the speed of include some static files which has
> > no variable,and it's so easy for you guys, isn't it?
>
> It'd be very easy to add an template tag that just includes raw data
> from a file. Though I have to comment that this might not be neccesary
> for two reasons:
>
> 1.) The Django templates parse fast and if you're not including an
> extremely large HTML file it should handle it with ease. I've never
> managed to create a CPU bound application, as the database was always
> the slowest part. If you really worry about the template performance so
> much you might be best of switching to some alternative template
> technology like jinja2, which is told to be faster. (*)
>
> 2.) The include tag inlines the included template if it's specified as
> string. So if you cache your template instances and don't regenerate
> them on every request it will get even faster. Only the first request,
> which hasn't cached the template yet will have to parse it once.
>

How can I cache the sub-template witch is included in the main
template? And how can I ensure it won't be render(parse) the next
request?



> (*) Even the jinja2 page states: "Generally speaking the performance of
> a template engine doesn’t matter much as the usual bottleneck in a web
> application is either the database or the application code."
>
> --mp
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session/cookie based messages (#4604)

[Tobias McNulty]

For reference purposes, I started a branch of django on bitbucket with
a contrib.messages app heavily based on django_notify (only
renamed/updated to reflect the API on the wiki):

http://bitbucket.org/tobias.mcnulty/django-contrib-messages/

It's a work in progress and I'll be updating it in the coming
days/weeks but feel free to try it out/push back any changes you see
fit.

Tobias

On Fri, Oct 16, 2009 at 2:10 PM, David Cramer  wrote:
> I agree, this is 30 minutes of work to change the usage in Django, and it
> should be done with the inclusion of the messages patch.
>
> 
> David Cramer
>
>
>
> On Fri, Oct 16, 2009 at 1:08 PM, Tobias McNulty 
> wrote:
>>
>> On Fri, Oct 16, 2009 at 5:10 AM, Luke Plant  wrote:
>> > I think this means that either the deprecation cycle would have to
>> > pushed back one (i.e. pending deprecation warning in 1.3, deprecation
>> > in 1.4, removed in 1.5), or core/contrib should be fixed by 1.2.  I
>> > would strongly prefer the latter, and this would affect my vote: I
>> > don't want two messaging systems in Django, and if user messages are
>> > not deprecated, then we do have two systems.
>>
>> I agree that using deprecated code in the core is setting a bad
>> example.  A quick review of the code shows 8 calls to
>> message_set.create: 3 in auth, 2 in admin, and 3 in the
>> create/update/delete family of generic views.  This definitely sounds
>> to me like a manageable update for 1.2.
>>
>> Per feedback from Jacob, Chris, and Luke, I updated the notes on the
>> existing API, the transition plan, and the potential API on the wiki:
>>
>> http://code.djangoproject.com/wiki/SessionMessages
>>
>> Cheers,
>> Tobias
>>
>>
>> --
>> Tobias McNulty
>> Caktus Consulting Group, LLC
>> P.O. Box 1454
>> Carrboro, NC 27510
>> (919) 951-0052
>> http://www.caktusgroup.com
>>
>>
>
>
> >
>



-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Custom fields and PostGreSQL composite types

[Michael P. Jung]

I've written something called a 'CompositeField' which basicly does what
you're looking for by grouping fields together. Assume you want to have
an AddressField you could define it the following way:

class AddressField(CompositeField):
def __init__(self, blank=False):
super(AddressField, self).__init__(
addressee=models.CharField(max_length=30, blank=blank),
street=models.CharField(max_lenghth=40, blank=blank),
zipcode=models.CharField(max_length=5, blank=blank),
city=models.CharField(max_lenght=30, blank=blank),
)

Using it is equally simple:

class Customer(models.Model):
billing_address = AddressField()
shipping_address = AddressField(blank=True)

It will create extra fields in the model called
billing_address_addressee, billing_address_street, etc. and also provide
some helpers which makes assignment simple. e.g. foo.shipping_address =
foo.billing_address will work as expected.

The code is almost ready for prime. I just want to include some minor
change and add some more test cases. It is ment to be licensed under BSD
just like Django itself. I'd be delighted to get that code included into
Django core some day.


Would this be of any help to you?


--mp

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Custom fields and PostGreSQL composite types

[Alex Gaynor]

On Tue, Oct 20, 2009 at 2:50 PM, thierry  wrote:
>
> Hello everybody,
>
> I'm working on a scientific project and Django has been chosen to
> develop our database model. I'd like to develop a
> 'PhysicalQuantityField' that manages a value and its relative unit.
>
> The first way to do this stuff is to translate the couple (value,unit)
> into a string and use Django custom field to manage the translation
> between Python and PostgreSQL. It works perfectly but I don't like the
> fact to mix the value and the unit. Moreover, postgres stores a string
> rather than a numeric and It makes me feel that the database model is
> not really clean.
>
> The second way, and in my mind the cleaner way, is to create a
> composite type at the postgres side called 'physicalquantity'  with
> "CREATE TYPE physicalquantity AS (value numeric,unit varchar)". It is
> possible to add data to the database, but not to search data because
> the where clause of a select query, generated by a get or filter would
> be :
>
> (with measure as a composite type)
>
> SELECT measure
> FROM myapp_mytable
> WHERE measure = '(10,"mV")'
>
> That is incorrect. The correct query would be :
>
> SELECT measure
> FROM myapp_mytable
> WHERE (measure).value = 10
> AND (measure).unit = 'mV'
>
> Can you tell me if there is a way to control the content of the where
> clause from the custom field class ?
>
> If not, do you think Django will be able one day to manage composite
> types ?
>
> Cordially,
>
> Thierry.
>
> >
>

I think your best bet would be to make 2 fields, a numeric field
(integer, decimal, float whatever you need) and a charfield or
something with the units and then just have a property in Python that
returns what you want.  Basically implement this the same way as
GenericForeignKeys.

As for whether Django will eventually support Composite data types, I
think the answer is maybe, AFAIK no one has worked on this (besides
composite primary keys which may be related implementation wise).  So
the first step would be for someone to come up with a design/API for
what it should look like.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[Vinay Sajip]

On Oct 19, 4:13 pm, mrts  wrote:
> now. Maintaining your own branches on GitHub or
> BitBucket off the corresponding Django SVN mirrors
> is easy and effortless, so it's time to put the
> grudges behind and happily fork and branch Django

It seems like the word "fork" is invested with political meaning (a
"nuclear option") so I would stick with "branch". What you're
suggesting is just what I did some time ago: My svn checkout is in a
folder '~/projects/django/upstream' which is also a DVCS repository,
and from there I create DVCS branches in sibling directories for
working on specific features: ~/projects/django/logging, ~/projects/
django/app_labels etc. I periodically merge these with the upstream
branch, which I keep up to date using 'svn up'.

While this works well for scratching my own itches, and for
experimentation, I'm not sure to what extent (if at all) it helps move
the platform forwards. If I published my branches in a public
repository (GitHub/Launchpad/BitBucket), and if people then started to
use that code, then unless I keep all those branches (with different,
independent features) updated with changes in Django trunk, and I am
very responsive to users of my code in terms of suggestions for
improvements etc. then all I've achieved is to create another version
of the code which doesn't please people, isn't known to a lot of
potential users for a variety of reasons, and perhaps becomes the
basis of someone else's branch - it sounds like there's a possibility
that a lot of time will be spent in merging, checking what different
branches do, etc. - a DVCS version of DLL hell ;-)

So, DVCSs are great for each person to maintain their own variant of
Django, but less useful for sharing our variants with the rest of the
community because each variant will (understandably) have tiny
mindshare compared with the main project.

Sometimes, that won't matter because we're in complete control of what
variant of Django gets installed on a particular site. At other times,
we want to take advantage of a standard Django that our customers have
already got and are invested in, where there's no room for our
branched Django with those must-have (in our opinion) features. Then,
having our own branched version with our favourite bells and whistles
will be no good to us.

Am I making sense?

Regards,

Vinay Sajip
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Custom fields and PostGreSQL composite types

[thierry]

Hello everybody,

I'm working on a scientific project and Django has been chosen to
develop our database model. I'd like to develop a
'PhysicalQuantityField' that manages a value and its relative unit.

The first way to do this stuff is to translate the couple (value,unit)
into a string and use Django custom field to manage the translation
between Python and PostgreSQL. It works perfectly but I don't like the
fact to mix the value and the unit. Moreover, postgres stores a string
rather than a numeric and It makes me feel that the database model is
not really clean.

The second way, and in my mind the cleaner way, is to create a
composite type at the postgres side called 'physicalquantity'  with
"CREATE TYPE physicalquantity AS (value numeric,unit varchar)". It is
possible to add data to the database, but not to search data because
the where clause of a select query, generated by a get or filter would
be :

(with measure as a composite type)

SELECT measure
FROM myapp_mytable
WHERE measure = '(10,"mV")'

That is incorrect. The correct query would be :

SELECT measure
FROM myapp_mytable
WHERE (measure).value = 10
AND (measure).unit = 'mV'

Can you tell me if there is a way to control the content of the where
clause from the custom field class ?

If not, do you think Django will be able one day to manage composite
types ?

Cordially,

Thierry.

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal for __neq field lookup

[Jerome Leclanche]

This is something I attempted once to do over a small GET wrapper by
adding __not; any __not query would be passed to exclude(). Would that
be a solution to the problem?


J. Leclanche / Adys



On Tue, Oct 20, 2009 at 6:31 PM, Michael P. Jung  wrote:
>
> rm> exclude(x=1).exclude(y=2) translates to NOT (x=1) AND NOT (y=2)
>
> So why do we have __gt, __ge, __lt, __le then? It would be as simple to
> have only __le and get rid of the rest as it can easily expressed using
> exclude and filter. I know, it's picky, but you get my point.
>
> I don't see why all comparison operators are supported except for one:
>
> http://dev.mysql.com/doc/refman/5.1/en/comparison-operators.html
> http://www.postgresql.org/docs/8.3/static/functions-comparison.html
>
> mp> (...) Since __isnull is ment to be obsolete, according to Russ
> mp> Magee, it'd be really ugly having to rewrite these queryies to a
> mp> chain of excludes.
>
> rm> I didn't say they were obsolete - I said that they existed for
> rm> historical reasons. I don't think there's been any formal decision to
> rm>  deprecate these operators.
>
> Whops. Sorry for quoting you wrong. I thought you ment it was supposed
> to be obsolete even though it hasn't been marked as such yet.
>
>
> --mp
>
> >
>

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[Vinay Sajip]

On Oct 20, 5:26 pm, Jacob Kaplan-Moss  wrote:
> I don't have time to teach you how to communicate professionally.

I don't presume to speak for Yuri (or anyone else) but I think it's
not unreasonable that some allowance be given in situations where
miscommunication of tone can happen because of cultural differences
or differing levels of facility with language, or sheer lack of time
used in crafting a communication. It's very understandable if you and
Russ want to turn your backs because of a communication which appears
abrasive - we're all human, after all - but might that not be throwing
the baby out with the bath water? Unless someone is obviously
trolling, and if it appears that they want to improve Django in some
way (even if their way seems weird or doesn't align with what the core
devs want) then it's perhaps worth giving the benefit of the doubt,
and important not to discount a message just because of the tone in
which it's conveyed.

> Reading your message first makes me feel angry, then dismayed. It
> makes me feel as if all the hard work I've put into Django doesn't
> matter. It makes me think there's really no point in doing any further
> work, because someone will just come along and crap all over it again.

Please don't feel like that - it's very clear that lots of people
value Django enormously, which means they value the hard work everyone
has put in to get it to where it is. And I'm not sure if you're
talking about any other post than Yuri's in this thread, but that
appeared to me to arise from frustrations with the process rather than
attributing any particular criticism of the software.

> You need to empathize with how someone's going to feel reading your
> message. Until you do, people are going to ignore you at best, and get
> into a flame war at worst. This is your problem, not mine.

Well, if a good idea gets ignored by the committers because it was
suggested in a snotty way, perhaps that's not *just* a problem for the
suggester.

> But since good communication is a two-way street, I'll give you a
> hand. Why don't you try making some concrete, actionable suggestions
> about how you'd like to volunteer to improve things? If you see
> something broken, how about starting by offering to fix it?

Perhaps I've misunderstood, but "offering to fix it" for a non-
committer means "making a suggestion about how to fix it". Sometimes
that involves submitting a patch, and other times (because the problem
may be clear but the solution isn't) it means trying to engage in a
discussion about "how to fix it". A discussion isn't a monologue, is
it? And I know that Django committers are all volunteers, but aren't
many of the non-committers who make suggestions volunteers too? You
mentioned empathizing, so put yourself for a minute in the position of
non-committers who want to suggest how to improve something. If their
suggestions seem to disappear into the ether, and are *apparently*
ignored by the core devs, then what would constitute reactions from
the suggester which are "not unreasonable"?

I've got some quotes from Yuri's post, with my comments and questions:

"... who will respond on what kind of messages, what part of Django
contributions is under their maintenance."

I have to admit, I don't know the answer to this. Is it documented
somewhere? Does it matter, in your view?

"Moreover, new contributors are considered the least important
creatures in the world!!!"

Do you disagree with this? Obviously newcomers will need to earn the
trust of the community and the committers. But perhaps a way needs to
be found of avoiding what mrts characterises as "there are many who
have at times felt frustrated how contributions or suggestions are
managed in Django. Some of them seem to have walked away or just don't
participate in discussions any longer". Or this this just a figment of
mrts' imagination?

"The more you do, the more attention your suggestions receive. But for
your first enhancement to be approved, you'll have to wait a year!"

It would seem that what the suggestion is should merit the level of
attention rather than who the suggester is, modulo the notion that
obviously old hands have greater credibility than new kids on the
block.

"Half of feature expressed in list is never replied by core developers
with their opinion or explanations. Half of feature requests in Trac
got misunderstood or not replied or
reviewed within 1 year."

"Imagine your recipients email boxes silently drops 50% of your
traffic, and recipients don't response on 50% of last 50% within first
year of waiting"

Leaving aside the exact time frames and percentages which may well be
exaggerated, do you feel that the process is working so well that no
one is justified in feeling the frustration that's obviously being
expressed?

Overall ISTM that people are expressing frustration at "being hard
done by" rather than just being ungrateful whiners. Or am I coming
across as an ungrateful whiner myself? ;-)

Re: The this-needs-to-be-in-django angst

[James Bennett]

On Tue, Oct 20, 2009 at 8:44 AM, Yuri Baburov  wrote:
> Moreover, new contributors are considered the least important
> creatures in the world!!!

As they say on Wikipedia, "[citation needed]". This list grows with
every new release:

http://code.djangoproject.com/browser/django/trunk/AUTHORS#L27

> Half of feature requests in Trac got misunderstood or not replied or
> reviewed within 1 year.

The tickets currently open in Trac represent approximately 14.5% of
all tickets ever opened. About 15% of all open tickets are currently
at the "unreviewed" stage.

These numbers suggest that you are, at the very least, exaggerating
quite a bit. I'm sure you can and will cherry-pick a few tickets to
try to show as examples of why you're right, but on the whole the
statistics aren't in your favor here.

That doesn't mean we can't do better, of course (we could always do
better), but it does mean that your claims need to be taken with a
pretty big grain of salt.

> So I hope django team will analyze their management structure
> critically and at least set responsible persons (maintainers) for
> different parts, to ensure there are no items nobody wants to
> listen/answer on feature request.

You seem to think that any input anyone makes gives them an automatic
claim to the time and attention of a committer. I think that's a
rather strange idea, because I already don't have enough hours in the
day to get the stuff done that I'm doing right now, and that's not
exactly a unique situation to be in. This is the point where,
traditionally, someone steps up and says we should just bring in a
bunch of new committers -- then there'd be plenty of people with
plenty of time! -- but it's still not going to get what you seem to
want, since there'll always be times when nobody can spare much
attention, or requests that nobody particularly feels like dealing
with immediately (and, on the whole, I think it's been a very good
thing for Django to be so stingy with the commit bits).


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[Jacob Kaplan-Moss]

On Tue, Oct 20, 2009 at 9:35 AM, Yuri Baburov  wrote:
> how would you reformulate this in friendly and professional tone so
> this can be discussed?

I don't have time to teach you how to communicate professionally.

Reading your message first makes me feel angry, then dismayed. It
makes me feel as if all the hard work I've put into Django doesn't
matter. It makes me think there's really no point in doing any further
work, because someone will just come along and crap all over it again.

You need to empathize with how someone's going to feel reading your
message. Until you do, people are going to ignore you at best, and get
into a flame war at worst. This is your problem, not mine.

But since good communication is a two-way street, I'll give you a
hand. Why don't you try making some concrete, actionable suggestions
about how you'd like to volunteer to improve things? If you see
something broken, how about starting by offering to fix it?

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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[Jacob Kaplan-Moss]

On Tue, Oct 20, 2009 at 10:52 AM, mrts  wrote:
> Jacob, I'm afraid you totally misunderstood me.
> My message was intended to encourage people to
> scratch their own itches more now that it's so
> much easier -- and, of course, give back --
> instead of grumbling on the mailing list.

Yup, that's very constructive advice, and my apologies: I was mostly
referring to Yuri's message when I talked about tone. Although you're
both talking about forks, you're doing it in a much more constructive
way.

You have to understand that historically the fork as been the nuclear
option in open source. Threatening to fork the code is roughly the
equivalent of saying "screw you guys." Forks diverge quickly, and
reconciliation becomes difficult, and so it's hard to feel any desire
to engage.

I understand you're saying something different here -- DVCSes have, to
a limited degree, changed the story when it comes to forks. Rather,
it's enabled a middle ground -- distributed branches -- that allow
many of the benefits of a fork without all the heartache.

What's frustrating, though, is hearing that you have a problem with
our workflow without any concrete suggestions to improve it or offers
of assistance. There's a general theme underlying most of this "angst"
(as you call it): the tone implies that you're somehow entitled to our
(core developers) time and energy, when we're just as stressed,
harried, and busy as you.

We're *volunteers*. We work on Django because we *want* to, because it
scratches our own itches. This sense of entitlement to our time and
energy is rude and offensive. If *anything* gets done, it's because
someone volunteers to do it. If things aren't getting done, volunteer.

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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[mrts]

Jacob, I'm afraid you totally misunderstood me.
My message was intended to encourage people to
scratch their own itches more now that it's so
much easier -- and, of course, give back --
instead of grumbling on the mailing list.

I fail to see how can "so it's time to put the
grudges behind and happily fork and branch Django
on the DVCS sites whenever there's a need for
something missing from or broken in the official
trunk - and, what's perhaps even more important,
give back by shepherding the corresponding tickets
in Django trac" considered to be hostile.

Baffled,
MS

P.S. I've worked on [1] exactly that way, is that
considered to be hostile?! If so, please elaborate.

[1] http://code.djangoproject.com/ticket/7028

On Oct 20, 5:23 pm, Jacob Kaplan-Moss  wrote:
> Hi Yuri, Mart --
>
> I feel that I need to make it clear that I'm not ignoring you, or this
> conversation. However, the tone is so hostile and unprofessional that
> it'd be a waste of my time to try to engage, so I'm simply going to
> stay out.
>
> 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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Reversing URL for a view with namespaces

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> On the 'missing something' front, reverse() now takes a 'current_app'
> argument that gives context to the app lookup, which resolves the
> ambiguity from the point of view of the reverse() function.

I saw this one. It doesn't work in this case exactly beacuse of this:

> This solves the problem as long as applications have been built to
> provide a namespace.

Which means an app knows its exact namespace.

> However, this doesn't fully address the 'bug' you
> describe - an application that hasn't been built to accept namespaces
> will have problems if it is deployed in a namespace.

There's important detail here.

One thing is a namespace-ignorant application that just uses reversing 
the old way. I don't think we can fix it in any way except saying 
somehow "don't install this app under a namespace" (as you suggested).

Another thing is an application that is being written now and that wants 
to be namespace-aware. The problem is that while an application knows 
that it can be included under a namespace it doesn't care under which 
one exactly.

As far as I can tell it can be solved by keeping views in 
resolver.reverse_dict as it was before namespaces were introduced as 
well as in namespace_dict and app_dict. This way they could be found 
both by specifying a name with or without namespace. However it doesn't 
solve the problem when you have two instances of the same application. 
For this we should have a way for an application to know which instance 
of it is "current". Which means tying reversing to a request (right?). 
At this point I didn't come up with anything more useful...

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal for __neq field lookup

[Michael P. Jung]

rm> exclude(x=1).exclude(y=2) translates to NOT (x=1) AND NOT (y=2)

So why do we have __gt, __ge, __lt, __le then? It would be as simple to
have only __le and get rid of the rest as it can easily expressed using
exclude and filter. I know, it's picky, but you get my point.

I don't see why all comparison operators are supported except for one:

http://dev.mysql.com/doc/refman/5.1/en/comparison-operators.html
http://www.postgresql.org/docs/8.3/static/functions-comparison.html

mp> (...) Since __isnull is ment to be obsolete, according to Russ
mp> Magee, it'd be really ugly having to rewrite these queryies to a
mp> chain of excludes.

rm> I didn't say they were obsolete - I said that they existed for
rm> historical reasons. I don't think there's been any formal decision to
rm>  deprecate these operators.

Whops. Sorry for quoting you wrong. I thought you ment it was supposed
to be obsolete even though it hasn't been marked as such yet.


--mp

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Dennis]

> Signed cookies are useful
> for all sorts of things - most importantly, they can be used in place
> of sessions in many places, which improves performance (and overall
> scalability) by removing the need to access a persistent session
> backend on every hit. Set the user's username in a signed cookie and
> you can display "Logged in as X" messages on every page without any
> persistence layer calls at all.

I appreciate your signed cookie work.  I downloaded the latest version
with the
intent of using it to implement cookie-based login.
But in researching how to use signed cookies for login, I came across
this technique used by drupal:
http://jaspan.com/improved_persistent_login_cookie_best_practice
(based on 
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/
)
which just uses server-side state (and no encryption at all).

So, there seem to be several alternatives.
>From the pastiche.org article's premise 2, it seems that a signed
cookie containing a user identifier
is sufficient for cookie-based login.
Very easy to implement with your signed cookie implementation.
On the other hand, cookie-based login can be achieved with regular
cookies and
some server state.
The later solution also allows identification of stolen cookies when
the real user logs in
and a mutating cookie which reduces a stolen cookie's lifetime.
But this requires implementing their specs and lots of testing.
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal for __neq field lookup

[Russell Keith-Magee]

On Tue, Oct 20, 2009 at 10:09 PM, Michael P. Jung  wrote:
>
> I'd like to propose a new field lookup __neq which could be used to
> negate a single parameter. It is not ment to make exclude() obsolete, as
> they both have a different scope:
>
> filter(x__neq=1, y__neq=2) would translate to "(x <> 1 AND y <> 2)"
> while exclude(x=1, y=2) translates to "NOT (x = 1 AND y = 2)"

yes, but:

exclude(x=1).exclude(y=2) translates to NOT (x=1) AND NOT (y=2)

So, put me down as -1 on this.

As a matter of historical note, once upon a time, Django _did_ have a
__neq operator. It was removed in favour of the exclude() grouping.

> So far I'v never come across a single use case, where I had to exclude()
> based on more than one field, but I have several applications where I
> perform more than one __isnull=False lookups. Since __isnull is ment to
> be obsolete, according to Russ Magee, it'd be really ugly having to
> rewrite these queryies to a chain of excludes.

I didn't say they were obsolete - I said that they existed for
historical reasons. I don't think there's been any formal decision to
deprecate these operators.

> Besides exclude(x=None).exclude(y=None).exclude(z=None) feels less
> intuitive to me than filter(x__neq=None, y__neq=None, y__neq=None).

Opinion noted, but I disagree :-)

The way Django interprets filter() and exclude() groups is consistent
across a number of uses, including logical structure and join reuse.
Personally, I don't find it at all unusual that exclude(A, B) is
different from exclude(A).exclude(B).

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[Yuri Baburov]

On Tue, Oct 20, 2009 at 9:23 PM, Jacob Kaplan-Moss  wrote:
>
> Hi Yuri, Mart --
>
> I feel that I need to make it clear that I'm not ignoring you, or this
> conversation. However, the tone is so hostile and unprofessional that
> it'd be a waste of my time to try to engage, so I'm simply going to
> stay out.

Hi Jacob,

well, let's go further,

how would you reformulate this in friendly and professional tone so
this can be discussed?

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[Russell Keith-Magee]

On Tue, Oct 20, 2009 at 10:23 PM, Jacob Kaplan-Moss  wrote:
>
> Hi Yuri, Mart --
>
> I feel that I need to make it clear that I'm not ignoring you, or this
> conversation. However, the tone is so hostile and unprofessional that
> it'd be a waste of my time to try to engage, so I'm simply going to
> stay out.

Likewise for myself.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[Jacob Kaplan-Moss]

Hi Yuri, Mart --

I feel that I need to make it clear that I'm not ignoring you, or this
conversation. However, the tone is so hostile and unprofessional that
it'd be a waste of my time to try to engage, so I'm simply going to
stay out.

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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal for __neq field lookup

[Dennis Kaarsemaker]

On di, 2009-10-20 at 16:09 +0200, Michael P. Jung wrote:

> Besides exclude(x=None).exclude(y=None).exclude(z=None) feels less
> intuitive to me than filter(x__neq=None, y__neq=None, y__neq=None).

That's what Q objects are for:

.filter(~Q(x=None),~Q(y=None),~Q(z=None))

or:

.filter(~(Q(x=None)|Q(y=None)|Q(z=none))
-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.


--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Change compilemessages command

[urukay]

Hi folks,

is there a plan to change command compilemessages, so it will ignore
duplicity translations? In my native language it's necessary to have more
than one translation for particular string.

Radovan 
-- 
View this message in context: 
http://www.nabble.com/Change-compilemessages-command-tp25975917p25975917.html
Sent from the django-developers mailing list archive at Nabble.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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: auth.User: a new approach

[Russell Keith-Magee]

On Mon, Oct 19, 2009 at 11:52 PM, Hanne Moa  wrote:
>
> It doesn't look like Contrib-06, covering ticket #3011, Allow for
> extendable user module, will be in for 1.2. So: let's think afresh,
> start from scratch, think about what we really, really want. This is
> my pony for *2.0*:

I completely agree that we need to do something about #3011. If you
look at the voting, I'm +1 in favour - with the caveat that the most
recent patch on #3011 is *completely* the wrong approach.

However, the time has really past for big ticket discussions for v1.2,
and it certainly isn't the time to talk about ponies for v2.0. We've
just been through a 3 month process of discussing features, and this
discussion process consumes a lot of time. At some point, we (the
community) need to stop talking about features and start implementing
them, and we (the core team) needs to start integrating the work that
the community develops. That point is essentially now.

I don't want to dampen your enthusiasm here - I think this is a _very_
important problem, and your analysis covers many of the reasons why I
think this ticket is important, and the use cases that we need to
capture with any potential replacement. I just want to point out that
now isn't the best time to start an abstract discussion about big
changes.

Personally, I think you're on the right path - I think auth.User needs
to become a barebones model that is essentially just a primary key,
some datestamps for last login and last modified, and m2m relations
with permissions. Authentication should then be against a
profile-style model; calls like user.get_full_name should be deferred
to the information provided by the auth profile.

One of the big problems that needs to be solved that you haven't
addressed is the migration path. Obviously, we can't just replace the
current auth.User model - we need to have a migration plan for all
existing users of contrib.auth. I have some ideas on how this could be
done, but I'd be interested in hearing what others come up with. There
are also complications with integrating with admin that need to be
worked through.

So, if you want to play around with ideas in this space, I encourage
you to do so. Having a working implementation of an alternative auth
module would be a good starting point for discussions when we make the
call for proposals for v1.3.

If you need feedback on a design issue you confront, django-developers
is still the right place to ask. However, I want to moderate your
expectations regarding the level of intense design discussion that the
core will be able to engage in while simultaneously working on v1.2.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Proposal for __neq field lookup

[Michael P. Jung]

I'd like to propose a new field lookup __neq which could be used to
negate a single parameter. It is not ment to make exclude() obsolete, as
they both have a different scope:

filter(x__neq=1, y__neq=2) would translate to "(x <> 1 AND y <> 2)"
while exclude(x=1, y=2) translates to "NOT (x = 1 AND y = 2)"


So far I'v never come across a single use case, where I had to exclude()
based on more than one field, but I have several applications where I
perform more than one __isnull=False lookups. Since __isnull is ment to
be obsolete, according to Russ Magee, it'd be really ugly having to
rewrite these queryies to a chain of excludes.

Besides exclude(x=None).exclude(y=None).exclude(z=None) feels less
intuitive to me than filter(x__neq=None, y__neq=None, y__neq=None).


--mp

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The this-needs-to-be-in-django angst

[Yuri Baburov]

Hi Mart,

actually, you are half right. Fork & go.

Still the main reason I wrote wasn't recognized.

Total anarchy in Django team.

Core developers don't agree with each other on who will respond on
what kind of messages, what part of Django contributions is under
their maintenance.
Moreover, new contributors are considered the least important
creatures in the world!!!

The more you do, the more attention your suggestions receive. But for
your first enhancement to be approved, you'll have to wait a year!
Ingenious!

Half of feature expressed in list is never replied by core developers
with their opinion or explanations.
Half of feature requests in Trac got misunderstood or not replied or
reviewed within 1 year.

Imagine your recipients email boxes silently drops 50% of your
traffic, and recipients don't response on 50% of last 50% within first
year of waiting, after their receive confirmation, because they can't
decide who can do what responses and they just don't have time.
Will you succeed? Would you ever try?

And a bit more about "fork & go" + "better maintenance":

Say, if django team will not agree with JQuery merge into admin app,
I'll fork django.contrib.admin as a separate project.
It will increase development speed in about 3 times, maybe more.
I still have much more other things to do it right now, but someone
else might think as a brilliant idea to do that right now ;)
I think some other modules can also be moved to separate repos, making
someone (maybe out of django team) their sole maintainer, or using
distributed model, and thus enhancing development speed in 3-100
times.

So I hope django team will analyze their management structure
critically and at least set responsible persons (maintainers) for
different parts, to ensure there are no items nobody wants to
listen/answer on feature request.
I strongly believe there should be no attempts to contribute that
"didn't attract our attention".

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Reversing URL for a view with namespaces

[Russell Keith-Magee]

On Tue, Oct 20, 2009 at 5:34 AM, Ivan Sagalaev
 wrote:
>
> Hello!
>
> I've just stumbled upon a difficult to understand problem. I have an app
>  that has an urlconf which is included in a project under a namespace:
>
>     (r'^blog/', include('app.urls', namespace='blog')),
>
> This namespace allows things like {% url blog:article ... %} which is
> very nice. But reversing doesn't work when an app itself tries to
> reverse its own urls having a callable at hand:
>
>     reverse(views.article, args=[...])
>
> It doesn't work because namespaced URLs are basically excluded from
> resolver's reverse_dict and are put in their own resolvers under
> namespace_dict. And reverse doesn't traverse those when it gets a callable.
>
> On one hand I can see logic here: trying to reverse a namespaced URL
> without specifying a namespace can lead to ambiguous results. But in
> practice it means that one can break any third-party app that reverses
> its URLs (using models.permalink, redirect, or reverse) just by
> including its urlconf under a namespace. Because an app doesn't know its
> namespace and then has no way of constructing a correct URL.
>
> Am I missing something or is it an evil bug?

A little bit of both.

On the 'missing something' front, reverse() now takes a 'current_app'
argument that gives context to the app lookup, which resolves the
ambiguity from the point of view of the reverse() function.

This solves the problem as long as applications have been built to
provide a namespace. However, this doesn't fully address the 'bug' you
describe - an application that hasn't been built to accept namespaces
will have problems if it is deployed in a namespace. contrib.comments
is one example of an application that you just can't deploy in a
namespace. It hasn't been written to allow this mode of deployment.

I'm not sure of the best solution to this problem, though.

This is at least partially a documentation problem. contrib.comments
simply isn't namespace-ready. The docs should probably say so, as
should the docs for any other app that provides an URLpattern that
needs be deployed.

However, it isn't *just* a documentation problem. We should probably
also provide some API-level protection to make sure that mistakes like
this aren't made by accident.

One possible approach would be to allow an application to mark its URL
patterns as "namespace safe"; include() would then raise an error if
the URLpattern that is included with a namespace doesn't have this
flag set (and/or raise an error if the urls are included without a
namespace and the flag *is* set).

The default would need to be 'not safe', so this would be a backwards
incompatible change for anyone that is currently using include with a
namespace on an app that doesn't have the flag set. This would be
slightly backwards incompatible for any existing uses that don't use
reverse() internally, or ship with sample templates that use {% url
%}.

However, I'm open to any other suggestions.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Join .Net Community

[Shawon_]

Join .Net Community

This group represents the Microsoft .Net community. All .net
programmers all around the world are welcome here. In this group
you'll find the latest releases of .Net related products, frameworks,
Upgradation, technologies, IDEs etc. You also can share your
experiences and problems you are facing. You can discuses about
C#.Net, VB.net, ASP.Net and .Net frameworks, .net in other operating
system etc. topics.



http://www.dotnetcommunity.tk
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Tutorial Refresh

[Dougal Matthews]

2009/10/19 Jeff Anderson 

>
> An official "real-life", advanced tutorial would have been wonderful to
> fill
> the gap that I had. It would have saved me quite a bit of *re-learning*
> things,
> which is always annoying.
>

If you can outline some of the gaps you had and examples it might be useful
for somebody when tackling the content for this. A more advanced topic is
fine but as long as it covers the topics people learning consider to be
advanced or initially more difficult.

Dougal

--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---