Re: Kickstarter for Django Admin?

[Florian Apolloner]

Hi,

I already wanted to look at hyperadmin, but got caught up reading what 
HATEOAS is and how it works first ;) I do have one question if you don't 
mind: With a REST/HATEOS backend you'd export links with appropriate rel 
attributes to tell the client what we can do. So far so good, but let's 
pick the template version as example, how does it know where to put which 
links, does it solely look on rel and figure out what to do with it? Also 
how do you sensible provide extradata like the _meta information of the 
model etc…

Which files do you think are a good start when looking at hyperadmin?

Thx & Regards,
Florian

P.S.: I agree that hyperadmin takes a good approach to the admin problem, 
imo something along this line should power a new admin.

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ALLOWED_HOSTS : Cannot allow hosts with single label

[Florian Apolloner]

Hi,

it's hard to say anything without knowing your real alias, the tests work 
for me as soon as I remove the underscore which is indeed not allowed in 
hostnames!

Regards,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with creating a one-to-one instance

[Florian Apolloner]

Hi Carsten,

first of all, django-dev is not a second level support list, so for the 
future please refrain from posting here just because you get no answer on 
the user list. As for the issue on hand, try accessing ma.vbp_id after you 
assign the instance, this should give you some clues.

Cheers,
Florian

P.S.: Also if you want your app to be reusable code in English  and not in 
German ;)

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[Florian Apolloner]

Hi,

On Saturday, April 20, 2013 8:03:43 PM UTC+2, LittleQ@NCCU, Taiwan wrote:
>
> cuz seems like there's no #django-dev, so feel free to add my XMPP 
> directly: littl...@gmail.com


There is #django-dev (sic) on irc.freenode.net.

Regards,
Florian 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[Florian Apolloner]

Hi,

aside from what Russell already pointed out, I would like to add a few 
points:

* You list "Refactor for Expandability" as last on your schedule. I think 
it should be at the start, eg compare different solutions like GAE, heroku, 
Gondor, find a common subset and then write the backends accordingly. I 
fear that if you do this the other way around you will have to throw away 
most of the code for heroku/GAE and rewrite it.

* Regarding storage stuff, you say "I chose Google Cloud Storage according 
to the networking speed and authorization flow will be easier than using 
other storage service such as S3.". Personally I don't think it's wise to 
choose the easier storage (network speed should be no concern here 
anyways), your API should be able to allow to hook in the more complex 
authorization flow too, what would be a better way to test your API than 
using S3 :)

All in all this proposal imo tries to address way to much and focuses to 
much on Google. It would be more useful to lay the groundwork for an API 
instead. That said, did you get in contact with the project authors about 
mentorship (eg are they interested and do have the time for it), I am 
pretty sure none of the core devs uses django-deployer, so mentoring it 
would be a bit suboptimal.

Regards,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changing deferred model attribute behavior

[Florian Apolloner]

On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote:
>
> Also, I should mention that this should be *optional* behavior, as the 
> current behavior is reasonable for the common case. The API for specifying 
> this "load everything" behavior is a separate discussion. Perhaps a keyword 
> argument like: User.objects.only('username', loadall=True).
>

I could imagine a Meta attribute which introduces so called "deferred 
groups" like SA has 
http://docs.sqlalchemy.org/en/latest/orm/mapper_config.html#deferred-column-loading,
 
accessing one column of a group will load all columns of the group. Not 
sure if we want that level of control, but I thought it would be worth to 
look what SA can do in this regard.

Regards,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Test failures under Oracle

[Florian Apolloner]

Hi,

now that the 1.6 release plan is out, I'd like to push this topic again. If 
you are using Oracle, now is the time to fix those bugs. Personally I am 
toying with the idea of dropping Oracle support from core if we can't 
ensure it's quality.

Regards,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Data concurrency, consistency and serializabe

[Florian Apolloner]

Hi,

this question seems to be more suited for django-users. django-developers 
is for the development of Django itself.

Regards,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

[Florian Apolloner]

Not good, at least our Jenkins runner which should generate xml output 
doesn't like it :/

