Re: revisiting the Python version support policy

[Gert Van Gool]

We can look at the larger distros (Debian, Ubuntu, RHEL). For RHEL, their
derivatives include CentOS , Scientic Linux, Amazon Linux, Oracle Linux.
RHEL 7 has no (main) Python 3 support. It's only introduced in RHEL 8
(which is currently in beta).

That gives us for Debian Stretch (stable) and Ubuntu 16.04 Python 3.5.
While Ubuntu 18.04 and RHEL 8 have Python 3.6.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gertvangool.be


On Tue, Jan 22, 2019 at 6:11 PM Collin Anderson 
wrote:

> Now that we've dropped Python 2, I personally wouldn't mind having the
> policy be to support all supported versions of python (except 2.7) at the
> time of each Django release. So Django would drop just after Python drops.
> (The most recent version of Django (and maybe LTS too) should probably also
> add support for new versions of Python, so we're not holding people back
> from trying out the latest Python.) But I don't have a good feel for what
> the maintenance burden is for supporting old versions of Python, so I don't
> see first-hand the advantages of dropping earlier. Now that we're 3.x-only,
> I don't like the idea of "driving the ecosystem forwards" being an excuse
> for dropping Python early. I agree "allowing users to easily use and
> install django based applications" is more important.
>
> I also like the idea of "amending the Python support version policy to
> account for the Python version in Debian stable", as that's a little more
> practical, though we start play favorites with distros.
>
>
> On Tue, Jan 22, 2019 at 10:04 AM Federico Capoano <
> federico.capo...@gmail.com> wrote:
>
>> I would ask: what are the pros and cons of dropping support for python
>> 3.5?
>>
>> I think allowing users to easily use and install django based
>> applications is more important than strictly follow a python version
>> support policy.
>>
>> I think that if we drop support for python 3.5, which is the default
>> python version on many linux platforms right now, we will make the life of
>> our users and developers harder.
>> I don't understand the reason for doing so, if we have to do it for a
>> good reason, like a security issue, or because django has to take advantage
>> of features that are available only from python 3.6 onwards, I would be in
>> favour, but if we have to do it only because the policy says so, without
>> any other advantage, I would amend the policy.
>>
>> My 2 cents.
>>
>> Thanks for your hard work maintaining django
>> Federico
>>
>>
>> On Monday, January 21, 2019 at 10:56:40 AM UTC-5, Tim Graham wrote:
>>>
>>> When deciding when to drop support for Python 2 in Django, there was
>>> consensus to adopt this Python version support policy [0]: "Typically, we
>>> will support a Python version up to and including the first Django LTS
>>> release whose security support ends after security support for that version
>>> of Python ends. For example, Python 3.3 security support ends September
>>> 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django
>>> 1.8 is the last version to support Python 3.3."
>>>
>>> Since then, we didn't abide by this policy when dropping Python 3.4,
>>> mainly because Debian stable still used Python 3.4 at the time and Claude
>>> argued that some people like him would have difficulty contributing to
>>> Django if they had to install another version of Python [1].
>>>
>>> Based on the policy, it's time to drop support for Python 3.5 in the
>>> master branch (Django 3.0) -- with Django 2.2 LTS supported until April
>>> 2022 and Python 3.5 supported until September 2020). I created a ticket [2]
>>> and PR [3] for dropping support for Python 3.5 [2], however, Claude
>>> commented, "I'm not so enthusiast to drop Python 3.5 now (it is still the
>>> default version in Debian stable). Couldn't this be done in Django 3.1
>>> instead?"
>>>
>>> Are you in favor of amending the Python support version policy to
>>> account for the Python version in Debian stable?
>>>
>>> [0]
>>> https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
>>> [1]
>>> https://groups.google.com/d/msg/django-developers/4rbVKJYm8DI/TTh3i04pBQAJ
>>> [2] https://code.djangoproject.com/ticket/30116
>>> [3] https://github.com/django/django/pull/10864
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/51dfc517-8b5a-4803-9f8d-daa1bf920e7b%40googlegroups.com
>> 

Re: SSL support for Django-admin runserver‏

[Gert Van Gool]

Hi Steven,

It might be handier to use gunicorn with SSL support[1] and since there is
already a section in the Django documentation on how to use gunicorn in a
project[2].


[1]: http://gunicorn-docs.readthedocs.org/en/latest/settings.html#ssl
[2]: https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/gunicorn/

-- Gert

Twitter: @gvangool 
Web: http://gertvangool.be

On Sat, May 9, 2015 at 4:19 PM, Steven Berry 
wrote:

> While working with an OAuth library I was running into some issues signing
> requests on a local development server due to lack of HTTPS.
>
> To solve this problem I was deploying web application code to a VM with a
> shared folder or SCP and running an TLS-enabled nginx server. Obviously the
> development/test latency here is unacceptable. I looked into what solutions
> were out there and found a Django plugin django-runsslserver (
> https://github.com/teddziuba/django-sslserver). I installed this app, but
> was disappointed by a few things:
>
>
>- The included certificates didn't work due to an EOF openssl error
>- I was required to install an additional app (even just doing a += on
>the INSTALLED_APPS tuple in a separate development settings module
>felt a bit wonky)
>- I now had command bifurcation when running development servers --
>runserver, runsslserver, and testserver (which in turn didn't support
>SSL)
>- The code was necessarily repetitive because Django does not
>currently abstract the django.core.servers.basehttp module enough for
>this purpose
>
> I felt like this was something Django should just optionally support out
> of the box for simple use cases such as my own. I forked Django and
> switched my installed version in my virtual environment to my fork with "pip
> -e". I used this myself for a while, but I thought my modest change would
> be objectively useful for others and would be relatively trivial to review
> and implement.
>
> For reference I developed a fix here
> https://github.com/sjberry/django/commit/c8e808d70f4a0ac6ebf4634576a2538b4f35b83e
>  and
> subsequently submitted a PR here
> https://github.com/django/django/pull/4633. Though the PR was admittedly
> out of order due to my inexperience with the contribution protocol.
>
> Let me know if I'm off base here.
>
> Regards,
> Steven Berry
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/40207727-f555-4c1a-bdc4-dcc40e9be935%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPuLG2KS-wFj%3D%3DerYmyC2A%3DNF998DsxYWPRo_Lf5ivr7QBYCfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Psycopg2 version support

[Gert Van Gool]

In CentOS 6, you can't run Django 1.8 anyway. It ships Python 2.6.

So if you want to run Django 1.8 on CentOS 6, you need to compile Python
yourself. In that case I don't think they'll complain about having to build
psycopg2 separately as well.

In the RHEL/CentOS universe, anyone who wants to run Django 1.8 needs
either SCL's (software collections that are installed next to system
binaries) or has access to psycopg2 2.5.

So my point for CentOS/RHEL 6 can be ignored.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gertvangool.be

On Mon, Feb 16, 2015 at 3:10 PM, Thomas Stephenson 
wrote:

> My mistake, sorry.
>
> So, to get the conversation back on track, is `2.4.5` acceptable as the
> minimum version, even if users who
>
> - use CentOS 6
> - install dependencies via the OS package manager
> - don't have sudo/root
> - can't request the sysadmin to install dev packages; and
> - keep django at the latest version
>
> don't have a valid upgrade path?
>
> Thomas
>
>
> On Tuesday, February 17, 2015 at 12:36:11 AM UTC+11, Florian Apolloner
> wrote:
>>
>> Not exactly, cause installing psycopg2 via the OS package manager should
>> __not__ require dev packages at all.
>>
>> On Monday, February 16, 2015 at 11:57:01 AM UTC+1, Thomas Stephenson
>> wrote:
>>>
>>> > Installing psycopg2 does require development tools, while Django does
>>> not
>>>
>>> Installing psycopg2 2.0.0 requires exactly the same `postgres-*-dev`
>>> libraries that 2.5 does as far as I know. If it is possible to install
>>> psycopg2 via the OS package manager then 2.5 can be installed via pip.
>>>
>>> On Monday, February 16, 2015 at 11:18:56 AM UTC+11, Xof wrote:


 On Feb 15, 2015, at 4:14 PM, Tim Graham  wrote:

 > Is there a scenario where you could pip install Django but not pip
 install psycopg2?

 Installing psycopg2 does require development tools, while Django does
 not.  I'm not offering this as a compelling argument for anything, just an
 observation.

 --
 -- Christophe Pettus
