Localflavor "US state" field choices

[James Bennett]

Over the past few months we've had a few back-and-forth tugs in the
ticket tracker, and a couple of commits, related to the choice list
for ``django.contrib.localflavor.us.forms.USStateField.``

Relevant background:

* First, ticket #8425 asked for several choices to be removed, on
  grounds that they are now sovereign nations and not US territories
  or protectorates (resolution: the choices were removed):
  http://code.djangoproject.com/ticket/8425

* Then, ticket #9022 asked for US armed forces postal codes to be
  supported (resolution: wontfix):
  http://code.djangoproject.com/ticket/9022

So it seems there's some tension as to what, exactly, "USStateField"
should do, and it seems there are a few options we could go with here:

1. Support only the fifty entities which are states of the US, and
   nothing else. This would make it a true "US state field", but would
   be unacceptable since this would exclude the District of Columbia
   (which is, famously, not a state) and so make quite a lot of people
   very unhappy.

2. Support the fifty states and the District of Columbia, and nothing
   else. This would technically add something that's not really a "US
   state", but I think most people would forgive us for it, and this
   is a bit more acceptable since it covers all common US
   destinations, for things like order forms which need addresses
   filled in.

3. Support all 50 US states, the District of Columbia, US overseas
   territories/protectorates/dependencies, and US armed forces postal
   codes. This would move further from just being  "US state" field,
   but would cover a much wider range of "US" addresses.

4. Support the full list of locations/codes supported by the US postal
   service[1]. This includes several places which are sovereign
   nations, but which have specialized treaties or other agreements
   with the US (often the result of former trust territory status) and
   so are supported by the US postal service as "US" addresses.

Personally I lean toward option 4. For a ``localflavor`` module, I
think we really ought to rely on appropriate local authority whenever
available, and in this case the US postal service is the appropriate
authority for what constitutes a "US" address.

One alternative, of course, would be to provide a number of separate
fields -- one for "US states + DC", one for "US territories and
protectorates", one for "US armed forces postal codes", etc. -- but
given that the utility of a ``localflavor`` field like this mostly
comes from having a *single* field that can cover addresses for a
given locale, I'd be rather averse to it.

Also, from a backwards-compatibility perspective, the ``USStateField``
in current trunk is a functionality regression for anyone relying on
the ``USStateField`` from Django 1.0.x, and that's also something I'd
prefer to avoid.

Does anyone have strong feelings on this one way or another? With 1.1
looming I'd like to get this resolved and have a consensus view we can
point folks to if there are further concerns about it.


[1] http://www.usps.com/ncsc/lookups/abbreviations.html#states

-- 
"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: Is this true. that django really takes a lot of memory?

[James Bennett]

On Tue, Feb 17, 2009 at 7:49 PM, Malcolm Tredinnick
 wrote:
> I'd be somewhat against this, I think. It's *very* easy to reuse
> querysets and inadvertently cause extra database queries. Unless you're
> using really huge querysets, the memory usage is not going to kill you.
> Pulling back the huge number of results already uses a bunch of memory
> and that's a property of the db wrapper. There's a multiplier involved
> for creating Python objects.

Speaking as someone who has (accidentally) brought down a beefy server
by accidentally evaluating a reasonably large QuerySet, I'd say
there's not a whole lot we can do without impacting usability in
other, more vital-to-support scenarios.

When we had our nasty server-crashing query (which thankfully never
made it out of staging; that's what staging servers are for and why
you should have one to test things before you ever think about
deploying), just fetching the data from the DB -- no object
instantiation at all -- was a significant drain. Actually trying to
instantiate the model objects kicked the usage up even higher, of
course, but it was mostly an interesting exercise in watching the
memory spike move from place to place as the data worked its way from
the DB to the Python process in which Django was running.

(incidentally, the above sort of situation is one reason why a
QuerySet limits itself to a certain number of objects displayed in
__repr__; the real killer was that an error was being thrown, and as
part of the Django debug page it was trying to print the __repr__ of a
QuerySet of, IIRC, about half a million objects. A QuerySet doesn't
try to do that anymore)


-- 
"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: App Engine port

[James Bennett]

On Fri, Feb 6, 2009 at 8:51 AM, David Stenglein
 wrote:
> I have to ask a question here. Why is there such reticence regarding
> App Engine?

I'm curious as to what reticence you think there is; since, as Russell
said, code to get a straight Django with all features working on App
Engine would be welcome, I don't really get the same vibe. The only
thing is that we're past the point where major features like this can
be proposed for Django 1.1; we're aleady a bit behind schedule getting
out the first alpha release, and delaying it even further isn't
something we can do at the moment.


-- 
"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: How to help with doc?

[James Bennett]

On Fri, Jan 16, 2009 at 1:53 PM, Geoffrey Ducharme
 wrote:
> From what I gather, the documentation effort have been mostly voluntary and
> not well organized. For example, I don't think there is a mailing list for
> documentation feedback. People like you seem to pop in from time to time,
> ask a few questions and then leave.

Documentation works the same way *any* contribution to Django works;
there's not a separate or different process for it, so just follow the
standard guidelines[1] for contributing to Django (which, btw include
a style guide for documentation). And major changes to the
documentation are generally discussed here on this list just the same
way major changes to Django's code are discussed.

If someone's interested in helping out, reading the contributing
guidelines, then looking at open documentation bugs[2] and submitting
patches, would be the way to go. For issues not covered by open
tickets, open a ticket and attach a patch (and keep in mind there's no
need to announce it; all the folks with commit bits are paying
attention to the tracker, and most get automatic notification of all
new tickets).

[1] http://docs.djangoproject.com/en/dev/internals/contributing/
[2] 
http://code.djangoproject.com/query?status=new=assigned=reopened=Documentation=priority

-- 
"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: deploying django project

[James Bennett]

This question most properly belongs on the django-users list.

Also, you may want to consider spending some time with the Django
documentation (in particular, searching the docs index for the word
"deploy").


-- 
"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: Problem with ORM

[James Bennett]

On Thu, Jan 15, 2009 at 2:58 AM, Jan Bednařík  wrote:
> this is happening, because Django ORM is not working as what you
> expect from ORM.
>
> In real ORM, this:

No... I don't think you mean "real ORM", I think you mean
"identity-mapping ORM". Those terms are not the same.


-- 
"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: Distributed workflow and the woes of slow testsuite

[James Bennett]

On Mon, Jan 12, 2009 at 6:53 AM, mrts  wrote:
> What if we try to be nice to ourselves and get #8138 and something in
> the lines of http://oebfare.com/blog/2008/mar/25/faster-django-test-suite/
> into trunk ASAP

What if we pay attention to the work that's been done on that
recently, including during the mini-sprint on Saturday?



-- 
"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: manage.py has x flag turned off

[James Bennett]

On Sat, Dec 27, 2008 at 4:18 PM, bedros <2bed...@gmail.com> wrote:
> my apologies, django 1.0.2 final does not have x turned on for
> manage.py.  However, the book I'm reading "Python Web Development with
> Django" has the x turned on. It must be that they used a version
> before 1.0.2 final. (it covers django 1.0)

Most official documentation will, IIRC, tell you do do 'python
manage.py runserver' rather than './manage.py runserver', which solves
this and potentially some other issues (e.g., with Windows where it
can be tricky to set up the association to make sure Python runs the
script, but where just invoking Python to run it always works). I
can't vouch for third-party documentation or third-party books,
however.


-- 
"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: Perl port of the django template system.

[James Bennett]

On Fri, Dec 26, 2008 at 11:36 AM, Maluku  wrote:
> Kind of different question: Why is there no {% else %} in {% ifchanged
> %}, I think it might be a help to some people.

Because it wouldn't make any sense; the point of 'ifchanged' is to say
"I have a special thing which only needs to happen when this other
thing changes", not to set up complex chains of conditionals.


-- 
"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: Perl port of the django template system.

[James Bennett]

On Tue, Dec 16, 2008 at 11:04 PM, Eugene Lazutkin
 wrote:
> Some people are blessed with being naturally confused without external
> factors.

Indeed. Documenting that something implements the same format as
Django templates will only confuse people who were already going to be
confused anyway (e.g., showing them a Python implementation of
Markdown or Textile would have the same effect). So I don't see any
problem there.

> Personally I like DTL --- it is a short memorable to-the-point acronym
> that pays homage to Django, yet distinctive enough from everything else.
> It doesn't play on subtle associations nor obscure music trivia, yet it
> doesn't hide its heritage.

I like it, especially since there's prior art.


-- 
"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: Perl port of the django template system.

[James Bennett]

On Tue, Dec 16, 2008 at 10:32 PM, alex.gay...@gmail.com
 wrote:
> I am not a legal expert(that's Justin's job ;-) ), but there is a
> precedent for a derivative template language going by the same name,
> Dojo also implements the Django template language and calls it just
> that.  That being said, that, amongst other things preceded the
> existence of the DSF.

Actually, they call their package "dojox.dtl". Their documentation
explains that it implements the Django template language.


-- 
"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: Default manager

[James Bennett]

On Tue, Dec 16, 2008 at 10:21 AM, Alberto Donato
 wrote:
> I don't see any downside in this proposal.

His proposal seems to center around forcibly making "objects" *always*
be a manager returning an unfiltered QuerySet, so I'm not sure where
it'd allow for that. And that's a downside (not to mention the fact
that it's really not that hard to get stuff right currently -- the
default behavior works, and if you start customizing the documentation
explains clearly what will happen and what to do).


-- 
"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: Default manager

[James Bennett]

On Mon, Dec 15, 2008 at 4:51 AM, Alex Rades  wrote:
> my understanding about custom managers is that if you want to define a
> custom manager, you also HAVE to remember to define the "objects"
> manager first, otherwise some parts of django (eg. admin) will not
> work.

No, if you want to have every object viewable/editable in the admin
you have to either set up a default manager which makes all objects
available, or you have to do some overriding in the ModelAdmin
subclass to make sure it gets the QuerySet you want it to get.

> I find this suboptimal.

I find it pretty logical, and I can think of plenty of cases where the
ability to prevent access to certain objects is a requirement. So I'm
very much against this proposal.


-- 
"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: How do you handle cascading deletes in your production apps?

[James Bennett]

On Thu, Dec 11, 2008 at 7:06 PM, Simon Litchfield  wrote:
> +1. Definitely need some kind of cascade=False option somewhere. I'd
> argue it should be the default. I have some production horror stories
> which I'm sure I don't need to share.

Keep in mind there is some prior art here which may be useful to review:

http://groups.google.com/group/django-developers/msg/4c65ac76d85c5c34


-- 
"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: IDN (Internationalized Domain Names) support for EmailField and URLField

[James Bennett]

On Fri, Dec 5, 2008 at 10:55 PM, UloPe <[EMAIL PROTECTED]> wrote:
> I created a ticket for this and added a patch which adds this
> fuctionality:
> http://code.djangoproject.com/ticket/9764

I have created a reply to your email pointing out that anyone who's
interested is likely already subscribed to either a dedicated
auto-mailer or an RSS feed providing information about new and updated
tickets, so there's no need to post an email here simply to say that
you opened a ticket.

As the contributing docs (which we recommend everybody read) state[1]:

"Don't post to django-developers just to announce that you have filed
a bug report. All the tickets are mailed to another list
(django-updates), which is tracked by developers and triagers, so we
see them as they are filed."