On Saturday, May 11, 2013 5:36:55 AM UTC+2, Carl Meyer wrote:
>
> I merged this patch tonight. Thanks to everyone who contributed! Now let's 
> see how the CI servers feel about it...
>
> Carl
>
> On Wednesday, May 8, 2013 5:00:56 PM UTC-4, Carl Meyer wrote:
>>
>> Preston Timmons and I have been working the last several weeks to get 
>> the test discovery branch (#17365) ready for merge, and I think we now 
>> have a pull request ready for consideration: 
>> https://github.com/django/django/pull/1050 
>>
>> Brief summary of the features, changes, and open questions: 
>>
>> * You can now place tests in any file matching the pattern 'test*.py', 
>> anywhere in your codebase, rather than only in tests.py and models.py 
>> modules of an INSTALLED_APP. The filename pattern is customizable via 
>> the --pattern argument to "manage.py test". 
>>
>> * When you run "manage.py test" with no arguments, tests are discovered 
>> and run in all subdirectories (recursively) of the current working 
>> directory. (This means that django.contrib and other third-party app 
>> tests are no longer run by default). 
>>
>> * When you pass arguments to "manage.py test", they are now full Python 
>> dotted module paths. So if you have a "myproject.myapp" app, and its 
>> tests.py contains "SomeTestCase", you would now run that single test 
>> case via "manage.py myproject.myapp.tests.SomeTestCase" rather than 
>> "manage.py myapp.SomeTestCase". This is longer, but allows more control 
>> when an app's tests are split into multiple files, and allows for tests 
>> to be placed anywhere you like. 
>>
>> * Doctests are no longer discovered by default; you will need to 
>> explicitly integrate them with your test suite as recommended in the 
>> Python docs: http://docs.python.org/2/library/doctest.html#unittest-api 
>>
>> * Tests in models.py and tests/__init__.py will no longer be discovered 
>> (as those don't match the default filename pattern). 
>>
>> * The old test runner, and Django's extensions to the doctest module, 
>> are deprecated and will be removed in Django 1.8; they could of course 
>> be packaged separately if some people would like to continue using them. 
>>
>> Open question: how to handle the transition? 
>>
>> Jacob has suggested that back-compat breaks in test-running are not as 
>> serious as in production code, and that we should just switch to the new 
>> test runner by default in Django 1.6. This is what the pull request 
>> currently does. This will mean that some people's test suites will 
>> likely be broken when they upgrade to 1.6. They would have two options, 
>> both documented in the release notes: they can update their test suite 
>> to be discovery-compatible immediately, or they can just set TEST_RUNNER 
>> to point to the old runner and get back the old behavior, which they can 
>> keep using until Django 1.8 (or longer, if they package the old runner 
>> externally). 
>>
>> The alternative would be to keep the old test runner as the default in 
>> global_settings.py until it is removed in 1.8, and add the new runner as 
>> the TEST_RUNNER in the startproject-generated settings.py. This would 
>> provide a gentler transition for upgrading projects. On the other hand, 
>> we just recently got the startproject settings.py all cleaned-up, 
>> slimmed-down, and newbie-friendly, so it would make me sad to start 
>> polluting it again with stuff that new projects generally shouldn't care 
>> about, for solely legacy reasons. 
>>
>> Thoughts, questions, comments, code review and testing welcome! I'd like 
>> to merge this on Friday (it's a bear to keep updated with trunk), so let 
>> me know if you need longer. 
>>
>> Carl 
>>
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

[Florian Apolloner]

Hi Carl,

before I read all the tickets etc; why does runtests.py not use the 
TEST_RUNNER from settings.py (see 
https://github.com/django/django/commit/9012833af857e081b515ce760685b157638efcef#L60L149)?
 
We'd need that for jenkins to produce xml files as output.

Thanks,
Florian 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

[Florian Apolloner]

On Saturday, May 11, 2013 2:38:23 PM UTC+2, Carl Meyer wrote:
>
> No good reason, just an oversight I think. If that's all that's needed to 
> make the CI happy, feel free to change it, should be a simple fix.
>

Perfect, pushed a fix, let's see what jenkins says. 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Reopening/Refixing #20246

[Florian Apolloner]

Hi,

I don't think that the fix of #20246 [0] is correct. You started using \xa0 
while Wikipedia clearly suggests that we should use a narrow space instead 
of a full-space (probably U+202F). This is something we learned during our 
physics courses too, so it's in line with what science departments do too. 

Any objections on refixing it?

Cheers,
Florian

0: https://code.djangoproject.com/ticket/20246

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ORA-01882 [was Re: looking up date as str (fails under Oracle, Ticket #20015)]

[Florian Apolloner]

Hi Shai

On Sunday, May 19, 2013 7:12:12 AM UTC+2, Shai Berger wrote:
>
> Florian, Aymeric, or any Django/Oracle user in Kenya: How did you overcome 
> this? 
>

I have no idea, I just bang my head against the CI till it works or falls 
completely apart  (well not really, but you get the gist ;)). I'll ask 
Aymeric when he shows up and get back to you.

Cheers,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: add request decompression to gzip middleware

[Florian Apolloner]

Hi,

given that I already think that the GzipMiddleware is a bad idea (it should 
be left up to the webserver), I don't like the idea of adding this to the 
current middleware. Any reason why you couldn't do this in the webserver?

Regards,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Reopening/Refixing #20246

[Florian Apolloner]

Hi,

On Sunday, May 19, 2013 8:18:48 PM UTC+2, Claude Paroz wrote:
>
> I'm not completely sure. The narrow space should certainly be used between 
> a number and its unit symbol (kg, cm, Mb, etc.). So your proposal is at 
> least valid for a part of the patch. However, for "5 hours, 4 minutes", I'm 
> not sure it's the same rule. I'd suggest you add references on the ticket 
> and then fix the parts that need to be fixed.
>

Hmm, how do you suggest fixing it? adding a new function 
avoid_narrow_wrapping and changing everything in defaultfilters, or… (I am 
asking cause the current fix confuses me, since you didn't touch the 
translations [eg 
https://github.com/django/django/commit/7d77e9786a118dd95a268872dd9d36664066b96a#L3R825
 
] but just replace the space later on).

Thanks,
Florian 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: add request decompression to gzip middleware

[Florian Apolloner]

Hi,

On Sunday, May 26, 2013 3:49:48 PM UTC+2, Sébastien Béal wrote:
>
> - limit resources available with the resource module. Is there any other 
> parts of Django using this technique?


Using rlimits are imo not an option; as (to my knowledge) it affects the 
whole process and not just the thread; also you'd have to reset it later on 
etc… All in all a solution which sounds to complicated imo.
 

> - use the zlib module instead of the gzip one with a max_size in the 
> decompress function. A pattern could be to require the Content-Length of 
> the request to be equal to the uncompress size and use it as the max_size 
> argument to be more dynamic, or just to set an arbitrary max_size. It will 
> involve more work than just using the gzip module though.
>

I am not sure that's going to fly well, since when you use gzip you 
probably wanna send plenty of data, and as long as the user can control the 
max_size you are running into the same issues; so the only option would be 
your suggested max_size. 

As Aymeric already pointed out, this is certainly easier in a real WSGI 
middleware, so the question is on whether we really want a suboptimal and 
error prone implementation as a django middleware. Personally I don't think 
it's worth is if the code is really as short as Aymeric demonstrated, ymmv.

Regards,
Florian

>
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: SQL from Models

[Florian Apolloner]

Hi,

this list is about the development of Django itself, please take your 
question to django-users.

Thanks,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Supported Python versions for Django 1.7

[Florian Apolloner]

Hi,

On Friday, June 28, 2013 4:17:22 PM UTC+2, Aymeric Augustin wrote:
>
> As far as I can tell, there's a consensus on dropping support for Python 
> 2.6. That will allow us to remove the vendored copy of unittest2 and to 
> take advantage of datastructures introduced in Python 2.7 like OrderedDict. 
>

Oh yes, getting rid of our vendored unittest2 is totally worth it 
(debugging failures when someone imports from below django.utils.unittest2 
is no fun)!

Cheers,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Deprecate FCGI support in Django 1.7

[Florian Apolloner]

Hi,

I'd like to get rid of everything FCGI-specific in Django sooner or later 
(rather sooner). Flup isn't maintained since a long time and there is no 
ticket tracker to report stuff. Graham pointed out that if someone wants to 
use FCGI they can use 
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socket 
which doesn't even require flup, which sounds like a good compromise to me. 
I'd need some help for the docs from some uWSGI users, since I have no idea 
about it ;)

Thoughts, objections?

Cheers,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Spam on ticket #542

[Florian Apolloner]

On Monday, July 15, 2013 3:20:16 AM UTC+2, Ramiro Morales wrote:
>
> Would it be worth look at the web server log to see if these comments 
> were effectively created by HTTP POST requests at all? 
>

That's what I did to figure out the ip (which I blocked via iptables before 
Aymeric played with the apache config). 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Florian Apolloner]

On Monday, July 15, 2013 7:07:08 AM UTC+2, Russell Keith-Magee wrote:
>
> I'm not arguing that FastCGI is a good option, just that it's prevalent. 
> And if we're going to stop supporting it, we need to be aware of who we're 
> cutting off.
>

We won't cut anything off (maybe aside from the runfcgi command). 
Supporting FCGI should be as easy as shown in the flask docs: 
http://flask.pocoo.org/docs/deploying/fastcgi/ -- This means that even if 
we remove everything FCGI specific from Django this doesn't prevent people 
from using FCGI+Django, it just means they have a bit more work to do 
(although if you look at the flask docs, it's really just a .fcgi file).

Cheers,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Florian Apolloner]

On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:
>
> If you're suggesting to move the FastCGI code into a separate app: +1 
>

I'd have just dropped it, but yes we can move it out; although someone else 
will have to step up to continue maintaining it (if there is a need to 
maintain it).

Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Florian Apolloner]

On Monday, July 15, 2013 6:20:45 PM UTC+2, Some Developer wrote:
>
> What about SCGI and AJP support? Is that going? 
>
Yes, it's either all or nothing.

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Florian Apolloner]

On Monday, July 15, 2013 9:55:51 PM UTC+2, Aymeric Augustin wrote:
>
> - Django's core developers don't use FCGI — at least, I don't know any 
> active core dev who does. 
>

I do, but with a patched flup and a patched suexec and what else, so I am 
hardly a typical usecase; and I am in the process of moving the systems to 
a sane setup.
 

> That makes FCGI a dead end. At some point we'll have to pull the plug. 
> Right now seems early. 
>

The plug is pulled when it's removed from Django, deprecating doesn't mean 
right now. Also, if we move it outside of django-core we can send a good 
signal that FCGI in Django is basically "Use at your own risk" (which it is 
already if you ask me).

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: docs.djangoproject.com very slow

[Florian Apolloner]

Hi,

should be back to normal by now.

On Monday, July 29, 2013 7:46:20 PM UTC+2, Kevin Veroneau wrote:
>
> Not sure where to report this, but the docs.djangoproject.com is going 
> very slow today, and I received a "504 Gateway Time-out" from the nginx 
> server.  Any ideas?
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support Negative Indexing on QuerySets

[Florian Apolloner]

Hi Mark,

How do you think such support would look like? For negative indices you'd 
have to know the size of the resultset to be able to do "limit somthing 
offset length-your_negative_index" -- this doesn't seem to make any sense 
for an ORM. You can always do list(qs)]:-1] though…

Cheers,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support Negative Indexing on QuerySets

[Florian Apolloner]

On Tuesday, July 30, 2013 11:34:18 PM UTC+2, Andre Terra wrote:
>
> On Tue, Jul 30, 2013 at 6:06 PM, Florian Apolloner 
> <f.apo...@gmail.com
> > wrote:
>
>> You can always do list(qs)]:-1] though…
>
>
> Although you really shouldn't [1].


Right, it depends on your usecase; I was just trying to point out other 
alternatives aside from the ones mentioned on the ticket.

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support Negative Indexing on QuerySets

[Florian Apolloner]

On Wednesday, July 31, 2013 1:03:31 AM UTC+2, Andre Terra wrote:
>
> On Tue, Jul 30, 2013 at 6:55 PM, Florian Apolloner 
> <f.apo...@gmail.com
> > wrote:
>
>> Right, it depends on your usecase; I was just trying to point out other 
>> alternatives aside from the ones mentioned on the ticket.
>
>
> I'm sorry if I seemed arrogant in my post. I most definitely did not 
> intend it, as I was absolutely sure that you were aware of the implications 
> of wrapping list() around a queryset.


No worries, you weren't sry if my wording suggested that. 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support Negative Indexing on QuerySets

