Re: GSOC Tags

[Russell Keith-Magee]

Hi Jasvir,

Frankly -- if something like this has happened, it's because Melange (the
software Google uses to run GSoC) is a complete mess. The fact that a
Melange search for "Django" doesn't return "Django Software Foundation" is
in no way surprising if you've spent any time actually using Melange.

We certainly haven't done anything strategically to avoid tagging the
project. I didn't set up our project in Melange - Andrew Godwin has done
this for the last few years - but I can't imagine he would have avoided
putting "django", "python", "web" or any other useful tags if given the
opportunity.

As an aside - I'm intrigued where you've found this "search by tag"
functionality, because it isn't something I've seen in the Melange
interface.

Yours,
Russ Magee %-)

On Tue, Oct 22, 2013 at 12:21 AM, Jasvir Singh wrote:

> I am searching django on list on organisations in GSOC 2013 and
> when I typed "django" in tags it shows a list of organisation but
> Django Software Foundation was none of them. Later I found that
> there are no tags for Django in "Django Software Foundation". The
> only way to search Django Software Foundation is by name.
>
> When I move towards GSOC 2012, same scene was there.
> But in GSOC 2011, some tags were there.
> In GSOC 2010, tags were but django is none of them.
> In 2009, again there were no tag.
>
> Don't you think that if someone just search by tag(easiest way to
> search), not by name then he/she will be misguided?
> As they will not be able to find Django Software Foundation.
> I don't know whether it is common or not. But I found it strange.
>
> --
> Jasvir Singh Grewal
> Blog: jasvirsinghgrewal91.wordpress.com
>
> :
> [ GNU/Linux One Stanza Tip (LOST) ]###
>
> Sub : Removing blank lines (with awk)LOST #549
>
> To remove blank lines from a text file (using awk):
> $ awk 'NF>0' < text_file
>
> [usmbish (at) users.sourceforge.net]##
> :
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20131021162151.GA4923%40gmail.com
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-6P-xD1si649hVau%3DMdFRCWHZe5qSNEqT%3DzR0v6qD7bw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

GSOC Tags

[Jasvir Singh]

I am searching django on list on organisations in GSOC 2013 and 
when I typed "django" in tags it shows a list of organisation but
Django Software Foundation was none of them. Later I found that
there are no tags for Django in "Django Software Foundation". The 
only way to search Django Software Foundation is by name.

When I move towards GSOC 2012, same scene was there.
But in GSOC 2011, some tags were there.
In GSOC 2010, tags were but django is none of them.
In 2009, again there were no tag.

Don't you think that if someone just search by tag(easiest way to 
search), not by name then he/she will be misguided?
As they will not be able to find Django Software Foundation.
I don't know whether it is common or not. But I found it strange.

-- 
Jasvir Singh Grewal
Blog: jasvirsinghgrewal91.wordpress.com

:
[ GNU/Linux One Stanza Tip (LOST) ]###

Sub : Removing blank lines (with awk)LOST #549

To remove blank lines from a text file (using awk):
$ awk 'NF>0' < text_file
 
[usmbish (at) users.sourceforge.net]##
:

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20131021162151.GA4923%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Creating a minimal custom user model. Seems last_login is required. Should it be?

[Xavier Ordoquy]

Hi,

Le 21 oct. 2013 à 16:04, Tino de Bruijn  a écrit :

> Harry's use case is an interesting one -- his authentication is being done 
> entirely by an external process, so there's no need for a password field. 
> Yes, he could just have the password and last_login fields and not use it, 
> but why should he need to carry around he extra weight when Django doesn't 
> need it.
> 
> @Harry, just out of curiosity, may I ask how you *do* authenticate your users?

I can't speak for Harry but using the RemoteUserBackend you don't need the 
password nor the last_login for Django.
In my case Apache did the authentication through Kerberos.
Django's documentation explains more there: 
https://docs.djangoproject.com/en/dev/howto/auth-remote-user/

Regards,
Xavier,
Linovia.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2738BC7D-3E19-42EB-BD70-031E8DCE94C5%40linovia.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Creating a minimal custom user model. Seems last_login is required. Should it be?

[Daniele Procida]

On Mon, Oct 21, 2013, Tino de Bruijn  wrote:

>@Harry, just out of curiosity, may I ask how you *do* authenticate your
>users?

I think he challenges them to a sword fight with rolled-up umbrellas.

Daniele

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20131021141029.1537145532%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Creating a minimal custom user model. Seems last_login is required. Should it be?

[Tino de Bruijn]

On Mon, Oct 21, 2013 at 2:13 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Mon, Oct 21, 2013 at 7:17 AM, Tino de Bruijn  wrote:
>
>>
>> On Mon, Oct 21, 2013 at 12:25 AM, Harry Percival <
>> harry.perci...@gmail.com> wrote:
>>
>>> I don't care about last_login!  Can this be circumvented?  Should that
>>> signal be optional, or gracefully handle the case where the user model has
>>> no last_login field?  Should I log this as a bug?
>>
>>
>> No, this is not a bug, it is by design. Django needs the last_login field
>> for generating password reset tokens [0], and I guess you do want to leave
>> that functionality in there. It is also not going to change anytime soon.
>> Please look at another recent thread on this list about this same subject,
>> and some reasoning from the core devs behind it.
>>
>> If you really want a 'bare' User model, you can, you just can't use other
>> contrib.auth stuff and contrib.admin stuff, as they expect more than just
>> and identifier (like password reset, permissions and groups).
>>
>
> Actually, until the introduction of the login signal, this was untrue.
>
> I looked into this at DjangoCon US specifically because of a request from
> Harry, and I got a passwordless login to admin working fine. Groups and
> permissions are also unnecessary -- you just need to implement the
> has_permission() family of APIs, and they can be implemented with a simple
> "return True" result, or by calls on external authentication APIs if
> they're available.
>

Ah, I stand corrected.

>
> Harry's use case is an interesting one -- his authentication is being done
> entirely by an external process, so there's no need for a password field.
> Yes, he could just have the password and last_login fields and not use it,
> but why should he need to carry around he extra weight when Django doesn't
> need it.
>

@Harry, just out of curiosity, may I ask how you *do* authenticate your
users?


Tino

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANQFsQAq7a1-4Vd04zxknjEXitdJjYs5Mkn2fMwh%3DVKU_qHuVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: Django Sprint November 23/24, Thinkfarm co-working space, Berlin, Germany

[Marc Tamlyn]

Hi Jannis,

Let me know if you're in need of another committer at the sprint. Can't
make any concrete promises as yet and I'd need to work out how cheaply I
can get there, but I'd love to come assist if that's helpful.

Marc
Hi all,