x...@thebuild.com

  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4efc59f0-0b97-4ed9-bbce-bd1b124ea978%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPuLG2%2BJAwjr4M%3D8kvnz8EZc98rt316DduFnybETzhZeGL-K4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Psycopg2 version support

[Gert Van Gool]

For what it's worth, CentOS 6 (supported until November 30, 2020) ships
with 2.0.14. CentOS 7 has 2.5.1.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gertvangool.be

On Mon, Feb 16, 2015 at 9:11 AM, Florian Apolloner 
wrote:

> Core could stay at 2.4.5 and contrib.postgresql could require a newer
> version :)
>
> On Saturday, February 14, 2015 at 9:53:43 PM UTC+1, Marc Tamlyn wrote:
>>
>> Hi all,
>>
>> Related ticket - https://code.djangoproject.com/ticket/24335
>>
>> Django 1.8 will necessarily be the first version with a true minimum
>> requirement on psycopg2 version. Historically we have never documented a
>> required version.
>>
>> - The new UUIDField requires at least 2.0.9
>> - Some code which is currently contained in the backend, not in
>> contrib.postgres, but I think only relates to arrays of
>> (Generic)IPAddressFields requires 2.4.5. As yet I have not tried moving
>> this compat code so it only runs if contrib.postgres installed.
>> - Range fields (in contrib.postgres) require 2.5
>> - There may be other things I'm not responsible for I don't know about,
>> with different version requirements.
>>
>> Release history for psycopg2:
>> - 2.0.9 is extremely old (date unknown)
>> - 2.4.5 was released in March 2012
>> - 2.5 was released in April 2013
>> - 2.6 was released this month (Feb 2015)
>>
>> According to Claude, some distros have a python-psycopg2 package which is
>> still on 2.4.5 (or maybe older?).
>>
>> We have several options:
>> - Ensure as much as possible works with old versions of psycopg2 by
>> shuffling code around and/or using conditional imports.
>> - Making sure everything *outside contrib* doesn't require newer psycopg2
>> that 2.0.9, and making contrib.postgres require 2.5. This may not be
>> possible, but I think it should be.
>> - Change nothing but docs, so outside contrib requires 2.4.5,
>> contrib.postgres requires 2.5.
>> - Just document that Django 1.8+ needs psycopg2 2.5 (pip install it...)
>>
>> The latter would be my preferred option, but then I've never understood
>> the argument for distro packages instead of pip. In any case, I feel that
>> any distro not supporting a two year old version of psycopg2 is unlikely to
>> be distributing a brand new version of Django.
>>
>> As far as I know we have no official policy on dependencies like this (we
>> don't have many).
>>
>> Marc
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/dbde195e-39e8-438c-a30d-f95911e1b5ee%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPuLG2%2BAcKTPxx%2BQfqeHreHO999hJY3xds2Rx9ysRW3Ukx8dQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is "transaction.atomic" in 1.6 supposed to work this way?

[Gert Van Gool]

If the `innocent_looking_function` would use transactions. And thus handles
the `IntegrityError by`
issuing a rollback, just like `get_or_create` does (
https://github.com/django/django/blob/1.6b4/django/db/models/query.py#L360-L390
).
Do you see the same behaviour in `my_func`?

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gertvangool.be


On Thu, Sep 19, 2013 at 2:38 PM, Richard Ward wrote:

> We're building a site that needs to use transactions, and have been doing
> so against the 1.6 beta as 1.6 is nearly out and we thought it would be
> easier to use the new transaction api, but we came across an unexpected
> problem.
>
> Basically if you catch an IntegrityError and 'recover' from it, then your
> transaction is still not committed.
>
> I'm posting this here rather than in django-users as its a feature in an
> unreleased version and it seems like it a bug to me (apologies if it is the
> wrong place).
>
> Take this code:
>
> def innocent_looking_function():
> "Makes sure that a MyModel with foo=1 exists"
> try:
> #imagine mymodel has a unique constraint on 'foo'
> MyModel(foo=1).save()
> except IntegrityError:
> pass
>
> @transaction.atomic
> def my_func():
> innocent_looking_function()
> MyOtherModel(bar="hi").save()
>
> If you call 'my_func' when a MyModel with foo=1 exists, then the
> transaction.atomic decorator will roll back the transaction, even though it
> seems like everything is alright. 'my_func' doesn't know that
> 'innocent_looking_func' may cause this behaviour, and as far as
> 'innocent_looking_func' is concerned it has not done anything wrong - it
> caught and ignored a harmless error.
>
> I had assumed that transaction.atomic would only roll back the transaction
> if an exception was propagated through it (eg if innocent_looking_function
> did not catch the error), that would seem like the natural way of doing
> things.
>
> So what is the problem here? I assume it is one of:
>
>1. 'innocent_looking_function' is badly written: it should not be
>catching IntegrityErrors under any circumstances (though that seems like a
>valid thing to do), it should instead use something like get_or_create.
>2. 'innocent_looking_function' should have 'with
>transaction.atomic():' just inside the 'try' block, and presumably so
>should every other bit of code where an IntegrityError is caught. But what
>if 'innocent_looking_function' also gets used elsewhere that may not be
>inside an atomic block?
>3. transaction.atomic is in some way buggy / oddly designed.
>
> IMO this behaviour makes code that looks valid (to me) not work in the
> expected way.
>
> In case its relevant I'm using InnoDB tables on MySQL.
>
> So Is there a bug? Or am I using this incorrectly, or misunderstanding
> something?
>
> Thanks,
>
> Richard
>
> --
> 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.
>

-- 
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: Django MEDIA url in storage.py

[Gert Van Gool]

The usage of MEDIA_ROOT is by design.

According to the release notes from 1.3 [1], the intention is to have
uploaded files in MEDIA_ROOT and assets/static files in STATIC_ROOT.

Nothing stops you from doing:

MEDIA_ROOT = STATIC_ROOT
MEDIA_URL = STATIC_URL

[1] 
https://docs.djangoproject.com/en/dev/releases/1.3/#extended-static-files-handling

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be


On Wed, May 16, 2012 at 3:47 PM, Andre Terra  wrote:
> You can define a custom location for your files like the docs tell you:
> https://docs.djangoproject.com/en/dev/topics/files/#the-built-in-filesystem-storage-class
> https://docs.djangoproject.com/en/dev/howto/custom-file-storage/
> https://docs.djangoproject.com/en/dev/topics/http/file-uploads/
>
> If you believe you've encountered a bug, please create a ticket on TRAC:
> http://code.djangoproject.com/newticket
>
>
> More customization can be achieved by specifying a custom file upload
> handler:
> https://docs.djangoproject.com/en/dev/topics/http/file-uploads/#upload-handlers
>
>
> Cheers,
> AT
>
>
> On Wed, May 16, 2012 at 10:26 AM, hakim  wrote:
>>
>> Hi all,
>>
>> I am developing an intranet portal using django 1.3.1. I noticed in my
>> uploader app that the default storage redirects the saved files to the
>> apache2 directory.
>> I found later that the reason of this is due to
>> Django.core.files.storage.py in line 152, 154. It still uses
>> settings.MEDIA_URL. The same thing for 1.4.
>> I fixed it changing it to STATIC_URL. please fix it in the future release.
>>
>> regards,
>>
>> --
>> 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/-/GatVnD3aRs8J.
>> 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.
>
>
> --
> 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.

-- 
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: Authentication page

[Gert Van Gool]

django-developers is for the discussion of the development of Django
itself, not development with Django.
As such this mailing list is not appropriate for this message,
django-users would be more appropriate.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be


On Tue, May 15, 2012 at 3:55 PM, francescobocca...@libero.it
 wrote:
> Hi all,
> i'm new of Django world and i would like to create  for my web site an
> autentication page (login, logout, sign up, change user , etc..)
> How can found a tutorial to do that? Anyone can suggest me ho build that?
> Thanks
>
> Francesco
>
> --
> 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.
>

-- 
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: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

[Gert Van Gool]

What I would love as a developer in the documentation is, what do I
need to do so my code "could" run on Python 3.
It might not work, but most obvious issues (like b() and u()) would be
out of the way.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be



On Sat, Dec 10, 2011 at 02:25, Joe & Anne Tennies  wrote:
> Doh, accidentally hit "send on my phone." Let me finish my thought:
>
>
> I must say that I would personally LOVE to see this in 1.4 as some sort of
> "preview" (akin to __future__) to give people a chance to get their packages
> up and running on Python 3. This would also allow people to document the
> porting process properly.
>
> Obviously, this is dependent on the code passing code reviews in time, which
> may be hard as I know this effort is based upon a separate effort.  I'm
> betting this ends up being a lot of code that will need some very specific
> people's time. I know Jannis would like the original person to review the
> additional changes.
>
> Core Developers, what else would we need as far as documentation? I'm
> assuming the current test suite should be good. Do we need some more numbers
> besides Linux and maybe OS X to prove timing still looks good? Would there
> be a potentially larger slow down w/ all the u() and b() calls on Windows
> than the others?
>
> I have no governing power on the project, so these are all my opinion with
> no power to make them happen.
>
>
>>
>> 
>> On Dec 9, 2011 2:26 PM, Ram Rachum  wrote:
>>
>> In which Django release are we hoping to release this port? 1.4 or 1.5?
>>
>>
>> Ram.
>> --
>> 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/-/Y8-2tS9lth4J.
>> 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.
>
>
>
>
>
> --
> Joe & Anne Tennies
> tenn...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

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

[Gert Van Gool]

On Tue, Nov 29, 2011 at 13:40, Tomek Paczkowski  wrote:
> What happend to "SVN is least common denominator"?
>
> --
> 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/-/5DgmsJ17_8oJ.
> 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.
>

@Thomas, GitHub provides an svn bridge: see
https://github.com/blog/626-announcing-svn-support,
https://github.com/blog/644-subversion-write-support and
https://github.com/blog/966-improved-subversion-client-support

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be

-- 
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 13125 is waiting for a design decision for 18 months

[Gert Van Gool]

Well, we - and I imagine many others - are actively using this behavior.
So our use-case is simple: a user registers, the user remains inactive
until they click on a link in their mailbox.
That is the behavior is "defined" by django-registration.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be



On Fri, Sep 9, 2011 at 07:24, subs...@gmail.com  wrote:
> Could anyone provide a use case where I want a de-activated user to
> remain authenticated? Who is this option for? Why is it default?
>
> When I originally reported this ticket I did so because this is a
> plain security risk--non-technical users uncheck 'is active' when they
> want to lock someone out of access. They don't realize that the
> session remains active and I believe this to be an oversight within
> the original design, not a design preference.
>
> On Sep 8, 2:11 am, Vladimir Kryachko  wrote:
>> I think it has been done on purpose, and should not be changed.
>> Because different authentication backends may choose to support
>> inactive users or not. And the default (ModelBackend) supports
>> inactive users which is expressed in
>> ModelBackend.supports_inactive_user = True. So I would suggest you
>> write a custom decorator.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen  wrote:
>> > I'd like to draw attention to an open ticket which needs a design
>> > decision.
>>
>> > Description:
>> > "The login_required decorator is not checking User.is_active, as
>> > staff_member_required does. If an authenticated user is deactivated
>> > (via setting is_active to False), the user is still able to browse
>> > login_required-protected views."
>>
>> > For probably most people, the expected and (most likely) wanted
>> > behavior would be not to let inactive users have access to
>> > login_required files.
>>
>> > Wim
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Django developers" group.
>> > To post to this group, send email to django-developers@googlegroups.com.
>> > To unsubscribe from this group, send email to 
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group 
>> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> 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.
>
>

-- 
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: Google Contacts API

[Gert Van Gool]

django-developers is for the discussion of the development of Django
itself, not development with Django.
As such this mailing list is not appropriate for this message,
django-users would be more appropriate.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be



On Wed, Aug 24, 2011 at 11:46, Purna Chander  wrote:
> Can anyone help me regarding Google Contacts API... How to
> authenticate the google contacts
>
> I tried one code
>
>   import gdata
> import atom
> import atom.data
> import gdata.data
> import gdata.contacts.client
> import gdata.contacts.data
> import gdata.contacts.service
> # Application name as 'geo-int' for ContactsClient
> #gd_client = gdata.contacts.client.ContactsClient(source='geo-int')
> gd_client = gdata.contacts.service.ContactsService()
> next = 'http://www.example.com/welcome.py'
> scope = 'https://www.google.com/m8/feeds/'
> secure = False
> session = True
> authSubLogin = gd_client.GenerateAuthSubURL(next, scope, secure,
> session)
>
> def OnSave(self, fields):
>    new_contact = gdata.contacts.data.ContactEntry()
>
>    name = self.params.get('name')
>    phone = self.params.get('phone')
>    email_id = self.params.get('email_id')
>    #print email_id
>    #Name
>    new_contact.name =
> gdata.data.Name(full_name=gdata.data.FullName(text=name))
>    #Phone Number
>    new_contact.phone_number.append(gdata.data.PhoneNumber(text=phone,
>      rel=gdata.data.WORK_REL, primay='true'))
>
>    #Email Address
>    new_contact.email.append(gdata.data.Email(address=email_id,
>      primary='true', rel=gdata.data.WORK_REL, display_name=name))
>    new_contact.email.append(gdata.data.Email(address=email_id,
>      rel=gdata.data.HOME_REL))
>
>    # Send the contact data to the server.
>    contact_entry = gd_client.CreateContact(new_contact)
>    print "Contact's ID: %s" % contact_entry.id.text
>    return contact_entry
>
>
> While running this , I am getting the error ---
>
>    Traceback (most recent call last):
>  File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/
> base.py", line 99, in get_response
>    response = callback(request, *callback_args, **callback_kwargs)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/view_utils.py",
> line 344, in __call__
>    response = self.Post(self.params)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/view_utils.py",
> line 582, in Post
>    return self.HandleEditFormPost(params)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/views.py", line
> 235, in HandleEditFormPost
>    self.OnSave(form.cleaned_data)  # Modified from above.
>  File "/home/boddireddy/Desktop/MainInstance-1/src/views.py", line
> 259, in OnSave
>    contact_entry = gd_client.CreateContact(new_contact)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/gdata/contacts/
> service.py", line 132, in CreateContact
>    converter=gdata.contacts.ContactEntryFromString)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/gdata/service.py",
> line 1236, in Post
>    media_source=media_source, converter=converter)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/gdata/service.py",
> line 1322, in PostOrPut
>    headers=extra_headers, url_params=url_params)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/atom/__init__.py",
> line 93, in optional_warn_function
>    return f(*args, **kwargs)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/atom/service.py",
> line 176, in request
>    content_length = CalculateDataLength(data)
>  File "/home/boddireddy/Desktop/MainInstance-1/src/atom/service.py",
> line 731, in CalculateDataLength
>    return len(ElementTree.tostring(data))
>  File "/usr/lib/python2.6/xml/etree/ElementTree.py", line 1009, in
> tostring
>    ElementTree(element).write(file, encoding)
>  File "/usr/lib/python2.6/xml/etree/ElementTree.py", line 663, in
> write
>    self._write(file, self._root, encoding, {})
>  File "/usr/lib/python2.6/xml/etree/ElementTree.py", line 673, in
> _write
>    items = node.items()
> AttributeError: 'ContactEntry' object has no attribute 'items'
>
> --
> 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.
>
>