[Florian Apolloner]

Hi Wim,

On Wednesday, July 31, 2013 12:04:42 AM UTC+2, Wim Lewis wrote:
>
> On 30 Jul 2013, at 2:06 PM, Florian Apolloner wrote: 
> > How do you think such support would look like? For negative indices 
> you'd have to know the size of the resultset to be able to do "limit 
> somthing offset length-your_negative_index" -- this doesn't seem to make 
> any sense for an ORM. You can always do list(qs)]:-1] though… 
>
> It seems like the first comment in the ticket answers that question. 
> Django would reverse the sense of the query's ordering clause and use a 
> simple LIMIT. 
>

In my opinion it doesn't; eg imagine the following as query: 
MyModel.objects.order_by('whatever')[0:-50]; this isn't translateable into 
MyModel.objects.order_by('-whatever')[50:] (the issue here is that the end 
is now again undefined) since at least SQLite doesn't support an OFFSET 
clause without a LIMIT. Also I think it's more natural to rewrite the 
ordering of the query yourself to express that instead of using negative 
ranges.

If there isn't an ordering clause in the query, then I agree it makes no 
> sense to do any indexing other than [0:N]. 
>

In that case it's even debatable if limiting makes any sense at all ;) 

Cheers,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Avoid unbounded memory consumption when running `manage.py test`

[Florian Apolloner]

Hi Matt,

On Thursday, August 1, 2013 12:08:23 AM UTC+2, Matt McClure wrote:
>
> Is the ultimate upstream the CPython repository now? Or a separate 
> unittest2 repository?


For Python >= 2.7 it should be CPython; for everything below the separate 
unittest2 repository. 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Merging Schema Alteration branch

[Florian Apolloner]

On Saturday, August 10, 2013 4:41:28 AM UTC+2, Russell Keith-Magee wrote: 
>
> Say… Andrew… there's this guy on a black horse at my front door… says his 
> name is "Famine"… he wants to talk about the coming apocalypse… :-)
>

Indeed, I already got migrations which magically unapply themself everytime 
I try to apply them, good thing that's not a production db ;)

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GZipMiddleWare documentation

[Florian Apolloner]

Hi,

On Saturday, August 10, 2013 9:54:02 AM UTC+2, Daniele Procida wrote:
>
> There is this discussion:  
> which concludes that it shouldn't be deprecated because some versions of 
> nginx ( don't work 
> with Etags and GZip as expected otherwise). 
>
> If that's because nginx doesn't behave properly, and the only reason for 
> not deprecating it, then perhaps it should be renamed 
> "GZipForMisbehavingBrowsersMiddleware". 
>

That might have been the only reason (btw other servers might behave the 
same or have similar, didn't test that myself); but as Donald says, in 
light of BREACH there are new reasons to keep it (at least for now, till we 
know if we want to keep it). Also, renaming things doesn't play well with 
Django's backwards compat policy and java-style 200Char class names are 
ugly, but I am sure you only suggested that as jest ;) 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Merging Schema Alteration branch

[Florian Apolloner]

On Sunday, August 11, 2013 12:26:10 AM UTC+2, Andrew Godwin wrote:
>
> I'll take a look at those over the next few days, Florian, it's the most 
> serious bug I've seen for a while!
>
No worries, I was mostly kidding; I want to get this in ASAP too, even with 
bugs; we'll have quite some time to fix them till the release of 1.7 ;)

Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecation a little harsh?

[Florian Apolloner]

Hi,

On Monday, August 12, 2013 6:21:46 AM UTC+2, Simon Litchfield wrote:
>
> One of Django's key strengths is the large collection of apps. Some aren't 
> as regularly maintained as we'd like but we still love them. Is it a little 
> unreasonable to expect them all to move so fast?
>

Fast? Imo the web world is one of the fastest moving places in the IT; and 
at the speed we release Django releases you still have a year or more and 
often you are not affected by those changes…
 

> Any one else found themselves spending too much time lately patching other 
> peoples' stuff?
>

Not really; generally people fix stuff quickly if I ask them, also the 
projects I maintain have compatibility for 1.7 already -- I agree that the 
database backend changes had been a bit much for me, but they are so much 
better now that it's totally worth it (and they are private api ;))

Cheers,
Florian 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Order of INSTALLED_APPS

[Florian Apolloner]

On Monday, August 12, 2013 3:41:15 PM UTC+2, Ramiro Morales wrote:
>
> For translations, we have such documentation already: 
>
>
> https://docs.djangoproject.com/en/1.5/topics/i18n/translation/#how-django-discovers-translations
>  
>

For templates too: 
https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.loaders.app_directories.Loader
 
-- but I agree it's somewhat hidden ;) 

Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecation a little harsh?

[Florian Apolloner]

Hi François,

On Tuesday, August 13, 2013 5:46:10 PM UTC+2, François Schiettecatte wrote:
>
> I have done 1.3.x -> 1.4.x -> 1.5.x and they have all been painless, each 
> migration taking less than 1/2 day. Point being that back-porting is not 
> something I would ever need. 
>

It's good to hear that some people are keeping up2date and it didn't cause 
any pain! Do you mind sharing how big (lines of code wise) those apps are 
(just a rough classification).

Regards,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: read-only admin view

[Florian Apolloner]

As with most open source projects; if you really want to see this done feel 
free to get coding and submit a patch :)

Cheers,
Florian

On Friday, August 16, 2013 9:01:07 AM UTC+2, Trevor Cox wrote:
>
> There are lots of reasons why read-only/view permissions are appropriate 
> for an admin system. I'd really like to see this done! I want to be able 
> to give readonly admin accounts to my designers, developers, sales reps and 
> sales prospects, because I want them to be able to try out the admin 
> interface of my live systems.
>
>
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: read-only admin view

[Florian Apolloner]

On Friday, August 16, 2013 6:19:03 PM UTC+2, Trevor Cox wrote:
>
> At least two people have already submitted a patch. 
>
Chances that they still work are not really big.
 

> The issue is not the coding but that the feature request is being rejected.
>
I see 3 core-devs in this thread which seem to be in favor of adding it, 
including Russ who wontfixed it previously; so I don't think that rejection 
is an issue here.
 

> I'm commenting because I don't think the arguments against the feature 
> have considered all the use cases for read only admin access; they're just 
> assuming that providing read only permissions would be for 
> non-administrators such as regular website users.
>
Your "I want people to see data in the admin" isn't really a compelling 
argument imo; but either way, as said above already, there are at least 3 
core devs in this thread which are not or no longer opposed to this 
feature. So if you'd like to see this in 1.7 now would be the time to get 
involved.

Cheers,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

[Florian Apolloner]

On Wednesday, August 21, 2013 12:18:24 PM UTC+2, Anssi Kääriäinen wrote:
>
> Improvements to error messages are usually accepted. This idea, too, if 
> there is a way to actually do it without ugly hacks. 
>

I doubt there is a way to get that from the error message itself and I'll 
strongly object to adding logic like parsing the error message to figure 
that stuff out. Especially since the traceback is pretty clear and it's not 
as if one were searching through 5000 fields in a model… Also, this error 
is the result of putting data into the database without prior validation 
which is a bad idea anyways…

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

[Florian Apolloner]

On Thursday, August 22, 2013 6:43:39 AM UTC+2, Ben Finney wrote:
>
> This could be done by having Django's database interface catch the 
> error, and chain a new exception from that one: 
>

Knowing the model alone is imo pretty useless since that's in the traceback 
anyways; also what you suggest has to happen way up higher the chain; 
otherwise model wouldn't be known…

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

[Florian Apolloner]

On Friday, August 23, 2013 4:52:16 AM UTC+2, Ben Finney wrote:
>
> I didn't see a traceback. The OP gave only the error message. How do you 
> know they are getting the model name? 
>

If he had shown his full traceback you'd see how django came to execute 
this query; when it reaches your code you'll see which model you tried to 
insert/query there…

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecating ipaddressfield

[Florian Apolloner]

On Sunday, August 25, 2013 12:07:11 AM UTC+2, Michael Manfre wrote:
>
> IPAddressField is meant for IPv4 addresses and GenericIPAddressField is 
> for both IPv4 and IPv6. Most backends define different database data types 
> for each of those fields. E.g. mysql is char(15) vs char(39). Forcing the 
> larger data type on users doesn't make sense. 
>
 
