https://www.djangoproject.com/download/ is down!

[Wim Feijen]

The download page for Django is down.

I also filed a ticket, so this is a duplicate message.

Wim

-- 
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: plea for re-opening ticket 13125 marked as won't fix

[Wim Feijen]

The case is as follows:

1. An active user is logged in and has a valid session.
2. The user is inactivated by a system admin, who wants to disable the
user.
3. Because the user is still logged in, (maybe for two weeks, or for
whatever expiration time the developer has set), he passes the
login_required decorator, and still can see those pages which we
naively thought were being protected by the login_required decorator,
because that decorator doesn't check for is_active.

This patch is a patch for that problem.

Wim


On 10 sep, 23:09, Florian Apolloner  wrote:
> Stupid question, but why do you let inactive users login at all? I mean is
> this really a problem of the decorator and not of the login system you use?!

-- 
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: https://www.djangoproject.com/download/ is down!

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/11/2011 12:46 PM, Wim Feijen wrote:
> The download page for Django is down.
> 
> I also filed a ticket, so this is a duplicate message.

Thanks for the alert, but it seems to be up for me, and
"downforeveryoneorjustme.com" confirms that its up. Either its a
localized issue, or if it was down, it isn't any longer. I've closed the
ticket "worksforme".

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5tBX0ACgkQ8W4rlRKtE2fY8ACgl0nnp5ymGV0QXrI6n0XWc3AI
3/wAnjuSafU/ymyh2qlmoOIZuWuiZV1I
=GKeE
-END PGP SIGNATURE-

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

Just curious, why is admin.site.register([Model], [ModelAdmin]) not done within ModelAdmin?

[Joshua Russo]