-- 
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: Drag and drop functionality?

[Gert Van Gool]

django-developers is for the discussion of the development of Django
itself, not development with Django.
As such this mailing list is not appropriate for this message,
django-users would be more appropriate.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be



On Wed, Aug 24, 2011 at 08:35, gh  wrote:
>
> Hi
>
> I new to this and I have just started with django. I have one
> question, maybe this is not the right forum but I'll try here first.
> I would like to have some kind of container where I for example can
> drag and drop a webaddress to the container and then save them to may
> django application.
> Is there any Javscript or anything else that I can use to handle this?
>
> Regards
> glenn
>
> --
> 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.
>
>

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

[Gert Van Gool]

On Thu, Jun 9, 2011 at 12:32, Idan Gazit  wrote:

> I'm looking at admin tickets, and I realize that some defined policy for
> when we can safely start to break IE6 would be very helpful.
>
> I'd like to simply declare that going forward, the admin need not work
> perfectly in IE6. That leaves our support footprint for the Admin at "modern
> browsers" + IE>7.
>
> * contrib.admin is contrib, and thus not covered by Django's deprecation
> policy
>
> * This isn't a change which affects any other frontend product built with
> Django. The only audience this affects is users of the admin. I think it's
> reasonable to require administrative users to have IE7 if all they have is
> IE.
>
> The admin is already using the HTML5 doctype (see
> https://groups.google.com/d/topic/django-developers/wJ9dnUDHUVI/ for
> background), but not any of the new HTML5 elements.
>
> This change would mainly open up the ability to use PNGs and remove hacks
> and workarounds from admin CSS/HTML
>
> Any objections?
>
> I
>
>
>
> --
> 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.
>
>
Although I don't personally.
I remember from the HTML5 doctype that some people (with app in enterprises)
need the support

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 