It does make sense; storage is usually not such a concern and it's time 
that people start supporting IPv6; Even if we don't remove it now we should 
make the docs very clear about which field to use (basically you always 
want the generic variant). Also the normal IPAdressField has a few issues 
on postgres if it's nullable, so it's a nogo anyways if you want this to 
work over more databases… I don't see any strong reason why we shouldn't 
deprecate it.

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

get_cache and multiple caches

[Florian Apolloner]

Hi,

so when reviewing https://github.com/django/django/pull/1490/ I once again 
ran over an issue with our current caching implementation: Namely get_cache 
creates a new instance every time which is kind of suboptimal if you don't 
store it as module level variable like we do with the default cache. Are 
there any objections to make get_cache store those instances in a dict and 
return those on request? It shouldn't cause to much problems, since the 
current cache infrastructure expects you that you can share those objects 
over multiple threads and requests anyways [And for caches which don't 
support it like pylibmc we use threadlocals…]. Changing how get_cache works 
could significantly reduce connections to the cache server depending on how 
your views/templates are written.

Thoughts?

Cheers,
Florian 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Florian Apolloner]

Hi,

On Sunday, September 1, 2013 4:34:54 AM UTC+2, Curtis Maloney wrote:
>
> I've a possible solution - 
> https://github.com/funkybob/django/compare/simple_caches
>
> Basically, the existing API and behaviours are still available through 
> get_cache, but you can avoid duplicate instances of caches using 
> django.core.cache.caches[name]
>

As noted on the ticket (https://code.djangoproject.com/ticket/21012), I 
think this needs some more brainstorming (preferably on this ml) before we 
introduce a new pulbic API to access a cache. My main concern is: does it 
even make sense to share the cache connection between threads? eg what 
happens if two threads want to read a value from the cache, will one thread 
block till python-memcached returned the value for the other thread?

Cheers,
Florian 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Florian Apolloner]

Hi,

On Monday, September 2, 2013 6:39:09 AM UTC+2, Curtis Maloney wrote:
>
> Whilst it's conceivable  some cache backend will have the smarts to 
> multiplex requests on a single connection, I suspect that's more the 
> exception than the case.
>

Agreed
  

> Obviously, the default would be one per thread.
>

This is what the pylibmc backend does already and memcached should do too; 
the db backend is per thread too since it uses Django's db connection. We 
might wanna supply a building block so that not everone has to implement 
their own variant of the threadlocal stuff :)  [Locmem and filebased 
shouldn't cause any issues either way and can stay as they are I think]

Of course, that could be simplified by just always creating a new instance 
> when more than just a name is provided. [or a "force new" keyword is 
> passed].
>

I wonder how common it is to supply more than just the name to get_cache 
(aside from tests maybe), I am +0 for making get_cache return "cached" 
instances for a single name and construct new ones for the other cases (+ a 
force keyword if someone really wants the old behavior).

Cheers,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance optimisation documents, ticket 20877

[Florian Apolloner]

Hi Daniele,

On Friday, September 13, 2013 4:18:05 PM UTC+2, Daniele Procida wrote:
>
> Any further comments would be welcomed. There's some disagreement about 
> the appropriateness of the last section, <
> https://github.com/django/django/pull/1463/files#L5R318> so it would be 
> particularly usefukl to have some further opinion on that. 
>

Personally I'd remove it completely for the following reasons:
 * Especially newcomers tend to think that they need the most performant 
system and will probably try to switch out whatever they can, even if not 
necessary; and switching to PyPy might not be a good idea in most of those 
cases ;)
 * This dual-import of libraries where you try to select the most 
"efficient" versions quite often results in issues for those versions which 
didn't get used by the developer. As an example simplejson and json are not 
100% compatible and I think had issues with the c-variant of Elementtree 
too. Especially when it comes to unicode/str handling the c-variants tend 
to have some ugly edge cases (at least in my experience -- this is not a 
problem though, but you have to test all variants…). Imo it's most of the 
times easier to just develop against one, if you need the speed and 
verified that the c-variant actually offers an improvement use that and 
__require__ it.

Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Florian Apolloner]

On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote:

> What if instead of calculating the PBKDF2 hash of the password, we'll 
> calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking 
> passwords wouldn't depend on their length, and we wouldn't even have to 
> place a limit of 4096 characters on passwords-- An attacker could try a 
> 1MB-long password but it would slow us down the same amount as trying 
> "123456" would. 
>

PBKDF2 takes long by design… A better long term solution would be to rate 
limit password attempts…

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Florian Apolloner]

Hi Ram,

On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>
> Florian, I'm not sure that you read my message carefully enough. I'm *not 
> *proposing to reduce the time that PBKDF2  takes to hash.
>

By replacing the password with a hash before running it through PBKDF2 you 
are reducing that time for every password longer than the hash… And given 
the way PBKDF2 works you'll reduce it by quite a bit (note that all of this 
only applies to passwords longer than the hash, so it's probably pretty 
academical). Either way, we'd at least need a new hasher class since it 
would be backwards incompatible. Independent of that we'd have to evaluate 
if pre-hashing the password could make  PBKDF2 less secure (probably not to 
likely, but who knows).

Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

[Florian Apolloner]

Hi,

there are a few things which worry me about this patch (aside from the note 
from charettes). You write "and the DoS attack vector is avoided" which is 
not true, hashing functions are by design CPU-intensive so you are not 
avoiding DoS, even if hashing now consistently takes less (for short 
passwords more) time you still can DoS a site. Avoiding the DoS vector in 
this case would mean something like rate limiting… And curious, why are you 
not able to run the tests, it's as simple as "cd tests; ./runtests". No 
offense, but copying those few lines and adding a broken test isn't really 
helping that much…

I am also not sure if we would want to use this as default hasher at all, 
the current default isn't that bad and puts a limit onto the hashing like 
yours does (granted, a bit later timewise, but as I said before changing 
the hash function is not a longterm solution).

Cheers,
Florian

On Sunday, September 15, 2013 10:27:16 PM UTC+2, Ram Rachum wrote:
>
> Submitted patch:
>
> https://code.djangoproject.com/ticket/21105#comment:1
>
> On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote:
>>
>>
>> On Sep 15, 2013, at 2:59 PM, Florian Apolloner <f.apo...@gmail.com> 
>> wrote:
>>
>> Hi Ram,
>>
>> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>>>
>>> Florian, I'm not sure that you read my message carefully enough. I'm *not 
>>> *proposing to reduce the time that PBKDF2  takes to hash.
>>>
>>
>> By replacing the password with a hash before running it through PBKDF2 
>> you are reducing that time for every password longer than the hash… And 
>> given the way PBKDF2 works you'll reduce it by quite a bit (note that all 
>> of this only applies to passwords longer than the hash, so it's probably 
>> pretty academical). Either way, we'd at least need a new hasher class since 
>> it would be backwards incompatible. Independent of that we'd have to 
>> evaluate if pre-hashing the password could make  PBKDF2 less secure 
>> (probably not to likely, but who knows).
>>
>>
>> According to Thomas Porin in the context of bcrypt pre-hashing the 
>> password is fine (and we already do this in Django 1.6). I see no reason 
>> the same wouldn't hold true for PBKDF2.
>>
>> -
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
>> DCFA 
>>
>>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Question about new tests

[Florian Apolloner]

Hi Justin,

many core developers haven't been at DjangoCon US, so would you mind to 
summarize a few things like: What is the roadmap, how do you plan to tackle 
things; who is involved + whatever else you think would be nice to know for 
someone who more or less heard the first time of this from your mail here.

Thanks & regards,
Florian

On Tuesday, September 17, 2013 7:55:08 PM UTC+2, Justin Holmes wrote:
>
> I'm working on the #unsetting project (ie, making all of Django's 
> internals work without having to import the settings global).
>
> We have two key areas that now seem to work without running settings: mail 
> and templating.
>
> I want to demonstrate these with tests.  Where shall I put these tests?
>
> 1) Alongside the respective tests for these features (ie, tests.mail)?
> 2) As a regression test (ie, also in tests.mail, but demonstrating that 
> the inane errors no longer appear)
> 3) Alongside the unsetting config?
>
> -- 
> Justin Holmes
> Chief Chocobo Breeder, slashRoot
>
> slashRoot: Coffee House and Tech Dojo
> New Paltz, NY 12561
> 845.633.8330 
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Florian Apolloner]

Hi,