I've wondered this for a while, but is there a reason why the call to 
admin.site.register(([Model], [ModelAdmin]) is not done within the init of 
ModelAdmin?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/OxXmz1Obc0oJ.
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: plea for re-opening ticket 13125 marked as won't fix

[Wim Feijen]

Paul,

On further thinking, I do believe that the current behaviour of
login_required should be considered a bug.

Wim

On 10 sep, 02:03, Paul McMillan  wrote:
> No. Django makes an incredibly strong promise about backwards
> compatibility to its users. Security releases are the ONLY reason we
> modify behavior in backwards incompatible fashions, and we try very
> hard to avoid that.

-- 
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: https://www.djangoproject.com/download/ is down!

[Wim Feijen]

It is up for me as well. It was just the Download page.

Thanks, Wim

On 11 sep, 21:01, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/11/2011 12:46 PM, Wim Feijen wrote:
>
> > The download page for Django is down.
>
> > I also filed a ticket, so this is a duplicate message.
>
> Thanks for the alert, but it seems to be up for me, and
> "downforeveryoneorjustme.com" confirms that its up. Either its a
> localized issue, or if it was down, it isn't any longer. I've closed the
> ticket "worksforme".
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk5tBX0ACgkQ8W4rlRKtE2fY8ACgl0nnp5ymGV0QXrI6n0XWc3AI
> 3/wAnjuSafU/ymyh2qlmoOIZuWuiZV1I
> =GKeE
> -END PGP SIGNATURE-

-- 
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: Just curious, why is admin.site.register([Model], [ModelAdmin]) not done within ModelAdmin?

[Jeremy Dunck]

On Sun, Sep 11, 2011 at 11:56 AM, Joshua Russo  wrote:
> I've wondered this for a while, but is there a reason why the call to
> admin.site.register(([Model], [ModelAdmin]) is not done within the init of
> ModelAdmin?

You can run multiple AdminSite instances mounted at different URLs.
admin.site is just a default instance of AdminSite for ease of use.

-- 
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: Just curious, why is admin.site.register([Model], [ModelAdmin]) not done within ModelAdmin?

[Joshua Russo]

gotcha, thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/z1jxGo07QQIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal for a new templatetag definition syntax

[Mikhail Korobov]

I gave up defining this template tag with existing template tag libraries:

{% easy_map  [ ] [] [using ] %}


Can positional arguments be optional? Will it be possible to express this 
syntax?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/-ZjMdkCLOS0J.
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: plea for re-opening ticket 13125 marked as won't fix

[Florian Apolloner]

On Sunday, September 11, 2011 8:52:03 PM UTC+2, Wim Feijen wrote:
>
> 3. Because the user is still logged in, (maybe for two weeks, or for 
> whatever expiration time the developer has set)
>

Imo in that case the developer should write a middleware that logs the user 
out on the next request. I see your problem, but imo your system needs a bit 
of tweaking if you allow inactive users to browse your site till their 
session expires (which with SAVE_EVERY_REQUEST +  a high timeout) could as 
well be never… 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/gXvWPvnJThgJ.
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.

Check-in #1 / Multiple timezone support for datetime representation

[Aymeric Augustin]

Hello,

Given the positive feedback received here and on IRC, I've started the 
implementation.

Being most familiar with mercurial, I've forked the Bitbucket mirror. This page 
that compares my branch to trunk:
https://bitbucket.org/aaugustin/django/compare/..django/django

I've read a lot of code in django.db, and also the documentation of PostgreSQL, 
MySQL and SQLite regarding date/time types.

I've written some tests that validate the current behavior of Django. Their 
goal is to guarantee backwards-compatibility when USE_TZ = False.

At first they failed because runtests.py doesn't set os.environ['TZ'] and 
doesn't call time.tzset() , so the tests ran with my system local time. I fixed 
that in setUp and tearDown. Maybe we should call them in runtests.py too for 
consistency?

By the way, since everything is supposed to be in UTC internally when USE_TZ is 
True, it is theoretically to get rid of os.environ['TZ'] and time.tzset(). They 
are only useful to make timezone-dependant functions respect the TIME_ZONE 
setting. However, for backwards compatibility (in particular with third-party 
apps), it's better to keep them and interpret naive datetimes in the timezone 
defined by settings.TIME_ZONE (instead of rejecting them outright). For this 
reason, I've decided to keep os.environ['TZ'] and time.tzset() even when USE_TZ 
is True.

Best regards,

-- 
Aymeric Augustin.


On 3 sept. 2011, at 17:40, Aymeric Augustin wrote:

> Hello,
> 
> The GSoC proposal "Multiple timezone support for datetime representation" 
> wasn't picked up in 2011 and 2010. Although I'm not a student and the summer 
> is over, I'd like to tackle this problem, and I would appreciate it very much 
> if a core developer accepted to mentor me during this work, GSoC-style.
> 
> Here is my proposal, following the GSoC guidelines. I apologize for the wall 
> of text; this has been discussed many times in the past 4 years and I've 
> tried to address as many concerns and objections as possible.
> 
> Definition of success
> -
> 
> The goal is to resolve ticket #2626 in Django 1.4 or 1.5 (depending on when 
> 1.4 is released).
> 
> Design specification
> 
> 
> Some background on timezones in Django and Python
> .
> 
> Currently, Django stores datetime objects in local time in the database, 
> local time being defined by the TIME_ZONE setting. It retrieves them as naive 
> datetime objects. As a consequence, developers work with naive datetime 
> objects in local time.
> 
> This approach sort of works when all the users are in the same timezone and 
> don't care about data loss (inconsistencies) when DST kicks in or out. 
> Unfortunately, these assumptions aren't true for many Django projects: for 
> instance, one may want to log sessions (login/logout) for security purposes: 
> that's a 24/7 flow of important data. Read tickets #2626 and #10587 for more 
> details.
> 
> Python's standard library provides limited support for timezones, but this 
> gap is filled by pytz . If you aren't familiar 
> with the topic, strongly recommend reading this page before my proposal. It 
> explains the problems of working in local time and the limitations of 
> Python's APIs. It has a lot of examples, too.
> 
> Django should use timezone-aware UTC datetimes internally
> .
> 
> Example : datetime.datetime(2011, 09, 23, 8, 34, 12, tzinfo=pytz.utc)
> 
> In my opinion, the problem of local time is strikingly similar to the problem 
> character encodings. Django uses only unicode internally and converts at the 
> borders (HTTP requests/responses and database). I propose a similar solution: 
> Django should always use UTC internally, and conversion should happen at the 
> borders, i.e. when rendering the templates and processing POST data (in form 
> fields/widgets). I'll discuss the database in the next section.
> 
> Quoting pytz' docs: "The preferred way of dealing with times is to always 
> work in UTC, converting to localtime only when generating output to be read 
> by humans." I think we can trust pytz' developers on this topic.
> 
> Note that a timezone-aware UTC datetime is different from a naive datetime. 
> If we were using naive datetimes, and assuming we're using pytz, a developer 
> could write:
> 
> mytimezone.localize(datetime_django_gave_me)
> 
> which is incorrect, because it will interpret the naive datetime as local 
> time in "mytimezone". With timezone-aware UTC datetime, this kind of errors 
> can't happen, and the equivalent code is:
> 
> datetime_django_gave_me.astimezone(mytimezone)
> 
> Django should store datetimes in UTC in the database
> 
> 
> This horse has been beaten to death on this mailing-list so many times that 
> I'll  keep the argumentation short. If Django handles everything as UTC 
> internally, it isn

Re: Fixture loading using bulk_create

[Anssi Kääriäinen]

I created a POC patch that does bulk loading of fixtures. The work can
be found from github: https://github.com/akaariai/django/tree/fixture_loading.
Be warned, it really is POC :)