[1] http://docs.djangoproject.com/en/dev/internals/contributing/#id1


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: logout() method for custom authentication backends

[James Bennett]

On Mon, Dec 1, 2008 at 8:10 AM, David Reynolds
<[EMAIL PROTECTED]> wrote:
> That doesn't help if you want to continue using the login/logout views
> from django.contrib.auth.views

Since you can drop callables directly into URL patterns, you can write
a decorator which does what you need, import the logout view into your
URLConf, decorate it there and then use the resulting callable in a
URL pattern.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: deprecate and remove django.utils.simplejson

[James Bennett]

On Mon, Dec 1, 2008 at 12:45 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> I have to say I agree with Malcolm. I don't believe we are currently
> hampered in any real way by bundling an old version of the SimpleJSON
> library, and it doesn't take that much effort to update the bundled
> version of SimpleJSON when the time comes.

I guess the thing that's bugging me is that this mostly seems to come
down to historical inertia; we already have simplejson in Django, and
so the perception is that we should continue to bundle it. I think
eventually we're going to have to get rid of it since sooner or later
we'll be targeting only Python versions which have a json module built
in, so we might as well start dealing with it.

> On the other hand: at present, the only prerequisite for running the
> system test suite is a database backend, and not even that if you're
> running Python 2.5 and SQLite. If we stopped packaging SimpleJSON with
> Django, a great chunk of the system test suite would no longer work
> out of the box. On top of that, no matter obvious we make the error
> message, we're going to get "Why doesn't my fixture load" questions on
> Django-users.

Several large and popular third-party Django apps already make use of
non-JSON fixture formats; for example, Satchmo cannot load its
fixtures or run its unit tests without PyYAML (and in my experience,
YAML is preferred over JSON as a fixture format when it can be used),
and yet they don't seem to be crushed under the weight of "I can't
load the fixtures" problems.

Similarly, ImageField has always required PIL (which is much trickier
to install), and yet we don't see corresponding large numbers of
questions on this list from people who can't manage to get it working.

So I have a hard time believing that this would pose such a large
hurdle to use of Django.

> IMHO, the suggestions hovering around #9266 and the related mailing
> list threads - that users should be able to override the bundled
> version of SimpleJSON - have merit, and it looks like Malcolm has a
> handle on how to make this approach happen. However, completely
> removing SimpleJSON seems like asking for a world of pain, with no
> real gain.

To me, the gain is no longer bundling and maintaining something that
we don't *have* to bundle and maintain. Advertising simplejson (or
Python 2.6+) as a dependency for using JSON serialization doesn't, to
me, seem to be too onerous a thing to do, and it gets something out of
Django (where, arguably, it didn't belong in the first place) and out
of our hair.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Proposal: deprecate and remove django.utils.simplejson

[James Bennett]

Apologies for bringing this up past the 1.1 feature deadline, but
since this isn't a feature perhaps it'll be OK :)

Currently, Django bundles a copy of simplejson[1], at
django.utils.simplejson. We use this solely in the serialization
system to support dumping to and loading from JSON fixtures.

This presents several problems:

1. Because we exclusively look for Django's copy of simplejson, we
   naturally cannot take advantage of bugfixes or performance
   improvements in simplejson unless/until we integrate them into the
   bundled copy.

2. This in turn creates a maintenance headache and a source of
   potential bugs (e.g., one found recently by someone using NetBeans
   to report unresolved symbols[2]).

3. We constantly get into debates about when and how often to update
   our bundled copy of simplejson.

4. We occasionally get into debates over whether Django ought to first
   search for a system-installed copy of simplejson or for the "json"
   module (simplejson under a new name) which exists in the Python
   standard library as of Python 2.6[3].

It is occasionally stated that Django tries, as much as possible, to
avoid having many dependencies out of the box and, if this is true,
then bundling simplejson may make sense despite the above problems, as
it means there's one less piece of software people need to install to
use Django.

But this argument doens't really hold water, because we already
require people to install:

* A database adapter (unless on Python 2.5+ and using SQLite).

* PIL, to use ImageField.

* The Python memcached bindings to use memcached.

* Perversely, Jing to use XMLField.

* flup to use FastCGI/SCGI/AJP.

* A whole pile of stuff to use django.contrib.gis.

* And, most damning for th case of something that's only bundled to
  support serialization, PyYAML for YAML serialization.

I'm sure there are more dependencies lurking out there, actually,
depending on which bits of Django people want to use, but hopefully
the point is made: any argument based on "Django doesn't have
dependencies" falls flat, because Django's always had various
dependencies for the core framework and various others for additional
functionality.

Given this, the fact that it's trivially easy to install simplejson
(and it's bundled with Python these days) and the fact that it creates
a number of problems, I'd like to propose that we begin the process of
deprecating and removing django.utils.simplejson in favor of
system-installed simplejson or Python 2.6 json. Since eventually we'll
have to get to Python 2.6/3.0 anyway (see my earlier Stephensonian
post regarding *that* migration process) and when we do there'll be
literally no point to bundling our own copy, we can even view this
simply as getting a head start on the process.

The only remaining argument I can see against unbundling simplejson is
that it would break backwards compatibility in the 1.x release
series. While this is undoubtedly a pedantic answer, the API stability
document[4] is quite clear about which parts of Django constitute
stable, supported APIs, and django.utils.simplejson is not one of
those parts (in fact, most of django.utils is not).

This leaves only the question of how, precisely, we'll get simplejson
out of Django. One possibility would be to deprecate and remove over a
period of releases, and this would be consistent with, e.g., how
Python typically handles this problem. Such a process might look like
this:

* Django 1.1: JSON serialization looks for system json/simplejson
  first, fall back to django.utils.simplejson if not found and warn
  with PendingDeprecationWarning whenever django.utils.simplejson is
  used.

* Django 1.2: Continue looking for system json/simplejson and falling
  back, but the PendingDeprecationWarning becomes a
  DeprecationWarning.

* Django 1.3: django.utils.simplejson is removed, and attempting to
  use it simply gets you an ImportError. Use of JSON serialization
  will require separate installation of simplejson, or Python 2.6 with
  the json module.

In the meantime, django.utils.simplejson should basically cease being
maintained apart from bugs which interfere with the use of JSON
serialization; in other words, new versions of simplejson should not
be integrated into Django, and users should be advised that if they
want to use a newer version they should simply install it (since
Django will start using system json/simplejson when available).

So... thoughts?


[1] http://pypi.python.org/pypi/simplejson
[2] http://blogs.sun.com/tor/entry/netbeans_screenshot_of_the_week1
[3] http://docs.python.org/dev/library/json.html
[4] http://docs.djangoproject.com/en/dev/misc/api-stability/#misc-api-stability


-- 
"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 

Re: Dropping Python 2.3 compatibility for Django 1.1

[James Bennett]

On Thu, Nov 27, 2008 at 7:20 AM, Tim Chase
<[EMAIL PROTECTED]> wrote:
> So I'm somewhere between -0 and -1 on the voting scale regarding
> forced/long-range Python-version deprecation.  But when a version
> becomes sufficiently dead weight, slowing down Django's progress
> like 2.3 seems to be doing, I'm +0 to +1 on dropping it with one
> Django-version worth of notice.  Once the decision has been made,
> release one last Django version with a "this is the last version
> of Django to support Python version X" notice (judicious timing
> of the discussion-to-drop shortly after an official Django
> release would help).

Well, the big impetus is, of course, Python 3, where the recommended
upgrade process is to get to where the software runs on Python 2.6
(which supports various 3.0-style things that previous 2.x releases
don't and won't) without warnings, and then use 2to3 to help manage
the final transition. Along the way, of course, we'll most likely need
to drop support for older Python versions and so a timeline of how
we're going to do that is a good thing.

Also, note that the timeline I proposed puts the final 2.6-only
support something like two years in the future, which should be plenty
of time for people to get ready and for the benefits of 2.6/3.0 to
become sufficient incentives that we'd want to be at that point.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dropping Python 2.3 compatibility for Django 1.1

[James Bennett]

Apologies for the length of this email, but I've been holding back on
my thoughts about Python version compatibility for a while, mostly due
to the fact that:

1. Until recently, we didn't have a stable Django release series on
   which to begin considering the process of dropping support in
   anticipation of Python 3.0.

2. Python 3.0 isn't available yet.

But now that we have 1.0 (and 1.0.1, and 1.0.2) out the door and 1.1
in planning, and now that Python 3.0 is imminent, I'm going to dump
out my thoughts on the matter in a semi-organized fashion. If you want
to skip the boring bits and just read the conclusion, scroll down.

Now.

The first thing which comes to my mind is a simple question: who's
still stuck with Python 2.3? Anyone whose only option is 2.3 will,
obviously, no longer be able to use Django if we drop 2.3 support and
I'd hate to strand people who want to use Django but don't have the
ability to deploy on a more recent Python. This is also, IMHO, the
strongest argument in favor of maintaining 2.3 support for as long as
possible.


Availability of Python 2.4-compatible platforms
===

So to get things rolling, I spent some time researching the (C)Python
version supported by various alternative Python implementations and
operating systems. What I ended up with is, of course, an incomplete
list, but I think I've at least hit all the major platforms we need to
worry about.

First up, the alternative Python implementations:

* Jython: Jython 2.2.x is roughly equivalent to CPython 2.2, and
  Django has never run on CPython 2.2 so that's a wash. The upcoming
  Jython 2.5 will be roughly equivalent to CPython 2.5, and so
  dropping CPython 2.3 support will not affect users of Jython.