On Wednesday, September 18, 2013 1:29:25 PM UTC+2, Curtis Maloney wrote:
>
> 1) Can we share "ad-hoc" caches -- that is, ones created by passing more 
> than just the CACHES alias.
>
Imo no, you probably have a good reason if you create ad-hoc ones 

> 2) What to do about django.core.cache.cache ?
>
Has to stay for now, same as django.db.connection
 

> A separate approach is to introduce a new API to provide access to the 
> shared, pre-configured caches, and retain get_cache for the old, ad-hoc, 
> non-shared caches.
>
I think it would be sensible if that API would mimic django.db.connections

Florian.

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Default session data serializer doesn't support extended data types

[Florian Apolloner]

Hi Davide,

On Thursday, September 19, 2013 4:46:44 PM UTC+2, Davide Rizzo wrote:
>
> The inconvenience is breaking compatibility with all third party apps that 
> rely on storing extended data types (such as those supported by 
> DjangoJSONEncoder) with the default settings. Properly serializing datetime 
> (possibly tz-aware) can be hard, and changing the default puts the burden 
> on third party apps coders.
>

In all fairness, we didn't just break third party apps, we broke our code 
too… We always said that security will trump inconvenience, the only 
inconvenience I can see here is that users have to switch to the pickle 
backend if they use old third party apps (although only for those which use 
the session at all…).

They would have the option to either add two complexity layers (properly 
> serializing/deserializing datetime objects, and not breaking compatibility 
> with the previous versions of the same app), or to break compatibility with 
> Django default settings.
>

We added those two complexity layers for our code too, it was merely one 
extra line to ensure backwards compatibility.
 

> I think the option of reverting the default to pickle should be also 
> considered.
>

No, this has been discussed and security will trump minor inconvenience.

Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Florian Apolloner]

On Friday, September 20, 2013 8:58:25 AM UTC+2, Curtis Maloney wrote:
>
> I guess the remaining question to address is :  close()
>
Leave it as is I think.
 

> Thinking as I type... it wouldn't hurt, also, to allow a cache backend to 
> provide an interface to a connection pool, so the manager can play friendly 
> with it.  If it doesn't have one, fall back to an instance-per-thread... 
> this would require still hooking request complete, but not so much for 
> "close" as "release".
>

If it can be added afterwards without to much issues, I prefer to leave 
APIs for connection pools out for now; since it will make the patch 
smaller, which makes it easier to merge.

Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Default session data serializer doesn't support extended data types

[Florian Apolloner]

On Friday, September 20, 2013 10:24:00 AM UTC+2, Davide Rizzo wrote:
>
> - using the raw JSONEncoder by default is not offering any significant 
> security advantage over using an extended encoder. I feel like it's going 
> to discourage coders to use JSONSerializer at all.
>

Btw could it be that you are mixing out Encoder and Serializer? Or are they 
supposed to be the same, if not please add import names, so one knows which 
and from where you mean. Personally I don't see any improvement in using an 
extended encoder -- in the end it's just more work for us and people 
complaining why we don't support their $magical class. In most if not all 
cases storing full objects in the session is wrong; what we could have 
supported would be timestamps, but those are storable as utc seconds easily 
enough… Why would the current status be discouraging anyone?

But I believe this decision didn't give a realistic weight to the impact on 
> the community.
>

I still fail to see the issue; 3rd party projects have to adapt, this is 
why we have deprecation paths and accelerated paths for security related 
stuff. The net result is the same, at some point you will be forced to use 
a new feature (although in this case a bit sooner, but again: security and 
you can reenable the old default); eg newforms->forms, Model.Admin class to 
newadmin etc. And those last two literally affected everyone, that's what 
I'd call impact; the current impact is __only__ on people which do use the 
session (granted that's probably everyone) and did put complex data into 
the session. This pretty much narrows the list down to a percentage of the 
whole usergroup, when I audited my projects for this switch I had a few 
datetimes saved, although most of them saved them as integers already 
(which makes sense from a performance standpoint).

So all in all I think 3rd party authors will adapt without any problems 
since they are most of the time not affected, or they'll have to change a 
few lines of code… Can you provide a big list of 3rd party apps storing 
Models etc in the session?

Regards,
Florian

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Admin-Actions also in the object details view

[Florian Apolloner]

There is already a ticket for this request: 
http://code.djangoproject.com/ticket/12090

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: 1.2 beta?

[Florian Apolloner]

Hi,

I am far away from beeing a commiter, but would like to get some
thoughts about the AnonymousUser permission checks written down (I'll
keep it short to not hijack this thread): By the time I moved
permission checks to the backends I didn't thought much about
anonymous users (I guess that was bad, but by that time I never needed
it). The current situation is as follows: If we pass the AnonymousUser
into the backend we will berak any code that relied on the User object
to be in the database [disclaimer: as far as I can tell, we always
said that the programmer should check if the User is authenticated or
not, but as we never passed AnonymousUser into the backends I doubt
someone checks that. Though I guess most people used the backends to
check against ldap etc, so this would be a non issue…]. If you are
okay with that, I am +1 on whatever needs to be done to get this
feature in.

Aside from that I would like to know what the status on admin-ui is,
as Janis worked on that lately. That said I don't see any real reason
why we would need to postpone the beta.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: AnonymousUser has_perm/has_module_perms function check authentication backends

[Florian Apolloner]

On Jan 26, 3:19 pm, Harro  wrote:
> - If the default backend always returns false for anonymous users then
> pluggable apps have to either expect some row level permission system
> is installed and used or don't check permissions for things that an
> anonymous user can access.
Why do they have to expect a row level permission system to be
installed? The ModelBackend would always return False for anonymous,
so everything would stay as it is…

> I think the best solution is to add anonymous user permissions as
> proposed by me a bit up, but only actually check them if a settings
> flag is set to True (with a default on False). If it's not set it will
> simply return False for anonymous users, otherwise it will check the
> permissions.
I am -1 on that, using `supports_anonymous_users` is way better and
allows a cleaner upgrade path (as every backend will have to support
anonymous users sooner or later)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: AnonymousUser has_perm/has_module_perms function check authentication backends

[Florian Apolloner]

> some documentation should also be added.
+ Tests

The question is, whether we want `supports_anonymous_users` to go away
at some point or stay forever (I would prefer if it went away and
every backend had to support anonymous users; then the patch would
need the usual deprecation warnings…).

Cheers, Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: AnonymousUser has_perm/has_module_perms function check authentication backends

[Florian Apolloner]

> I would then write a simple decorator which checks the backends for
> that flag to determine if we should do a login_required or has_perm
> check.
> Because a real pluggable app would want to support both :)
No it wouldn't. It would either use the permission system or the
decorator for login_required (which would require an extra field on
the model…). The checking for `supports_anonymous_users` in 3rd party
apps doesn't make sense as backends which supporting it, don't
necessarily need to provide a permission system for that app… (For one
system I take the common permissions from ldap and another app uses a
custom in database system, all running of the same Django install)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: HTML 5

[Florian Apolloner]

> I'd like to see using the new input types (eg  for
> email form fields). Since this doesn't break any backwards compatibility
> it shouldn't hurt to include this.
It is backwards incompatible, every current app which is outputting
valid html/xhtml will stop beeing valid; eg this document doesn't
validate without a html 5 doctype:
http://www.w3.org/TR/html4/loose.dtd;>



Test










-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

#12804 - decorating admin views marked as invalid

[Florian Apolloner]

Hi,

first of all, I agree with Luke that it's hard to fix this if it's
possible at all [1]. The only real problem I have with this ticket
beeing closed is the backwards compatibility issue. Decorating admin
views worked just fine in 1.1 and r11660 broke it (At least I hope it
worked in 1.1, but as the admin view wasn't decorated at all there, it
should have worked). Imho we should at least consider documenting it,
and maybe mention it in the release notes, as custom admin code might
break by an upgrade from 1.1 to 1.2.

Cheers,
Florian

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12804 - decorating admin views marked as invalid

[Florian Apolloner]

Hi,

thx for your quick response, I'll update the ticket and reopen it (I
hope that's okay in this case…)

Cheers, Florian