The results are somewhat depressing for Django tests. The reason is
that there just isn't that much fixture loading going on. Some
statistics numbers I gathered using the patch:

total_objects:  11200
average batch size: 2.51069012179
selects done: 4291 # Need to do a select to see which objects are
already in the DB
updates done: 1756 # Those that were are updated in the regular way
raw inserts done: 159 # Can't use bulk_insert for inherited models, so
use save(force_insert=True) instead
batch_inserts done: 9277 # Amount of objects inserted using
bulk_create
batch_count: 3695

So, before patch there would have been 22400 queries (each save is a
select + update or insert), after patch there were 4291 + 1756 + 159 +
3695 = 9901 queries.

The speed of running the tests was about 3% faster using sqlite3.

Things look a bit better when loading a dump of 1 objects into db,
for sqlite3 I got 4-5x better timing, for PostgreSQL I got 3-4x better
timing for that test. If the DB would be non-local the result would be
even better.

All tests are passed on SQLite3, except two tests in modeltests/
fixtures which I suspect are QuerySet ordering related. There was one
model that was missing default ordering, and it caused some breakages
due to different order of results. The remaining broken tests are a
bit complicated to debug. The broken tests are two full dumps of the
DB, one in XML and one in JSON format. The dumps are then compared
character for character to expected output. The dumps are somewhat
large and I am somewhat tired, I think there is a row in different
order somewhere in there...

I am currently running the PostgreSQL tests, all I know is the
PostgreSQL tests take a long time :)

The main issues with the patch are:
  - I expect it to break when given models with lots of columns in big
batches: too many sql parameters for backend.
  - Signals are sent, but they are sent in batches.
  - Generally more complicated object saving. The old way was very
easy to understand: each object is saved when read from the fixture.
Now that isn't true any more.
  - Same model, same pk multiple times in one fixture does not work.
Django doesn't create fixtures like this.
  - I might be missing something obvious in the patch, fixture loading
is a new area to me.

The feature could be useful if there are users loading big fixture
files regularly. Otherwise it complicates fixture loading for little
gain.

I am not going to create a ticket for this one. I have too many
tickets in POC+DDN state already.

 - Anssi

-- 
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: Improved password hashing for 1.4

[Daniel Swarbrick]

On Sep 10, 11:36 pm, Paul McMillan  wrote:
> Yes, you're absolutely right. My choice of words was incorrect. Is
> your python implementation licensed in such a way that we could
> consider including it in Django? We've looked at a couple
> implementations now, having another option would be helpful.

License? What license? Heheh... my PBKDF2 implementation is solely
being used by an in-house Django app. I haven't open sourced it, but
am perfectly willing to let you guys pick over the PBKDF2 class and
include it in Django if you so desire. It even includes unit tests for
RFC 3962.