-- 
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: sitemaps and prepend_www

[Gert Van Gool]

Usually you would create a ticket on trac [1] which describes your problem
and reasoning.
And you can attach a patch file to it. This way, it will go through the
normal triaging and feature requests.

[1] http://code.djangoproject.com/newticket
-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gert.selentic.net



On Fri, Apr 22, 2011 at 13:14, Nikolay Panov wrote:

> Hi,
>
> I cannot use www in current_site.domain since .domain is used in many
> places (e.g. emails) where www is not required. BTW, I'm using
> PREPEND_WWW=True setting, since it makes url looks better.
> Now, google webmaster tools rejecting all links in sitemap of my
> project because lack of 'www'.
>
> My question is: why we cannot have something like:
>
> --- django_old/contrib/sitemaps/__init__.py   2008-11-19
> 08:44:26.0 +0300
> +++ django_new/contrib/sitemaps/__init__.py 2010-11-24
> 18:57:34.0 +0300
> @@ -1,4 +1,5 @@
>  from django.core import urlresolvers, paginator
> +from django.conf import settings
>  import urllib
>
>  PING_URL = "http://www.google.com/webmasters/tools/ping";
> @@ -29,7 +30,10 @@
>
> from django.contrib.sites.models import Site
> current_site = Site.objects.get_current()
> -url = "http://%s%s"; % (current_site.domain, sitemap_url)
> +domain = current_site.domain
> +if settings.PREPEND_WWW and not domain.startswith('www.'):
> +domain = 'www.' + domain
> +url = "http://%s%s"; % (domain, sitemap_url)
> params = urllib.urlencode({'sitemap':url})
> urllib.urlopen("%s?%s" % (ping_url, params))
>
> @@ -62,9 +66,12 @@
> def get_urls(self, page=1):
> from django.contrib.sites.models import Site
> current_site = Site.objects.get_current()
> +domain = current_site.domain
> +if settings.PREPEND_WWW and not domain.startswith('www.'):
> +domain = 'www.' + domain
> urls = []
> for item in self.paginator.page(page).object_list:
> -loc = "http://%s%s"; % (current_site.domain,
> self.__get('location', item))
> +loc = "http://%s%s"; % (domain, self.__get('location', item))
> url_info = {
> 'location':   loc,
> 'lastmod':self.__get('lastmod', item, None),
> and
>
> --- django_old/contrib/sitemaps/views.py  2008-11-19
> 08:44:26.0 +0300
> +++ django_new/contrib/sitemaps/views.py2010-11-24
> 18:57:58.0 +0300
> @@ -4,6 +4,8 @@
>  from django.core import urlresolvers
>  from django.utils.encoding import smart_str
>  from django.core.paginator import EmptyPage, PageNotAnInteger
> +from django.conf import settings
> +
>
>  def index(request, sitemaps):
> current_site = Site.objects.get_current()
> @@ -15,10 +17,13 @@
> else:
> pages = site.paginator.num_pages
> sitemap_url =
> urlresolvers.reverse('django.contrib.sitemaps.views.sitemap',
> kwargs={'section': section})
> -sites.append('%s://%s%s' % (protocol, current_site.domain,
> sitemap_url))
> +domain = current_site.domain
> +if settings.PREPEND_WWW and not domain.startswith('www.'):
> +domain = 'www.' + domain
> +sites.append('%s://%s%s' % (protocol, domain, sitemap_url))
> if pages > 1:
> for page in range(2, pages+1):
> -sites.append('%s://%s%s?p=%s' % (protocol,
> current_site.domain, sitemap_url, page))
> +sites.append('%s://%s%s?p=%s' % (protocol, domain,
> sitemap_url, page))
> xml = loader.render_to_string('sitemap_index.xml', {'sitemaps': sites})
> return HttpResponse(xml, mimetype='application/xml')
>
>
> This fix works well for me, but it will be great to have this into
> official django repo.
>
> Have a nice day,
>Nikolay.
>
> --
> 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.
>
>

-- 
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: Instructions for code changing to Django 1.3

[Gert Van Gool]

What's wrong with the release notes[1]?
They contain a list of backwards incompatible changes [2], which is
the only this you'd need to change.

[1]: http://docs.djangoproject.com/en/dev/releases/1.3/
[2]: 
http://docs.djangoproject.com/en/dev/releases/1.3/#backwards-incompatible-changes-in-1-3

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net



2011/3/30 Thiago Carvalho D' Ávila :
> I have a project running in Django 1.2.5 and I want to update it (the code)
> to Django 1.3. I've seen the release notes, but there is no direct
> instructions to what I have to change in the code.
>
> It would be very useful to me, to all the community (I know that a lot of
> people may be in the exact same situation), and to the new version adoption
> if exists an official document like this.
>
> This would be a great culture to adquire to make a better Django and a more
> easy framework to the developers.
>
> --
> 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.
>

-- 
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: ANN: Django 1.3 released

[Gert Van Gool]

Congratualations to all involved!

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net



On Wed, Mar 23, 2011 at 07:15, James Bennett  wrote:
> It's here!
>
> Django 1.3 has been officially released.
>
> Blog post here: http://www.djangoproject.com/weblog/2011/mar/23/13/
> Release notes here: http://docs.djangoproject.com/en/dev/releases/1.3/
> Download here: http://www.djangoproject.com/download/
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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: Feature request: Abstract ManyToManyField

[Gert Van Gool]

Can you give an example of the model(s) you're talking about?

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net



On Thu, Feb 3, 2011 at 22:36, Mike Lindsey  wrote:
> I'm doing something with bidirectional ManyToManyFields, in a project
> I'm working on, that is resulting in duplicate attempts to create the
> intermediate tables.  I'm perfectly open to suggestions of "You're
> doing it wrong" if they come with advice on how to fix my problem,
> without losing the easy Admin insertion of the relationships (without
> resorting to InLines, which don't seem to play nicely at all with
> FieldSets).  Right now I'm getting around the problem by running
> syncdb, running dbshell to drop the table it complains about, and
> rerunning syncdb; repeating until syncdb finishes successfully.
>
> What would make this exceptionally easy, is if there was the option to
> set 'abstract=True' on second iteration of each of the
> ManyToManyFields, telling syncdb to not attempt to create it.
>
> Thoughts?
>
> --
> Mike Lindsey
>
> --
> 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.
>
>

-- 
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: Issue 14878 And Changeset 15133

[Gert Van Gool]

Not really related to #5373, since it's related to the new generic views code.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net


On Fri, Jan 7, 2011 at 00:26, Lachlan Musicman  wrote:
>
> 2011/1/7 Diego Andrés Sanabria Martín :
> > A few weeks ago i report this issue, 14878[1], and Rusell fix it, but
> > i think still there is a possible bug, if the verbose name of a model
> > includes a translation string.
>
> Is this related to http://code.djangoproject.com/ticket/5373 ?
>
> cheers
> L.
>
>
> --
> "... imagine a puddle waking up one morning and thinking, 'This is an
> interesting world I find myself in - an interesting hole I find myself
> in - fits me rather neatly, doesn't it? In fact it fits me
> staggeringly well, must have been made to have me in it!' This is such
> a powerful idea that as the sun rises in the sky and the air heats up
> and as, gradually, the puddle gets smaller and smaller, it's still
> frantically hanging on to the notion that everything's going to be
> alright, because this world was meant to have him in it, was built to
> have him in it; so the moment he disappears catches him rather by
> surprise."
> Douglas Adams
>
> --
> 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.
>

-- 
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: i18n bug in template rendering.

[Gert Van Gool]

So for the sake of the argument I've changed the template code to use
"{% load i18n %}" and also added a filter, since that is our use-case.
http://dpaste.com/294778/

I thought that if you wanted to apply a filter to a string in a
template that you had to use _ instead of {% trans %}.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net



On Thu, Jan 6, 2011 at 00:05, Ramiro Morales  wrote:
> On Wed, Jan 5, 2011 at 12:21 PM, Jonathan S  
> wrote:
>> I guess, we found a bug, not sure if it has been reported earlier and
>> whether this is the right place to report.
>>
>> When a template contains translations in variables, like
>> {{ _("text") }}, the text seems to be translated already during the
>> creation of the Template object. Every following call of
>> Template.render() will output the translation which was made earlier.
>> (Possibly in the wrong language.)
>>
>> Templates are cached in 'django.template.loaders.cached.Loader', so
>> this bug makes constructions like  {{ _("text")|upper }} impossible.
>
> But you aren't using the i18n support correctly.
>
> You aren't supposed to use _('Foo') as a standalone variable.
> (see last paragraph here
> http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#other-tags)
>
> Also,
>
> * You need to load the i18n template tag library
>
> * Use the trans tag.
>
> Try using Template("{% load i18n %}{% trans 'Yes' %}").render(...)
> to achieve what you want.
>
> All this is covered in the docs:
>
> http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#specifying-translation-strings-in-template-code
>
> --
> Ramiro Morales
>
> --
> 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.
>
>

-- 
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: more than one querys LIKE in the same field

[Gert Van Gool]

django-developers is for the discussion of the development of Django
itself, not development with Django.
As such this mailing list is not appropriate for this message,
django-users would be more appropriate.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gert.selentic.net



On Tue, Dec 14, 2010 at 09:14, marcoarreguin wrote:

> Hi friends!
>
> I mean do something like this:
>
> SELECT * FROM table WHERE tags LIKE '%candy%' AND  tags LIKE '%milk%'
>
>
>
> I've tried:
>
> table.objects.filter(tags__icontains='candy', tags__icontains='milk')
>
> I've tried too:
>
> list = ['candy', 'milk']
> table.objects.filter(tags__icontains=list
>
> And nothing work. Help me please :s
>
> Thanks bros!
>
> --
> 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.
>
>

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

[Gert Van Gool]

BTW: what happens when your verbose_name_plural contains a quote (single or
double)?

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gert.selentic.net



On Thu, Dec 9, 2010 at 18:42, Luke Plant  wrote:

> Hi,
>
> First, in answer to your question in the title - yes, normally you
> should report bugs like this to Trac, once you are sure you've found a
> bug.
>
> > The problem here is:
> >
> >
> > If i don't set a context_object_name in my app, the method
> > get_context_object_name puts a name based  in the verbose_name_plural
> > of my model's name but in the method get_context_data, ithe queryset
> > is set twice, first as 'object_list' and then with the generated name.
> > Querysets being lazy, this is not really a problem in templates, but
> > if I want to serialize that context generated by get_context_data (to
> > create a generic view that outputs results in json), I will load the
> > data twice and that could be a problem.
>
> I don't see anything that makes me think the data will be loaded twice.
> Have you actually seen this happening in practice? Giving a single
> QuerySet object two entries in a dictionary doesn't clone it.
>
> > In the edit,py file (django/views/generic) the
> > class ModelFormMixin inherits from FormMixin and the
> > methods form_invalid from both classes are the same code:
> >
> >
> > return self.render_to_response(self.get_context_data(form=form))
> >
> > I think the method from ModelFormMixin just should call super from
> > FormMixin, like in form_valid, but perhaps this is intentional.
>
> Even better would be to miss out the method altogether. I can't think
> why right now, but it is possible that it is intentional - if so a
> comment to say why would be better.
>
> Luke
>
> --
> "My capacity for happiness you could fit into a matchbox without
> taking out the matches first." (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.
>
>

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

csrf_token on 404 page

[Gert Van Gool]

I'm unsure whether this is a bug or not. So I'm checking here first.
But it seems impossible to use {% csrf_token %} on a 404 page?
On a 500 page, it's works though.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net

-- 
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: be localflavor Belgium

[Gert Van Gool]

IMHO I would allow a non-spaced version. My typing my phone number as
0498725202 should also work.
Second thing, wrap the long lines :)

Relevant ticket is #14349 (http://code.djangoproject.com/ticket/14349)

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gert.selentic.net



On Wed, Sep 29, 2010 at 18:26, Laurent Luce  wrote:

> Hello,
>
> I created a patch to add support for Belgium to localflavor. I
> attached the patch to a ticket which is marked as accepted. The patch
> contains the forms fields, unit tests and the doc changes.
>
> What do I need to do next ? Wait for someone to review the patch and
> commit it ?
>
> Laurent
>
> --
> 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.
>
>

-- 
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: Making WSGIHandler the only handler / mod_python support

[Gert Van Gool]

So in theory, if you change the mod_python handler to one of the projects
mentioned (like paste.modwsgi).
mod_python is "promoted" to the same status as FastCGI?

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net


On Wed, Jun 23, 2010 at 13:43, Russell Keith-Magee
wrote:

> On Wed, Jun 23, 2010 at 5:26 PM, Tom Evans 
> wrote:
> > On Wed, Jun 23, 2010 at 12:22 AM, Gustavo Narea 
> wrote:
> >> Hello,
> >>
> >> I'm going to work on some patches to improve WSGI support, and I found
> >> something that, if changed, could make my patches and
> django.core.handlers
> >> simpler... As well as make it possible to use WSGI middleware with
> Django
> >> under mod_python.
> >>
> >> ...
> >>
> >> To sum up, I'm proposing two things:
> >>  1.- Making the WSGI handler the only handler.
> >>  2.- If we want to keep mod_python support, use a mod_python<->WSGI
> wrapper.
> >>
> >
> > What about FastCGI?
>
> FastCGI is a server interface, not a handler interface. If you dig
> into the internals, the FastCGI interface uses WSGI to serve pages.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-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.
>
>

-- 
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.3: Start deprecating mod_python?

[Gert Van Gool]

You could release the "officially endorsed" external package together with
1.3. So people can start migrating towards that.
However, I assume that people who're still using mod_python, won't be
upgrading to 1.4/1.5 without updating the rest of the system...

We're currently running two websites on mod_python. Both are
dead-in-the-water-projects, they're only running for old-times sake on a
separate server. So if they're ever revived (or get traffic), the first
thing I'll do is move them to mod_wsgi.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net


On Wed, Jun 23, 2010 at 03:05, Graham Dumpleton
wrote:

>
>
> On Jun 23, 9:48 am, Alex Gaynor  wrote:
> > On Tue, Jun 22, 2010 at 6:47 PM, Graham Dumpleton
> >
> >
> >
> >
> >
> >  wrote:
> >
> > > On Jun 23, 9:41 am, Russell Keith-Magee 
> > > wrote:
> > >> On Wed, Jun 23, 2010 at 5:51 AM, Jacob Kaplan-Moss <
> ja...@jacobian.org> wrote:
> > >> > On Tue, Jun 22, 2010 at 4:47 PM, Robert Coup
> > >> >  wrote:
> > >> >> While people are throwing around 1.3 ideas... I think we should
> start
> > >> >> the process of deprecating and removing support for mod_python.
> Why?
> >
> > >> > The other huge win -- besides your great versions -- is that without
> > >> > mod_python support Django just becomes a pure WSGI framework,
> meaning
> > >> > there's just a single codepath and a single way to deploy Django.
> > >> > Much, much easier.
> >
> > >> >> Objections?
> >
> > >> > None whatsoever. I'm +1e100 or so.
> >
> > >> None from me. +1.
> >
> > >> The only catch I can think of that hasn't been raised is the hotshot
> > >> profiling handler; it's currently dependent on the modpython handler.
> > >> I don't think there's a whole lot of extra work required to port it
> > >> over, but it's worth putting on the todo list so it isn't forgotten.
> >
> > > Can you provide a reference to this profiler you are talking about so
> > > I can have a quick look?
> >
> > > Graham
> >
> > > --
> > > 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 athttp://
> groups.google.com/group/django-developers?hl=en.
> >
> > http://code.djangoproject.com/browser/django/trunk/django/core/handle...
> >
> > (Honestly does anyone use this?)
>
> I am not really sure that Django should even need to provide this.
> This sort of thing is easily done with a WSGI middleware like wrapper
> these days. As such, it is better left to third party packages to
> provide such tools.
>
>
> # Original WSGI application.
>
> import os, sys
> sys.path.append('/usr/local/django')
> os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
>
> import django.core.handlers.wsgi
>
> application = django.core.handlers.wsgi.WSGIHandler()
>
> # Logging WSGI middleware.
>
> import threading
> import hotshot
> import time
> import os
>
> class ProfilingMiddleware:
>
>def __init__(self, application, savedir):
>self.__application = application
>self.__savedir = savedir
>self.__lock = threading.Lock()
>self.__pid = os.getpid()
>self.__count = 0
>
>def __call__(self, environ, start_response):
>self.__lock.acquire()
>self.__count += 1
>count = self.__count
>self.__lock.release()
>
>key = "%s-%s-%s" % (time.time(), self.__pid, count)
>
>savedir = os.path.join(self.__savedir, key + ".prof")
>profiler = hotshot.Profile(savedir)
>return profiler.runcall(self.__application, environ,
> start_response)
>
> application = ProfilingMiddleware(application, '/tmp/wsgi')
>
>
> --
> 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.
>
>

-- 
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: abstract file upload/download handling

[Gert Van Gool]

What's wrong with the current StorageBackends?
Apart from the fact that everything goes through Django first, which imho
isn't a bad default solution (easier for parsing and the like...).

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net


On Tue, Jun 22, 2010 at 08:55, Waldemar Kornewald wrote:

> Hi,
> first I should say that I'm not 100% sure if this feature should be in
> Django core, so I'm kind-of asking for you opinion.
>
> Problem:
> Currently, Django already has an API for file uploads, but it's not
> useful for the new cloud-based file services which support the more
> efficient asynchronous uploads (i.e., the file gets sent directly to
> the file server instead of being piped through Django). Also, Django
> doesn't provide an API for handling downloads in an abstract way
> (e.g., via X-Sendfile or a cloud-based file service). This means that
> you can't write reusable Django apps that handle file uploads and
> downloads using your actual hosting solution. Also, you can't use
> Django's admin interface for file uploads/downloads.
>
> Proposal:
> I've already implemented a really simple backend-based API which could
> solve this problem. It's called django-filetransfers:
> http://www.allbuttonspressed.com/projects/django-filetransfers
>
> It basically has:
>
> * a pre-upload handler which generates an upload URL for a single file
> and additional POST data if that's needed (e.g., for async S3)
>
> * a template tag which generates  fields
> for the additional POST data
>
> * a download URL generator for public files (e.g., publicly accessible
> files hosted on S3 or via MEDIA_URL or ...)
>
> * a download view for private files (e.g., X-Sendfile, App Engine
> Blobstore, private S3, ...)
> The download view also serves as a fallback in case the backend
> doesn't support public URLs.
>
> With this solution you can continue to use ModelForm and FileField in
> your project.
>
> Normally, I'd just keep this API in a separate app (outside of Django
> core), but without this API the admin interface won't work properly.
> What do you think? Should Django consider including this (or a
> similar) API in core, so there is a standard way to handle any kind of
> upload/download solution? Or should the admin interface try to use
> django-filetransfers if it's available (probably not; just thinking
> aloud)?
>
> Bye,
> Waldemar Kornewald
>
> --
> 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.
>
>