* IronPython: IronPython 1.0.x and 1.1.x seem to be (someone correct
  me if I'm wrong) roughly equivalent to CPython 2.4, and the
  forthcoming IronPython 2.x will be roughly equivalent to CPython
  2.5. So dropping CPython 2.3 support will not affect users of
  IronPython.

Then there are the operating systems:

* Windows: Windows doesn't ship Python, so developers wishing to use
  Django on Windows will need to install Python and will, presumably,
  grab the latest Python they can get. Dropping 2.3 support, then, is
  unlikely to affect Windows users.

* Mac OS X: OS X 10.3 (Panther) and 10.4 (Tiger) shipped Python 2.3;
  10.5 (Leopard) shipped Python 2.5. Thus, dropping 2.3 support may
  pose a problem for OS X users who have neither upgraded to Leopard
  nor installed a more recent Python build (but, of course, a number
  of useful/necessary bits to go with Django are difficult or
  impossible to build on stock OS X, so I'd imagine most people using
  Django on pre-Leopard OS X have installed their own Python,
  presumably a more recent version).

* Red Hat Enterprise Linux/CentOS: RHEL 5 / CentOS 5 ship Python
  2.4. RHEL 4 / CentOS 4 ship Python 2.3. Earlier versions appear to
  have shipped Python 2.2 or older, making this moot for versions
  prior to RHEL / CentOS 4, but there's more to consider here than
  will fit in a bullet point (see below).

* Fedora Linux: Python 2.4 appears to be available for releases back
  to Fedora 6. The current release is Fedora 10.

* Debian GNU/Linux: Current Debian stable (Etch) ships Python 2.4.

* Ubuntu Linux: Ubuntu Linux 6.06 LTS (Dapper Drake), the oldest
  currently-supported release, shipped Python 2.4.

* SUSE Linux Enterprise: SUSE LE 10 ships Python 2.4. SUSE LE 9
  shipped Python 2.3.

* openSUSE: openSUSE 10.2 shipped Python 2.5.

* Solaris: I'm unable to find information detailing which Python
  version ships with various releases of Solaris and OpenSolaris. If
  anyone has that information, please post it in a reply.

* NetBSD: Python 2.4 appears to have first become available in the
  ports tree for NetBSD 2.1. The current release of NetBSD is 4.0.1.

* FreeBSD: Python 2.4 appears to have first become available in the
  ports tree for FreeBSD 4.11. The current release of FreeBSD is 7.0.

* OpenBSD: Python 2.4 is available for the current release of OpenBSD
  (4.4). I'm unable to find historical information detailing when
  Python 2.4 first became available in the OpenBSD ports tree.


What this all means, part 1
===

For the overwhelming majority of platforms in the above lists,
dropping 2.3 compatibility should pose no problem, because 2.4 or
later (or 2.4-compatible or later) are available. This is the good
news.

The bad news is contained simply in the list of platforms which won't
fare so well if we drop Python 2.3 support:

* Red Hat Enterprise Linux 4 / CentOS 4

* SUSE Linux Enterprise 9

I don't know offhand how widely Django is deployed on SUSE LE 9, but I
know from experience that a *lot* of corporate Django deployment takes
place on RHEL 4 / CentOS 4. That's a problem in and of itself, but it
gets worse when you take into account the fact that many of those
deployments cannot, in 

ANN: Django 1.0.2 released

[James Bennett]

Tonight, to clear up some problems with the packaging of the Django
1.0.1 release from Friday, we've released Django 1.0.2; once again,
this is a bugfix-only release, and is a recommended upgrade for anyone
targeting or using Django 1.0 or Django 1.0.1.

Weblog entry announcing the release is here:
http://www.djangoproject.com/weblog/2008/nov/18/102/
Release notes are here: http://docs.djangoproject.com/en/dev/releases/1.0.2/


-- 
"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 [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)

[James Bennett]

On Tue, Nov 18, 2008 at 12:04 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> I'm always wondeing how it's possible that Django creators don't use
> django in ways that are written in django documentation. That leads to
> misunderstanding in expectations, and should explain why some tickets
> don't get expected resolutions.

Adrian may not use it, but I certainly do, as do plenty of other folks
I know. Which means, I guess, that it's time for you to maybe stop
making sweeping generalizations and jumping to conclusions about
tickets based on someone simply saying he does or doesn't use some
particular feature a lot.



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ANN: Django 1.0.1 released

[James Bennett]

On Sun, Nov 16, 2008 at 5:42 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> I'll defer to James to make the final call, but I'd prefer to do this
> and release 1.0.2 on Monday or Tuesday with a note that it's basically
> 1.0.1 plus the GeoDjango stuff we forgot and a couple of new bug fixes
> that got slipped in. If you look around you'll see other projects do
> the same all the time; I see no reason to be different.

That sounds like the best plan. Let's aim for Tuesday (Monday I've got
to babysit some site launches), and add a couple caveats to
contributing instructions for patch authors and committers reminding
them to run 'setup.py sdist' and check that the package includes any
new directories they've added (if not, patch should be amended to
include changes to setup.py or the manifest).


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ANN: Django 1.0.1 released

[James Bennett]

On Sat, Nov 15, 2008 at 8:42 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> 1. When I rolled the release last night, I did 'python manage.py
> sdist' to generate the package, then uploaded it to the
> djangoproject.com server.

(and obviously I meant 'setup.py sdist')



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ANN: Django 1.0.1 released

[James Bennett]

On Sat, Nov 15, 2008 at 7:48 AM, leonel <[EMAIL PROTECTED]> wrote:
> Ive downloaded the tar.gz from
> http://www.djangoproject.com/download/1.0.1/tarball/
>
> and the  md5sum does not match the md5sum from:
> http://media.djangoproject.com/pgp/Django-1.0.1-final.checksum.txt

OK, so here's what happened:

1. When I rolled the release last night, I did 'python manage.py
sdist' to generate the package, then uploaded it to the
djangoproject.com server.
2. I then made my fatal error, which was that I uploaded it to the
Cheese Shop via 'python setup.py sdist upload'.
3. And then I did the checksums and placed the signed file on djangoproject.com.

Astute readers will notice what I did not, namely that step 2
re-generated the package, resulting in a tarball whose constituent
files and directories have slightly different creation times than the
package from step 1. And as a result, the checksums of the package
generated in step 2 are different from the checksums of the package
generated in step 1 -- even though their unpacked contents are
identical -- because 'tar' stores information about creation time in
the resulting compressed file.

So I've replaced the package on djangoproject.com with the copy
generated in step 2 above, and we've verified that its contents and
its checksums match exactly.

Your friendly local release manager apologizes for the inconvenience,
and will now go find someplace to hang his head in shame.

-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ANN: Django 1.0.1 released

[James Bennett]

Tonight we've released Django 1.0.1, a bugfix release in the 1.0
series containing improvements and fixes since the 1.0 release. This
is a recommended upgrade for anyone currently running Django 1.0.

The blog entry announcing the release is here:
http://www.djangoproject.com/weblog/2008/nov/15/101/

And the release notes are here:
http://docs.djangoproject.com/en/dev/releases/1.0.1/

-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.1 feature: unify access to response.context in test client

[James Bennett]

On Sun, Nov 9, 2008 at 2:25 PM, Gábor Farkas <[EMAIL PROTECTED]> wrote:
> does this mechanism work with contexts with integer-keys?

A context variable can't really be an integer, so far as I can tell...


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.1 feature: unify access to response.context in test client

[James Bennett]

On Sat, Nov 8, 2008 at 5:34 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> However, to clarify - are you talking about a backwards incompatible
> change, or are you talking about putting a backwards compatible layer
> in place that tries to tell the difference between the two modes of
> access?

I'd prefer backwards compatibility. The way I'm envisioning it would
complicate the code a bit, but I think preserving compatibility is
worth it:

1. response.context simply stuffs away a complete copy of the final
Context used in rendering, as well as the current behavior of
maintaining a list of contexts.
2. A call to response.context.__getitem__() with a string argument
goes straight into that Context; thanks to Context's own fall-through
semantics, this will find a key (if it's there to be found) in
whatever layer of the context stack it happens to be in.
3. A call to response.context.__getitem__() with an integer argument
'n' returns Context 'n' out of the list.

This maintains backward compatibility for people doing things like
"response.context[0]['foo']", and maybe we can toss in a
DeprecationWarning and eventually get rid of that behavior, but more
importantly it makes "response.context['foo']" always work.



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[James Bennett]

On Tue, Nov 4, 2008 at 8:04 AM, mrts <[EMAIL PROTECTED]> wrote:
> Except that most of the tickets that have been brought up in this
> discussion already have patches, they just don't get the needed
> attention from core devs.

And if you feel that's the case, by all means bring them up. But there
isn't any special bit in Trac to set for it, and there's really no
great need for such a thing. So let it go, OK?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[James Bennett]

On Sun, Nov 2, 2008 at 5:54 AM, Tai Lee <[EMAIL PROTECTED]> wrote:
> There's still no comment in the ticket from a core developer or
> anybody else, though. As this is a simple bug fix, can I (as the
> reporter) mark this ready for checkin, as there is a patch with tests?

You do know that Karen has a commit bit, right? If she's got concerns
about a ticket, then I at least take that as meaning it's got problems
and isn't ready for checkin.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ANN: Django 1.0.1 beta available

[James Bennett]

See the weblog entry:

http://www.djangoproject.com/weblog/2008/oct/31/101-beta/

And the downloads page:

http://www.djangoproject.com/download/

As previously mentioned, this is mainly a preview to let people get a
feel for what's been fixed/improved in the 1.0.X line since the 1.0
release, and a reminder to anyone who's interested in helping to fix
an issue in the 1.0.X codebase that time is running short leading up
to the 1.0.1 release :)


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[James Bennett]

On Fri, Oct 31, 2008 at 5:38 AM, mrts <[EMAIL PROTECTED]> wrote:
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?

We certainly can discuss such things. To open a discussion on a
particular ticket, post a working patch with unit tests.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Absolute paths in settings.py

[James Bennett]

On Thu, Oct 30, 2008 at 3:20 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Not necessarily true.  If this code were in the settings.py from the
> project_template it would get laid down in your project when you ran
> django-admin.py startproject, which is, I think, the appropriate place
> for this relative path stuff to land.

Except for the part where it breaks/causes headaches for eggs and
zipped packages, both of which are somewhat popular in this Python
world.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Who can set "ready for checkin"?

[James Bennett]

On Tue, Oct 28, 2008 at 7:33 AM, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> Who can set "ready for checkin"? You know the answer: Ticket triagers
>
> But who are they? I have some tickets which are only small changes incl.
> unittest.

Generally speaking, it should be set by:

1. Someone who is not the reporter of the ticket or the author of the
patch (since the review should be done by someone neutral).

2. Someone who has a lot of experience reviewing code and ensuring it
meets Django's standards.



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: AnonymousUser that you can set specific permissions for

[James Bennett]

On Fri, Oct 24, 2008 at 9:40 PM, Dj Gilcrease <[EMAIL PROTECTED]> wrote:
> This patch allows the creation of a user with the username
> BuiltinDjangoAnonymousUser, and will return an instance of that User
> (if it exists) instead of the AnonymousUser class. I added checking in
> the actual user model for this special user so that it will still
> return the proper values for is_authenticated, and is_anonymous, and
> so that noone could login as the special anonymous user. I also added
> a management command to create the new Anonymous User, and a signal
> listener to ask if you want to create one when you first install the
> Auth app.
>
> http://code.djangoproject.com/ticket/9444

Seeing as you can already create a special user object in your own app
and treat it as "the" "anonymous" user, I don't see any benefit from
this, as I told you when you mentioned this in the #django-dev
channel. Plus, it's unlikely that everyone who wants a "real"
anonymous user will have exactly the same needs you do, which makes
this even more a candidate for being your own code in your own app,
rather than everyone's code in everyone's copy of Django (this is a
huge bikeshed argument waiting to happen, in other words).

So this is a big -1 from me.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ANN: Initial release timelines for Django 1.0.1 and Django 1.1

[James Bennett]

(putting on release manager hat...)

We've just put up an entry over at the official Django project blog
with details of the timelines for Django 1.0.1
and Django 1.1:

http://www.djangoproject.com/weblog/2008/oct/24/upcoming-releases/

Please bear in mind the immediate consequences of these timelines:

* Django 1.0.1 will release November 14, which means that any 1.0
bugfixes you'd like to see make it in
  will need to have patches and tests prior to that date.

* If you have a feature proposal for Django 1.1 that you haven't
already brought up on the django-developers
  list, you'll want to do so quickly; the window for feature proposals
will close on November 15.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GET requests should not alter data?

[James Bennett]

On Fri, Oct 17, 2008 at 7:10 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> To reiterate, I am proposing: "avoid, and if not possible, document" for DB
> updates in GET, are you really saying you are against this? Is your logical
> position "encourage" or "don't care/document"?

To reiterate, I am proposing: "as you're developing your application,
pay attention to what's going on in the code and tailor your solutions
accordingly."