On Feb 8, 3:05 am, Luke Plant <l.plant...@cantab.net> wrote:
> Ignore my last post - my 'fix' only fixes one corner case, and not a
> very useful one either.  I've got it fairly sorted out now, I'll post
> tomorrow about this.
>
> Luke
>
> On Sunday 07 February 2010 21:11:42 Luke Plant wrote:
>
>
>
> > On Sunday 07 February 2010 10:45:29 Florian Apolloner wrote:
> > > Hi,
>
> > > first of all, I agree with Luke that it's hard to fix this if
> > > it's possible at all [1]. The only real problem I have with this
> > > ticket beeing closed is the backwards compatibility issue.
> > > Decorating admin views worked just fine in 1.1 and r11660 broke
> > > it (At least I hope it worked in 1.1, but as the admin view
> > > wasn't decorated at all there, it should have worked). Imho we
> > > should at least consider documenting it, and maybe mention it in
> > > the release notes, as custom admin code might break by an upgrade
> > > from 1.1 to 1.2.
>
> > I've thought some more about it, and I think you are right.
> > Descriptors hurt my head, and descriptors plus decorators and
> > decorator decorators (like auto_adapt_to_methods) are particularly
> > bad!
>
> > Python 3.0 is actually more helpful here, as it does away with
> >  unbound methods - they are just functions. That helps to clarify
> >  that your pattern (as on the ticket) is not actually strange, and
> >  ought to work - SomeClass.method is just a function, and it is the
> >  function as originally defined, so it ought to work as an
> >  assignment in that context.
>
> > Anyway, could you try the attached patch?  My experiments suggest
> >  it should fix the issue, but coming up with it hurt my brain too
> >  much for me to do any more!
>
> > Luke
>
> --
> "Yes, wearily I sit here, pain and misery my only companions. And
> vast intelligence of course. And infinite sorrow. And..." (Marvin
> the paranoid android)
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12804 - decorating admin views marked as invalid

[Florian Apolloner]

On Feb 8, 2:44 pm, Luke Plant  wrote:
> What do people think?
+1 for everything which removes the magic from auto_adapt_to_methods.
Can't say much about the backwards incompatiblity issue, cause I don't
care ;) Of course it would be nice, but given the options I would just
document it and live with it…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: GSoC: App Loading

[Florian Apolloner]

I don't have much to say, as Alex pretty much covered it; but that's
the list:

 * Assume an app1 which requires another app2 (and has some
ForeignKeys to it). Currently that's easy; just import the model and
ForeignKey it. How would those imports look like in your case (eg to
which models would app1 link)?! [This problem could be solved by
adding an app column to the models and patch all queries to just
select from the current app. And yes alex's link covers that, but a
reuseable app doesn't know to which app (instance) it will get linked
-- yet another setting to the rescue; ah no a whole dict of settings,
to specify which app instance the setting belongs to…]
 * What happens to login procedures etc? Eg one of the auth
middlewares would stick an user object onto request.user and most of
the apps won't be able to link to it, as their foreign keys point to
the wrong instance of the auth app.

While I am more than happy to see improvements in the app loading area
(customisable names etc…), I don't like the idea of multiple instance
deployments like you/alex propose (especially if that means the same
set of models being installed twice/trice…; I however do like the way
the admin takes).

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 delete() clear() behavior and you.

[Florian Apolloner]

Uhm, your fix fixes the problem at the wrong end. This can and should
be supported by the database's native capabilities. This would be the
ticket for it: http://code.djangoproject.com/ticket/7539

But I like your imagination, or is there more truth behind your story
than you'd admit?

Cheers,
Florian Apolloner

On Apr 5, 8:06 pm, Kevin howerton <kevin.hower...@gmail.com> wrote:
> Hi.
>
> So I came across a use-case for wanting to delete content (which
> django doesn't really handle exactly to my liking).  I just got back
> from a vacation in vegas and noticed in a drunken stupor I had posted
> some pictures on my blog that should I really shouldn't have 
> (http://i.imgur.com/5oj15.jpgSFW).
>
> Anyhow, currently django's only delete behavior (to my knowledge) is
> to delete all objects related from a reverse relation.  I think it
> would be preferable to actually delete only objects that have NOT NULL
> **and** no default set.
>
> Right now clear() sort of fills some of the void for what you need to
> do prior to deleting an object, but it fails to handle DEFAULT
> conditions.
>
> I realize changing the default behavior of the delete() method is
> probably out of the question... and there are a bunch of tickets open
> asking for cascades and what-not, that will hopefully one day fill the
> void.  clear(), however, *should* handle DEFAULTS in the same way it
> handles null=True.
>
> Also, I wrote a mix-in class that fixes the delete method to work as I
> believe it should... for those of you with similar use-cases.  Anyone
> have any feedback on it?
>
> ps.  I didn't really murder a hooker in vegas (I don't even have a
> blog), just felt that I should provide a relevant use-case ;)
>
> from django.db.models.fields import NOT_PROVIDED
> from django.contrib import admin
>
> class ClearOnDelete(models.Model):
>     def delete(self):
>         related_objects = self._meta.get_all_related_objects()
>         for object in related_objects:
>             accessor_name = object.get_accessor_name()
>             related_accessor = getattr(self.__class__, accessor_name)
>             related_accessor_instance = getattr(self, accessor_name)
>
>             if related_accessor.related.field.default is not
> NOT_PROVIDED:
>                 for relation in related_accessor_instance.all():
>                     setattr(relation,
> related_accessor.related.field.name,
> related_accessor.related.field.default)
>                     relation.save()
>             elif related_accessor.related.field.null:
>                 for relation in related_accessor_instance.all():
>                     setattr(relation,
> related_accessor.related.field.name, None)
>                     relation.save()
>         super(ClearOnDelete, self).delete()
>
>     class Meta:
>         abstract = True

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 delete() clear() behavior and you.

[Florian Apolloner]

Hi,

On Apr 6, 12:19 am, Kevin Howerton  wrote:
> I only killed one hooker, but it was really small so I don't know if it 
> counts.
Hmmm…

> The problem with those patches though are that they don't appear
> (correct me if i'm wrong) to account for handling different deletes
> per reverse relation.  You really need to have a more granular
> approach.  If an object has two parents pointing at it; one with NULL,
> and one with a DEFAULT set... how would you be able to have it handle
> the different behavior on both?
I won't; the database takes care of it, if I delete the object the
foreignkey from parent1->object will get set to null and the
foreignkey from parent2->object will get set to the default. (see
http://www.postgresql.org/docs/8.4/static/ddl-constraints.html#DDL-CONSTRAINTS-FK
for more info, I guess it becomes clearer when you see it in a non orm
context)

> Also, regardless of whether an elegant solution that relies on the
> database exists for the delete method, I feel like the clear method
> should be patched to match the behavior of the code I posted.
Yes, I hope this will land together with ON_UPDATE/ON_DELETE support.

I hope I didn't confuse you more than necessary ;)

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Wherein Benjamin Franklin answers questions pertaining to the Django development process

[Florian Apolloner]

On Apr 20, 10:38 am, Andrew Badr  wrote:
> Umpires? Strike three off a curveball?
+1, though I'd quoted big bang theory, no need for a umpire, bdfl
should be more than enough!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: High Performance solutions are needed to do things like urlretrieve

[Florian Apolloner]

On Jul 16, 1:51 pm, shi shaozhong  wrote:
> Any solution for this?

Yes; plz post usage questions to django-users.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: request.is_ajax() and hidden iframe kludge => request.is_framejax()?

[Florian Apolloner]

Hi,

On Jul 16, 7:25 pm, David De La Harpe Golden
 wrote:
> People doing ajax have probably hit the "XMLHttpRequest doesn't do file
> uploads (at least not non-browser-specifically), use a hidden iframe
> kludge or flash" issue. Anyway, maybe that will change one day

It's already changing, modern browsers can do what you want (google
for html5 file uploads). I don't see any reason to support something
like you suggest; we should support standards and not workarounds
(just my opinion). Imo the best way currently is to use the new apis
and fallback to flash or whatever if needed (I actually guess flash is
the best fallback here).

> The hidden-iframe requests will AFAIK show up with request.is_ajax() ==
> False to django.  So a "done thing" (I think) to distinguish between the
> non-ajax and hidden-iframe requests seems to be to just have an extra
> field to act as a pseudo-header, i.e.
>
> 

This input field is easily fakeable. An attacker can't fake your
browsers XHR requests, which makes request.is_ajax somewhat secure and
trustable. I don't see how your solution could achieve that.

> or "?X-Requested-With=ScriptedIFrame"

Same as above.