-- 
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: Replace django.contrib.formtools.wizard

[Gert Van Gool]

MEDIA_ROOT isn't a good solution. It should use a StorageBackend.
For instance, when you use a load-balancer there is no guarantee that
your session hits the same server twice.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Mon, May 31, 2010 at 10:36, Gregor Müllegger  wrote:
> Storing the file in a temporary directory is elegant but brings up
> some new problems.
>
> IMO it's critical - if you want to support file uploads - to put these
> files into MEDIA_ROOT. Otherwise you wouldn't be able to show previews
> of uploaded images etc.
>
> 2010/5/30 TiNo :
>> On Sat, May 29, 2010 at 22:07, Stephan Jäkel  wrote:
>>>
>>> I already discussed this ticket with Jannis during the sprints and hope to
>>> start a discussion here to find the right way to allow file uploads and see
>>> if my approach takes the right direction.
>>
>> Couldn't you just use python's tempfile.NamedTemporaryFile[1]? That way the
>> file will get cleaned by the filesystem itself, unless you move it somewhere
>> else in your ``done`` method. If you pass delete=False, you will be able to
>> open the file again in the last step, as long as you properly closed it
>> before.
>> TiNo
>> [1] http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile
>>
>> --
>> 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.
>>
>
> --
> 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.
>
>