Paul, I'll contact you off-list.

MfG
Daniel

-- 
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: Improved password hashing for 1.4

[Jacob Kaplan-Moss]

On Sun, Sep 11, 2011 at 6:11 PM, Daniel Swarbrick
 wrote:
> License? What license? Heheh... my PBKDF2 implementation is solely
> being used by an in-house Django app. I haven't open sourced it, but
> am perfectly willing to let you guys pick over the PBKDF2 class and
> include it in Django if you so desire.

Please be careful here -- this runs pretty close to including
proprietary code in Django. Without a license code defaults to "all
rights reserved."

If you're going to let Paul look at your work, please make sure you've
read and signed a CLA (https://www.djangoproject.com/foundation/cla/)
covering the code in question.

Sorry to be a license-dork!

Jacob

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

Re: Improved password hashing for 1.4

[Daniel Swarbrick]

On Sep 12, 2:58 am, Jacob Kaplan-Moss  wrote:
>
> If you're going to let Paul look at your work, please make sure you've
> read and signed a CLA (https://www.djangoproject.com/foundation/cla/)
> covering the code in question.

Jacob, you're absolutely right, and I should really be a bit more
organized with sticking licenses on code that I write. It just so
happens that this particular piece of code is quite new, and
associated with a long-running project that I've developed in my own
time, and which has never really been let out of the lab.

I will follow up on that CLA.

-- 
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: #7198 - Better error message when app is missing models.py

[Gary Wilson Jr.]

On Fri, Sep 9, 2011 at 4:35 PM, Justin Lilly  wrote:
> Not sure why this particular ticket is marked as DDN, as it seems like
> a no-brainer. The patch provides a more clear error message when a
> user is attempting to load an app which doesn't have a models.py.
>
> https://code.djangoproject.com/ticket/7198
> https://github.com/django/django/pull/39
>
> Happy to respond to any feedback, as I think this is a worthwhile
> change.

As Carl recently commented on the referenced ticket, the DDN was
likely due to a decision on whether or not to require a models.py at
all.

I'm a fan of not requiring a models.py, as IMHO it shouldn't be any
different than other common files found in an app e.g. urls.py,
templatetags dir, etc.  If I don't need any models for my app, then
why must I still have a models.py?  That said, it also seems there
could be some backwards incompatibilities if code or external tools
rely on a valid app including a models.py file.

For the record, about 20% of the models.py files in the django
codebase are empty (or just contain a comment):
$ find . -size -60c -name 'models.py' | wc -l
44
$ find . -name 'models.py' | wc -l
211

The issue of a missing models.py file also seems to be a frequent
visitor to our ticketing system:
https://code.djangoproject.com/ticket/3125
https://code.djangoproject.com/ticket/3310
https://code.djangoproject.com/ticket/4153
https://code.djangoproject.com/ticket/6883
https://code.djangoproject.com/ticket/7198
https://code.djangoproject.com/ticket/10661
https://code.djangoproject.com/ticket/13985
https://code.djangoproject.com/ticket/15605

...and there's been a few occasions where we've had our own issues
with missing models.py files:
https://code.djangoproject.com/changeset/6991
https://code.djangoproject.com/changeset/7950
https://code.djangoproject.com/changeset/12156
https://code.djangoproject.com/changeset/12170
https://code.djangoproject.com/changeset/13670

Gary

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

Re: Proposal for a new templatetag definition syntax

[Anssi Kääriäinen]

On Sep 11, 10:36 pm, Mikhail Korobov  wrote:
> I gave up defining this template tag with existing template tag libraries:
>
> {% easy_map  [ ] [] [using ] %}
>
> Can positional arguments be optional? Will it be possible to express this
> syntax?

>From the department of stupid ideas: Would it be possible to support
the above syntax? I mean, the MyTag definition would be just:

class MyTag(Tag):
syntax = "mytag  [ ] [] [using
]"

That would be my preferred solution.

There is just the little problem of how to parse the syntax. I don't
know how to do that. If there is any support for this idea, I am
willing to check if this is possible.

 - Anssi

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