> It might nonetheless be nice for django to have some support for
> checking for some particular pseudo-header.

-1, mostly due to the fact that it's something most people won't need
and you can easily inject that info using a middleware yourself. Hence
I am for solution A.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: djangoproject.com hiccup: community section configured wrong

[Florian Apolloner]

On Jul 16, 11:20 pm, Jeremy Dunck  wrote:
> I looked just now, and it looks like the importer ran incorrectly for
> one run -- from "My thoughts on DjangoCon Berlin 2010" to "First Post"
> on the run at July 9, 2010 at 4:04 PM.

Aren't those all from http://nomadblue.com/? Maybe Hector Garcia's
feed was broken (eg contrib.sites was still set to example.com).

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: request.is_ajax() and hidden iframe kludge => request.is_framejax()?

[Florian Apolloner]

On Jul 17, 11:29 am, Gregor Müllegger  wrote:
> I think Florian meant that its not possible to change HTTP headers by
> Javascript XSS attacks (or am I wrong here as well?).
Exactly.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: CSRF Middleware/SSL/Firefox 3.6.8 bug

[Florian Apolloner]

On Aug 27, 12:20 pm, Mat Clayton  wrote:
> Any
> chance of getting some of the core dev's to think about removing additional
> SSL checks, as FF 3.6.8 is a pretty major browser to support and this is
> likely to only get worse as adoption increases. Is the additional security
> worth the trade off?

I doubt that. It will only get worse if users use crappy addons; it's
not a firefox problem per se…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12012 Logging: request for comments

[Florian Apolloner]

Hi,

On Sep 25, 1:25 pm, Jannis Leidel  wrote:
> Given the fact that the current implementation of the app cache does quite a 
> few hoops to make it possible to implicitely import the models modules by 
> iterating over INSTALLED_APPS, I'd like to propose to rather move the logging 
> initialization to the app class initialization, instead of introducing 
> another place of implicite importing -- to prevent having ambiguous locations 
> for app specific code execution.

I agree, the only problem I see (not having looked at the app refactor
branch yet + having no idea in which direction it is heading) is that
if the app class is allowed to import other stuff. Cause this might
easily end in models (or whatever) being imported and as a result we
can't guarantee that it would happen as early as startup.py (though if
someone imports critical stuff there we might get the same unwanted
results). Btw: Is there a wiki page describing exactly what the branch
solves currently and which direction it will be heading?

Another question that came into my mind, after reading
http://www.reddit.com/r/Python/comments/ddkal/django_vs_web2py_what_do_you_use_and_why/c0zmxqz
(actually the whole thread, but that's the relevant post): Is there an
easy and nice way to attach some extra info (eg request) to the
logging info? Especially since I can't pass the request down all way
to 3rd party apps; but I still want it to be logged in context of the
current request (for easier debugging etc). The example in the reddit
link isn't really convincing me -- especially since django doesn't put
the request and other info into threadlocals.

Regards,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12012 Logging: request for comments

[Florian Apolloner]

Hi,

On Sep 26, 2:55 pm, Russell Keith-Magee 
wrote:
> Yes, there is, and the logging calls I've included in the patch on
> #12012 make use of it. All the logging calls take an 'extra' parameter
> which can be used to insert relevant context into the logging call,
> and can be used in a custom formatter. In all the logging calls
> registering 4XX and 5XX messages, I've included the current request as
> extra context.

I am aware of those; but let's imagine a 3rd party library which has
no idea what a request is. In my logs I still want to know the request
(even if it's just for formatting purposes…); so I am looking for a
way to attach request specific info to __all__ logging calls done in
one request __without__ adding it to the logging call.

Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12012 Logging: request for comments

[Florian Apolloner]

On Sep 26, 4:13 pm, Jannis Leidel <jan...@leidel.info> wrote:
> On 26.09.2010, at 14:45, Florian Apolloner wrote:
> Not sure I understand the problem, the app instances are initialized by the 
> app cache, at the same time as the proposed logging patch would import the 
> startup modules.

Jupp, my mistake -- nevermind.

Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Meta.required_together

[Florian Apolloner]

Please post usage questions to the users list. This is already doable
with model validation.

Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Meta.required_together

[Florian Apolloner]

On Sep 27, 9:22 am, "David P. Novakovic" 
wrote:
> Is it? I read this as different to anything in the ORM.
Well either way; he could have been more specific which stuff he is
talking about (remember the only classes having Meta are Modelform and
Model -- at least does are the two where I use it on a regular base)

> This is about conditionally requiring a second field if one is filled
> out. Normally it would be done at the JS level.
JS level + Server level

> I think it's a good idea, assuming I haven't missed something that
> already does this.
Yes, form.clean and the model validation can do it.

> I can't help thinking this is part of a much larger problem though.
> That problem is multifield validation. I think we'd have to address
> that issue first before working on this specific case that is probably
> the simplest.
Why is multifield validation a problem? I works (tm).

Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Increasing the usefulness of ModelAdmin.get_formsets

[Florian Apolloner]

Hi,

in one of my projects I would like to alter the inlines in the admin
on a per request basis. So I though I could use get_formsets to drop
unneeded inlines; this isn't the case :( get_formsets has to return
the same inlines in the correct order (eg
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L789
requires this). Maybe we could add a method like
get_formsets_with_inlines (better name anyone) which (by default)
would just return zip(self.get_formsets(request),
self.inline_instances). This would increase the usefulness of
get_formsets quite a bit imo. Any thoughts?

Cheers, Florian Apolloner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Permission support for admin inlines

[Florian Apolloner]

Hi,

the permission checking should be doable if my ideas from
http://groups.google.com/group/django-developers/browse_thread/thread/bfad2774ff7c357b#
get in. So if someone can come up with a proper api as suggested by
Russell I'd be happy to help codewise (this way we could even work
around the DDN, as it leaves the user the choice to implement
permission checks the way he wants to).

Cheers, Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: country and states list in registration form

[Florian Apolloner]

On Nov 16, 6:29 pm, hemi19  wrote:
>  If anyone know plz help me

Plz post usage question to django-users!

Thx, Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: ModelForm + MultiValueField = form.save() problem

[Florian Apolloner]

Hi,

Plz post usage questions to django-users. This group is about the
development of Django itself.

Cheers, Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

[Florian Apolloner]

+1 on fixing the the verbose_name_plural usage, as __every__ user with
an activated language (that is: aside from english) will run into it.
Regarding the double entry in the context: I am +1 on leaving
object_list in there. This way middlewares (or other generic view
mixins) could act on object_list and don't have to specialized for the
context_name which they can't know.

Cheers, Florian

P.S.: Sending this from the new groups interface; I am really sorry if
that sends HTML, will try to turn that off…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

[Florian Apolloner]

Hi,

Option (5) sounds great; but if you want backwards compat option (1)
is the only way to go. cache_page isn't the only decorator affected by
this problem; I could imagine there are many decorators in 3rd party
apps which try to alter the response. So the question is how much code
will we break if we not go with option (1) and does the backwards
policy allow that at all?

That said I am -1 on option (2) and -0 on (4) since it only fixes the
decorator and not the problem per se.

Cheers, Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

[Florian Apolloner]

Hi,

On Jan 6, 12:02 am, Russell Keith-Magee 
wrote:
> There are no backwards compatibility concerns here. We're talking
> about the class-based generic TemplateView.

Sorry, I just noticed now, that the current function based views are
still function based and not wrappers around the class based views.
Then option (5) sounds great :)

Cheers, Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

r15401 and removing star imports

[Florian Apolloner]

Hi,

I think the "url" function should get added to the imports in
http://code.djangoproject.com/changeset/15401 since many people use it
by now. Any thoughts or objections?

Cheers, Florian

-- 
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: r15401 and removing star imports

[Florian Apolloner]

In previous Django versions it was necessary to import those; that's
no longer the case.

Cheers, Florian

On Feb 5, 11:21 am, lucky  wrote:
> Look at 
> thehttp://code.djangoproject.com/browser/django/trunk/django/conf/urls/d...
> .
> There are __all__ = ['handler404', 'handler500', 'include',
> 'patterns', 'url']
> It seems as you forgot to add 'handler404' and 'handler500'.
> Whats about handlers?
>
> On Feb 4, 10:50 pm, Carl Meyer  wrote:
>
> > Only reason I didn't add it to the import is that it's not used in any
> > of the commented sample lines. But the better solution is to import it
> > and demonstrate using it.
>
> > Done inhttp://code.djangoproject.com/changeset/15415
>
> > Thanks for the suggestion.
>
> > Carl

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