-- 
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: How can transmit variable and values to Django template other then Context?

[Gert Van Gool]

django-developers is for the discussion of the development of Django
itself, not development with Django.
As such this mailing list is not appropriate for this message,
django-users would be more appropriate.

However you should take a look at template context processor[1]

[1]: http://docs.djangoproject.com/en/dev/ref/templates/api/#id1
-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Fri, Apr 23, 2010 at 09:38, JohnHenry  wrote:
> Hi, all
>    As I know, Django Templates got all variables through views
> function with Context dict; But I read some source, There is some
> variables like {{SITE_ROOT}} {{MEDIA_URL}} {{MEDIA_SERIAL}}
> {{request}}  {{ user }}  {{siteconfig}} ; Such variables seems globlly
> usable; But I can't find any Context Items about them in relative View
> function. Then How did those variables transimitted to Templates? And
> Can I add some global varible values like that which need no value
> from Context?
>
>
>
> Best Regards!
>
> --
> 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.
>
>

-- 
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 Proposal: Web Unifying Markup (templating) Language, or WUML

[Gert Van Gool]

I have some remarks/thoughts.
 - How does this make code re-use better?
   For instance, how do you use the same CSS styles along different files.
  Or am I required to move the re-usable CSS/JS code  in a normal file?
 - Can you give an example on how you see the template tags being used in here?