I've already made this point but I'll lay it out once again. Here is
an exhaustive list of every view in Django which might do a DB write
on a GET request:

* All of them.

As I said before, that's because of Django's configurability; it
simply is not possible to produce a list people can trust, because if
we did we'd almost immediately get someone (probably you) right back
here saying "this view wasn't on the list but it ended up doing a
write on a GET" based on what happens when you enable/disable various
combinations of middlewares, decorators, etc. So the only truly safe
answer is that every single GET request your application receives
might do a DB write, and it's up to you -- you, Amit, since you know
your needs and we don't -- to look at how you're using Django and
configure things appropriately for your situation.

> You have to make assumptions or/and read the source to evaluate any
> solution. DB selection based on request method is the only obvious solution
> I can come up with for scaling after exhausting caching options. Are you
> ruling it out for django apps? If so what are the other solutions? If not,
> should django not be a little accomodating about it?

If you want to do DB selection based on the request method, *do it*.
Just keep in mind that there is not and never will be a list of view
functions which are labeled "these views, only these views, and no
other views will ever do a DB write on a GET". Aside from the safe
answer of "any of them can, depending on configuration", it's just not
possible to produce such a list.

It's also not worth trying to go back and rewrite everything in Django
to try to conform to the easy assumptions you'd like to make about
HTTP; there are too many useful and non-RFC-violating cases for
writing some data on a GET.

> I do not understand, when everywhere django tries so very hard in a
> pragmatic sense to decouple things where it logically makes sense, then why
> suddenly an ideological outburst of "because we are not violating any specs,
> we refuse to even think".

And this is where the histrionics take over and I sign out. If your
first response to the discussion here is to say "Django developers
refuse to even think about this", then honestly I don't have the first
clue how to go about helping you.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GET requests should not alter data?

[James Bennett]

On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Either this becomes a django standard, every code that might update database
> on GET doing something like:
>
> connection.use_master()
> try:
> ... # something that updates db
> finally:
> connection.revert()
>
> or we pray/discard this approach of scaling altogether.

I love the smell of false dilemmas in the morning.

So, you all know the old joke:

A man goes to the doctor and says, "Doctor, it hurts when I hit my
head with this hammer." So the doctor says, "Well, then, stop doing
it!"

Except in this case it's:

A developer goes to the django-dev list and says, "Django devs, my
application breaks when I assume that GET requests never do DB
writes." So the Django devs say, "Well, then, stop assuming that!"

If, however, you really want to keep hitting yourself in the head with
that hammer, your best course is to take steps on your own -- steps
which do not involve rewriting Django to suit the peculiarities of
your situation -- to ensure that nothing in your setup does a DB write
on a GET. Fortunately, if you're truly concerned about scaling you'll
already have moved away from DB-backed sessions, so that's one
potential problem gone. And the auth middleware and auth context
processor probably get tossed as well, in favor of more efficient
solutions suited to what you actually need. At which point the "DB
write on a GET" problem suddenly starts to disappear (gasp and
amazement!)...



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GET requests should not alter data?

[James Bennett]

On Thu, Oct 16, 2008 at 7:11 AM, Rajeev J Sebastian
<[EMAIL PROTECTED]> wrote:
> Without trying to read deeply between the lines, the thread seemed to
> come to a point where the one choice would be to document the cases
> where in the core (i.e., django+contrib) a GET request could cause a
> db write. I *think* thats where Amit is now. (He also mentioned this
> as the second option)

And the answer is... *any* GET request may end up causing a DB write.
That's what happens when you have things like middleware and
configurable view arguments available. So as Ned pointed out, it's up
to someone developing an application, if they have extremely strong
feelings about this, to ensure they don't configure anything which
will do it.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Custom submit buttons on admin form

[James Bennett]

This question belongs on the django-users list; in the future, please
keep in mind that this list is for discussion of actually developing
Django itself, while django-users is for discussion of how to use
Django.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: "things are ready" signal?

[James Bennett]

On Wed, Oct 1, 2008 at 4:04 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> The thing is, it's a really nice place to emit a signal if you want to
> do things "just after things are ready", but there's no signal for it.

Just after *what* is ready, precisely? After "import django" has
succeeded? After settings have been imported? After model caches have
been initialized? After a request handler has been instantiated (which
we already sort of have a signal for)?

This is one of many problems with a "Django is ready" signal --
everybody's going to have a use case which demands a different
definition of what "ready" means.

As it is, you have a signal which fires when we start processing an
HTTP request, and that's what most people should look to since Django
is, fundamentally, about cycles of HTTP request/HTTP response and so
that's the most useful mindset to have.

Failing that, there are plenty of well-established Python idioms for
"run this code once and only once the first time I'm imported", which
covers the remainder of the use cases (or really stubborn people who
want to act like Django is a desktop application instead of a web
framework).


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ANN: 1.0.X branch created; trunk is open for features

[James Bennett]

On Wed, Oct 1, 2008 at 4:07 AM, Richard Davies
<[EMAIL PROTECTED]> wrote:
> Perhaps it's now time for a '1.0.1' milestone in the ticket tracker,
> to nominate those tickets which are simple bug fixes against '1.0'?

No.

Right now any bug at all that was present in 1.0 is a candidate for fixing.

Seriously, people, cool it for a while (where by "a while" I mean "at
least a couple months") about the milestones, OK? They're only useful
when we're getting close to a release, and we're not going to be close
to a release for a while.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

django.VERSION changes committed

[James Bennett]

In revisions 9102 and 9103, I committed the changes to django.VERSION
and django.get_version() announced previously[1].

To recap:

The VERSION tuple in trunk is now (1, 1, 0, 'alpha', 0), and
get_version() in trunk now prints "1.1 pre-alpha SVN-9103".

The VERSION tuple in the 1.0.x branch is now (1, 0, 1, 'alpha', 0),
and get_version() in that branch prints "1.0.1 pre-alpha SVN-9103".

I'll write up final documentation for this a bit later on, but since
we're now doing exactly the same thing Python does with
sys.version_info, it hopefully won't be too difficult for people to
work with :)