Re: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off

[Florian Apolloner]

Hi,

On Mar 5, 9:30 am, akaariai  wrote:
> on(primary_key) id, val1, ... from table order by primary_key this
> would solve the problem.

Is "DISTINCT ON" part of the SQL standard at all?

Cheers, Florian

-- 
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: uWSGI documentation

[Florian Apolloner]

On Apr 2, 1:23 pm, James Pic  wrote:
> I think it should because it's easier, safer, faster and more secure
> than flup or mod_wsgi. Also, it made my sysadmin life really easy and
> that's something cool to share with the community.

+1 on more docs, since uwsgi is quite useable by now. But please leave
claims like faster etc out if you can't back it up. Especially since
david cramer showed on pycon that it makes no difference for them and
both are equal... (and yes I do consider disqus as a relevant
benchmar ;))

Cheers, florian

-- 
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: Ticket #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allows exceptions to reach the user

[Florian Apolloner]

Hi,

On Apr 20, 8:00 am, legutierr  wrote:
> modelform.is_valid() fails to anticipate database integrity errors
> when those errors involve any fields that are not part of that form
> itself.

That is wanted behaviour, eg consider my workflow:

class SomeForm(ModelForm):
  class Meta:
exclude = ['user']
model = …

Now in the view I do this:
  if form.is_valid():
instance = form.save(commit=False)
instance.user = request.user

Now assume user is a not nullable Foreignkey. In that case the
is_valid on the form would throw an error -> BAD. The issue you
describe (fields not beeing run through model validation if not on the
form) got "added" after adding model validation, since the code I
describe is pretty common and would have broken all those apps. I
suggest you read the history on the development of modelvalidation;
especially: 
http://groups.google.com/group/django-developers/browse_thread/thread/cee43f109e0cf6b

Btw, just my humble opinion: If you exclude fields from the ModelForm
it's your duty to check for valid data.

Regards,
Florian

-- 
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: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

[Florian Apolloner]

On Apr 23, 7:23 am, Carl Meyer  wrote:
> This is really giving me the itch to build a new context-manager-based
> idiom for ModelForm validation in 1.4 that would allow modification of
> the to-be-saved object within the context manager and always perform
> full validation of the model on the way out. This idea was raised
> briefly in discussions right around the time model-validation landed,
> but was tabled due to the need (at that point) to support Python 2.4.
> Seems like that could neatly resolve all these knotted issues around
> validation of partial ModelForms.

Nice, something like that would be great. One of my bigger problems
regarding modelforms lately was that I wanted something like: "If you
don't fill out the user it's set to the current user", in the admin,
with as little modifications as possible. So save_model sounded like
the right spot but modelvalidation will make the form invalid (I want
the user field on the form…). Still no idea on how to solve that
properly and nicely; if the context managers can take care of that too
(though I doubt it since I can't change the is_valid call in the
admin) I am all in for it. Btw any threads around that subject I could
read?

Regards, Florian

-- 
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: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

[Florian Apolloner]

Hey Carl,

On Apr 23, 5:55 pm, Carl Meyer  wrote:
> http://groups.google.com/group/django-developers/msg/3014f29c5125653ais
> where it was briefly mentioned by Lukasz, I haven't seen any discussion
> since.

Thx

> In any case, if we have this, I could see switching the admin to use it,
> and perhaps adding an overridable method that's called from within the
> context manager, to allow you to complete/tweak the model instance
> before full validation is run. Seems like this would solve your problem?

Hell yeah, that would solve all of my problems :þ

Regards,
Florian

-- 
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: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

[Florian Apolloner]

On Apr 23, 7:12 pm, Florian Apolloner <f.apollo...@gmail.com> wrote:
> > In any case, if we have this, I could see switching the admin to use it,
> > and perhaps adding an overridable method that's called from within the
> > context manager, to allow you to complete/tweak the model instance
> > before full validation is run. Seems like this would solve your problem?
>
> Hell yeah, that would solve all of my problems :þ

At least if I can defer validation of some fields on the form to the
end (in my case the user)

-- 
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: logging view errors

[Florian Apolloner]

Hi,

On May 10, 11:33 pm, Shawn Milochik  wrote:
> You and someone on django-users both told me about process_exception,
> which I had been unaware of. It looks perfect for what I need.

There is also a signal for it: 
http://docs.djangoproject.com/en/dev/ref/signals/#got-request-exception
if you don't want to write the middleware ;)

-- 
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: Error importing template source loader /media/OTHERS/wb development/python/codes/django/django_bookmarks/../django_bookmarks/templates: "Import by filename is not supported." Request Method:

[Florian Apolloner]

Hi,

please post usage questions on django-users, not django-developers.
This mailing list is about the django development itself…

On May 15, 4:09 pm, kracekumar ramaraju 
wrote:
> I am getting this error
>
> Error importing template source loader /media/OTHERS/wb 
> development/python/codes/django/django_bookmarks/../django_bookmarks/templates:
>  "Import by filename is not supported."
>
>  Request Method:
>
> My views.py
> # Create your views here.
> from django.http import HttpResponse
> from django.template import Context
> from django.template.loader import get_template
> def main_page(request):
>     template=get_template('main_page.html')
>     variables=Context({
>     'head_title':u'Django Bookmarks',
>     'page_title':u'Welcome to Django Bookmarks',
>     'page_body':u'Where     you can store and share Bookmarks'})
>
>     output=template.render(variables)
>     return HttpResponse(output)
> ~                                
> #templates/main_page.html
> 
>     {{ head_title }}
>     
>     
>         {{ page_title }}
>         {{ page_body }}
>     
> 

-- 
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: Deprecation policy for IE6

[Florian Apolloner]

Hi,

On Jun 9, 1:11 pm, Gert Van Gool  wrote:
> I remember from the HTML5 doctype that some people (with app in enterprises)
> need the support

Right, but even Google is dropping support for IE < 8 [1]! And if
Google is trying to get companies to use newer browsers we should
support that too ;)

Cheers,
Florian

1: 
http://gmailblog.blogspot.com/2011/06/our-plans-to-support-modern-browsers.html

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

Reversing translated urls in templates

[Florian Apolloner]

Hi,

I would like to get some feedback on https://code.djangoproject.com/ticket/16332
Jacob suggested that the standard url-tag should take a lang argument
so we don't need an extra tag (okay, his actual concern was the
dislike of the name i18n_url ;)). I would like that idea too, but I am
somewhat worried about the implications; eg it would break as soon as
someone already has "lang" as param in his urlconf and using a
parameter like __lang isn't that nice either…

Any thoughts on this?

Cheers,
Florian

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

Reversing translated urls in templates

[Florian Apolloner]

Hi,

I would like to get some feedback on https://code.djangoproject.com/ticket/16332
Jacob suggested that the standard url-tag should take a lang argument
so we don't need an extra tag (okay, his actual concern was the
dislike of the name i18n_url ;)). I would like that idea too, but I am
somewhat worried about the implications; eg it would break as soon as
someone already has "lang" as param in his urlconf and using a
parameter like __lang isn't that nice either…

Any thoughts on this?

Cheers,
Florian

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

Re: Reversing translated urls in templates

[Florian Apolloner]

On Jun 25, 11:58 am, Jannis Leidel  wrote:
> As I said initially when we discussed this on IRC, I believe a "i18n_url" is 
> good enough
> and would fit well with the other i18n related template tags.

Jupp, I just wanted to here if someone else had different feelings
about it.

> I believe
> this pattern should also be applied to the template tag which a user might 
> use to point to
> one of those translatable URLs.

Agreed, I leave the patch like it's now. Though I am still open for
suggestions on cleaning up the code duplication.

Cheers,
Florian

-- 
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: Django 1.4 Roadmap

[Florian Apolloner]

Hi,

On Monday, August 8, 2011 2:19:07 AM UTC+2, Russell Keith-Magee wrote:
>
> someone who has the spare time to manage the release process. That's
> been me for the last two releases; I'm fairly certain I won't have the
> spare cycles to make it three in a row.
>
Is the release process documented somewhere and could someone from outside 
of the core team step in to help out here?

Cheers,
Florian 

-- 
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/-/yblqbZc_m24J.
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]

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 view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/vLiHd62iAJ0J.
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.