>From what I've read in the other proposals, your timeline should be
divided into weeks.
It shows a better understanding of the problem.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Fri, Apr 9, 2010 at 20:14, nubela  wrote:
> Proposal Title
> --
>
> Web Unifying Markup (templating) Language, or WUML
>
> Background
> --
>
> As a freelance developer having built entire platforms of Django, I
> find the most time consuming part of web development to be the front
> end development. Essentially, Javascript, HTML, and CSS. Of course
> there are tools that might help. For example, SASS for CSS, JQuery for
> Javascript, and recently, an exciting new library known as the SHPAML
> surfaced that is pretty similar to HAML, but more pythonic, and
> definitely more transparent. (http://shpaml.webfactional.com/)
>
> However, what does not change is that these components are still
> distinct. Everytime I have to modify a property of an element, I'd
> still have to go to my CSS file, or SASS file. Same goes to JS, or
> HTML.
>
> But thats not all, if we were to use SHPAML and SASS, every time we
> have to test the interface, we have to manually compile, or have a 3rd
> party script to compile all the relevant files back into its HTML/CSS/
> JS components. And that means before every F5, we have to run a mini
> script. It gets annoying after a while.
>
> This is when I hope WUML can come in.
>
> Essentially, I hope to have a unified templating language that will
> coexists with template tags of Django, whereby I can streamline my
> development into a pythonic element-centric experience. But its better
> to demonstrate with examples.
>
> Examples
> 
>
> html
>  body
>    div#header
>      | this is some verbose text inside this div
>      + background-color: {{ backgroundcolor }}
>      + pointer: cursor
>      ^ alert("true");
>      ^ this.hide();
>
> will be compiled into
>
>> A HTML FILE
>
> 
>  
>    this is some verbose text inside this div
>  
> 
>
>> A CSS FILE
>
> html body div#header {
>  background-color: #FFF;
>  pointer: cursor;
> }
>
>
>> A JS FILE (using JQuery)
>
> $(document).ready({function(){
>  $("div#header").live("click",function() {
>    alert("true");
>    this.hide(); //hide here has to be defined in another js file.
>  });
> });
>
>
> Arguments against WUML (or why it is helpful)
> -
>
> Some people might argue that this defeats the purpose of abstraction
> of different components into its respective components. JS/HTML/CSS
> existed distinctly for a reason. While I agree strongly with this
> point, but I hope to point out that WUML is not replacing any of those
> components.
>
> Here are some reasons why WUML might be interesting:
>
> 1) A javascript coder, a HTML writer, and a CSS scriptor, can still
> work on their individual files, no one is stopping them. What WUML
> does is, it provides a shorthand in an element-centric manner to
> various of these components in a pythonic sense. The 3 different
> people can now instead of working on 3 different files, they can work
> on the same code, and view distinctly what are the relevant details to
> each element they should take note of. Besides, with the state of the
> art revision control any decent programmer should use these days,
> merging will make this much easier.
>
> 2) WUML is s much shorter.
>
> 3) WUML is pythonic, at least syntatically-wise.
>
> 4) WUML will greatly boost any frontend developer's lead time.
>
> Implementation Details
> --
>
> In a gist, I will basically be merging the best components of JS/CSS/
> HTML, and providing a markup syntax for them in a pythonic fashion.
>
> Details:
>
> - Architecture: The WUML layer will live atop the 2 main components,
> namely SASS and SHPAML. Hopefully, we can use the python-sass library,
> instead of its generic binary backend for compilation. This way, the
> WUML layer will interface the 2 pythonic layer, and provide a whole
> new markup language. The template compiler which I hope will be worked
> on this GSoC, will live atop WUML layer, and hence compile the WUML
> compliant template everytime a change is made.
>
> - Compilation: I would hope to work with a co-developer who would be
> working on template compilation, and provide an extension of
> compilation of WUML into their relevant separate components. This way,
> compilation can take place dynamically and when needed, instead of
> manually.
>
> Some Notes
> --
>
> - Old templates will still be compliant.
>
> - Using SHPAML's principle, all code can still be hardcoded. That
> means one would be able to mix in generic

Re: Templates by app

[Gert Van Gool]

django-developers is for the discussion of the development of Django
itself, not development with Django.
As such this mailing list is not appropriate for this message,
django-users would be more appropriate.

But to quickly answer, yes. Especially if you're using many 3rd party apps.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Sat, Mar 20, 2010 at 12:11, Joan Miller  wrote:
> Is there any reason to have a global directory with all templates
> instead of to have the templates for each application:
>
> project/
> \___ apps/
>      \___ templates/
>
> --
> 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.
>
>

-- 
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: GSoC10 Idea: Additional queryset methods

[Gert Van Gool]

What would be the difference with the new raw method on manager
(http://docs.djangoproject.com/en/dev/topics/db/sql/#django.db.models.Manager.raw)?

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Fri, Mar 19, 2010 at 13:39, Sh4wn  wrote:
> ## The Django ORM
>
> ### The Problem
>
> Django is a awesome webframework, and works quite well. But after
> using it for about a year now, I've came across some annoyances. One
> great thing of django is the amount of third party reusable apps,
> unfortunately, this comes at a cost in the number of database queries.
> For example, the comments application, which has a template tag
> 'get_comment_count', this tag executes a query everytime when it gets
> called. Or even better, the django-avatar app which executes 2 SQL
> queries each time the {% avatar %} is called. This is not really
> efficient as it often possible to select the required data with
> joins.
>
> With a custom Manager class, you can quite easily annotate the count
> of an related object, but unfortunately not for generic relations.
> When you want to add the comment count to, for example, a list of news
> items, without executing a query for each news item, you'll have to
> fallback to the 'extra' method of a queryset, which often will contain
> raw SQL.
>
> ### The Solution
>
> I want to refactor the QuerySet and other databases related API's,
> which adds an additional method of selecting records, and provides
> more control of what data you'll select, but probably is a bit more
> complex than the current API. It's a bit inspired by Doctrine, a PHP
> ORM, and yes, one of the few decent PHP projects.
>
> Example 1.1:
>    qs = QuerySet().select(News.all, User.username,
>            Count('c__id'), comment_average=Avg(OtherModel.field)
>        ).from(News) \
>        .leftJoin('comments c')
>        .filter(news__title="value") \
>        .order_by('comment_average')
> (This is just a not-working dummy example)
>
> As you can see you can explicitly set the fields and tables you want
> to select. Beside that the existing queryset methods will remain to
> work. There'll be a slight difference though: instead of the related
> name in filter/order_by/other methods you don't use the related name,
> but the table name specified in the from method.
>
> The select method supports selecting fields by string and python
> object, the same for the from method. In addition, the select method
> also supports the builtin django aggregates. Renaming selected fields
> works the same as the aggregate method, just use python's named
> parameters.
>
> It also provides a simple method for joins, simply put the name of the
> table you want to join, or the model class, and it will automaticly
> generate the ON statement, when the two models are related, but is
> overrideable with the second parameter of the leftJoin method.
>
> --
> 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.
>
>

-- 
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: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

[Gert Van Gool]

There is a ticket for something similar #8896
(http://code.djangoproject.com/ticket/8896).
Let urlresolvers also route according to hostname.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



2010/3/15 jens :
> On Mar 15, 3:44 pm, Yuri Baburov  wrote:
>> How do you like the following idea:
>> startproject command puts a fixture for django.contrib.sites (and
>> fixture for superuser probably) to the root folder or whatever, to be
>> loaded with syncdb?
>
> IMHO it would be a great, if django can set the SITE_ID dynamic, based
> on the current domain.
>
> There exist some old links related to this:
> http://groups.google.com/group/django-developers/browse_thread/thread/d9f1088de7944de3
> http://code.djangoproject.com/ticket/4438
> http://www.djangosnippets.org/snippets/1099/
>
> --
> 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.
>
>

-- 
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: 2 small tickets

[Gert Van Gool]

I believe you still need test cases for both tickets.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Wed, Mar 3, 2010 at 08:41, Jared Forsyth  wrote:
> I found some bugs, wrote come patches, submitted some tickets. =) Is that
> all that's needed?
> The two patches I wrote are very small, one is only one char diff...
> I guess I just want to know
> a) have I done all that's required/suggested, and
> b) if so, what's the expected turnaround time for very small bugs w/ a patch
> attached?
> for reference, the
> tickets: http://code.djangoproject.com/ticket/12974, http://code.djangoproject.com/ticket/12972
> thanks,
> Jared
>
> --
> 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.
>

-- 
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: Using dajaxice to get my data to javascript

[Gert Van Gool]

django-developers is for the discussion of the development of Django
itself, not development with Django.
As such this mailing list is not appropriate for this message,
django-users would be more appropriate.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Tue, Feb 16, 2010 at 09:07, Alexis Selves  wrote:
> Hello there,
> Is possible to get my data from Django using Dajaxice? I need get
> information to create markers on google maps.
> Thanks for your advices.
>
> Alex.
>
> --
> 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.
>
>

-- 
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: Add Mod(%) Operator to If Tag

[Gert Van Gool]