I'm excited to announce that the next Django sprint will take place in
Berlin, Germany on November 23rd and 24th. The event is organized by the
German Django Association (http://django-de.org/) together with the Django
Users Berlin.

The sprint is hosted at the Thinkfarm co-working space (
http://berlin.thinkfarm.de/) in Berlin Kreuzberg.

Sprinting will start on Saturday, November 23rd at 10:00 CET and ends on
Sunday, November 24th around 22:00 CET.

On Friday, November 22nd at 20:00 CET we especially invite newcomers to
join our Django installation party.

Please don't forget to RVSP:
http://www.meetup.com/django-user-group-berlin/events/146656662/

If this is your first time contributing to Django itself and can't make it
to the installation party on Friday please have a look at the contributing
guide (https://docs.djangoproject.com/en/dev/internals/contributing/) and
set up your clone of the Django git repository.

If we are lucky Django 1.6 will be released before the event so we can
concentrate on those many new features that will be part of Django 1.7 or
on post-release bugfixes.

If you’re unable to come to Berlin you're still very welcome to contribute
to the sprint online. Sprinters and core developers will be available in
the #django-sprint IRC channel on Freenode (http://freenode.net/).

We hope you can join us and make it an awesome sprint!

Jannis

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/839533E2-3EC5-4F2E-9B95-574F41BD230C%40gmail.com
.
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HF2bEoMYF%2BwqiHE3uzUuaDiASSHcV14x2dO-UsrxG-%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

ANN: Django Sprint November 23/24, Thinkfarm co-working space, Berlin, Germany

[Jannis Leidel]

Hi all,

I'm excited to announce that the next Django sprint will take place in Berlin, 
Germany on November 23rd and 24th. The event is organized by the German Django 
Association (http://django-de.org/) together with the Django Users Berlin.

The sprint is hosted at the Thinkfarm co-working space 
(http://berlin.thinkfarm.de/) in Berlin Kreuzberg.

Sprinting will start on Saturday, November 23rd at 10:00 CET and ends on 
Sunday, November 24th around 22:00 CET.

On Friday, November 22nd at 20:00 CET we especially invite newcomers to join 
our Django installation party.

Please don't forget to RVSP: 
http://www.meetup.com/django-user-group-berlin/events/146656662/

If this is your first time contributing to Django itself and can't make it to 
the installation party on Friday please have a look at the contributing guide 
(https://docs.djangoproject.com/en/dev/internals/contributing/) and set up your 
clone of the Django git repository.

If we are lucky Django 1.6 will be released before the event so we can 
concentrate on those many new features that will be part of Django 1.7 or on 
post-release bugfixes.

If you’re unable to come to Berlin you're still very welcome to contribute to 
the sprint online. Sprinters and core developers will be available in the 
#django-sprint IRC channel on Freenode (http://freenode.net/).

We hope you can join us and make it an awesome sprint!

Jannis

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/839533E2-3EC5-4F2E-9B95-574F41BD230C%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Possible idea for removing global state in Django.

[Jonathan Slenders]

Le vendredi 18 octobre 2013 13:27:21 UTC+2, Anssi Kääriäinen a écrit :
>
> On Friday, October 18, 2013 1:31:07 AM UTC+3, Shai Berger wrote:
>>
>> On Thursday 17 October 2013 08:34:48 Aymeric Augustin wrote: 
>> > 
>> > For instance, thread locals are strictly equivalent to regular 
>> variables in 
>> > tests because they are single threaded (with a handful of exceptions). 
>> But 
>> > allowing testing in isolation is a major goal of "removing global 
>> state". 
>>
>> If I understand correctly, what Jonathan is suggesting is not your 
>> garden- 
>> variety thread-local variables, but what Common Lisp calls "dynamically 
>> scoped 
>> variables" -- you could call them "call-stack-local" or something like 
>> that. 
>> In Python terms, every change to the values of such variables would be 
>> done in 
>> the __enter__() of a context manager, and undone (that is, old value 
>> restored) 
>> in the __exit__(). I think such variables are a great idea, and would 
>> indeed 
>> help a lot with all the problems associated with global state. In terms 
>> of 
>> software engineering, they are a lot like exceptions: A channel of 
>> communications between functions on different levels of the call stack, 
>> that 
>> does not require explicit acknowledgement on every level, and yet does 
>> not 
>> completely break locality. 
>>
>> However, I don't think such variables can be used in a reliable and 
>> elegant 
>> manner without language-level support, and sadly, Python does not support 
>> them. Attempts I've made to get the functionality using context managers 
>> ended 
>> with awkward APIs for either setting values, getting values, or both; as 
>> a 
>> trivial example, Jonathan's suggestion of the context manager being 
>> returned 
>> by django_project.activate() is of such low granularity, that it is 
>> almost 
>> equivalent to regular globals. 
>>
>> If a reasonable API for this can be defined, I'd be all for it. I suspect 
>> that's a non-trivial "if". 
>>
>
>
> One possible improvement is to start collecting all global and thread 
> local state under one object (call it "env" or something like that). That 
> way it would be a lot easier to actually see what global state you are 
> using. Currently that isn't at all clear. We have a couple of different 
> thread-local storages, and then we have a lot of cached values based on 
> settings, import time actions etc.
>
> The difficulty of doing this will likely be somewhere between really hard 
> and impossible. And that environment object might end up as a God Object 
> for Django (http://en.wikipedia.org/wiki/God_object). So maybe not so 
> great idea in practice...
>
>  - Anssi
>

I'm in favour of everything that makes it easier to see where we still have 
a global state.

About threads, I realised there's the case where you'd use a threadpool in 
a Django views for optimising stuff. The thread locals wouldn't work there, 
so that means we would have to offer an API for copying thread locals from 
one thread to another... Maybe very dirty, but I wonder whether Python has 
a concept of "parent thread" and whether thread locals could look in there?


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f0e8883d-884c-4cb6-97d4-6597540a5bfe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.