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
On Sat, Aug 23, 2008 at 2:43 PM, mrts <[EMAIL PROTECTED]> wrote:
> http://code.djangoproject.com/ticket/7524 is tagged as post-1.0.
> http://code.djangoproject.com/ticket/8221 was closed as duplicate of
> #7524, which it is not.
In triaging, I'm trying to take the position that all of the various
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 o
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 differen
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
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
>
As part of the run up to the final Django 1.0 release (scheduled for
next week!), tonight we've pushed out Django 1.0 beta 2, including the
final new features for 1.0 (mainly a refactoring of
django.contrib.comments). As a beta release, we of course don't
recommend it for production use, but if yo
istribution), 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 ad
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 t
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 tec
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
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
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-registrat
On Fri, Sep 12, 2008 at 10:00 AM, Jeff Anderson
<[EMAIL PROTECTED]> wrote:
> I actually was quite amused by your reaction.
>
> You are right though, this community does seem to come through with a
> tone more mature than your average mailing list. :)
You damn kids and your fancy "DVCS" tools. Ema
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
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
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
> transactio
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
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.
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? Afte
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."
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 w
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
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
(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 timel
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 mo
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
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 r
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
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
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 h
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
The Django test client exposes the Context used to render the returned
response, so that unit tests can inspect that Context and verify that
it contained what it was expected to contain. This is all well and
good, except that there is no consistent way to write tests which do
this.
When an inheri
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
> acce
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."
--~--~---
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/10
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 ha
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 sdi
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
>
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
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
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
an
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 doi
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.
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
> ver
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 t
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
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 u
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 eve
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 ment
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,
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.
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
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
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 du
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 Conra
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."
--~--
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
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
On Tue, Feb 17, 2009 at 7:40 AM, NitinHayaran wrote:
> Today i read this article and was wondering whether django orm is
> really that bad.
>
> http://dayhacker.blogspot.com/2009/02/why-django-orm-sucks-it-takes-hell-lot.html
Well, it's obligatory for me first to say "wow, Blogger sucks", since
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
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
As we run up to Django 1.1 (due in April), we've started the process
of alpha and beta preview packages with Django 1.1 alpha 1, released
tonight. As always, alpha and beta packages are *not* for production
use, but if you'd like to try out the new features or go bug-hunting
in a safe environment,
OK, so, time to step back a bit and think big-picture.
How to specify the markup type
==
Yes, you and your co-workers like having an internal app where
everybody chooses their own markup format every time they post
something. But if something's going to go into Djang
> This needs to accept kwargs as well. Lets take the use case were
> Markdown it the default. And most of the site is used by trusted users
> so Markdown is not in safe_mode (we allow raw html). But now, we have
> one field (perhaps comments) which is accessable to the general
> untrusted public.
On Wed, Feb 25, 2009 at 10:04 PM, smoluf wrote:
> If I issue an equivalent query with a QuerySet, however, and then
> select two rows by indexing into the result at two random locations, I
> can not currently be guaranteed that they are different rows because
> the QuerySet will use two different
On Wed, Mar 11, 2009 at 9:45 PM, Eduardo Cereto Carvalho
wrote:
> I already had a google code project for this but there is nothing
> there yet. My primary goal is to create a pluggable django app to help
> you take your django applications offline. But I have nothing yet, I
> just wanted to hear
On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov wrote:
> Maybe let's go a bit further towards pool of db connections and wrap a
> bunch of lines importing backend into some function that depends on
> engine argument?
FWIW I'm still strongly of the opinion that database connection
pooling does not
On Fri, Mar 13, 2009 at 5:51 PM, Adrian Holovaty wrote:
> My proposal is not necessarily to get this in Django 1.1, but to get
> it in trunk at the very least. I'm selfishly motivated by my own
> project to get this done ASAP, so I'm very happy to do the
> development.
Since 1.1's only about a m
On Mon, Mar 16, 2009 at 3:40 PM, dalore wrote:
> I've submitted ticket #762 which contains patches and new files that
> allow google checkout v2 integration. It implements the necessary
> components of the google checkout notification api so that an order in
> satchmo gets updated with callbacks
On Wed, Mar 18, 2009 at 10:59 AM, Jacob Kaplan-Moss
wrote:
> I'm a somewhat reluctant +0 on this -- the content re-writing that the
> CSRF middleware does has always rubbed me the wrong way. For one,
> it'll make implementing streaming responses quite a bit more
> difficult. But more importantly
On Sat, Mar 21, 2009 at 11:24 AM, Alex Gaynor wrote:
> b) Having the admin be CSRF safe by default doesn't seam like a feature, it
> feels like a bug, even if it's implementation gives everything a new
> feature. That's just my thoughts though.
Personally I'd much rather have it actually *be* s
Ticket #9282 [1] is aiming to integrate the simple comment-moderation
features from my (now out-of-date) comment-utils application directly
into contrib.comments, and I notice from looking at the ticket and
attached patches that the built-in support for calling out to Akismet
has been removed.
Is
On Sun, Mar 22, 2009 at 9:20 PM, Justin Lilly wrote:
> My thoughts are that while akismet is the current gold standard, it
> should be replaceable with another, user-defined, backend if you so
> choose. Another that comes to mind is http://stupidfilter.org/main/
> which attempts to tell if someth
On Mon, Apr 13, 2009 at 6:12 PM, Glenn Maynard wrote:
> Anyhow, I'm not advocating changing it--nothing prevents people from
> ignoring get_profile entirely and just using OneToOne (which is
> probably what I'll do).
Well.
First let's explore why get_profile() exists. Back in the day -- the
fir
On Mon, Apr 13, 2009 at 7:32 PM, Glenn Maynard wrote:
> Well, you might want to do that for any model, and the admin API
> provides a more generic approach to managing this sort of task--but
> OK.
It's true you *might* want to do it for any particular model, but the
specific case of user profile
On Mon, Apr 13, 2009 at 8:34 PM, Glenn Maynard wrote:
> You don't need to come up with helpers--OneToOneField automatically
> creates the only helper this provides, in a way that (unlike
> get_profile()) is consistent with all other model relationships. It's
> standardizing how to get to somethi
On Tue, Apr 14, 2009 at 7:40 AM, Russell Keith-Magee
wrote:
> The exact state of the Django source tree as at the v1.0.2 release is
> stored in Trac, using the tag "releases/1.0.2"
>
> http://code.djangoproject.com/browser/django/tags/releases/1.0.2
Also, Django's install scripts have been updat
On Thu, Apr 30, 2009 at 6:31 PM, Igor Sobreira wrote:
> Because it violates DRY, and will mess the template inheritante.
The problem is that this isn't actually an argument. It's just a statement.
The real thing to consider here is what trade-off is being made: in
return for having to do a bit
On Sat, May 2, 2009 at 11:27 PM, Paul Johnston wrote:
> However, the use of JavaScript MD5 is not widespread. I think this is
> because few authentication libraries support it. It is possible for a
> library to provide JavaScript MD5 as an authentication mechanism, with
> the details hidden from
On Thu, May 7, 2009 at 3:30 AM, Tai Lee wrote:
> BooleanField(null=True) indicates that the field can have null values
> in the database (or does already have null values in the case of an
> existing database), but that any objects created or edited via Django
> must specify one of two values, tr
On Thu, May 7, 2009 at 4:26 AM, James Bennett wrote:
> relying on a bug in Django which allowed BooleanField to accept any of
> three values rather than restricting it to either of two values.
And I misspoke there, thinking of a different bug. Now that I look at
it you couldn't ev
On Sun, May 10, 2009 at 11:53 PM, Joshua Partogi wrote:
> I really doubt that the people from HR would really read the
> description of the group. I've been dealing with HR people. :-D All
> they care about is posting the job based on the specs their end user
> told them. And to them, the name dj
On Mon, May 11, 2009 at 5:12 PM, Glenn Maynard wrote:
> Better names for django-users and django-developer would have been
> django-developer and django-core, respectively. Calling this list
> "developer" wasn't such a great idea--the users of Django *are*
> developers; they're developing with D
On Mon, Jun 22, 2009 at 1:43 PM, Sergio Oliveira wrote:
> Some suggestions for the number 2:
> - Django 1.1: What do we need to release? It's only the bugs in the
> milestone 1.1?
1.1 is down to just a handful of bugs, and I think they're mostly well in hand.
A better focus, for those who are i
Hi folks! Tonight we've pushed out the Django 1.1 release candidate,
which is hopefully the last stepping-stone to the final 1.1 release.
If you'd like to try it out, here's where you'll want to look:
* Download instructions: http://www.djangoproject.com/download/
* Release notes: http://docs.dja
Tonight the Django team has issued two releases related to a security
issue reported to us. These releases are Django 1.0.3 and Django
0.96.4.
Full information is available on the Django project weblog:
http://www.djangoproject.com/weblog/2009/jul/28/security/
These releases are strongly recomm
Tonight we're extremely proud to announce the release of Django 1.1,
the latest major milestone in Django's development.
To learn about the new release:
* Blog post: http://www.djangoproject.com/weblog/2009/jul/29/1-point-1/
* Release notes: http://docs.djangoproject.com/en/dev/releases/1.1/
* D
On Mon, Aug 10, 2009 at 5:05 AM, Bala kumar wrote:
> Can anyone please suggest me a good open source python lib for
> generating PDF files from HTML file.
>
> Mainly I want to display an formatted table with some images..
This list, as has been advertised many, many times in the past, is not
the
I also think the overlap between
1) People who want to always be running the absolute latest-released
cutting-edge versions of software, and
2) People who are running older editions of RHEL
...is likely to be rather small.
--
You received this message because you are subscribed to the Google Gr
This list is for discussion of the development of Django itself. For
discussion of how to use Django, please see the django-users mailing list.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receivin
Today the Django team is issuing multiple releases -- Django 1.4.7, Django
1.5.3, and Django 1.6 beta 3 -- as part of our security process. These
releases address a directory-traversal vulnerability in one of Django's
built-in template tags.
More details can be found on our blog:
https://www.djan
Earlier today a message posted to the django-developers mailing list
publicly disclosed what was later determined to be an exploitable security
issue in Django.
As such, we have short-circuited our normal one-week process and moved to
immediately issuing new releases to remedy the problem.
Full d
It's almost here!
Tonight we've issued a release candidate for Django 1.6. Information,
including links to downloads and release notes, is available on the Django
project blog:
https://www.djangoproject.com/weblog/2013/oct/22/16c1/
--
You received this message because you are subscribed to the
These are minor bugfix releases, so not particularly urgent to upgrade.
Details and release notes are available from the blog post:
https://www.djangoproject.com/weblog/2013/oct/24/bugfix-releases/
--
You received this message because you are subscribed to the Google Groups
"Django developers"
Django 1.6 and Django 1.4.10 are out today; the latter is a bugfix release
to restore Python 2.5 compatibility in the 1.4 series.
Full details are in the blog post:
https://www.djangoproject.com/weblog/2013/nov/06/django-16-released/
--
You received this message because you are subscribed to th
Yup, we're on the way to 1.7!
Check out the blog post (which mentions a couple of important issues to be
aware of *before* trying out the alpha):
https://www.djangoproject.com/weblog/2014/jan/22/django-17-alpha-1-released/
And the in-progress 1.7 release notes for a full rundown of what's going
We're getting closer to 1.7!
Details in the blog post here:
https://www.djangoproject.com/weblog/2014/mar/20/django-17b1/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, se
Today we've issued releases to remedy three security issues reported to us.
Affected versions are Django 1.4, Django 1.5, Django 1.6 and the Django 1.7
beta.
Full details and download information are on the Django project weblog:
https://www.djangoproject.com/weblog/2014/apr/21/security/
--
Yo
Today we've issued releases which remedy a regression reported with last
week's security release.
Details and updated packages are available from the Django project blog:
https://www.djangoproject.com/weblog/2014/apr/28/bugfix-releases-issued/
--
You received this message because you are subscr
601 - 700 of 1014 matches
Mail list logo