Why do you need new operators?
You can use normal templatefilters according to the documentation.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Wed, Feb 10, 2010 at 20:00, Jonas Obrist  wrote:
> Alex Gaynor wrote:
>>
>> On Wed, Feb 10, 2010 at 12:10 PM, megaman821  wrote:
>>
>>>
>>> Since Django 1.2 is not out yet I have been using the smart_if tag in
>>> all my projects, with one addition. Since I believe the new if tag is
>>> based on the smart_if tag code on Django Snippets, I want to propose
>>> adding the mod(%) operator to it.
>>>
>>> Often I have display logic where I am displaying a grid of items so
>>> every nth item I need to create a new row. Right now you can awkwardly
>>> do this with the cycle tag but it gets a bit tedious and error prone
>>> if you want to have a row of 10 items. For example, you could do:
>>>
>>> {% cycle '' '' '' '' '' '' '' '' '' '' %}
>>>
>>> or
>>>
>>> {% if forloop.counter % 10 %}
>>>   
>>> {% endif %}
>>>
>>> --
>>> 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.
>>>
>>>
>>>
>>
>> Isn't this solved by the |divisibleby filter?
>>
>> Alex
>>
>>
>
> I'm not sure if this was discussed before, but what about allowing to easily
> register custom comparison operators? I'm thinking of a similar API we
> currently have for registering template tags/filters for if-tag operators.
>
> Jonas
>
> --
> 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.
>
>

-- 
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: Feedback on ticket #12399

[Gert Van Gool]

The second patch [1] fixes the memcached backend.

[1]
http://code.djangoproject.com/attachment/ticket/12399/memcached-timeout-fixes.diff
-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net


On Wed, Jan 27, 2010 at 08:28, Kristian Klette  wrote:

> > It's a nasty bug which leads to a 100% cache misses situation on
> > memcached when using long keys timeouts.
>
> Wouldn't it be better to fix this in the memcache backend itself? It does
> cause a backward compatibility problem for users that do takes this
> memcached
> behaviour into account in their code though.
>
> Either way, this memcached behaviour should be mentioned in the cache
> documentation.
>
> - Kristian
>
> --
> 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.
>
>

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

[Gert Van Gool]

@Noah, You could also look at it as what a AnonymousUser can't do on
some objects (while it's possible on others).

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



2010/1/19 Noah Silas :
> I'm not certain I understand - if anyone can perform some action, what's the
> point of protecting it with a permissions check?
> ~Noah Silas
>
>
> 2010/1/18 Łukasz Rekucki 
>>
>> 2010/1/18 Alex Gaynor :
>> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel 
>> > wrote:
>> >>
>> >> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>> >>
>> >>> Hi Harro,
>> >>>
>>  Hmm I guess I'll just have to keep on hacking django then..
>>  because that 1% case is something I keep running into for every
>>  project in one way or another.
>>  And if it was designed for most apps, why was the row level
>>  permission bits added? It's useless without simply always being
>>  able to call request.user.has_perm('permission', obj)
>> >>>
>> >>> Despite a slight overstatement in that last paragraph, your argument
>> >>> seems pretty good to me.  The whole point of these methods is to allow
>> >>> custom backends to implement their own logic, so obviously it is
>> >>> pointless to arbitrarily limit it.
>> >>>
>> >>> The only downside is that custom backends need to be able to cope with
>> >>> anonymous users being passed to the has_perm methods, but that is
>> >>> already well catered for with the is_anonymous() method.  It is also
>> >>> better to make this change before 1.2 lands, otherwise we have a
>> >>> slight backwards incompatibility if we wanted to do it in the future
>> >>> (backends could break if they unexpectedly got an AnonymousUser
>> >>> instead of a User).
>> >>>
>> >>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
>> >>> committing.
>> >>
>> >> Hm, I don't see a good argument to allow anonymous users to have a
>> >> permissions, to be honest. Anonymous users are by definition not
>> >> authenticated. Giving them more meaning by being able to grant them
>> >> permissions doesn't make them anonymous anymore, right?
>> >>
>> >> Also, before adding those hooks to the ModelBackend, AnonymousUser
>> >> never returned True when asked if it has a permission or not. Why should 
>> >> it
>> >> now?
>> >>
>> >> Jannis
>> >>
>> >>
>> >> --
>> >> 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.
>> >>
>> >
>> > I think the best argument in favor of it is using permissions with
>> > reusable applications.  Say I have a wiki application I write, I don't
>> > know whether anonymous users should be able to edit pages, I could
>> > make it a setting, but that's ugly.  Instead the natural thing to do
>> > is ask the auth backend and let the developer implement it however.
>>
>> This argument convinced me to like this idea :) My only concern is
>> that, a newly created user could have fewer permissions then an
>> anonymous one. I can't think of a situation where this would be
>> useful. So maybe all other users could actually inherit those
>> "anonymous permissions" ?
>>
>> >
>> > Alex
>> >
>> > --
>> > "I disapprove of what you say, but I will defend to the death your
>> > right to say it." -- Voltaire
>> > "The people's good is the highest law." -- Cicero
>> > "Code can always be simpler than you think, but never as simple as you
>> > want" -- Me
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Django developers" group.
>> > To post to this group, send email to django-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.
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Łukasz Rekucki
>>
>> --
>> 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.
>>
>>
>>
>
>
> --
> 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.
>
>
-- 
You received this message because you are subscribed to the Goog

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Gert Van Gool]

Isn't the idea of row based permission that you don't need a special
model for that?

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Fri, Jan 15, 2010 at 13:55, Anton Bessonov  wrote:
> Hello,
>
> It's a false place. All what you need - one Model for Settings.
>
> if SettingsModel.objects.get(code='guest_can_comment'):
>  can_post
> else:
>  cant_post
>
> You can wrap this in one decorator function.
>
> Harro schrieb:
>>
>> Because the authentication backend now allows for role based
>> permissions you might have a blog post which anonymous users are
>> allowed to comment on (create_comment) and another they can't.
>>
>> Now you would have to have a guest_can_comment flag or something on
>> the blog post and check that before displaying the form.
>> Instead I want to use the permission system to see if the anonymous
>> user has create_comment permission on that specific blog item.
>>
>> so that's why I think this would be a good addition.
>>
>> It would also allow for temporary shutting down of certain publicly
>> accessible items by simply removing/disabling the permissions for
>> guest users.
>>
>>
>>
>> On Jan 14, 3:17 pm, Juan Pablo Scaletti 
>> wrote:
>>
>>>
>>> If an AnonymousUser can do something then everybody can do that as well.
>>> So why a regular unprotected view can't do the job?
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jan 14, 2010 at 8:13 AM, Harro  wrote:
>>>

 I was having a look at the new 1.2 row level permission support that
 got added and ran into the problem that the AnonymousUser does not
 call the authentication backend functions.
      The default backend doesn't need this, but with a custom backend I
 might want to implement Guest permissions.
      I think it will make the permission system even more powerful !
      What do you guys think?
      Ticket:http://code.djangoproject.com/ticket/12557
      --
 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>>> i...@googlegroups.com>
 .
 For more options, visit this group at
 http://groups.google.com/group/django-developers?hl=en.

>>>
>>> --
>>>
>>> Juan Pablo Scaletti
>>>
>
>
> --
> 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.
>
>
>
>
-- 
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: please help me about enum attribute..

[Gert Van Gool]

You should use instance.get_gender_display().
See http://www.djangoproject.com/documentation/models/choices/ for more
information...

I do believe this is more a question for django-users.
-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net


On Tue, Jan 12, 2010 at 12:38, 'chiru'tha  wrote:

> Hi every one..
>  i got a problem.. please help me..
>I create a class for my model, in that class i declare an property
> gender and i make it as enum..
> it stores M or F only to the database. the sample code is shown
> bellow..
>
> GENDER_CHOICES = (
>(u'M', u'Male'),
>(u'F', u'Female'),
>)
> class Player:
> -
> gender = models.CharField(max_length=2, choices=GENDER_CHOICES,
> null=True, blank=True)
>  -
>
>
> The problem is, i want to get the fields from data base , it returns
> only M or F.. but i want the real values that is  Male and Female..
> how to achieve this one.. please help me..
>
> thank you..
>
> --
> 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.
>
>
>
>
-- 

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.