[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/1f703b2afe6bb35c/dccef0aac01d7cf3


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Postgresql transaction aborts, despite being in autocommit mode

[James Bennett]

On Mon, Sep 22, 2008 at 9:11 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> However, Django also misuses transactions in other cases (exactly the
> ones you mention).  A transaction does not guarantee consistency of
> multiple operations, at least not in the default READ COMMITTED
> transaction mode.  Django is written assuming that the database
> transaction mode is SERIALIZED, which basically never true (someone
> would have to explicitly configure postgresql for this, and I'm
> guessing no one actually does aside from places like banks).

I didn't see anywhere that Malcolm claimed a transaction will
magically make concurrency issues go away all on its own, and I'm a
bit put off by the fact that you're here:

1. Overloading the word "integrity" with multiple meanings and
choosing which one you want to use at a given moment, and
2. Doing a lot of dancing from one issue to another (one moment you're
talking about BEGIN/COMMIT causing overhead, the next you're arguing
about transaction isolation).

Can we figure out what this thread is about, and stick to it, please?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

django.VERSION changes

[James Bennett]

A while back I proposed changing the way the ``django.VERSION`` tuple
is set up. That discussion petered out a bit, until I brought it up
with Jacob just before the 1.0 release. At the time, we felt it wasn't
possible to do it before we rolled 1.0 (this was, due to my
absent-mindedness, about ten minutes before we tagged the release, so
it's my fault this didn't happen prior to 1.0), but now I'd like to
revisit this and get it done so we have something a bit more sensible
going forward.

I'm writing this mostly as an explanation of what I plan to do; if
there aren't any well-founded objections, I'll make the necessary
changes and commit them before we create the 1.0.x branch.


The problems with the current scheme


Right now, ``django.VERSION`` is a 3-tuple whose format has been known
to vary wildly according to what we're doing at a given moment. This
has led to two major problems:

1. Because the third item in the ``VERSION`` tuple has been used for
   qualifiers like 'pre', 'beta', etc., we only have two items
   available for the actual version number. This has been known to
   cause hilarious results in the case of releases like, say, 0.96.3,
   which has to be (0, 96.3, None) (stop and think about how IEEE
   floats get printed, and you'll see the issue here).

2. That third item has never followed any really predictable format,
   except for the period of the 1.0 alpha/beta releases. This makes it
   difficult to tell what sort of Django codebase you're looking at
   without thinking about it and possibly doing some archaeology.

I don't see any good way to deal with these issues while retaining the
current 3-tuple, so...


The format of ``django.VERSION`` going forward
==

Based on a good suggestion from Steve Holden, I'm going to change
``django.VERSION`` to follow, as closely as possible, the format of
Python's own ``sys.version_info``. This means it will become a
5-tuple, whose elements are, in order: major version, minor version,
micro version, release level, serial.

The Python docs don't actually define these terms clearly, but for
Django's use I'm going to lay out what these mean and what values they
can take, inferring at times from how Python's done it (I've been
reading the history of Include/patchlevel.h to get a feel for the way
that's evolved over time... fun fun). So here goes:

"major"
The major version number of the Django release, e.g., 1 for the
1.x releases.

"minor"
The minor version number of the Django release, e.g., 0 for the
1.0.x releases, 1 for the 1.1.x release, etc.

"micro"
The micro version number of the Django release, e.g., 1 for a
release number 1.0.1, 2 for a release number 1.0.2, etc.

"release level"
A short string describing the type of release. Value will be one
of: "alpha", "beta", "rc" (for release candidates, "final".

"serial"
For situations where we do more than one release of a given level,
the incremental number of the release (e.g., 1 for "alpha 1", 3
for "beta 3", etc.).


How this will work
==

For the most part, this all works pretty simply and intuitively. Let's
consider the case of the eventual 1.1 release and, for sake of
example, assume we do two alpha releases, two beta releases, one
release candidate and then the final 1.0. During that process, the
``VERSION`` tuple would evolve as follows:

* For Django 1.1 alpha 1: (1, 1, 0, 'alpha', 1).

* For Django 1.1 alpha 2: (1, 1, 0, 'alpha', 2).

* For Django 1.1 beta 1: (1, 1, 0, 'beta', 1).

* For Django 1.1 beta 2: (1, 1, 0, 'beta', 2).

* For Django 1.1 release candidate 1: (1, 1, 0, 'rc', 1).

* For the final 1.1 release: (1, 1, 0, 'final', 0).

The only tricky bit is what to do immediately after a release; for
example, after we release 1.1, what happens to ``django.VERSION`` in
trunk as we gear up development for 1.2? Taking a cue once again from
Python, the answer is that we go from this, which is 1.1 final::

(1, 1, 0, 'final', 0)

to this, which denotes dev work in trunk for 1.2 prior to any alpha
release::

(1, 2, 0, 'alpha', 0)

In other words, a release level of "alpha" and a serial of 0 indicates
we're working toward the release specified by the rest of the tuple,
but have not yet reached the point of issuing alpha versions of it.

The ``django.get_version()`` function will be rewritten to piece this
together as follows:

* For a "real" release like, say, 1.1, the tuple (1, 1, 0, 'final', 0)
  will become the printed string "1.1 final".

* For an alpha, beta or RC, a tuple like (1, 1, 0, 'beta', 2) will
  become the printed string "1.1 beta 2". (1, 1, 0, 'rc', 1) will
  become "1.1 rc 1".

* For the one special case of checkouts from trunk prior to the
  beginning of alpha releases, a tuple like (1, 2, 0, 'alpha', 0) will
  become the printed string "1.2 pre-alpha".

In all cases, if we're on an SVN checkout we append the revision
number, 

Re: Signal Connection Decorators

[James Bennett]

On Sat, Sep 13, 2008 at 8:10 AM, zvoase <[EMAIL PROTECTED]> wrote:
> Couldn't we move this discussion to the ticket on Django's Trac?

Preferably not; it's far easier to keep track of a threaded discussion
here on the mailing list, as opposed to trying to follow it in the
ticket.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: I want a pony: Django Cheeseshop

[James Bennett]

On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote:
>  * create a central app index à la Cheeseshop

Doesn't the Cheese Shop already exist?

>  * create an automated system similar to easy_install for installing
> apps from
>   o that central repository

"easy_install django-registration" works fine for me right now. Why
not encourage people to use standard Python practices for packaging
and distribution?

>   o either globally to Python packages -- *but under django namespace!
> *
>   o or locally into a concrete project

Does anybody else actually do this? Last I checked, Pylons, TurboGears
and Zope apps didn't install or need to be installed into
framework-specific locations. Django applications are just Python
modules, and that's a *strength* from where I sit.

>  * provide app dependency handling like setuptools does for
>   o python package dependencies (identical to setuptools 'depends')
>   o Django app dependencies (e.g. 'django_app_depends')

Or just, you know, use setuptools.

>  * bundle the install tool either as a command for manage.py or a
> separate utility in bin

Or just, you know, install setuptools.

>  * create the solution so that it can be adopted by other projects by
> clearly decoupling Django-specific functionality (i.e. engage more
> brainpower and devs)

Or just use the existing packaging and distribution tools Python already has.

Have I made my point clear enough yet?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: djangoproject.com/documentation/ redirected

[James Bennett]

On Wed, Sep 10, 2008 at 2:52 AM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> Nice! Now the only thing left is to have 1.0 docs (aka:
> docs.djangoproject.com/en/1.0/)
> and make docs.djangoproject.com redirect there instead of /en/dev/ ;)) (
> #8992 )

Yes, and that's holding a bit until we get a few typo fixes and other
things in; then the 1.0 docs will be tagged and frozen.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Forms and edition of an object : non-pythonic default behaviour

[James Bennett]

On Sat, Sep 6, 2008 at 8:40 AM, Denis Frère <[EMAIL PROTECTED]> wrote:
> Why LinkForm(request.POST, instance=link) doesn't behaves like
> link.update(request.POST) ?
> Is it a will or an "omission" ?

it doesn't behave that way because it'd make no sense to behave that
way; if there's a field in a form and it gets no data, then the form
has _no data_ for that field. Not "keep the existing data", not "make
a guess about what this means", just "I have no data for this field".
And the only thing to do with no data is to blank the field.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ANNOUNCE: Django 1.0 released

[James Bennett]

The Django team is pleased to announce the release of Django 1.0 this evening:

Download: http://www.djangoproject.com/download/
Release notes: http://docs.djangoproject.com/en/dev/releases/1.0/

Have fun with it, and we'll see you in a few days for DjangoCon.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ANNOUNCE: Django 1.0 release candidate now available

[James Bennett]

We've just put up the package for the first Django 1.0 release
candidate; this package contains all of the progress made on Django
through the alpha and beta releases, and is fairly close to the final
Django 1.0 release. It's still not recommended for production use, but
we do encourage everyone to check it out and help us identify any
remaining bugs; the next step in this process is the final Django 1.0
release, and we need your help to make it as smooth as possible.

Download: http://www.djangoproject.com/download/
Release notes: http://docs.djangoproject.com/en/dev/releases/1.0/
Package checksums:
http://media.djangoproject.com/pgp/Django-1.0-rc_1.checksum.txt


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ANNOUNCE: Security updates for Django trunk, 0.96, 0.95 and 0.91

[James Bennett]

In accordance with our security policy[1], today the Django project is
issuing a set of releases to fix a security vulnerability reported to
us. This message contains a description of the vulnerability, a
description of the changes made to fix it, and pointers to the patches
for each supported version of Django.


Description of vulnerability


The Django administration application, as a convenience for users
whose sessions expire, will attempt to preserve HTTP POST data from an
incoming submission while re-authenticating the user, and will -- on
successful authentication -- allow the submission to continue without
requiring data to be re-entered.

Django developer Simon Willison has presented the Django development
team with a proof-of-concept cross-site request forgery (CSRF) which
exploits this behavior to perform unrequested deletion/modification of
data. This exploit has been tested and verified by the Django team,
and succeeds regardless of whether Django's bundled CSRF-protection
module is active.


Affected versions
=

* Django development trunk
* Django 0.96
* Django 0.95
* Django 0.91


Resolution
==

As it represents a persistent vector for CSRF attacks, this behavior
is being removed from Django; henceforth, attempted posts from users
whose sessions have expired will be discarded and the data will need
to be re-entered.

This is, then, backwards-incompatible with existing behavior and may
be considered a feature removal; however, the Django team feel that
the security risks of this feature outweigh its minor utility.

The fix for this issue was applied to the Django repository in
changeset 8877, which contains the relevant changes for each affected
version::

http://code.djangoproject.com/changeset/8877

Based on these changes, the Django team is issuing three new releases:

* Django 0.96.3: http://www.djangoproject.com/download/0.91.3/tarball/
* Django 0.95.4: http://www.djangoproject.com/download/0.95.4/tarball/
* Django 0.91.3: http://www.djangoproject.com/download/0.96.3/tarball/

The relevant patch has been applied to Django trunk as well, and so
will be included in the forthcoming Django 1.0 release candidate (to
be issued later today) and the final Django 1.0 release.

All users of affected Django versions are encouraged to upgrade
immediately.

A file containing the MD5 and SHA1 checksums of the new release
packages has been placed on the ``djangoproject.com`` server::


http://media.djangoproject.com/pgp/django-security-releases-20080901.checksums.txt

This file is PGP-signed with the Django release manager's public
key. This key has the fingerprint ``0x8C8B2AE1`` and can be obtained
from, e.g., the MIT PGP keyserver::

http://pgp.mit.edu:11371/pks/lookup?op=get=0x8C8B2AE1


Release manager's note
==

If you are currently maintaining and distributing a packaged version
of Django (e.g., for a Linux or other Unix distribution), or if you
are a hosting company which officially supports Django as an option
for customers, and you did **not** receive an advance notification of
this issue, please contact Django's release manager (James Bennett,
james at b-list dot org) as soon as possible so that you can be added
to the list of known distributors who receive such notifications.


[1]
http://www.djangoproject.com/documentation/contributing/#reporting-security-issues


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: request_started signal

[James Bennett]

On Tue, Aug 26, 2008 at 8:05 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> I have some code for processing the urlsconf so signals seems like the
> obvious tool. Apparently there is on server_started signal firing when
> configuration is complete(that would be a very nice signal to get into
> 1.0), so I try to use request_started.

I think you're running into conceptual problems with both the
"request_started" signal, and the architecture of Django itself.

The "request_started" signal simply means "an HTTP request has come
in, and processing of that request is beginning". As such, it fires on
*every* HTTP request/response cycle. So any function listening for
that signal will also execute on *every* HTTP request/response cycle.

Speaking more broadly, there's really no concept of "server started"
in Django, because Django stays fairly close to the nature of HTTP --
a stateless protocol built around request/response cycles. For some
notes on that and how to work with it, see this blog entry:

http://www.b-list.org/weblog/2007/nov/05/server-startup/


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: old docs not opening

[James Bennett]

On Tue, Aug 26, 2008 at 4:58 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Giving 404. Known issue or I should file a bug?

Due to limitations of the old docs system, there are quite a few such
links (typically due to documentation which existed in one release but
not in another). There's no need for a ticket.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: validator_list still in docs

[James Bennett]

On Mon, Aug 25, 2008 at 6:57 PM, Michael Hrivnak
<[EMAIL PROTECTED]> wrote:
> That is neither a direct nor indirect replacement for model-level validation.
> Many applications receive input from sources other than forms.  Validation at
> the form and model level are both valuable, but for different reasons.

True, but Django has *never* supported model-level validation;
validator_list has always only been a shortcut for specifying some
validation logic that shows up in automatically-generated forms.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: validator_list still in docs

[James Bennett]

On Mon, Aug 25, 2008 at 10:12 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> So there isn't a direct replacement for validator lists in 1.0.

(other than just setting up the form used for your model in the admin
to have the validation you want, which isn't terribly hard and is how
this sort of stuff should have worked long ago)


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers

[James Bennett]

On Sun, Aug 24, 2008 at 2:11 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> I don't understand this argument.  At some point fixing this general issue
> is going to have to involve a piecemeal change of each instance where
> exceptions are currently swallowed.  (Or at least each instance where the
> swallowing/transforming is causing problems.)  How can this not be
> eventually fixed in a piecemeal fashion?  It sounds like maybe you want to
> design something consistent to do instead and not do anything until that
> consistent design is developed...is that what you're getting at?

Yes. I'd rather have thought put into A) whether it's worth doing
something (after all, this is really more of a Python thing -- Python
has "except", not "except but only when the exception was in the last
stack frame") and B) what that thing is. I don't want to end up with a
patchwork of different solution because different cases ended up with
different people passionately arguing about how best to solve them.

> This one, I think, is worth fixing sooner rather than later.  I don't even
> know if the others are worth worrying about, since I can't say I recall any
> people on the users list running into trouble with other cases of this
> exception-swallowing behavior. This one I definitely have seen causing
> problems, triggered by newforms-admin causing a lot more code to get
> executed when urls.py is loaded.

Then we need a *general* solution, that can and must be applied to all
the various places where we do stuff like this (template tag loading
also has the potential to "swallow" exceptions, as do other areas of
URL resolution, as does middleware loading, as do... well, lots of
stuff in Django). But again I think this comes down to prioritization;
it's really less of a bug in Django than it is an attempt to help
people rescue their own broken code (since the root of the issue is
that somebody will have broken code somewhere and the "real" exception
is masked when something else incidentally bumps against it), and we
still have plenty of genuine bugs where things in Django don't work
properly. So I still think this is a post-1.0 thing.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers

[James Bennett]

On Sun, Aug 24, 2008 at 12:53 AM, Jonas Pfeil <[EMAIL PROTECTED]> wrote:
> P.S.: I should have brought this up here earlier instead of causing a
> somewhat lengthy discussion on IRC, sorry for that. I hope James
> doesn't hate me after this ;)

I stand by what I said in the dev channel yesterday: this is one
instance of a more general issue (there are lots of places where --
because we need to import or check something -- we can end up
"swallowing" exceptions in this fashion), one which will require time
and thought to deal with, and which should not be tackled piecemeal.
Given that, and the fact that there's a lot of much more critical work
to do, I think the appropriate time to do that is **after** Django
1.0. This is simple prioritization (and, as others have pointed out to
you, the fact that there hasn't been a big flood of bug
reports/support problems related to this probably indicates it's not
as critical as you're making it out to be).



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Please force ticket 8367 to inclusion.

[James Bennett]

On Fri, Aug 22, 2008 at 4:08 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> 1) You have less than 2 weeks left and still 188 tickets marked with
> 1.0 tag

Correction: we have 153 tickets open with the 1.0 milestone. Not bad
for eight hours' work, IMHO, and we've still got a couple sprints left
to go.



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Please force ticket 8367 to inclusion.

[James Bennett]

On Fri, Aug 22, 2008 at 4:08 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> Really?

Dude. Don't be that guy. OK?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Use admin.autodiscover() by default?

[James Bennett]

As of the newforms-admin merge, the IRC channel is seeing a sudden
rush of folks who try the tutorial and complain because the admin
doesn't work. And they're right, because as written the tutorial sets
up the admin in such a way that it's never aware of any models being
registered -- including the contrib models that already have admin
classes.

Adding 'admin.autodiscover()' to the project's root URLConf fixes
this; normally I'd just check in a quick change to the tutorial to
indicate that this should happen, but it feels to me like the right
thing to do here is instead tweak the project template so that line is
in the default URLConf (but commented out like the rest of the admin
stuff), at which point the tutorial can simply stay as-is.

Thoughts?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: DjangoCon

[James Bennett]

On Fri, Jul 18, 2008 at 1:59 PM, Frijole <[EMAIL PROTECTED]> wrote:
> Does anyone know how to get tickets for the DjangoCon, I though they
> were releasing them today?

When the time comes there will be a large and loud public announcement
that you will not be able to miss.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Inquiry

[James Bennett]

This list is not for general usage questions; rather, it is for
discussion of the development of Django itself. Please keep usage
discussion on django-users.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: MS SQL pyodbc backend update to trunk

[James Bennett]

On Tue, Jul 8, 2008 at 8:26 AM, vcc <[EMAIL PROTECTED]> wrote:
> I just updated this backend, it's look like everything work fine for me. I 
> have some projects working with this backend, I'll keep improve it. Please 
> check the patch in the attachments.

As Russ, and the many previous threads have pointed out: the thing to
do right now is:

1. Put the code up somewhere public -- somewhere that is *not*
djangoproject.com's ticket tracker or a mailing-list thread -- and
advertise it to people.
2. Respond to bug reports and suggestions from people who use the code.
3. Repeat.

Once there's an established history of good code and willingness to
maintain it, then -- and only then -- should it be considered for
inclusion in Django itself. Remember: database backends don't have to
be distributed as part of Django, and can live anywhere on the Python
path, so it's easy to do this.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: #7666: Default managers should not restrict access to single related objects

[James Bennett]

On Mon, Jul 7, 2008 at 8:29 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Currently, ReverseSingleRelatedObjectDescriptor uses _default_manager,
> which is the problem (line 239 in django/db/models/related/fields.py).
> One clean solution would be to give each model a _pristine_manager
> attribute, which would be *guaranteed* to be a simple Manager()
> instance -- i.e., not a custom one. Then we could use
> _pristine_manager here, in this case.

Why bother with the overhead of creating and maintaining an entire
Manager instance, when what's really wanted is a pristine QuerySet?
That can be obtained by the simple expedient of

qs = QuerySet(whatever_model_this_should_be)

and doesn't come with any baggage.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Community representation, or, #django user "Magus-" needs to go far away

[James Bennett]

On Wed, Jun 25, 2008 at 4:21 PM, Tom Tobin <[EMAIL PROTECTED]> wrote:
> Specifically, I'd like you to note interactions with user "Magus-"
> (with trailing dash).

Four points:

1. His name is Collin.
2. He's one of the channel ops.
3. As someone who hangs out in the channel pretty much 24/7 I can
vouch for him being helpful. An instructive example is to run "grep
thanks #django.log | grep -c Magus", and then compare to other
usernames.
4. Tom, you worked at the next desk over from me for how long, and you
think Collin is nasty? ;)


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[James Bennett]

On Mon, Jun 16, 2008 at 1:48 PM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> You could as stick them in a single manager as well (and wouldn't
> have to remember which method is available via which manager).
> My point is that one manager per model would be enough to do anything
> you can do with multiple managers (and if you want modified querysets
> you get a little extra flexibility if you just subclass QuerySet).

Simply "being enough" won't cut it though, because you'd end up having
to do some very ugly things and crowding up your single manager with a
lot of stuff that'd make more sense logically broken out.

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 introducing a whole chain of manager
classes inheriting from each other to bring in the right sets of
methods.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[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 managers and also add other supporting methods (which I
also often do).


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[James Bennett]

On Mon, Jun 16, 2008 at 10:22 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Has anyone else noticed that development progress seems to have
> exploded since this thread was created? In the weeks/months after the
> qs-rf merge, several days would go by when there wasn't a single
> change committed, but suddenly there have been like 10 per day in the
> last few days.

Like most development processes, it runs in cycles. After qsrf there
was a lull while people were shaking it out and reporting bugs, but
before that there was a whole lot more activity. And now, once again,
there's activity.

Such is the nature of what we do.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[James Bennett]

On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> Is there a rationale for multiple managers per model?

Yes, and I at least use them all the time. For example, I'll often
have one manager that does no special filtering, and another that only
returns things with a "live" or "published" status. Once you start
working with them, you find lots of uses for multiple-manager tricks
like this.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[James Bennett]

On Thu, Jun 12, 2008 at 11:10 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> And this is great of course.  But having to develop externally away
> from the many eyes of the Django community is sort of an impairment.
> It's a lot easier to get traction on a project that is in the Django
> repo somewhere than to get it for a project on Google Code.

If somebody wants a branch in which to do the work, I wouldn't have
any problem setting it up; that's how we did it for Oracle, and merged
it back to trunk when it was ready.

> No one says the Django team must exhaustively maintain every bit of
> code in the repository.  Surely it is quite easy to not include MS SQL
> in the default list of backends and/or mention in the documentation
> that MS SQL support is unsupported and experimental until such time as
> it improves.  Plenty of projects have bits of code that are crufty and
> get labeled as such, and don't burn cycles maintaining it themselves.

Having dead, non-functional code in Django is something I'd like to
avoid. And there's a world of difference between "here's an
experimental feature" and "here's something that was abandoned by the
person who developed it, and we don't know much about it".



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[James Bennett]

On Wed, Jun 11, 2008 at 11:17 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I have to ask why must Django prevent work in this regard?

To be perfectly fair, it's not really "prevented". Django supports the
use of database backends not defined in Django itself, so third-party
development of backends is unimpaired. And for the one most people
mention wanting -- MS SQL -- I think that's a good idea; that backend
has a history of people stepping up, putting in a burst of work and
then fading away, leaving the code dead and the Django dev team
responsible for maintaining it as long as it's in Django's codebase.
What really needs to happen there is much the same as what happened
with Oracle: some people who are really clamoring for it need to
organize and start pooling their efforts to develop something that can
comfortably become a part of Django (and now that external backends
are supported and qs-rf made the underlying mechanics of custom Query
classes much simpler, anyone wanting to do a new backend probably
faces a much easier time of it than the Oracle folks did).

Post-1.0, any externally-maintained backend that has a good track
record of support and a commitment from a developer to maintain it
into the future can easily be considered for integration, but until
then such projects should stay external.

> I would even consider dropping all but security patches to 0.96.  That
> is practically the limit of support anyway it seems, and is not likely
> to cause much work.  Those of us on 0.96 don't expect you to support
> our private branches anyway, and maintaining that mess ourselves is a
> huge incentive to bite the bullet and upgrade.  You also might
> consider letting whoever can spare the time apply patches to 0.96 and
> do point releases for those people who will stay there forever (and
> I'm sure there will be plenty).  You lose nothing as long as there are
> volunteers willing to do that work.

Personally, so long as folks are OK with the fact that it'll only ever
get security fixes I'd be happy with setting a time-based official
support window for 0.96, after which a community effort can pick it up
if desired. At that point I'd imagine it wouldn't be too hard to set
up one or two folks with commit access to the 0.96-bugfixes branch for
that purpose (and we've had good experience with clients who are on
legacy 0.91 Django installs and quite happily just run off a
0.91-bugfixes checkout, which makes pushing security updates to them
insanely easy).



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

On Mon, Jun 9, 2008 at 3:57 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
> As mentioned in my previous post, if it's indeed three months, I agree,
> but if it's only "hopefully" three months, then do we want to end up six
> or nine months out still waiting for 1.0 to land "in a couple months?"

Well, nfa is doing pretty well; as others have mentioned, it's at or
near parity (functionality-wise) with the current admin, and
incidentally has already fixed quite a lot of bugs which hamper the
current admin. So even a pessimistic estimate would have to concede
that it's quite close, and it's the last huge change to land before
1.0, which in turn means that by the time we'd get back to normal
development after doing QA and everything for an interim release, we
could instead be doing 1.0 alphas or betas.

(and note that I'm not relying on any secret insider information in
saying this, because there isn't any; I just pay attention to what's
going on publicly)

> Maybe that policy should be looked at?  Obviously there are limited
> resources for maintaining security patches, but it would be easier to
> organize a grassroots effort for the community to support backporting
> security patches to a hypothetically-obsolete older release or two, and
> sharing it with the community than it would be to ask everyone running
> an older trunk to create backport their own patches.

I personally wouldn't have any problem with keeping a branch or two
alive and giving a couple trusted community folks commit bits on it if
they want to maintain support past the official period for a release.
But like all things, that would take time to get going, and since I've
already pointed out that on a "release when a big thing finishes"
schedule we'd probably be kicking out releases far too quickly for any
such effort to keep up (having to hunt up new community maintainers
every couple months probably wouldn't have worked).

> Agreed, except that there are fewer targets.  My point was that frequent
> releases are not *causing* this problem.  The problem already exists.

Not really, no; there'd be just as many targets, only they'd have
different names ("Django 0.98" instead of "QSRF merge", for example).

> Again, I'll buy that argument if we can really push 1.0 in the short
> term.  My concern is that this has been one of the arguments for
> avoiding 0.97 before.  Of course the closer we get to release, the truer
> it gets, but also the more evident it becomes that it wasn't *really*
> true before (when we were still 12 months away from 1.0, for example).

Keep in mind that, twelve months ago, 0.96 wasn't even six months old.

At any rate, Jacob's already mentioned he'll be posting quite a lot of
information quite soon; it'll largely just be collating a lot of
already-available information into one document and slapping some
projected dates on it, but perhaps that'll help a bit.



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django development staleness

[James Bennett]

On Tue, Jun 10, 2008 at 5:46 PM, Edgars Jēkabsons
<[EMAIL PROTECTED]> wrote:
> I'd like to remind everyone involved that Django development really
> seems to stale when looking at active tickets.
>
> There are 1116 active tickets right now, 341 of them haven't even been
> reviewed and 201 of the remaining 775 tickets are waiting on a design
> decision from the core developers or community. I can't even know if
> any of those 542 tickets is getting fixed at all or not.

Bear in mind, though, that "unreviewed" does not actually mean
"no-one's ever looked at this". For example:

* Tickets whose problems could not be reproduced by a triager
typically remain "unreviewed" until further information comes from the
reporter (or until they've sat for a while with no further input, at
which point they typically get closed out when someone does a sweep
through the ticket system).

* Tickets which may be duplicates but have not yet been confirmed as
duplicates typically remain at "unreviewed" until it can be determined
whether they should close as dupes.

Also, the oldest unreviewed ticket in Trac is about five months old,
and the vast majority are much more recent; large changes like qsrf
inevitably involve large numbers of new tickets (both purported bugs
as well as feature requests based on new functionality), and Django's
user base has been expanding dramatically. This means the rate of new
tickets goes through sudden spikes after which it takes some time to
catch up, which is where we are right now. If you'd like to help with
triaging and you feel you're familiar enough both with Django and with
the existing base of tickets (one of the toughest things, in my
experience, is keeping track of a small number of major issues which
end up spawning large numbers of duplicates or related tickets), feel
free to lend a hand, but keep in mind that not everything marked
"unreviewed" has gone entirely without oversight ;)


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

(incidentally, for anyone who's joining in and wants to genuinely add
to the discussion: starting your reply by calling one of the
developers a douchebag causes me, at least, to stop listening and
simply assume you're a troll. The more you know...)


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

On Tue, Jun 10, 2008 at 12:24 PM, testguy56 <[EMAIL PROTECTED]> wrote:
> Wow, starting a reply like that makes you sound like an elitist douche
> bag.

I love the smell of troll in the morning, don't you?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Understanding HTML, XML and XHTML

[James Bennett]

On Tue, Jun 10, 2008 at 10:38 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> I am curious if anyone thinks having support for outputting html4
> compliant markup in Django is a good thing?  And if so, what can I do
> to help make that become a reality?

I for one would appreciate it, because I'm abotu to switch back to
HTML4 Strict and I'm having to write some support code to handle that.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

On Mon, Jun 9, 2008 at 2:47 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
> I agree with the sentiment of this, but we've passed the point where
> it's a useful argument.

I'll concede that if you'll concede that we've also passed the point
where issuing interim pre-1.0 releases offers any real gain over
finishing 1.0 ;)

> * A year and a half (with still a major branch to be committed before
> 1.0 lands and no release date in sight) is *not* too frequently to have
> a couple incompatible updates.  The longer the stretch before 1.0, the
> less true this argument becomes.

People have been saying that they'd like to see, for example, a
six-month release schedule. That's about the shortest that's
practicable in terms of expecting people to go through the upgrade
process. But since this time last year, I count the equivalent of four
major breaking (in the sense of either "loses backwards compatibility,
or otherwise requires significant effort to port across) changes and a
fifth is on the way. Assuming, as I hope it will, the newforms-admin
is done within the next couple of months, that's equivalent to a
"release cycle" of 2-3 months with a non-trivial upgrade process along
the way.

So following several folks' suggestion of releasing every time a big
breaker lands would have pushed us through 0.97, 0.98, 0.99 and
probably two more *pre-1.0* non-trivial upgrade processes in just over
a year. I don't see that as a smart thing to do.

> * Further nobody is going to be forced to update just because it has a
> number on it any more than they're forced to keep up with trunk.

In a "release early, release often" scheme, yes they will, because --
as I've pointed out already -- such a scheme would push at least two
releases over the support cliff. Plus, third-party apps would likely
track the latest stable release on a faster schedule, which means that
there would be no alleviation of the "I'm on Django  and the app I
want to use is on Django " problem people have complained about.

> In
> fact, there will be less pressure to update, because security patches
> will be backported.

Nope. At the very least, 0.96 and a hypothetical 0.97 would lose
support before 1.0, and potentially (depending on how aggressive a
hypothetical release schedule you want) a hypothetical 0.98 would lose
support too. And no support == time to upgrade.

> * The only exception is, as you mention people who are relying on third
> party apps, but this doesn't hold water either, because many third party
> apps are actually based on trunk (or worse! branches of trunk).

My point about third-party apps is simply to note that more frequent
releases would not alleviate versioning issues with third-party apps.
"My codebase and apps are written for pre-autoescape trunk but this
third-party app I need is written for post-qsrf trunk" is
fundamentally no different from "my codebase and apps are written for
Django 0.97, but this third-party app I need is written for Django
0.99". In other words, more frequent releases do not solve this
problem (unless of course, we're talking about 1.x releases where
compatibility within the line would be maintained).

> I do see from Adrian's post above that there is some rethinking of the
> release schedule going on now.

If so, I missed it; I don't see anything from Adrian in this thread.

>  As you said, there's a trade-off to be
> had with releasing now and holding off to 1.0, but as the interval
> stretches out, the balance shifts toward the need to release, and maybe
> we've reached the threshold where the problems with the current release
> plan are starting to outweigh the benefits.

At this point, I don't see any possible gain to be had. With one
large-scale item left to land on the 1.0 checklist (everything else is
smaller and/or more distributed in terms of workload and/or doesn't
involve breaking changes) and with development ramping up on that item
(newforms-admin) to get it done, I don't see how an interim release
would be anything other than a slap in users' faces: "OK, you begged
for a release before 1.0, so here it is, so close to the time of 1.0
that it's practically pointless."



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

On Mon, Jun 9, 2008 at 11:54 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I believe it's one official release back.  James will know better.

For security we patch trunk, of course, as well as current stable
release plus the two previous releases. This means we currently
provide security updates for trunk, 0.96, 0.95 and 0.91.

As an aside, we have a number of clients running on checkouts of the
SVN "bugfixes" branches for their versions of Django, which makes
management of that sort of thing quite easy -- security updates are
just an 'svn up' away for them, and for stuff we host it actually
reduces down to a single Capistrano task to deploy that :)


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

On Mon, Jun 9, 2008 at 1:50 AM, Ashish <[EMAIL PROTECTED]> wrote:
> In short all I am looking for is commitment to " freezing the scope,
> publishing a plan  and hitting it for 1.0 " That will greatly increase
> the community's trust.

Er. You linked to a well-known thread in which the plan for 1.0 was
published; do you mean to say that this is evidence that there is no
publicly-available plan for 1.0 (which is self-contradictory), or have
I disastrously missed something?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

On Sun, Jun 8, 2008 at 9:51 PM, Ashish <[EMAIL PROTECTED]> wrote:
>  my proposal is

You do know that a list of what has to happen before 1.0, and a page
listing the status of each item, has been available for quite some
time, right? I

> Lack of visibility on what is going on with 1.0 and over an year delay
> on 1.0 (perceived) is causing people to get frustated and we see these
> discussions threads every few weeks now.

I'm really, honestly baffled by this statement. Django development
happens in the open. Always has. Anyone anywhere at any time can look
at what's going on, see what the dev team is talking about, etc. And
it's not like the places where the discussion happen are a super top
secret; a link to the dev list is publicly advertised on
djangoproject.com, as is the bug tracker and wiki.

So please, in all honesty, tell me why you think Django's development
process isn't "visible" enough for people who are concerned and want
to get information. If there's a genuine issue I'm missing here, I'd
love to correct it.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

0.96 tarball

[James Bennett]

Just a quick procedural thing:

The 0.96.2 tarball created for the recent security fix was generated
from the 0.96 setup.py script, which gets you the Django source tree
but misses things like the documentation files that we distribute with
Django. This has caused a couple of issues with downstream
distribution, since maintainers had to go and fetch those files
manually for packaging.

The setup.py in trunk (verified just a moment ago) gets things right
and includes, as far as I can tell, everything that ought to be
included, but I'm wary of trying to backport stuff from it into a
release branch that's really only supposed to get security fixes.

As an alternative, I can generate a complete tarball pretty easily
from an 'svn export' of the 0.96-bugfixes branch, and that seems to me
to be the best thing to do now (which would simply replace the 0.96.2
tarball with one that, while identical code-wise, contains the
additional files) and for the future (e.g., if we have another
security fix to push out during the support period for the 0.96 line.

Anyone have strong objections to doing this?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

And for the record, I do think that *post-1.0* we should do more
frequent releases, because it'll be quite a bit simpler to do at that
point. I just think that right now it's not really worth the trouble;
the same people who currently complain that they have to use a
packaged release but want a post-0.96 feature would just turn around
and complain that they need stability and wish we'd stop pushing
releases with big changes in them.

There's really nothing we can do that'll make those folks happy, so
I'd vote for continuing on the path toward 1.0.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: About an UPDATE.txt file

[James Bennett]

On Sat, Jun 7, 2008 at 7:46 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> Right now Backwards Incompatible changes are documented in a wiki page,
> with some disadvantages:

And in the release notes when a new release happens.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part -- make
> newforms-admin an "optional" part. If it's done, awesome; if not,
> include it in the next release. The current admin has some bugs, yes,
> but it's usable enough. As long as we advertised that it's on the way
> out we shouldn't have too much trouble.

vote(-(sys.maxint))

Newforms-admin needs to get done. Putting it off from the first couple
betas or RCs will just increase the temptation to put it off further,
so what we should do is identify anything that's slowing it down and
work to resolve that. If that means organizing a sprint or two on it
and then doing a trunk merge to get more eyeballs on the code, then
let's do that instead.



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[James Bennett]

On Sat, Jun 7, 2008 at 11:48 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> I think the most often reason why I've heard is that it takes time to
> create a release, post it, push security patches to it, etc.  Which
> makes sense, but at the same time there are a lot of valid points in
> the blog post.

It does indeed take time to roll a release. More importantly, issuing
a release means that we -- the Django team -- make a promise of
support for it, which is the important part and the part that
ultimately ends up eating much more time. It's also the part people
tend to forget about when they start asking why we don't just roll a
new release whenever they think we should.

We've stated in the past that the next official supported release of
Django will be 1.0. I think that's a good idea, and I personally think
we ought to stick to it; the things we've outlined for 1.0 are
significant enough that incrementally pushing releases before that
will do more harm (in terms of presenting a constantly-moving target
to the people who believe releases mean long-term stability) than
good.

And, really, that's the catch-22: if we released much more frequently
than we do now we'd likely get just as many complaints, only from a
different group of folks. As has been stated before, having people
upgrade from 0.96 to a 0.97 release based on current trunk would
subject those people to a fair number of required changes; having them
upgrade at each step along the way to 1.0 would impose that on them
repeatedly. That's not something I'd be comfortable with; I'd rather
try to minimize the number of releases which involve significant
end-user changes. The ideal is to just do it once, and then we're at
1.0 with a compatibility guarantee toward the future.

So personally, I think discussion of more aggressive release schedules
should happen once we're *at* 1.0, with a hard promise of stability.
Once we're there, more frequent releases (say, to add new features or
to expand django.contrib) make a whole lot more sense to me. But right
now as we're working through the changes necessary to reach 1.0, I
don't see much good in diverting that goal to produce interim packages
that will, in turn, increase our support workload.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: flatpages and 404

[James Bennett]

Sigh.

In [7555] I added a warning to the flatpages docs to hopefully silence
this issue once and for all. Note that I did this not because I feel
it's necessary or appropriate, but because I'm just getting really,
really, really tired of people complaining about this. Can we please
let this one go now, finally? Please?



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Rethinking silent failures in templates

[James Bennett]

On Wed, May 14, 2008 at 8:58 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> Silent errors are bad. If we were to remove them, how much of a
> negative impact would it have on the existing user base?

The impression I get is that a lot of people rely on silent *variable*
failure, but very few rely on silent *tag* failure. In fact, most
real-world custom template tags I've seen are wired up to raise errors
quite loudly, and the few times I've tried to write tags which fail
silently it's been a laborious process that results in much more
brittle code.

And, really, variables are the big thing that the current behavior
helps: it's really really nice to be able to do boolean tests on
things that might not exist, and trust that the test evaluates False
instead of, say, raising a KeyError because you asked about something
that isn't in the context dictionary.

So, personally, I'd vote for keeping the current behavior with respect
to variables, and rewriting any built-in tags to raise exceptions when
you do something wrong.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ANNOUNCE: Security bugfix releases

[James Bennett]

In accordance with our security policy[1], a set of releases is being
issued tonight to fix a security vulnerability reported to the Django
project. This message contains a description of the vulnerability, a
description of the changes made to fix it, pointers to the the
relevant patches for each supported version of Django and pointers to
the resulting releases. A copy of this information will also be posted
on the official Django weblog, and the relevant areas of the Django
website are being updated to reflect the new releases.

Description of vulnerability:

The Django administration application will, when accessed by a user
who is not sufficiently authenticated, display a login form and ask
the user to provide the necessary credentials before displaying the
requested page. This form will be submitted to the URL the user
attempted to access, by supplying the current request path as the
value of the form's "action" attribute.

The value of the request path was not being escaped, creating an
opportunity for a cross-site scripting (XSS) attack by leading a user
to a URL which contained URL-encoded HTML and/or JavaScript in the
request path.


Affected versions:

* Django development trunk
* Django 0.96
* Django 0.95
* Django 0.91


Resolution:

The login form has been changed to escape the request path before use
as the form's submission action.

The relevant changesets for affected versions of Django are:

* Django development trunk: Changeset 7521
(http://code.djangoproject.com/changeset/7521)
* Django 0.96: Changeset 7527 (http://code.djangoproject.com/changeset/7527)
* Django 0.95: Changeset 7528 (http://code.djangoproject.com/changeset/7528)
* Django 0.91: Changeset 7529 (http://code.djangoproject.com/changeset/7529)

The following releases have been issued based on the above changesets:

* Django 0.96.2:
http://media.djangoproject.com/releases/0.96/Django-0.96.2.tar.gz
* Django 0.95.3:
http://media.djangoproject.com/releases/0.95/Django-0.95.3.tar.gz
* Django 0.91.2:
http://media.djangoproject.com/releases/0.91/Django-0.91.2.tar.gz

All users of affected versions of Django are strongly encouraged to
apply the relevant patch or upgrade to the relevant patched release as
soon as possible.


Release manager's note:

If you maintain a third-party Django package and you did *not* receive
the announcement of these release from me earlier tonight, please
email me directly as soon as possible.

Also, please note that potential security vulnerabilities should be
reported directly to the Django project, at
[EMAIL PROTECTED], as outlined in our security policy[1].
Following this procedure helps us to maintain high standards of
response and disclosure, and makes the process of investigating and
resolving security issues much easier for everyone involved.


[1] 
http://www.djangoproject.com/documentation/contributing/#reporting-security-issues


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Callable context variables do not get called during resolution.

[James Bennett]

On Fri, May 9, 2008 at 9:27 PM, Peter Rowell <[EMAIL PROTECTED]> wrote:
> OK, I'll bite. I kind of doubt he rewrote the templating system in the
> ORM, so you must be inferring that multiple database support was part
> of the qs-refactoring. I just checked out trunk and I'll admit I'm
> working with a one-beer-handicap at the moment, but nothing jumped out
> and said "MULTIPLE DATABASE SUPPORT!!!"

Once again, there's no high-level support, but qsrf added some
infrastructure which will make an eventual high-level implementation
easier, and which makes writing a manual implementation right now a
bit less tedious. Look at the constructor of
django.db.models.sql.query.Query for the "connection" argument.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Callable context variables do not get called during resolution.

[James Bennett]

On Fri, May 9, 2008 at 9:01 PM, Peter Rowell <[EMAIL PROTECTED]> wrote:
> Now that Malcolm has subclassable models working, my number one
> complaint is the templating system. Number two is single DB, but I can
> work around that more easily.

You probably should take a look at the ORM code.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: /admin Cross-Site Scripting (XSS) issue!

[James Bennett]

On Wed, May 7, 2008 at 2:32 PM, Jan Rademaker <[EMAIL PROTECTED]> wrote:
>
>  It does work, make sure you're not logged in.
>
>  $ lynx -source -dump 
> http://localhost:8000/admin/%22%3E%3Cscript%3Ealert%283939%29%3C/script%3E/
>  | grep alert
>  alert(3939)/" method="post"
>  id="login-form">

OK, so what's happening is that the admin is assuming that if you're
not logged in, the current URL should be used as the URL to submit
login information to. Which means it drops the request path into the
form's "action" attribute and, since there are valid things for URLs
that'd be incorrectly escaped if we let the autoescaper get at them,
it's marked "safe" and so can contain HTML.

Since there is a genuine XSS threat here, it needs to be fixed in the
current admin and not simply punted to nfa. Optimal solution is to
just point the thing at a genuinely consistent login URL and redirect
back to where they were trying to go once the user's authenticated
(preferably keeping the URL firmly in the address bar the whole time,
like we already do with the "next" param for logging in everywhere
else).


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: API question for model saving

[James Bennett]

On Mon, May 5, 2008 at 1:00 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> This may not directly solve the problems that are being referred to, but it
> was a bug fix none the less, and I believe it is relative to the issue at
> hand.

I never said it wasn't a *possible* solution, I just said it wasn't a
*good* solution.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: API question for model saving

[James Bennett]

OK, so, we appear to have two camps:

1. People who think this should be handled by introducing one or more
   new methods to allow easy differentiation of the cases.

2. People who think this should be handled by adding new keyword
   arguments to save().

And, techncially, a third camp consisting of David, who thinks an
attribute on the model ought to control the behavior. But I'm going to
toss that out immediately because I don't want this to turn into
action-at-a-distance. Whatever mechanism we decide on should be
explicit and should be clearly visible from the point in the code
where you actually write data to the DB, which means one of the above
two mechanisms or a combination thereof.

Now, a couple of design goals for this API:

* The common case -- where you simply don't care and just want to save
  with no fuss -- needs to stay easy and so, in all likelihood, needs
  to be the default.

* The amount of new API to be introduced should be minimized, in order
  to maintain a simple interface.

* If there's anything we already have that can be leveraged to support
  this, we should do so.

So, the big trick is that people are approaching this from the
perspective of three-valued logic: either you force an INSERT or you
force an UPDATE or you don't care. To support this, we've had
proposals for two new methods (bringing the options up to three to
cover them all), two new keyword arguments (to cover the two
additional cases) or one new keyword argument with three possible
values (to cover all cases).

I think all of these are barking up the wrong tree, because this can
actually be accomplished by two minor tweaks.

The first is to look at the update() method that already exists on every
QuerySet and every default manager: this method *already* does one of
the things we want, namely force an UPDATE query to run. So, without
any changes whatsoever, a proposed API of, say::

e = Employee(drone_id=1234567)
e.salary = 10
e.save(force_update=True)

Can become::

Employee.objects.filter(drone_id=1234567).update(salary=10)

Now, the complaint people will have with this is that you can
accidentally leave off the filtering, or do it wrong, and make
everybody in the company a billionaire. Personally I think this is one
of those bits of SQL that people need to learn the hard way (and some
DBs have modes that won't let you run UPDATE or DELETE without a WHERE
clause), but as a concession I could see adding a tiny bit of new
behavior.

Currently, update() doesn't return anything; changing it to return the
number of rows affected would be a help. For bonus API-complication
points, it could sprout a kwarg that lets you assert a certain number
of affected rows, and then raise an exception and roll back the
transaction if that assertion fails.

That deals with one of the three cases (force UPDATE), which means
that save() itself only needs to deal with two cases: "force INSERT"
and "I don't care".

>From there, save() simply sprouts a "force_insert" kwarg, defaulting
to False, and you handle that when you care about it.

Also, the bikeshed should be blue.



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: EmptyQuerySet

[James Bennett]

On Tue, Apr 29, 2008 at 5:00 PM, Luke Plant <[EMAIL PROTECTED]> wrote:
>  I've created a patch, which special cases EmptyQuerySet in a couple of
>  places, which seems to be the simplest way of doing it.  I can commit
>  it myself, but I wanted to pass it by you first since I'm unfamiliar
>  with qs-rf, and in case you disagree about fixing this -- patch
>  attached.

Discussion of a similar issue is in ticket #7113:

http://code.djangoproject.com/ticket/7113

I'd be inclined to agree with Malcolm that this should be fixed on
QuerySet itself, rather than requiring every subclass or QuerySet-like
class to special-case the logic.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: QSRF Related

[James Bennett]

On Tue, Apr 29, 2008 at 3:54 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>  If I update from python 2.4 to 2.5 I can expect some trouble unless I know 
> what has changed. If I update trunk, which is what is considered the only 
> real version to use right now, I may encounter problems that I wasn't 
> expecting, especially since the closest thing to a changelog is svn log.

I still don't see how more releases would help you -- if you're
relying on an API that wasn't public/documented before and wasn't
public/documented after the change, what exactly does a release do for
you that the list of backwards-incompatible changes doesn't already
do?



-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: QSRF Related

[James Bennett]

On Tue, Apr 29, 2008 at 3:38 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>  Yes im aware of the backwards incompatibility page but that mostly covers 
> the public api. A lot of time for our uses we have to go beyond just using 
> the public api. This is another situation where having more releases could 
> help :)

How would releasing more often make it easier to find out what's
changed in an undocumented API?


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: QSRF Related

[James Bennett]

On Tue, Apr 29, 2008 at 12:55 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>  2) I thought the very smple example explained it. Selecting on a
>  related field which already is present (so naming the select field
>  something that exists) would cause it to disappear, no errors, no
>  warnings.

This is why a good bug report has sections titled "what I expected to
happen" and "what actually happened"; none of that can be inferred
from the one-liner you posted.

>  3) This is a pretty major change to Django, and there's nothing on the
>  page that says "HEY WE JUST CHANGED THE ENTIRE DBAPI ALL YOUR HACKS
>  WILL BREAK" (I didn't even know QSRF was released until someone
>  pointed it out to me)

Er, no, the public, documented API didn't really change much at all.
And people who were doing work deep under the hood presumably were
smart enough to be paying attention and so don't need a big screaming
warning that queryset-refactor was taking place.


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: QSRF Related

[James Bennett]

On Tue, Apr 29, 2008 at 11:35 AM, David Cramer <[EMAIL PROTECTED]> wrote:
>  2) Is the issue still present if you do
>  extra(select={'myforeignkeyname': 1}) ?

Is the issue still present where you didn't explain what you were asking about?

>  3) Most importantly. Is there a shiny new page in the documentation
>  that I don't see tagged somewhere that explains the new functionality?
>  If so, can we tag it as "Updated" or whatever is appropriate :)

Documentation update worked like any other documentation update from
any other commit of any other feature(s).


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Model Inheritance in qsrf and User?

[James Bennett]

On Fri, Apr 25, 2008 at 10:23 AM, AmanKow <[EMAIL PROTECTED]> wrote:
>  Could you elaborate or point to elaboration on why non-abstract
>  inheritance is a bad fit for extending user?

http://www.b-list.org/weblog/2007/feb/20/about-model-subclassing/


-- 
"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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---