Re: Replacing get_absolute_url, I am against it

[Daniel Sokolowski]

Hi Russ, thank you for the update, yes it's a 'wish' list item, and 
unfortunately my time is too limited right now to tackle the wiki. 

On Monday, 25 February 2013 00:11:07 UTC-5, Russell Keith-Magee wrote:
>
>
> On Sun, Feb 24, 2013 at 12:18 AM, Daniel Sokolowski 
> <elg...@danols.com
> > wrote:
>
>> Would anyone know if there is still any momentum behind this? I like 
>> Adamcik's approach.  
>>
>> Hi Daniel,
>
> I think if you polled the core team you'd probably still get agreement 
> that the problem exists; however, you'd probably get some disagreement 
> about how critical it is that we fix it. After all, this is something that 
> has been discussed for something like 5 years now, and we've been able to 
> live with the status quo without too many problems. 
>
> If this is an area where you'd like to contribute, I'd suggest the first 
> step is to make sure the wiki page on the topic is up to date, accurately 
> reflects all the discussions that have occurred. This is one of those 
> situations where the biggest impediment to progress is just making a 
> decision; if you can make that decision easier to make, we can try and get 
> some progress. 
>
> Yours,
> Russ Magee %-)
>  
>

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

Re: Replacing get_absolute_url, I am against it

[Daniel Sokolowski]

Would anyone know if there is still any momentum behind this? I like 
Adamcik's approach.  

On Saturday, 12 September 2009 07:42:40 UTC-4, adamcik wrote:
>
> On Thu, Sep 10, 2009 at 11:58:00AM -0400, Waylan Limberg wrote:
> > 
> > Easy, get_url returns the entire url while get_url_path returns only
> > the "path" portion of a url. One could imagine feature creep resulting
> > in 'get_url_protocol', 'get_url_domain' etc. I wouldn't actually
> > recommend those be added, but by thinking about it that way, it trains
> > my brain how to parse the proposed function names.
>
> Out of curiosity, has anyone looked at the possibility of modeling this 
> type of
> URL-handling in a similar way that we do for db.models.FieldField with 
> respect
> to the name, path and url properties?
>
> In essence we could add only one new method to the API that returns a
> URL-object that provides access to the data:
>
>url = obj.get_url()
>print url.absolute
>print url.relative
>print url.protocol
>print url.domain
>...
>
> If reverse() and {% url %} methods are updated to use such an URL-object
> backwards-compatibility can probably be persevered through a proper __str__
> method on the URL-object.
>
> IMO it feels more right to have single method that needs to know about this
> stuff instead of having separate methods for all this data which in essence
> is all part of the same URL complete.
>
> I have not double checked if all the issues mentioned in
> http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl can be solved 
> with
> such a scheme, but if there is interest in such a solution I'm willing to 
> look
> into this and trying out the idea either as an external project or as a 
> patch
> proposal.
>
> -- 
> Thomas Kongevold Adamcik
>

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

Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)

[Daniel Sokolowski]

+1 on the idea of just adding PROJECT_ROOT official setting and using that 
as needed - this is what I do in my projects already.


-Original Message- 
From: Luke Plant

Sent: Sunday, December 30, 2012 6:01 PM
To: django-developers@googlegroups.com
Subject: Re: Relative path support for TEMPLATE_DIRS and others in 
settings.py (django ticket 694)


On 29/12/12 04:08, Cal Leeming [Simplicity Media Ltd] wrote:


Could we not have something like this in the settings.py, which in turn
enabled the code pasted above?
TEMPLATE_PATH_RELATIVE=True


For consistency, we'd need STATICFILES_PATH_RELATIVE,
STATIC_ROOT_PATH_RELATIVE, MEDIA_ROOT_PATH_RELATIVE etc. which is
craziness. Having just one extra setting is a big deal.

There are use cases for all of these being absolute paths (or at least
some of them), and use cases for all of them being relative. We've
already chosen absolute paths, and you can generate absolute from
relative using os.path.realpath etc.

The only option I can is whether we put that snippet of code (e.g.
PROJECT_ROOT=os.path.realpath(os.path.dirname(__file__)) ) into the
settings file generated when starting a new project.

Luke


--
"If we could just get everyone to close their eyes and visualise
world peace for an hour, imagine how serene and quiet it would be
until the looting started" -- Anon

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



Daniel Sokolowski
http://klinsight.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.

Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)

[Daniel Sokolowski]

PROJECT_ROOT is what I have been using myself and seen it done by others so 
to me it makes sense to introduce an official setting for this purpose.


-Original Message- 
From: Shai Berger

Sent: Saturday, December 22, 2012 5:17 PM
To: django-developers@googlegroups.com
Subject: Re: Relative path support for TEMPLATE_DIRS and others in 
settings.py (django ticket 694)


Hi,

On Saturday 22 December 2012, Florian Apolloner wrote:

On Saturday, December 22, 2012 10:35:59 PM UTC+1, Ben Porter wrote:
> I would like to see support for relative paths.  It seems the solution 
> is

> simple, but I wonder if there is some compelling reason to require
> absolute paths?

It would seem so but it is everything but simple: First of, for a relative
path one needs a base path to join with, what is that? In your example 
it's

the project root, Django doesn't have such thing as a project root.


You are right, but that might be the root of the problem (no pun intended).
Django doesn't have a concept of a project root, and (partly as a result)
requires paths to almost anything that isn't a python module to be given as
absolute path.

I think adding an optional "PROJECT_ROOT" or "PROJECT_PATH_BASE" setting,
specifying that other paths can be made relative to it, will remove a
significant amount of boilerplate in settings files, and will not have any 
of

the problems you name.

Personally, I have yet to see a settings file in a non-trivial Django 
project
that doesn't do the os.path.join(os.path.dir(__file__), ...) dance. When 
done

properly, you end up with a function in_proj_dir that is applied to many
settings values. It would be much cleaner, IMO, to have this code defined in
the framework (rather than settings files) and limit the use of code to a
single setting.

My 2 cents,
Shai.

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


--

Daniel Sokolowski
http://webdesign.danols.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.

Re: Class based views: A standard hook for http-method-independent code

[Daniel Sokolowski]

I like this approach. 

From: George Hickman 
Sent: Thursday, November 15, 2012 7:27 AM
To: django-developers@googlegroups.com 
Subject: Re: Class based views: A standard hook for http-method-independent code

I have a slightly different proposal, one where we can avoid the extra hook but 
hopefully cover everyone's use cases too. 

https://github.com/ghickman/django/commit/85ac39a481074c25af1ed72a7a12e62ff5425e54

I've personally never liked the setting of args, kwargs & request from within 
dispatch since it seems like it's feature creep of the dispatch method. However 
I'm also in the same boat as many of the other posters here in needing to do 
permissions related checks before dispatch is called.

With my suggestion above you would be able to put your pre-dispatch code in a 
subclasses overridden dispatch before calling super while also depending on 
args, kwargs & request on self.

On Thursday, November 15, 2012 4:18:34 AM UTC, Aaron Merriam wrote: 
  If the super call changes any data then by the time you've run whatever code 
comes after the super call, the changes have already occured.   

a.. If you wait to call super before running your own code, then request, 
args, and kwargs are not available on the request, so anything that depends on 
them being there (such as self.get_object()) will not work, so it must be 
re-implemented,  
b.. Otherwise you have to set request, args, kwargs yourself which does not 
feel very DRY.

  For me, the entire reason I would like this change, is so that I can do 
something before dispatch that uses self.request/args/kwargs.  Everything I 
want can be accomplished within dispatch, but not as cleanly, or as DRY as if 
this method hook existed.

  On Wednesday, November 14, 2012 6:49:06 AM UTC-7, Daniel Sokolowski wrote: 
Can you elaborate the nasty side effects you are thinking of? I can’t think 
of any that that the base views do to warrant your statement. 

From: Aaron Merriam 
Sent: Friday, November 09, 2012 3:12 PM
To: django-d...@googlegroups.com 
Subject: Re: Class based views: A standard hook for http-method-independent 
code

That pattern has nasty side-effects.  It can be used in some cases but it 
fails in most.

On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote: 
  I’ve done the below in the past, the only issue with that is if you have 
side effects in parent’s dispatch you don’t want executed but you would also 
run that risk if you had an initialize() method work flow; in the end I find 
dispatch() is enough in my experience. 

  def dispatch(self, request, *args, **kwargs):
  parent_dispatch_return = super(Class, self).dispatch(request, *args, 
**kwargs)
  ...my code based on values based on the super call...
  return parent_dispatch_return

  From: Jordan Hagan 
  Sent: Friday, November 09, 2012 12:37 AM
  To: django-d...@googlegroups.com 
  Subject: Re: Class based views: A standard hook for 
http-method-independent code

  Hey Russ, 

  The main point of concern which I think you may be missing is that 
self.kwargs and self.args are set inside dispatch, so using other mixins that 
require self.kwargs and self.args to be set (most do) will not work, without 
doing:

  def dispatch(self, request, *args, **kwargs):
  self.args = args;
  self.kwargs = kwargs
  self.init()
  return super(Class, self).dispatch(request, *args, **kwargs)

  Which isn't very tidy, to me having self.args and self.kwargs be set 
twice (once in my overridden dispatch method, and once in the original 
dispatch) feels wrong. I can't give you a good reason for it, it just feels bad 
every time I do it. The only way to work around this is to override dispatch 
without calling the original, and essentially duplicate the original dispatch 
method with an init call added in.

  Cheers,
  Jordan

  On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee 
<rus...@keith-magee.com> wrote:




On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam <aaronm...@gmail.com> 
wrote:

  Without setting request, args, and kwargs on on the view instance 
(which is done during the base dispatch view), anything in the view that 
assumes these values are present cannot run.   

  Most of my views end up with functions which retrieve an object and 
then do some basic validation to ensure that a user has permissions, or that 
the object is valid in some fashion, or that some set of conditions is met 
prior to allowing any method call to happen.  

  I have found that without this init method, the vast majority of my 
views end up re-writing dispatch which includes the super call.  This is 
especially annoying when you have to compare some aspect of the requesting user 
with an object that must be looked up with something from args or kwargs.  My 
view often already has this machinery built in, b

Re: Class based views: A standard hook for http-method-independent code

[Daniel Sokolowski]

Hmm, ok, so that is only and issue if you don’t know the side effects calling 
super when dealing with non django provided views - and you can still 
pre-process request before calling super.  

So at the moment I can understand the appeal of init() as shown in the example 
but fail to see where I couldn’t just use dispatch() instead. In the past when 
we needed to tie permission checks I opted into making a view mixin to override 
dispatch similar to this one: 
https://github.com/lukaszb/django-guardian/blob/master/guardian/mixins.py

Perhaps people that do find this init() method worthwhile should voice so. 
Thanks
From: Alex Ogier 
Sent: Wednesday, November 14, 2012 10:35 AM
To: django-developers@googlegroups.com 
Subject: Re: Class based views: A standard hook for http-method-independent code

For example, you miss Http404 and other error responses, which are implemented 
as exceptional control flow. In addition, you can't do any preprocessing of the 
request; for example, you can't set up any invariants before your actual view 
method is called. 

Best,
Alex Ogier




On Wed, Nov 14, 2012 at 8:48 AM, Daniel Sokolowski 
<daniel.sokolow...@klinsight.com> wrote:

  Can you elaborate the nasty side effects you are thinking of? I can’t think 
of any that that the base views do to warrant your statement. 

  From: Aaron Merriam 
  Sent: Friday, November 09, 2012 3:12 PM
  To: django-developers@googlegroups.com 
  Subject: Re: Class based views: A standard hook for http-method-independent 
code

  That pattern has nasty side-effects.  It can be used in some cases but it 
fails in most.

  On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote: 
I’ve done the below in the past, the only issue with that is if you have 
side effects in parent’s dispatch you don’t want executed but you would also 
run that risk if you had an initialize() method work flow; in the end I find 
dispatch() is enough in my experience. 

def dispatch(self, request, *args, **kwargs):
parent_dispatch_return = super(Class, self).dispatch(request, *args, 
**kwargs)
...my code based on values based on the super call...
return parent_dispatch_return
-- 
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.

Daniel Sokolowski
http://webdesign.danols.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.

Re: Class based views: A standard hook for http-method-independent code

[Daniel Sokolowski]

Can you elaborate the nasty side effects you are thinking of? I can’t think of 
any that that the base views do to warrant your statement. 

From: Aaron Merriam 
Sent: Friday, November 09, 2012 3:12 PM
To: django-developers@googlegroups.com 
Subject: Re: Class based views: A standard hook for http-method-independent code

That pattern has nasty side-effects.  It can be used in some cases but it fails 
in most.

On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote: 
  I’ve done the below in the past, the only issue with that is if you have side 
effects in parent’s dispatch you don’t want executed but you would also run 
that risk if you had an initialize() method work flow; in the end I find 
dispatch() is enough in my experience. 

  def dispatch(self, request, *args, **kwargs):
  parent_dispatch_return = super(Class, self).dispatch(request, *args, 
**kwargs)
  ...my code based on values based on the super call...
  return parent_dispatch_return

  From: Jordan Hagan 
  Sent: Friday, November 09, 2012 12:37 AM
  To: django-d...@googlegroups.com 
  Subject: Re: Class based views: A standard hook for http-method-independent 
code

  Hey Russ, 

  The main point of concern which I think you may be missing is that 
self.kwargs and self.args are set inside dispatch, so using other mixins that 
require self.kwargs and self.args to be set (most do) will not work, without 
doing:

  def dispatch(self, request, *args, **kwargs):
  self.args = args;
  self.kwargs = kwargs
  self.init()
  return super(Class, self).dispatch(request, *args, **kwargs)

  Which isn't very tidy, to me having self.args and self.kwargs be set twice 
(once in my overridden dispatch method, and once in the original dispatch) 
feels wrong. I can't give you a good reason for it, it just feels bad every 
time I do it. The only way to work around this is to override dispatch without 
calling the original, and essentially duplicate the original dispatch method 
with an init call added in.

  Cheers,
  Jordan

  On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee <rus...@keith-magee.com> 
wrote:




On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam <aaronm...@gmail.com> wrote:

  Without setting request, args, and kwargs on on the view instance (which 
is done during the base dispatch view), anything in the view that assumes these 
values are present cannot run.   

  Most of my views end up with functions which retrieve an object and then 
do some basic validation to ensure that a user has permissions, or that the 
object is valid in some fashion, or that some set of conditions is met prior to 
allowing any method call to happen.  

  I have found that without this init method, the vast majority of my views 
end up re-writing dispatch which includes the super call.  This is especially 
annoying when you have to compare some aspect of the requesting user with an 
object that must be looked up with something from args or kwargs.  My view 
often already has this machinery built in, but it can't function without 
dispatch setting request, args, and kwargs, so to accomplish my check, I have 
to duplicate the lookup code in my dispatch method.

  I don't propose mine is the best solution, but I know that it is 
non-intrusive, simple, and covers my use cases well.  It is also simple to 
accomplish any number of things since `init` merely needs to return a falsy 
value to allow the request to pass on through, raise an exception if that type 
of failure is desired, or return a response of it wants to hijack the view 
entirely.



I'm starting to feel like I'm incredibly dense, because I still don't 
understand what your use case *is* - or, at least, why what your proposing 
provides any significant advantages over what you can do using basic Python 
inheritance techniques.

Specifically, I still can't see why:

class MyView(View):
def  dispatch(self, request, *args, **kwargs):
init()
return super(MyView, self).dispatch(request, *args, **kwargs)

def init():
# your init logic here

is superior to the solution provided by using basic Python inheritance:

class MyView(View):
def  dispatch(self, request, *args, **kwargs):
# your init logic here
return super(MyView, self).dispatch(request, *args, **kwargs)

You have exactly the same workflow, and exactly the same order of 
operations. You don't need to document any special CBV-specific API -- e.g., 
when/how init() will be invoked, and with what assumptions about the request 
environment can be made -- and you don't have to incur the overhead of a 
function call (ok - the overhead is tiny, but let's not pretend it's zero).

So - can someone explain to me what the advantage is? Why is this init() 
method needed?

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Gro

Re: Class based views: A standard hook for http-method-independent code

[Daniel Sokolowski]

l to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Daniel Sokolowski
http://webdesign.danols.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.

Re: URL dispatcher slow?

[Daniel Sokolowski]

Was that necessary?  I am tuning out of this conversion, it is becoming 
hostile. 
From: Alex Gaynor 
Sent: Thursday, October 11, 2012 10:01 AM
To: django-developers@googlegroups.com 
Subject: Re: URL dispatcher slow?




On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski 
<daniel.sokolow...@klinsight.com> wrote:

  I absolutely agree with: if we were looking for speed we wouldn't use python 
at all (period).


Speak for yourself.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to say 
it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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: URL dispatcher slow?

[Daniel Sokolowski]

I absolutely agree with: if we were looking for speed we wouldn't use python at 
all (period).

From: Florian Apolloner 
Sent: Wednesday, October 10, 2012 6:29 PM
To: django-developers@googlegroups.com 
Subject: Re: URL dispatcher slow?

Oh cmon,

please stop playing a socket puppet for the wheezy.web author. A web framework 
consists of more than just a win in speed (an the author of wheezy.web can 
argue whatever he wants that "basic" stuff stuff should be fast) -- if we were 
looking for speed we wouldn't use python at all (period). The goal is to be 
fast enough and be able to scale out horizontally, everything else is not 
really interesting in the case of web development. While I won't deny that 
Django isn't the fastest framework out there it certainly gets it's job done 
more than good enough and that's all it matters. I don't know what your goal 
is, but please stop posting such meaningless comparisons on django-dev…

That said, if you really think Django's urlresolver is to slow, go ahead, 
profile it and improve it, we certainly won't say no to speed improvements…

Cheers,
Florian

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

Daniel Sokolowski
http://webdesign.danols.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.

Re: URL dispatcher slow?

[Daniel Sokolowski]

Yes, wheezy.web is much more bare metal compared to Django : 
http://packages.python.org/wheezy.web/tutorial.html

From: Daniel Sokolowski 
Sent: Wednesday, October 10, 2012 10:32 AM
To: django-developers@googlegroups.com 
Subject: Re: URL dispatcher slow?

The middlewares appear to be disabled and the test bypasses the template system 
too: 
https://bitbucket.org/akorn/helloworld/src/c3f2d44dfca7/02-routing/django/helloworld/settings.py?at=default
 but yes Aymeric is right that Django provides a lot of convenience by default. 
In my opinion I rather take convenience as speed has not been a issue to me,  
but one thing though is that these benchmarks are  transparent enough to give 
them some validity. 

From: Aymeric Augustin 
Sent: Wednesday, October 10, 2012 9:30 AM
To: django-developers@googlegroups.com 
Subject: Re: URL dispatcher slow?

2012/10/10 Moonlight <moonlight_13_...@yahoo.com>

  Here is an article comparing various URL dispatchers:

  http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html

  What cause django URL dispatcher that much... slow?

Django's URL dispatcher is more complex than others. It provides advances 
features such as reversing, automatic i18n, and namespaces. Of course, these 
come at the expense of speed.

Note that this benchmark doesn't test URL dispatchers; it tests full stack 
requests. With Django's default settings, lots of convenient features such as 
middleware are enabled. This is likely to skew the results.

It'd be interesting to analyze what parts of the URL resolver are slow. If you 
really want to know what going on, go ahead and profile it. I'd be interested 
in the results (even though Django's performance has absolutely never been a 
problem for me).

As a side note, I read these benchmarks with a grain of salt. They're developed 
by the author of wheezy.web and consistently show it as a clear winner. Where's 
the line between testing and marketing?

-- 
Aymeric.

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

Daniel Sokolowski
http://webdesign.danols.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.

Re: URL dispatcher slow?

[Daniel Sokolowski]

The middlewares appear to be disabled and the test bypasses the template system 
too: 
https://bitbucket.org/akorn/helloworld/src/c3f2d44dfca7/02-routing/django/helloworld/settings.py?at=default
 but yes Aymeric is right that Django provides a lot of convenience by default. 
In my opinion I rather take convenience as speed has not been a issue to me,  
but one thing though is that these benchmarks are  transparent enough to give 
them some validity. 

From: Aymeric Augustin 
Sent: Wednesday, October 10, 2012 9:30 AM
To: django-developers@googlegroups.com 
Subject: Re: URL dispatcher slow?

2012/10/10 Moonlight <moonlight_13_...@yahoo.com>

  Here is an article comparing various URL dispatchers:

  http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html

  What cause django URL dispatcher that much... slow?

Django's URL dispatcher is more complex than others. It provides advances 
features such as reversing, automatic i18n, and namespaces. Of course, these 
come at the expense of speed.

Note that this benchmark doesn't test URL dispatchers; it tests full stack 
requests. With Django's default settings, lots of convenient features such as 
middleware are enabled. This is likely to skew the results.

It'd be interesting to analyze what parts of the URL resolver are slow. If you 
really want to know what going on, go ahead and profile it. I'd be interested 
in the results (even though Django's performance has absolutely never been a 
problem for me).

As a side note, I read these benchmarks with a grain of salt. They're developed 
by the author of wheezy.web and consistently show it as a clear winner. Where's 
the line between testing and marketing?

-- 
Aymeric.

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

Daniel Sokolowski
http://webdesign.danols.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.

Re: A bit of Django history

[Daniel Sokolowski]

Thanks for sharing that.

-Original Message- 
From: Jeremy Dunck

Sent: Friday, October 05, 2012 1:41 AM
To: django-developers@googlegroups.com
Subject: A bit of Django history

I was searching around for a different old blog post and found this one:
http://jacobian.org/writing/why-django/

It made me smile - we've come a ways since then. :)

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



Daniel Sokolowski
http://webdesign.danols.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.

Re: Model inheritance extended.

[Daniel Sokolowski]

Hi Jonathan, I am undecided on this one, when I first looked at it I thought it 
was a great idea but now I feel it would be more problematic to read and 
traverse and update such code due to the ModelFactory > MyModelFactory > 
MyModels logic flow. It feels a lot like using class based views – exciting at 
first but quickly the paradigm became complicated to understand and traverse 
when used beyond the base examples (at least in my case and until I understood 
it well enough). It also seems the current abstract model mechanism can do 
everything a model library can minus the model prefixing and the model 
grouping; that though I would just tackle using a naming convention, i.e. 
SimpleLibraryBook, ExtendedLibraryBook, with a BaseBook abstract class. 

Also where would the code live model_libraries.py ? I think explicit is better 
then DRY in this situation. This my opinion and as such can change - thank you 
for considering it. 

From: Jonathan Slenders 
Sent: Monday, September 24, 2012 9:55 AM
To: django-developers@googlegroups.com 
Subject: Model inheritance extended.

Hi everyone, 

This may be interesting to some of you. I created a small library for 
inheritance of a set of models.
It's best to go quickly through the Readme on the site below.

We felt a need for this, but I'm wondering whether some kind of inheritance 
like this has been discussed before. And whether, if useful, this would make a 
candidate for django.db.

https://github.com/citylive/django-model-blueprint

Cheers,
Jonathan
-- 

Daniel Sokolowski
http://webdesign.danols.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.

Re: Python 3 - style question

[Daniel Sokolowski]

I prefer Proposal 2 out of the list, and regarding Russell's point I 
believe that the tutorial ought to promote Python 3 and be written from 
that perspective with Python 2 exceptions -  because exactly of Django's 
importance in the Python landscape.


Thanks and good day.

On 09/08/2012 19:35, Russell Keith-Magee wrote:

On Fri, Aug 10, 2012 at 4:58 AM, charettes <charett...@gmail.com> wrote:

I think this will only be an issue for django application maintainers.

IMHO, projects target a specific version of python and won't have to provide
python 2-3 compatibility. Am I wrong?

Yes and no.

On the one hand -- yes. Jo(sephin)e Public is here to write some code,
and it's going to be for their own purposes, which means they've
already picked a Python version, and so making their code
cross-version isn't important.

However, on the other hand, if you're "doing it right™", *every* app
is a reusable app, and teaching best practices is important. Like it
or not, Django is a major part of the Python ecosystem, and a lot of
people look at us as an example of what best practices look like.

My suggestion would be to look at a fifth option. Lets remember that
this is a training exercise, and for many of our user base, this is
their first exposure to Python. If we overload complexity in the
basics, they're going to come to the conclusion that Python is nasty
and horrible.

So - let's write the initial tutorials targeting a specific version,
but provide hints/directions indicating that there is a bigger picture
to consider:

  a) There should also be an aside at the start of section 1 of the
tutorial quickly explaining the Python version landscape to those that
aren't familiar with it, and explaining how the tutorial will handle
this landscape.

  b) Write the docs as Py2, with "Py3 admonition" whenever there's a
difference between the two. I haven't done a full audit of the
tutorial, but there shouldn't be *too* many of these.

  c) Add a new tutorial section indicating how to write cross-version
Python. For that document, I agree that Aymeric's option 2 looks
attractive, because it's the version that is the easiest to clean up
when the time comes to deprecate Py2 (although I wouldn't complain if
we packaged a pre-canned version of the lambda function in
django.utils)

Over time, we could change the primacy of the docs from Py2 native
(with Py3 warnings) to Py3 native (with Py2 warnings), until we
finally deprecate Py2.

In the interest of keeping the tutorial clear, I *might* be convinced
to drop step (b) entirely. This would mean we still have a Py2
tutorial, but with a couple of clear pointers towards best practices
(one indicating that there is a bigger picture to consider, and one
showing how to paint that picture). However, that would leave native
Py3-only users high and dry, which isn't exactly ideal.

Yours,
Russ Magee %-)




--
Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/
Office: 613-817-6833
Fax: 613-817-5340
Toll Free: 1-855-5DANOLS
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review re-transmission dissemination or other use of or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error please contact the 
sender immediately by return electronic transmission and then immediately 
delete this transmission including all attachments without copying distributing 
or disclosing same.

--
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: portable django development environment

[Daniel Sokolowski]

Hi Michael, I have made the change but feel free to do so in the future 
as it publicly editable wiki.


Good day - Daniel.

On 21/07/2012 07:52, Michael wrote:

Hello

On the DjangoResources page: 
https://code.djangoproject.com/wiki/DjangoResources
There is a link to a portable Django development environment for 
Windows. "Instant Django" but the website does not exist anymore.


Since I needed a portable Django development environment for Windows 
and could not find any working solution, I went through it and made a 
tutorial for people looking for the same thing.


Maybe the broken link can be replace by my tutorial ? What do you think?
http://webdevon.com/setting-up-a-django-development-environment-from-scratch-on-windows/ 



Best
Michael
--
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/-/mGfyVj7hgxEJ.

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.



--
Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.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.

Re: Model equality in inheritance cases

[Daniel Sokolowski]

I would also throw this ticket into the mix - 
https://code.djangoproject.com/ticket/11154, it's related and has bit me in 
the past.


-Original Message- 
From: Anssi Kääriäinen

Sent: Monday, July 16, 2012 3:07 PM
To: Django developers
Subject: Model equality in inheritance cases

I was looking through some old tickets, and spotted a case which I had
worked on some time ago. The case is about model instance equality in
different inheritance situations. There are three different cases to
consider (assuming primary keys match):
 - should a proxy model be equal to its proxy parent?
 - should a inherited model be equal to its parent instance?
 - what to do in model multi-inheritance cases.

My take is that proxy models should be equal to their parent
instances, otherwise inherited models should not equal their parent
instances. The reasons for this are backwards compatibility,
performance and achieving correctness for all cases.

I won't go into details of what kind of problems multitable multi-
inheritance causes for achieving correctness. Suffice to say that it
is possible to construct cases where is it very hard to tell if two
models should be equal or not. Refer to ticket #16458 for more
details.

The backwards compatibility issue is in my opinion enough to say "no"
to the multitable-inheritance case. Django has one use in admin which
downright breaks when child models are equal to their parent models.
User code could have similar problems, too.

Writing a patch for proxy model equality is straightforward. Writing a
patch which takes all the corner cases of multitable multi-inheritance
in account is not trivial at all.

So, I propose to go forward with proxy model equality. Doing something
to this long standing issue would be welcome in any case.

For more dirty details, see ticket #16458. Tickets #11892 and #14492
are related.

- Anssi

--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.

To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.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.

Re: I think adding a "first" method to the QuerySet be useful.

[Daniel Sokolowski]

Shouldn’t it make sense to make it:

User.objects.first() ?

I assume first() is just a custom method on the objects manager, which would 
mean you could chain them, and so have objects.all().first(); this also makes 
the code more readable in a  template:
{{ users.first }} as opposed to {{ users.all.0 }}
I am +1, and if we are doing this might as well add last(); I don’t see any 
harm of adding this to the API, but I agree with Alex that I expect it to raise 
Model.DoesNotExist for consistency.
From: Maxime Haineault 
Sent: Tuesday, July 03, 2012 12:27 AM
To: django-developers@googlegroups.com 
Subject: I think adding a "first" method to the QuerySet be useful.

One of the common pitfall I come across way to often with novices is something 
like this:

def getFirstUser():
return User.objects.all()[0]

It looks innocuous and often wont raise any exceptions in dev because you 
develop and test with data,
so they slip easily in production.

def getFirstUser():
return User.objects.all().first()

If the QuerySet is empty it should just return None instead of raising an 
exception.

Other methods like .last() could probably also be useful, but getting the first 
element of a QuerySet
is the pitfall I see the most often.

Surprise Poney Quizz: which is the fastest way to get the first object of a 
QuerySet ?

A) Using count:


qs = User.objects.all()if qs.count() > 0:return qs[0]else: 
return NoneB) Convert to list:
r = list(qs[:1])if r:   return r[0]return None

C) Using len:


qs = User.objects.all()if len(qs) > 0: return qs[0]else:
return NoneD) Try/except:

qs = User.objects.all()try: return qs[0]except IndexError: 
return NoneThose examples have been taken from this post on StackOverflow 
(which also contains the 
answer):http://stackoverflow.com/questions/5123839/fastest-way-to-get-the-first-object-from-a-queryset-in-django--
 
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/-/JleI1VvzPXIJ.
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.

Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.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.

Re: ModelForms and the Rails input handling vulnerability

[Daniel Sokolowski]

in favour of keeping this is if we don't, people will just
use 'fields = [f.name for f in MyModel._meta.fields]' anyway.

== Option 2: the retains some of the convenience of option 1, while
encouraging more careful handling of "sensitive" models.

== Option 3: the most secure, the least convenient. You have to list all
fields for every ModelForm (except for cases of sub-classing forms,
where the base class's Meta.fields would still work, of course).
"Explicit is better than implicit".

The option doesn't make an assumption that models are either 'sensitive'
or not. It is also more consistent than option 2: if you add a field to
a model, you know that if it is meant to be publicly editable, you have
to edit the ModelForms to add it, and if it is not meant to be editable,
you don't, because the list is always "opt in".

~  ~  ~

So - discuss! If you have other options to bring to the table, please
do. Apologies to the core devs if I missed or misrepresented something.


Thanks,

Luke


[1] http://chrisacky.posterous.com/github-you-have-let-us-all-down
[2] http://weblog.rubyonrails.org/2012/3/21/strong-parameters/

--
OSBORN'S LAW
   Variables won't, constants aren't.

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



Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/
Office: 613-817-6833
Fax: 613-817-4553
Toll Free: 1-855-5DANOLS
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material. Any review re-transmission dissemination or other use of or taking 
of any action in reliance upon this information by persons or entities other 
than the intended recipient is prohibited. If you received this in error 
please contact the sender immediately by return electronic transmission and 
then immediately delete this transmission including all attachments without 
copying distributing or disclosing same.


--
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: Glad site is being brought back.

[Daniel Sokolowski]

Super legendary, thank you for your efforts.

-Original Message- 
From: Bruno Renié

Sent: Wednesday, June 06, 2012 10:47 AM
To: django-developers@googlegroups.com
Subject: Re: Glad site is being brought back.

On Wed, May 30, 2012 at 10:30 PM, Daniel Sokolowski
<daniel.sokolow...@klinsight.com> wrote:
Please disregard this message, it was meant as a reply to a thread not a 
new

thread.

-Original Message- From: Daniel Sokolowski
Sent: Wednesday, May 30, 2012 12:35 PM
To: Django developers
Subject: Glad site is being brought back.


I was just about to post a public message to Simon Willison urging him
to shut it down or fix the site when I found this thread.

I wish to say thank you and am very grateful that you are fixing and
bringing the service back.

On unrelated note would it be possible to change my username on the
site from: djangopeople.net/danols/ to djangopeople.net/
danielsokolowski/ ?


As announced on the Django weblog, people.djangoproject.com is live :)

The code currently lives on my github account [0]. Feel free to submit
issues and pull requests if you have ideas for improvements on the
site. I'll look at renaming usernames, in the meantime if you need
anything custom just get in touch privately.

Bruno

[0] https://github.com/brutasse/djangopeople

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



Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/
Office: 613-817-6833 


--
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: Glad site is being brought back.

[Daniel Sokolowski]

Please disregard this message, it was meant as a reply to a thread not a new 
thread.


-Original Message- 
From: Daniel Sokolowski

Sent: Wednesday, May 30, 2012 12:35 PM
To: Django developers
Subject: Glad site is being brought back.

I was just about to post a public message to Simon Willison urging him
to shut it down or fix the site when I found this thread.

I wish to say thank you and am very grateful that you are fixing and
bringing the service back.

On unrelated note would it be possible to change my username on the
site from: djangopeople.net/danols/ to djangopeople.net/
danielsokolowski/ ?

Daniel Sokolowski

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

Glad site is being brought back.

[Daniel Sokolowski]

I was just about to post a public message to Simon Willison urging him
to shut it down or fix the site when I found this thread.

I wish to say thank you and am very grateful that you are fixing and
bringing the service back.

On unrelated note would it be possible to change my username on the
site from: djangopeople.net/danols/ to djangopeople.net/
danielsokolowski/ ?

Daniel Sokolowski

-- 
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: GitHub migration done!

[Daniel Sokolowski]

Adrian, excellent job and thank you! Curious what five open-source on 
Subversion you are referring to?


-Original Message- 
From: Adrian Holovaty

Sent: Friday, April 27, 2012 11:08 PM
To: django-developers@googlegroups.com
Subject: GitHub migration done!

On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty <adr...@holovaty.com> 
wrote:

We're going to do the migration to GitHub today. This means we'll no
longer be committing code to our Subversion repository. Committers,
please hold off on making commits until the migration is done.


OK, it's live!

https://github.com/django/django

A few quick points (though this definitely deserves a more in-depth 
writeup):


* I renamed the old (mirror) repository to
https://github.com/django/django-old. We had talked about deleting it
outright to avoid confusion, but I realized at the last minute that
doing so would have deleted all the pull requests. I didn't want to
throw all of that out, and I think we can figure out a way to use
those pull requests in the new repository.

* I only migrated trunk (now called "master"), rather than including
all of the branches. This was the result of a bunch of discussion on
IRC with Brian R., et al. The thinking is that it kept the migration a
lot cleaner/simpler, and we can always add branches later. Of course,
we'll need to create the latest release branches. Otherwise, we can
consider the SVN branches on an individual basis.

* As expected, all forks of the old repository are now broken. Can
somebody volunteer to write some documentation on how to upgrade your
old fork to use the new upstream repo (rebase? simple patch?)?

* We're going to keep the Subversion repository around indefinitely,
but it'll no longer be updated.

* We're going to keep using Trac for tickets, but pull requests on
GitHub are also welcome.

* Clearly there are lots of bits of process that need to be updated
now, from the django-updates mailing list to our "contributing"
documentation, etc. We'll take care of all of that in the coming days,
and we should all expect some degree of confusion and unsettlement in
the community. That's totally fine, and we'll get through it. :-)

* Finally, big thanks to the folks on IRC today who helped me through
the process and contributed good ideas.

I'm planning to write up a blog post on how the process went, for the
benefit of the five open-source projects still using Subversion.

Adrian

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



Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.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.

Re: Django Admin Revamp - Any updates?

[Daniel Sokolowski]

On that note, why can't the fruits of Grappelli be used as a starting point?

-Original Message- 
From: h3

Sent: Friday, April 27, 2012 4:01 PM
To: Django developers
Subject: Re: Django Admin Revamp - Any updates?

I don't know the status of this project, but my guess is that you
shouldn't hold your breath for it.

Fortunately, there is Grappelli: 
https://github.com/sehmaschine/django-grappelli


We are currently working on making it compatible with django 1.4 (see
the "grappelli_2_4" branch)

Alternatively the branch on my fork works pretty well with 1.4:
https://github.com/h3/django-grappelli/tree/grappelli_2_4

Cheers

On Apr 26, 7:06 pm, Victor Hooi <victorh...@gmail.com> wrote:

Hi,

Is there any news on the Django Admin rewrite front?

I remember around a year ago, there was quite a bit of talk on revamping
the Django admin UI - I think Idan Gazit was heading that, right?

Is that still on the Django roadmap? Any idea of whether it'll be in 1.5,
1.6, 1.7 etc?

Cheers,
Victor


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



Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.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.

Re: Implementation of Object Permissions

[Daniel Sokolowski]

Fantastic job on the performance benchmarks, the number 4-5 seconds per check 
is scary. I’ve posted a comment on django-guradian in hopes the author can 
chime in onto this conversation by posting 
https://groups.google.com/forum/#!topic/django-developers/6UNjPu1mcgc/discussion.
  

Are there any hopes of speeding up or caching GenericForgeinKey queries ? I 
found -  
http://zerokspot.com/weblog/2008/08/13/genericforeignkeys-with-less-queries/ – 
can your solution be backward compatible?

And yes you are correct there is no GenericForeginKey on the Permission model, 
my bad; at the moment my understanding of this limits me really to just the 
opinion level. 

From: Moritz S. 
Sent: Monday, April 23, 2012 8:39 PM
To: django-developers@googlegroups.com 
Cc: tguett...@tbz-pariv.de 
Subject: Re: Implementation of Object Permissions

  With an appropriate index, SQL databases should be able to find rows matching 
a condition on two columns about as quickly as if the condition was only on one 
column, even in a table containing million of objects.

Databases can of course find the rows with appropriate indexes, but the problem 
is that GenericForeignKeys are precisely not such appropriate ones. 
  I'd like to see a benchmark before rejecting this idea on performance 
grounds. Could you point us to some data supporting your assertion that this 
isn't scalable?

To prove the increased performance I actually did some benchmark. I used the 
script in the attachment. It needs a model that has only one field called text. 
It randomly generates 10,000 users and 1,000,000 objects. Then it assigns to 
each user respectively 1,000 object permissions of randomly selected previously 
created objects. At least it checks for each user respectively 1,000 randomly 
selected objects again. That's what I got:

For the first version of my contrib.auth patch:
Summary:
granted permissions in 1 day, 10:41:07.523402
checked permissions in 22:48:44.662974

For a module using GenericForeignKeys (I used django-guardian because it seemed 
to be the most used one):
granted permissions in 11:31:12.216808
checked permissions 

I don't have the results for checking permissions with django-guardian yet 
because it took ages to check them. Each single check for a object permission 
took about 4 to 5 seconds! Now think about how long it would take to check for 
all users (10,000*1,000*4secs)! I think that is out of all proportion to my 
suggested solution.
This happens because of the lack of a appropriate index as you mentioned 
before. So the database has to do a full table scan and that's definitely not 
scalable at all.
By the way, the reason for the GenericForeignKeys being faster in creating them 
is that the database does not have to create the indexes (i.e. the foreign 
keys). 
  I'm -1 on a contrib app (django.contrib.auth) injecting a dynamic field into 
every model.

  (Yes, Django does that for the primary key, to avoid declaring it in every 
model. But it's core, not a contrib app.)

I totally agree with this but I don't see another way at the moment. 
  What's the definition of "when the auth app is initialized"? Wouldn't your 
solution required that django.contrib.auth be loaded before all other apps?

Unfortunately it does but I have a open mind about better implementations. 
  With the solution that I prefer, this doesn't seem absolutely necessary, the 
following statements are simple enough:


  ObjectPermission.objects.create(user=user, object=instance)
  ObjectPermission.objects.get(user=user, object=instance).delete()

I think that's matter of taste ;-) 

  Your need to add ‘object_permissions’ to a model is an incorrect approach in 
my opinion as it would require any old apps to undergo a schema migration. Your 
generic relations concerns might be valid however I would like to mention 
Django guardian does use generic FK but so does built in django auth – so I 
think this approach is just fine.
You don't have to add this field manually, auth app does that. And django auth 
does not use generic relationships, it only makes use of the ContentType field 
to comfortably store the type assigned to a permission. 

Best regards,
Moritz
-- 
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/-/fp-Bu8sgUq0J.
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 

Re: GitHub migration planning

[Daniel Sokolowski]

Thanks Luke for the clarification.

-Original Message- 
From: Luke Plant

Sent: Saturday, April 21, 2012 8:52 AM
To: django-developers@googlegroups.com
Subject: Re: GitHub migration planning

On 20/04/12 19:58, Daniel Sokolowski wrote:


Was BitBucket (mercurial system which is python based) not considered?
And could someone point me to a url where I can read the discussion on
this migration; I am rather curious why it’s happening – the current
system works so I see no reason to fix it.


Some of the discussion happened on django-core.

One of the reasons for this was that it affects core developers most of
all, so Adrian wanted their opinions first.

Another reason was that this kind of change is almost certainly going to
require a BDFL decision, because we will never come to consensus on Git
vs Mercurial etc. - even within the core developers they are strong
preferences in both directions, and even strong preferences to stick
with Subversion. And I guess that's the reason that we didn't have
further discussion on django-devs - since it already needed a BDFL
decision, there was no point making the pretence of discussion in a
wider forum. (Adrian/Jacob feel may correct me if I'm guessing wrongly).

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


Daniel Sokolowski
Web Engineer
KL Insight
http://klinsight.com/
Tel: 613-344-2116 | Fax: 613.634.7029
993 Princess Street, Suite 212
Kingston, ON K7L 1H3, Canada 


--
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: IDE Section for Wiki?

[Daniel Sokolowski]

Works for me, Aaron why not register for a username (or do it anonymously) 
and have the honours of adding it yourself? :)


https://www.djangoproject.com/accounts/register/


-Original Message- 
From: Aaron C. de Bruyn

Sent: Sunday, April 22, 2012 1:27 PM
To: django-developers@googlegroups.com
Subject: IDE Section for Wiki?

Since everyone lve to ask and answer questions about which IDE is
'best' for Django, I figured I'd save everyone some time and just have
a section on the wiki.

Here's my start if someone wants to post it.  I was thinking the
DjangoResources page would be good
(https://code.djangoproject.com/wiki/DjangoResources).

-A

== Integrated Development Environments ==
* [http://www.aptana.com/products/studio3/download Aptana Studio] -
"The world’s most powerful open-source web development IDE"
* [http://www.eclipse.org/ Eclipse] - "an open development platform
comprised of extensible frameworks, tools and runtimes for building,
deploying and managing software across the lifecycle."
* [http://eric-ide.python-projects.org/ ERIC] - "Eric is a full
featured Python and Ruby editor and IDE, written in python."
* [http://www.geany.org/ Geany] - "Geany is a text editor using the
GTK2 toolkit with basic features of an integrated development
environment."
* [http://www.activestate.com/komodo-ide Komodo IDE] - "The
Professional IDE for Python, PHP, Ruby, !JavaScript, Perl, Web and
Cloud Dev"
* [http://webpages.charter.net/edreamleo/front.html LEO] - "A premier
Integrated Development Environment, fully scriptable using Python."
* [http://notepad-plus-plus.org/ Notepad++] - "Notepad++ is a free
source code editor and Notepad replacement that supports several
languages. Running in the MS Windows environment, its use is governed
by GPL License."
* [http://www.jetbrains.com/pycharm/ PyCharm] - "Python IDE with
complete set of tools for productive development with Python
programming language."
* [http://pydev.org/ PyDev] - "!PyDev is a Python IDE for Eclipse,
which may be used in Python, Jython and !IronPython development."
* [http://code.google.com/p/pyscripter/ PyScripter] - "An open-source
Python Integrated Development Environment (IDE)"
* [http://scribes.sourceforge.net/ Scribes] - "Simple, slim and
sleek, yet powerful."
* [http://pythonide.stani.be/ SPE IDE] - Free python IDE for Windows,
Mac & Linux with UML, !PyChecker, Debugger, GUI design, Blender & more
* [http://code.google.com/p/ulipad/ ulipad] - "Ulipad is a wxPython
powered, programmer oriented and flexible editor."
* [http://wingware.com/ WING IDE] - "The Intelligent Development
Environment for Python Programmers"

--
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: GitHub migration planning

[Daniel Sokolowski]

Thank you Alex and Max for your responses.

-Original Message- 
From: Alex Ogier

Sent: Friday, April 20, 2012 3:15 PM
To: django-developers@googlegroups.com
Subject: Re: GitHub migration planning

On Fri, Apr 20, 2012 at 2:58 PM, Daniel Sokolowski
<daniel.sokolow...@klinsight.com> wrote:

Was BitBucket (mercurial system which is python based) not considered? And
could someone point me to a url where I can read the discussion on this
migration; I am rather curious why it’s happening – the current system 
works

so I see no reason to fix it.


Well there are two somewhat related questions in play. One is moving
Django's master repository to Git from SVN. This has a lot of support,
as Git is significantly more powerful and many (most?) Django
developers already use the Git mirror.

The other debate is about switching to Github as a hosting platform.
It already hosts the Git mirror, and people regularly submit pull
requests, a feature made possible by Git and that is being considered
as an alternative to submitting patches. Github Issues are basically
unacceptable for Django's process, so they have never been seriously
considered as far as I know.

There is a large social benefit to leveraging github: there is a large
community of developers with established presences there, and making
Django accessible to that community is valuable. BitBucket does not
have the same social benefits, and all the same drawbacks, so I don't
think anyone would seriously advocate moving there.

Best,
Alex Ogier

--
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: GitHub migration planning

[Daniel Sokolowski]

Was BitBucket (mercurial system which is python based) not considered? And 
could someone point me to a url where I can read the discussion on this 
migration; I am rather curious why it’s happening – the current system works so 
I see no reason to fix it.
From: Max Thayer 
Sent: Friday, April 20, 2012 1:26 PM
To: django-developers@googlegroups.com 
Subject: Re: GitHub migration planning

Luke, maybe I don't understand something about Trac, but some of the issues 
raised by you or those you quoted seem easily fixed. Consider: 

  "- there isn't a notion of "component", so there's no way to ask "give me
  the list of all contrib.auth tickets, so I can find the duplicate quickly";"

Why not tag all relevant issues "contrib.auth"?

  "- it's hard to navigate when there are more than 200 open tickets on a
  project."

There are easily that many open tickets on Trac (a quick look seems to indicate 
there are about 2k open tickets). What about Trac makes the number of open 
tickets a non-issue?

  "- we can't put customized flags on tickets (easy, ui/ux) -- there are
  tags, but the result of the "Keywords" field in Trac shows the limits of
  unstructured tags;"

Could you explain this more? "customized flag" sounds exactly like a tag.

Best regards,
Max

On Fri, Apr 20, 2012 at 3:21 AM, Luke Plant <l.plant...@cantab.net> wrote:

  On 18/04/12 22:44, philipn wrote:
  > Hey folks!
  >
  > I started a wiki page to help plan a migration to GitHub:
  >
  > https://code.djangoproject.com/wiki/GitHub%20Migration
  >
  > I don't know what I'm doing, but I do know that the current Trac setup
  > (attaching patches, etc) is less accessible to non-core contributors
  > than GitHub and I'd love to do anything I can to help make this better.


  In discussing the move to GitHub on django-core, we fairly quickly came
  to the conclusion that we wouldn't be using GitHub issues.

  One of my major points in this discussion was the need to be able to
  import our current Trac database, because otherwise we are throwing away
  a huge amount of important history. As a core committer I regularly
  trace history to work out why a certain change was made, and often find
  myself looking at bugs on Trac and reading the discussion there.

  But importing our Trac database to GitHub issues would be basically
  impossible as it doesn't support attachments, and various other things -
  we would lose a huge amount of info if we attempted to port our current
  Trac database.

  There were a fair amount of other objections too. Some copy and paste
  from that thread:

  Aymeric wrote:
  """
  I just looked at it again and here's what I noticed:
  - there is no workflow, so we lose the ability for the community to
  triage tickets;
  - we can't upload patches (which forces every contributor to sign up for
  GitHub and learn git) or arbitrary files (like logs, screenshots,
  tracebacks: not everything is a pull request);
  - there isn't a notion of "component", so there's no way to ask "give me
  the list of all contrib.auth tickets, so I can find the duplicate quickly";
  - we can't put customized flags on tickets (easy, ui/ux) -- there are
  tags, but the result of the "Keywords" field in Trac shows the limits of
  unstructured tags;
  - it's hard to navigate when there are more than 200 open tickets on a
  project.
  """

  Justin Bronn wrote:
  """
  GitHub's issue tracker is so much worse than Trac I don't know why we're
  even considering it.  I can attest it has NOT gotten better with age,
  and large projects on GitHub can't use it either.  For example, both
  Chef and Puppet are hosted on GitHub yet use their own ticket solutions
  (Puppet uses Redmine, Chef uses Jira).  The Pinax folks wrote their own
  issue system rather than using GitHub's!
  """

  Cheers,

  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-developers@googlegroups.com.
  To unsubscribe from this group, send email to 
mailto:django-developers%2bunsubscr...@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: Implementation of Object Permissions

[Daniel Sokolowski]

 the Meta.object_permissions set to True (for this to work, this 
meta attribute has to be set in django.db.models.options)
- the User model gets the methods grant_perm and revoke_perm that takes the 
permission and as optional argument the object in order to simplify the process 
of handling permissions
- in the ModelBackend the methods has_perm, etc. have to be modified to be able 
to handle function calls with given objects (obviously)

So that was the technical part.

Now I want you to give feedback if this implementation is viable and maybe 
sometimes may get into django.


Thanks,
Moritz
-- 
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/-/WbQ6EMVuxqkJ.
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.


Daniel Sokolowski
Danols Web Engineering
http://webdesign.danols.com/
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review re-transmission dissemination or other use of or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error please contact the 
sender immediately by return electronic transmission and then immediately 
delete this transmission including all attachments without copying distributing 
or disclosing same.

-- 
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: extra files in startproject

[Daniel Sokolowski]

Hi Carl,

Looks fine to me, and I think throwing the warning at the end is indeed a 
good idea.


-Original Message- 
From: Carl Meyer

Sent: Friday, April 13, 2012 2:20 PM
To: django-developers@googlegroups.com
Subject: Re: extra files in startproject

--
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: extra files in startproject

[Daniel Sokolowski]

You sir are Epic!

-Original Message- 
From: Carl Meyer 
Sent: Friday, April 13, 2012 10:33 AM 
To: django-developers@googlegroups.com 
Subject: Re: extra files in startproject 


--
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: extra files in startproject

[Daniel Sokolowski]

People won’t always read all the docs – it’s a fact – so sooner or later some 
other new comer will experience this issue complain, gave up and worse even 
blog his/hers negative experience. We do want the newbie experience to be as 
painless as possible which means popularity and growth of the framework - and 
ultimately continuation of our paying jobs.

This thread was started by a newbie to the framework, putting aside the 
confrontational tone it stated some valid concerns from a beginners perspective 
– a very important perspective. 

I’ve been using django for a long time and had no idea about this ‘distutils’ 
caveat; I do not understand or know how django installs setup process works but 
am up for some kind of a warning/error directly to the console.

Thank you for reading my opinion.

Daniel
From: Florian Apolloner 
Sent: Friday, April 13, 2012 2:15 AM
To: django-developers@googlegroups.com 
Subject: Re: extra files in startproject



On Friday, April 13, 2012 6:49:32 AM UTC+2, Alex Ogier wrote: 
  I have seen setup.py's that use remove_tree as part of a "clean" command
  to allow someone to run "setup.py clean && setup.py install" to obtain
  a pristine distribution idempotently, which I think is a good idea.


No, they should work on fixing distutils instead of creating solutions which 
probably could break even worse.
 

  The alternative is to have everyone remember to "rm -rf" their
  site-packages django every time they run setup.py install which is a
  bit unsavory in my opinion.

Or just tell them to use either pip even for development installs or just set 
their PYTHONPATH.
 

  If someone has managed to get extra files in their site-packages,
  because at any point they followed a tutorial on how to build from
  source, then their django installation is basically caput until they
  manually "rm -rf" a deep library path. One option is to document this
  and explain what to do

You made me lol, that approach is documented in the install guide: 
https://docs.djangoproject.com/en/dev/intro/install/#remove-any-old-versions-of-django
 -- If people would actually read the docs this issue wouldn't exist. FWIW the 
docs also mention to symlink a dev checkout and don't tell you to run setup.py
 

  That would mean listing somewhere the files from
  django/conf/project_template/ that should be included, which isn't
  very DRY, but is the only 100% solution I think.

Given that the documentation shows how to do it properly I don't see any point. 
Especially since this problem isn't related to the project_template alone -- 
that's just where it's most visible.

 
  So, that should give you some idea of the perils of not cleaning your
  output directories (or in this case, input directory).

We are aware of those, and fwiw: If you use git and switch branches it's up to 
you to know how python works and how git clean works, or do you want to suggest 
that django should rm al pyc files on startup?!
 
  My recommendation is to make "setup.py clean" do everything possible
  to ensure idempotent installation across any version, document that,
  and call it a day. 

What's wrong with the current documented approach? (Aside from the fact that 
people don't read it, but then again they won't read the setup.py clean 
either). 

Regards,
Florian

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

[Daniel Sokolowski]

Would it be hard for django to check during syncdb and complain that a 
schema migration is required for an app? I vaguely recall being stumped 
myself after changing a model, running syndb and getting my first database 
integrity error. I believe even a NOTE in the tutorial clarifying that 
schema migration is not automatic yet would be sufficient.


First impression of new comers to django are rather important I believe.

-Original Message- 
From: Russell Keith-Magee

Sent: Wednesday, April 11, 2012 8:54 AM
To: django-developers@googlegroups.com
Subject: Re: Django is not a serious framework, really


On Wednesday, 11 April 2012 at 8:10 PM, Jason Ma wrote:

Hi,
I download and tried to use the Django 1.4 yesterday. I am a dummy
and I just follow the official document, but When I just start a
project.
I found that it is what I see from my computer:

jason@jason-pc:~/workspace/hunqing$ tree .
.
├── hunqing
│ ├── __init__.py
│ ├── __init__.pyc
│ ├── settings.py
│ ├── settings.pyc
│ ├── urls.py
│ ├── urls.pyc
│ ├── wsgi.py
│ └── wsgi.pyc
├── __init__.py
├── manage.py
├── settings.py
└── urls.py

but what doc say?
mysite/
manage.py
mysite/
__init__.py
settings.py
urls.py
wsgi.py


First rule: If you're following a tutorial and want to follow along, you 
need to actually follow the instructions as given. The tutorial asks you to 
type:


django-admin.py startproject mysite


From the looks of it, you didn't type that. You typed:


django-admin.py startproject hunqing

Furthermore, you've evidently run some of the code before you looked at the 
directory structure. .pyc files are the Python runtime's precompiled byte 
code output. If you look at the directory structure at the point the 
tutorial asks you to, you shouldn't see any .pyc files.


If you're using an IDE, it's possible the IDE might have compiled these 
files for you. Regardless, the existence of .pyc files shouldn't be a 
surprise to anyone that has used Python before. Django's installation guides 
tells you that you're going to need to install Python -- that should be 
enough of a hint that you're probably going to need to know a little bit 
about Python in order to use Django. Django's tutorial can't -- nor should 
it -- teach you everything there is to know about Python. At some point, we 
have to assume that you're going to learn the language that Django uses.

If you're a beginner, what are you going to say, yes, F! Why I created
more files? I heavily doubted that whether the writers have tested
that carefully. Ok, forget that, We'll see and continue.


We've checked the tutorial quite carefully. To be doubly sure, I've just 
worked through the start of the tutorial myself to make sure it matches what 
is described -- and it does. If you follow the instructions as written, you 
should get the output as described. If you don't follow the instructions as 
written, then its anyone's guess what you'll get.

In the later chapter, we created two classes in the models.py in
polls, I do all the steps same as the doc except that one columns
name, mine is questions whereas the doc is question, so I want to test
the power of the syncdb, I modified the model.py and I just do the
python manage.py sql polls, that's ok, it is correct name this time.
So I just run it to change it in database using python manage.py
syncdb, it works too. But go to the db and see, the table is not
changed at all. I want to say F again now. That's what doc say:

The syncdb command runs the SQL from sqlall on your database for all
apps in INSTALLED_APPS that don't already exist in your database. This
creates all the tables, initial data and indexes for any apps you've
added to your project since the last time you ran syncdb. syncdb can
be called as often as you like, and it will only ever create the
tables that don't exist.

That's gr8, If you just create the tables that don't exist, why do you
syncdb successfully? One basic rule of database is consistence, if you
can't created the tables you want, why don't get alert? I am not a
good programmer though, I do know if you can't do something, just say
it. How can I know the error without any prompt?


But it *does* give you a prompt.

When you run syncdb, the output tells you exactly what has, and what has 
not, been created.


So, if a table for myapp.MyModel has been created, in the output of syncdb 
you'll see a message that looks something like:


Creating table myapp_mymodel

If you then go and modify MyModel, and then run syncdb again, you won't see 
this message. That means that the table hasn't been created as a result of 
your syncdb call. If you run syncdb, and you *don't* see a "Creating table" 
message that you were expecting, then you should probably go looking to see 
why.

There are many people saying the Django is well-documented, do you
still think it is true?


I may be biased, but I certainly think so.

If you print Django's documentation, it runs to over 900 pages. That's not 
900 pages of auto generated 

Re: auth.user refactor: the profile aproach

[Daniel Sokolowski]

How is the final approach chosen ?

From: Alex Ogier 
Sent: Friday, April 06, 2012 2:31 PM
To: django-developers@googlegroups.com 
Subject: Re: auth.user refactor: the profile aproach

Tai, read https://gist.github.com/2289395 for a summary of many reasons why I 
think profiles are a bad idea, and unifying multiple profiles is an even worse 
idea. 

Best,
Alex Ogier


On Fri, Apr 6, 2012 at 6:15 AM, Tai Lee  wrote:

  Alex Ogier,

  Is it really better to require users to create their own User model that 
behaves like an admin user, instead of just shipping with a self contained 
admin user (as a profile model) without the auth component?

  If the auth app was purely a stub to connect different profiles and 
authentication systems from different apps (or the project), but doesn't 
actually define any identity or authentication or profile models itself (not 
counting base abstract classes), isn't that effectively achieving the 
separation that you want? Being able to use admin without the current cruft in 
auth or with any completely different authentication credentials, and similarly 
using any other pluggable app without any cruft needed by the admin.

  In any case, I don't think it will actually be possible to use the admin or 
any other pluggable app that relies on the concept of a central user who might 
access to multiple apps (instead of every app having its own users and auth) 
without *an* auth app and a central User model.

  Like Adrian, I don't actually use the User model for auth or identity (name, 
email, etc.) anymore. But unless you have authored *all* the apps in your 
project and they know how to talk to *your* User model, you still need a User 
from Django, because that is what all 3rd party pluggable apps will need.


  If I want to use any 3rd party apps that use the central user, I will still 
need to create a Django User and fake or sync the that are only there for the 
admin, even if I don't use the admin. If you still require swapped in User 
models to assume a minimal interface and fields, people will still have this 
problem.


  This is why I think the central User should not contain any auth or identity 
data, so there is no cruft required only for apps you may not even be using, 
and so you are not tied to any particular auth system.

  Cheers.
  Tai.


  On 06/04/2012, at 3:44 PM, Alex Ogier  wrote:


I think this proposal will make more sense if people stop thinking "If 
someone wants to use contrib.auth, then why do we need another crufty interface 
to swap out auth.User?" Instead think of someone who wants to use contrib.admin 
but not be stuck with contrib.auth.

The point of this proposal isn't to make contrib.auth larger and better, 
it's to make it unnecessary. A lot of people find contrib.auth's models 
unsatisfactory. Adrian Holovaty stated that he hasn't used auth.User for 
several years. When you have a complex site with multiple authentication 
methods and requirements that don't fit django's idea of a user, it stops being 
worth it to bend yourself to django's will. The problem is that contrib.auth 
and contrib.admin are currently intimately linked. This proposal's purpose is 
to give an official way to break these two apart.

I don't know of a single framework out there besides Django that ships with 
a fixed model for its users. The reason is that authentication and identity are 
radically different for every site so it's tremendously important to support 
whatever people decide to do, and not force decisions on them.

So, stop thinking just in terms of contrib.auth.models.User. If you're 
already using that with a profile and it's all working fine, then this change 
isn't for you. This is for everyone who just wishes auth.User would go away 
without totally borking admin.

Respectfully,
Alex Ogier

On Apr 6, 2012 1:21 AM, "Donald Stufft"  wrote:

  Nothing about this proposal prevents this.

  And in that case, no those 2 apps would not be able to be used together. 
But this is hardly the first 
  time that 2 apps cannot be used together. because of choices made like 
that on the app owner.
  On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote:

I very much share Tai's concerns about the swappable user model 
introducing incompatibilities. Imagine two apps, each of which requires an 
"age" attribute on the user model. But suppose one of those apps expects age to 
be the number of years since that user's birth and one of those apps expects 
the age to be the number of years since the user registered for the website. 
The user model must provide the same attribute to both apps, but it is supposed 
to have a different value for each app. A developer will be unable to use these 
two apps together without patching one of them. 

A bit of a contrived example, maybe, but I can imagine this 
same-name-different-purpose issue 

Re: auth.user refactor: the profile aproach

[Daniel Sokolowski]

No I can not stomach a swappable User model or the LFK approach, so thank you 
for voicing your concerns.

From: Tai Lee 
Sent: Wednesday, April 04, 2012 9:37 PM
To: django-developers@googlegroups.com 
Subject: Re: auth.user refactor: the profile aproach

Are we really sure that we can or should stomach a swappable User model as a 
special case?

It's highly likely that I am missing something (or a few things), but aren't 
the main benefits of swapping the User model just to avoid making a backwards 
incompatible change, and to avoid making `select_related()` queries?

I'm not suggesting that backwards incompatibility is not important, but I'm not 
convinced by the argument about inefficient `select_related()` queries, and 
whatever we do will involve manual schema migration for many users.

Do we really need to allow users to swap in their own model with a combination 
of additional project level fields as well as additional fields required by 
various pluggable apps as the primary `User` model, instead of simply stripping 
out authentication and identifying fields from the primary `User` model and 
allowing users to implement whatever they need as app or project level profile 
models?

The more I think about it, the more I think this will just lead to more 
fragmentation and incompatibilities with pluggable apps, when the user 
"interface" is abused or causes conflicts.

What's going to happen when this is rolled out and people start developing an 
eco-system of pluggable apps without a concrete `User` model in Django? All 
they can rely on is that there will be some form of `User` model and that it 
*should* provide at least a minimal set of fields and behaviours as specified 
by some guidelines in Django docs?

Won't we just be back at square 1 in deciding what to include in the minimal 
fields and guidelines for the this "contract"? Isn't the only sensible minimal 
set of fields, no fields at all?

Pluggable apps will have to either dictate to developers in the installation 
instructions that their particular `User` model must have certain fields or 
behaviours that are required by the pluggable app, which may even conflict with 
other pluggable apps. Or they will still have to fallback to using an 
app-profile model, which brings us back to using `select_related()` anyway. I 
don't like the idea that a pluggable app might require users to change their 
existing models like this.

If pluggable apps will still need to use app-profile models anyway, if we can 
get past the backwards incompatibility issue, what is so bad about simply 
having a `User` model which has no auth or identity data in it, but is just 
there as glue for for apps to share data for a single "user"?

Bundled apps like the admin would define `AdminProfile` and any pluggable apps 
that require or support the admin could access `user.admin_profile`. Pluggable 
apps that don't use the admin and/or have their own auth or identifying 
requirements can just ship with their own profile and/or auth models and 
optional auth backend.

The only real issue I have with Django users/auth as it is right now is that 
there are redundant (for me) or non-compliant (with RFC) fields in `auth.User` 
that are required and that I have to fake in order to hook into the admin, 
groups and permissions or re-specify in my own profile for RFC-compliance.

The other problem I have seen mentioned with the profile approach is managing 
common fields (e.g. two pluggable apps that have a "name" field). I'm quite 
happy for this to be managed by the developer at a project level, either using 
signals or forms or a `save()` method on their profile model or whatever else 
they like to keep that data in sync, if it needs to be kept in sync.

I don't think pluggable apps requiring that developers have a "name" (for 
example) field on their primary `User` model is really a good solution to this 
problem, because the pluggable app doesn't know what other purpose that field 
is used for, and doesn't know if it is changed in app1 if it will have any 
consequences for app2.

If developers really want a single project level `User` model, they can still 
create that (with an FK back to Django's `User` model), and simply update it's 
`save()` method to sync any common fields on all the pluggable app's profile 
models (which may even have different field names). E.g. `project.User` could 
have `first_name` and `last_name`, but app1 has only `name`, and app2 has 
`given_name` and `family_name`. In `project.User.save()`, the developer of a 
project can determine how to sync this data.

Cheers.
Tai.


On Thursday, 5 April 2012 00:57:57 UTC+10, Jacob Kaplan-Moss wrote: 
  On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote:
My point is that there is nothing about this problem that is unique to 
User. Django's own codebase contains another example of exactly the same 
pattern -- Comments. 
  As the original author and designer of that pattern, I should probably 

Re: auth.user refactor: the profile aproach

[Daniel Sokolowski]

Can someone give me an example please where a swappable model would benefit 
me as opposed to one-to-one model inheritance, FKs, or even proxy models? 
Django does this very well and allows

for seamless up/down traversal.

It seems that swappable models are nothing but a different way of doing what 
I already am doing for when I am extending the flat pages; except that it 
ads a nice centralized SWAPPABLE_MODELS setting.
Furthermore if I do make a swappable custom user model the correct 
implementation of 'standard' User methods depends on me; sure I could extend 
a the base User model and inherit these methods but then

what did I gained by having this swappable model concept?

The more I think about it the more it makes sense to me to have a base User 
model just a stub with a user Identifier and password field. Sure one could 
argue for less ore more fields, but I think the idea
is to pick something that would work in 95% situations and yet be flexible 
enough to be extended as you wish. Need to extend to add your own 
authorization you create a profile with a FK key to the base model and

a new auth backend.

Perhaps the reason the current contib.auth is still not overhauled is 
because it does work for a large number of situation and extending it is 
relatively easy. Keep the solution simple - I think we are overthinking it.




-Original Message- 
From: Russell Keith-Magee

Sent: Wednesday, April 04, 2012 10:44 AM
To: django-developers@googlegroups.com
Subject: Re: auth.user refactor: the profile aproach


On 04/04/2012, at 8:44 PM, Tai Lee wrote:

I'm not so sure that it's necessary or even desirable to solve the 
"general" problem of swappable models. If anyone can swap any model by 
changing a setting, that sounds like a recipe for confusion to me.


Sure, but that's not what I've proposed. A model would only be swappable if 
the original app developer declared that model as swappable. An end user 
wouldn't be able to arbitrarily decide that they wanted to replace a model 
in an app developed by someone else.


And sure, any feature we add could ultimately end up being used (and 
overused) in bad ways. However, that's true of any language or library 
feature. Classes, metaclasses, decorators, or any other Python language 
feature can be both used and abused, as can Django features like ModelForms 
or the internals of the Meta class.


My point is that there is nothing about this problem that is unique to User. 
Django's own codebase contains another example of exactly the same 
pattern -- Comments. Therefore, we shouldn't pretend that the solution is 
User specific. At some point, we have to just provide enough documentation 
and guidance to shepherd people away from bad architectural decisions, and 
trust that the userbase will take that advice.


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-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: auth.user refactor: the profile aproach

[Daniel Sokolowski]

I agree with Luke that more explicit is better then implicit when dealing with 
the user.data.

From: Luke Sneeringer 
Sent: Tuesday, April 03, 2012 2:46 PM
To: django-developers@googlegroups.com 
Subject: Re: auth.user refactor: the profile aproach

So, after reading this, I think I really only have a couple questions/concerns:

1. What, if anything, is the primary key on the base User model? Is it the 
identifier? If so, can it be specified as the primary key, rather than 
unique=True, db_index=True? If it's not the primary key, is it the usual 
magical id = models.AutoField()?

2. I'm a little nervous about the magical installation of Profile modules -- 
specifically, what happens once this system has been around for one to two 
years and we have a ton of these? I'm imagining a situation where there are 
lots of apps floating around, each with their own Profile subclasses that 
install behind the scenes when you install the app (and which you may or may 
not actually realize up front -- yes, a good developer *should* be aware of 
that, but that doesn't mean they will be...). What happens if a beginner writes 
everything against user.data['name'], and then installs an app that adds a new 
name, which is unordered and magically ends up on top, and therefore introduces 
new, unexpected, and, most importantly, extremely difficult to debug logic 
errors?

I agree with some of the criticisms of swappable user models, but at least the 
developer always knows what he is doing in that case. In this case, the 
behavior of your user model can change in unexpected ways when you do something 
that seems totally unrelated; some code that previously worked might either (1) 
return different data or (2) suddenly raise KeyError.

Perhaps this is the best of bad options. I agree there's a decent bit to be 
argued in favor of it, but can we figure out a less error-prone way for 
user.data to work? Honestly, I think it would be less risky to force everyone 
to write user.admin_profile.name -- it's more typing, but at least it's 
explicit. The current proposal for user.data doesn't actually pass "refuse the 
temptation to guess", because it glosses over the fact that developers *will 
guess* and then their code will stop working after what feels like a completely 
unrelated change.

3. Might I suggest that the Profile model that the admin requires be called 
AdminProfile and not DefaultProfile? It's really an admin need more than 
anything else.


Best Regard,
Luke



On April 2, 2012, at 19:35 , Jacob Kaplan-Moss wrote:


  Hi folks -- 

  I've written up a proposal for how *I* would like to address refactoring 
auth.user: https://gist.github.com/2245327.


  In essence, this does two things:


  * Vastly "prunes" the required fields on auth.user. The only things left are 
an "identifier" (which could be username, email, url, uuid, whatever), and a 
password.
  * Introduces a new "profile" system that provides a way to contribute extra 
related fields. Multiple profiles are supported, along with some syntactic 
sugar for dealing with multiple profiles in a reasonably reusable way.


  And that's about it. I'm deliberately trying to find a middle ground between 
"do the minimum to allow people to move on" and "throw out and rewrite 
django.contrib.auth entirely". I'm not expecting everyone to be thrilled by 
this idea, but I'm hoping that this is "Good Enough" for almost everyone.


  For more please see the document. Please do try to read the whole thing: I've 
had a few rounds of feedback incorporated already, and there's even an FAQ at 
the end.


  I'm not using BDFL fiat here, at least not yet. This is a proposal, and I 
very much want to hear feedback, objections, and alternatives. I'm particularly 
interested in hearing from people who've got complicated auth needs and think 
this absolutely won't work for them. 


  I *have* reviewed all the other proposals and I'm between -0 and -1 on all of 
them. This means that if you don't like my proposal, you'll probably have to 
come up with a complete *new* idea to have any chance of getting my vote.


  Thanks!


  Jacob

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


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

Re: Proposal: upgrading the choices machinery for Django

[Daniel Sokolowski]

Hi Lukash, I'm 0 to this.

I find it well thought out but in my use cases I fail to see the advantage 
over the WAY 3 (or WAY 4 pointed out below) and it adds a layer of 
abstraction where a straight tuple or a list does the job well enough.


The choice filtering could come in handy and in the end I don't see why this 
can't co-exist with django's standard way.


WAY 4:

class UserManager(models.Manager):
   GENDER_MALE = 0
   GENDER_FEMALE = 1
   GENDER_NOT_SPECIFIED = 2
   GENDER_CHOICES = (
   (GENDER_MALE, _('male')),
   (GENDER_FEMALE, _('female')),
   (GENDER_NOT_SPECIFIED, _('not specified')),
   )

   def males(self):
   """ Returns all entries accessible through front end site"""
   return self.all().filter(gender=self.GENDER_MALE)
   def females(self):
   """ Returns all entries accessible through front end site"""
   return self.all().filter(gender=self.GENDER_FEMALE)
   ...

class User(models.Model):
   gender = models.IntegerField(choices=UserManager.GENDER_CHOICES,
   default=UserManager.GENDER_NOT_SPECIFIED)
   objects = UserManager()

   ef greet(self):
   if self.gender == UserManager.GENDER_MALE:
   return 'Hi, boy.'
   elif self.gender == UserManager.GENDER_NOT_SPECIFIED:
   return 'Hello, girl.'
   else: return 'Hey there, user!'

-Original Message- 
From: Łukasz Langa

Sent: Wednesday, April 04, 2012 9:15 AM
To: django-developers@googlegroups.com
Subject: Re: Proposal: upgrading the choices machinery for Django

Wiadomość napisana przez Dan Poirier w dniu 4 kwi 2012, o godz. 14:08:


One nice addition would be to specify explicitly what .id a particular
Choice should have. It would be useful in converting existing code that
might not have chosen to number its choices the same way this proposal
does by default. It looks like you could use Choices.Group(n-1) to make
the next choice defined use id=n, but that's not very elegant.


Right. The ability to explicitly set the .id on a single choice is useful.

The only reason it's not already there is that I didn't want to write my own
`makemessages`. Then again I might do just that. My proposal is based on
a working implementation because I didn't want to fall into bikeshedding on
what could have been theoretically implemented.

What we need now to push things forward is a list of +1, +1 if ..., +0,
+0 if ..., -1, "how dare you?!" from a bunch of people.

--
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

--
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: Improved Error Reporting in Django - GSoC

[Daniel Sokolowski]

FYI: for my development settings I set: TEMPLATE_STRING_IF_INVALID = 
'UNDEFINED_VAR: %s'  which tells me which variables are undefined. 

It has some quirks (password reset form in admin link fails or something) but 
it’s easy to live with during development. 

From: Sachin Gupta 
Sent: Tuesday, March 20, 2012 3:18 AM
To: django-developers@googlegroups.com 
Subject: Re: Improved Error Reporting in Django - GSoC

Hi Andrew 

As about the silent template failure I was not very sure if it was a deliberate 
design decision, but since it a deliberate design decision I would not like to 
change it. Since I did both the backend and template editing, it appeared to me 
that some error should have come.

But I would like to make the error reporting from signals a little better. What 
I would like to do is to trace the control flow and throw the error according 
to the context of the flow. About how I plan to do that, I need to go through 
the code base thoroughly and will try to come up with a method.

I went through the https://code.djangoproject.com/wiki/BetterErrorMessages 
page. 

Today I will go into the following errors 

Some of the django.db errors and also at Ticket:#15126, when a user forgets a 
trailing comma in a single-item tuple then the error message is quite 
misleading.

Could you guide me what number of error fixes would be good work for GSOC 
proposal. Also if there are any class of Django errors that are of greater 
concern (like django.db)

Regards
Sachin

-- 
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/-/cuYearvU_OoJ.
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 by email

[Daniel Sokolowski]

Ok to recap,

The issue here is that django auth is limited, and restrictive and needs 
hacks to make it use emails as usernames, we can agree on that yes? We can 
also agree that contrib.auth2 with LFK is a complex undertaking far into the 
future?. Can we also agree that the 30 character limitation on the username 
ought to be increased?


-Original Message- 
From: Luke Sneeringer

Sent: Thursday, March 15, 2012 2:11 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

On March 15, 2012, at 12:23 , Daniel Sokolowski wrote:

Carl, I sincerely appreciate your feedback, however again it seems no 
answers are given except more questions and considerations to consider. 
Why is it so unreasonable that we expect the end developer to be able to 
manually adjust their schemas, it's part of an upgrade process and it's 
been done in the past labelled backwards incompatible changes due to bugs 
or security, perhaps 30 character limitation ought to be considered a 
design bug - tomorrow I'll do an R day and see the feasibility of a 
solution.




I don't think Carl's point was to provide answers; his point was to explain 
why the proposal isn't a very good one. He doesn't have to propose an 
alternative to establish that a proposal doesn't work.


Most of Django's backwards incompatible changes are corner cases that most 
end developers never actually encounter. The only exception I can think of 
to this is the CSRF changes to AJAX requests in Django 1.3. This change, on 
the other hand, would affect basically every single Django installation; 
this is much more widespread than past Django releases.


Regards,
Luke



-Original Message- From: Carl Meyer
Sent: Thursday, March 15, 2012 12:49 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

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


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

[Daniel Sokolowski]

Carl, I sincerely appreciate your feedback, however again it seems no 
answers are given except more questions and considerations to consider. Why 
is it so unreasonable that we expect the end developer to be able to 
manually adjust their schemas, it's part of an upgrade process and it's been 
done in the past labelled backwards incompatible changes due to bugs or 
security, perhaps 30 character limitation ought to be considered a design 
bug - tomorrow I'll do an R day and see the feasibility of a solution.


-Original Message- 
From: Carl Meyer

Sent: Thursday, March 15, 2012 12:49 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

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

[Daniel Sokolowski]

That would be a workable compromise, yes?

-Original Message- 
From: Daniel Sokolowski

Sent: Thursday, March 15, 2012 12:41 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

Yes it clearly would, however I see two possible solutions to make it more
friendly:

1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - I
mean the actual commands to execute.
2. Catch the DB error and throw a form validation warning for those that
didn't.

-Original Message- 
From: Luke Sneeringer

Sent: Thursday, March 15, 2012 12:28 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email



On March 15, 2012, at 11:24 , Daniel Sokolowski wrote:

Tom makes a good point, but you can already store emails in the username, 
they are just limited to 30 characters or fewer. Lift this length 
restriction and I will be able to do everything I need without having to 
wait for contrib.auth2. In the 'I use django to make a living' world the 
solution doesn't have to be perfect just good enough. The talk of lazy 
foreign keys just so we can create contrib.auth2 just rubs me the wrong 
way, adds additional complexity, and I see no benefit of it over a 
UserProfile model or with model inheritance.


And Django developer ought to be familiar how to do a schema migration for 
this simple change, and if they fail to know instructions can be provided 
in the release notes; there is NO need to have progress being stalled 
because there is no built automated schema migration.


Why can we not just increase the length limit on the username field?, Why 
can't we just throw a validation error if data entered is to long and the 
schema has not been updated? I think the answer yes we can and easily.


Wouldn't increasing the length of the username field *also* incur a schema
migration? After all, anyone who has spun up a Django site previous to the
change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the
appropriate database-specific type is) in their database. So, we'd have a
situation where Django would accept a 40 character email address, but then
the database would truncate it or error out.

The argument that Django developers ought to know how to do the schema
migrations themselves seems poor to me. I expect some don't, and it's
certainly a bigger backwards incompatible change than the Django development
community has traditionally been comfortable with.

Regards,
Luke



-Original Message- From: Tom Evans
Sent: Friday, March 09, 2012 11:46 AM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant <l.plant...@cantab.net> wrote:

On 09/03/12 14:49, Tom Evans wrote:

Yes, since no one needs it. Okay no one isn't true, but no one (for 
true
this time) who needed it stepped up and said "I'll implement it and see 
that

it ends up in trunk"



I'm sorry, that completely mis-characterises the situation. Lots of
people want this, but every single time this has been brought up since
I started using django (1.0), a core dev or BFDL has explicitly ruled
it out, saying "we cannot do this, requires schema migration, we'll
look at it for the next version".


This is not true. There have been times when we have said we cannot
consider it right now, and that a solid proposal should be brought up at
the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the
core developers can look at it.

And every time, the proposal has either been missing or simply not been
adequate - for example, the GSoC 2010 and 2011 proposals regarding this.
Russell gave detailed feedback on why these solutions were not adequate
[1], and at other times has provided feedback on possible strategies
[2]. And the people who went away to work on the problem have gone
silent or admitted defeat. One presumes they fixed their immediate
problem in a way that would not be a general solution, and moved on, and
that is perfectly understandable. A adequate solution to this is very
hard, and probably requires solving several other big problems first
(like at least one of lazy foreign keys/virtual models/database 
migrations).


It isn't, however, impossible. Our definition of 'need' is that someone
is sufficiently motivated to overcome the obstacles, and contribute a
solution that works for other people as well as themselves.

Regards,

Luke


[1] http://goo.gl/swTpr

[2] http://goo.gl/7p1JN



I disagree. There are small problems with the User model that have not
been fixed. Every proposal you've listed does not address these
issues, but instead looks to find ways of replacing the base user
object, which is a complex and difficult project.

There is a reason why these are the proposals. Every time someone
proposes fixing these minor bugs, the cry from on high is that
instead, d.c.auth will be overhauled to allow for more customization
by the project, immediately increasin

Re: authentication by email

[Daniel Sokolowski]

Yes it clearly would, however I see two possible solutions to make it more 
friendly:


1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - I 
mean the actual commands to execute.
2. Catch the DB error and throw a form validation warning for those that 
didn't.


-Original Message- 
From: Luke Sneeringer

Sent: Thursday, March 15, 2012 12:28 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email



On March 15, 2012, at 11:24 , Daniel Sokolowski wrote:

Tom makes a good point, but you can already store emails in the username, 
they are just limited to 30 characters or fewer. Lift this length 
restriction and I will be able to do everything I need without having to 
wait for contrib.auth2. In the 'I use django to make a living' world the 
solution doesn't have to be perfect just good enough. The talk of lazy 
foreign keys just so we can create contrib.auth2 just rubs me the wrong 
way, adds additional complexity, and I see no benefit of it over a 
UserProfile model or with model inheritance.


And Django developer ought to be familiar how to do a schema migration for 
this simple change, and if they fail to know instructions can be provided 
in the release notes; there is NO need to have progress being stalled 
because there is no built automated schema migration.


Why can we not just increase the length limit on the username field?, Why 
can't we just throw a validation error if data entered is to long and the 
schema has not been updated? I think the answer yes we can and easily.


Wouldn't increasing the length of the username field *also* incur a schema 
migration? After all, anyone who has spun up a Django site previous to the 
change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the 
appropriate database-specific type is) in their database. So, we'd have a 
situation where Django would accept a 40 character email address, but then 
the database would truncate it or error out.


The argument that Django developers ought to know how to do the schema 
migrations themselves seems poor to me. I expect some don't, and it's 
certainly a bigger backwards incompatible change than the Django development 
community has traditionally been comfortable with.


Regards,
Luke



-Original Message- From: Tom Evans
Sent: Friday, March 09, 2012 11:46 AM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant <l.plant...@cantab.net> wrote:

On 09/03/12 14:49, Tom Evans wrote:

Yes, since no one needs it. Okay no one isn't true, but no one (for 
true
this time) who needed it stepped up and said "I'll implement it and see 
that

it ends up in trunk"



I'm sorry, that completely mis-characterises the situation. Lots of
people want this, but every single time this has been brought up since
I started using django (1.0), a core dev or BFDL has explicitly ruled
it out, saying "we cannot do this, requires schema migration, we'll
look at it for the next version".


This is not true. There have been times when we have said we cannot
consider it right now, and that a solid proposal should be brought up at
the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the
core developers can look at it.

And every time, the proposal has either been missing or simply not been
adequate - for example, the GSoC 2010 and 2011 proposals regarding this.
Russell gave detailed feedback on why these solutions were not adequate
[1], and at other times has provided feedback on possible strategies
[2]. And the people who went away to work on the problem have gone
silent or admitted defeat. One presumes they fixed their immediate
problem in a way that would not be a general solution, and moved on, and
that is perfectly understandable. A adequate solution to this is very
hard, and probably requires solving several other big problems first
(like at least one of lazy foreign keys/virtual models/database 
migrations).


It isn't, however, impossible. Our definition of 'need' is that someone
is sufficiently motivated to overcome the obstacles, and contribute a
solution that works for other people as well as themselves.

Regards,

Luke


[1] http://goo.gl/swTpr

[2] http://goo.gl/7p1JN



I disagree. There are small problems with the User model that have not
been fixed. Every proposal you've listed does not address these
issues, but instead looks to find ways of replacing the base user
object, which is a complex and difficult project.

There is a reason why these are the proposals. Every time someone
proposes fixing these minor bugs, the cry from on high is that
instead, d.c.auth will be overhauled to allow for more customization
by the project, immediately increasing the scope and complexity. But
this fabled d.c.auth2 never appears.

In fact, your reply alludes to this. We're talking about why a field
is too short to contain valid values, and you suggest that the
solution ine

Re: authentication by email

[Daniel Sokolowski]

Tom makes a good point, but you can already store emails in the username, 
they are just limited to 30 characters or fewer. Lift this length 
restriction and I will be able to do everything I need without having to 
wait for contrib.auth2. In the 'I use django to make a living' world the 
solution doesn't have to be perfect just good enough. The talk of lazy 
foreign keys just so we can create contrib.auth2 just rubs me the wrong way, 
adds additional complexity, and I see no benefit of it over a UserProfile 
model or with model inheritance.


And Django developer ought to be familiar how to do a schema migration for 
this simple change, and if they fail to know instructions can be provided in 
the release notes; there is NO need to have progress being stalled because 
there is no built automated schema migration.


Why can we not just increase the length limit on the username field?, Why 
can't we just throw a validation error if data entered is to long and the 
schema has not been updated? I think the answer yes we can and easily.



-Original Message- 
From: Tom Evans

Sent: Friday, March 09, 2012 11:46 AM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant  wrote:

On 09/03/12 14:49, Tom Evans wrote:


Yes, since no one needs it. Okay no one isn't true, but no one (for true
this time) who needed it stepped up and said "I'll implement it and see 
that

it ends up in trunk"



I'm sorry, that completely mis-characterises the situation. Lots of
people want this, but every single time this has been brought up since
I started using django (1.0), a core dev or BFDL has explicitly ruled
it out, saying "we cannot do this, requires schema migration, we'll
look at it for the next version".


This is not true. There have been times when we have said we cannot
consider it right now, and that a solid proposal should be brought up at
the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the
core developers can look at it.

And every time, the proposal has either been missing or simply not been
adequate - for example, the GSoC 2010 and 2011 proposals regarding this.
Russell gave detailed feedback on why these solutions were not adequate
[1], and at other times has provided feedback on possible strategies
[2]. And the people who went away to work on the problem have gone
silent or admitted defeat. One presumes they fixed their immediate
problem in a way that would not be a general solution, and moved on, and
that is perfectly understandable. A adequate solution to this is very
hard, and probably requires solving several other big problems first
(like at least one of lazy foreign keys/virtual models/database 
migrations).


It isn't, however, impossible. Our definition of 'need' is that someone
is sufficiently motivated to overcome the obstacles, and contribute a
solution that works for other people as well as themselves.

Regards,

Luke


[1] http://goo.gl/swTpr

[2] http://goo.gl/7p1JN



I disagree. There are small problems with the User model that have not
been fixed. Every proposal you've listed does not address these
issues, but instead looks to find ways of replacing the base user
object, which is a complex and difficult project.

There is a reason why these are the proposals. Every time someone
proposes fixing these minor bugs, the cry from on high is that
instead, d.c.auth will be overhauled to allow for more customization
by the project, immediately increasing the scope and complexity. But
this fabled d.c.auth2 never appears.

In fact, your reply alludes to this. We're talking about why a field
is too short to contain valid values, and you suggest that the
solution inevitably will involve "lazy foreign keys/virtual
models/database migrations" - it's changing one line, and adding a
comment to relnotes!

We may have to agree to disagree on how easy some of these things are to 
fix.


Lets look at one isolated aspect. The User email field in d.c.auth is
too short. Emails can be up to 248 characters long, and d.c.auth only
allows 75.

Clearly, this is a bug, is wrong and should be fixed. How can we fix it?

We can alter the length of the field in the model definition. What
problems does this bring?

Users who do not manually update their database will not be able to
store longer length emails, and will get 'strange effects' when they
try - either silent truncation, or database integrity errors. How can
we mitigate this for users who refuse to update?

Provide a compat shim that resets the email length to that in 1.3, and
immediately mark it PendingDeprecation. Users who read the relnotes
and don't want to change their DB can use the shim, and have a clear
expectation of when they must have updated their database.

I still think these bug fixes are paralysed by a fear of change, and a
desire to engineer a solution that is every thing to every man. Lets
just fix these glaring bugs…

Cheers

Tom

--
You 

Re: Revisiting multiline tags

[Daniel Sokolowski]

+1 and reason as previously stated: it makes sense to brake down very long tags 
for readability purposes. 
From: Alex Gaynor 
Sent: Friday, February 24, 2012 10:12 AM
To: django-developers@googlegroups.com 
Subject: Re: Revisiting multiline tags




On Fri, Feb 24, 2012 at 10:01 AM, Daniel Moisset  
wrote:

  On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch  wrote:
  >> This thread contains 6 people expressing support for this change, and 2 
against (a BDFL, a core developer) -- and you can add me to the -0 list. There 
are over 6000 subscribers to django-developers. I put it to you that the vast 
majority of people haven't expressed an opinion -- and many of those haven't 
expressed an opinion because they're happy with (or indifferent to) the status 
quo, and a BDFL has already indicated that the status quo is his preferred 
option.
  >
  > You asked for it, so here is my +1.
  >


  And mine; even if I might have needed multiline tags once or twice in
  several years, I think it's perfectly reasonable, and the current
  behaviour non-intuitive.

  +1

  D.


  --
  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 
mailto:django-developers%2bunsubscr...@googlegroups.com.
  For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Folks, you seem to have missed Russell's point.  Even if 100 people +1 this, 
it's meaningless.  That's a tiny fraction of this mailing list's readership, 
much less of the Django community at large.  Django is the way it is because, 
first and foremost, of taste.  If you'd like to make an argument as to *why* 
it's useful, that's useful, but we don't take polls. 

Alex


-- 
"I disapprove of what you say, but I will defend to the death your right to say 
it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero


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

Patch https://code.djangoproject.com/ticket/17756 ready for review

[Daniel Sokolowski]

Your guidance is required!

Would someone be kind enough and take a look at 
https://code.djangoproject.com/ticket/17756
and provide feedback.

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-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: read-only admin view

[Daniel Sokolowski]

+1 django has grown since the original design decision and as a rapid
development framework it sells itself it ought to have it --- me thinks.

Daniel

On Fri, Jan 27, 2012 at 9:28 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Sat, Jan 21, 2012 at 1:02 AM, Chris Wilson <ch...@aptivate.org> wrote:
> > Hi all,
> >
> > I really like how the admin interface does a lot of the work for me in
> > developing a site with basic CRUD functions, and a few free bonuses
> > like pagination and list filtering.
> >
> > I agree with all the comments on #820 <https://code.djangoproject.com/
> > ticket/820> requesting this feature (as well as the "view" permission
> > which goes with it).
> >
> > This ticket and several others were closed because a design decision
> > has been made that the admin interface is for admins only, and such a
> > feature is out of scope. A lot of people believe that it should be in
> > scope. Therefore I would like to politely request a reconsideration of
> > this decision.
>
> Even though I'm the person who wonfixed the ticket most recently, I'm
> inclined to agree with you -- but for a different reason.
>
> The original reason -- that the admin isn't intended as a general
> purpose site, just a backend editing interface -- is still valid. I'm
> not in favor of trying to turn the admin into something that people
> will try to interpret as a publicly visible CMS.
>
> However, over time, we've added a complication. We now have object
> level permissions, so it's possible for an admin user to see a list of
> objects, of which only *some* are editable. To me, the logical
> extension of this feature is that you should be able to view some
> objects in the admin, and edit others.
>
> So, count this as a tentative +0 for the idea, qualified by the fact
> that it in no way represents a promise to help this patch into trunk.
> I've got 99 problems, but view permissions in the admin ain't one. :-)
>
> I'd also point out that at DjangoCon.US last year, there were some
> initial discussions about developing a "NewAdmin". I don't think this
> effort has gone very far since then, but it's worth noting that there
> is high-level agreement that Django's admin is in need of a bit of a
> shakeup; increased functionality (like view permissions) might be
> something that could fit into that broader change.
>
> 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-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.
>
>


-- 
Daniel Sokolowski
Web Engineer
KL Insight
http://klinsight.com/
Tel: 613-344-2116 | Fax: 613.634.7029
993 Princess Street, Suite 212
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review re-transmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error please contact the sender immediately by return electronic
transmission and then immediately delete this transmission including all
attachments without copying distributing or disclosing same.

-- 
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: Thoughts on defining and autoimporting signals.py

[Daniel Sokolowski]

+1, 

I think they ought to be auto imported just like models.py, views.py, etc. are.

From: Emil Stenström 
Sent: Thursday, January 19, 2012 8:44 AM
To: django-developers@googlegroups.com 
Subject: Re: Thoughts on defining and autoimporting signals.py


On Thursday, 22 December 2011 03:49:44 UTC+1, Russell Keith-Magee wrote:

  ... there isn't a single solution that will work
  everywhere, which one of the reasons that the docs are silent on the
  issue.

Just for the record: The docs are actually telling you to put your signals in 
models.py, at the end of: 
https://docs.djangoproject.com/en/dev/topics/signals/#s-receiver-functions

I would much rather have them point people to signals.py, and an import 
signals.py in __init__.py. I've seen beginners be trapped in the circular 
import loop when trying to move their signals to a separate file, not realizing 
that they also need to move the import of signals.py away from models to be 
able to use Model classes inside signals.

-- 
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/-/RA_A6SsBM-YJ.
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: Don't assume that missing fields from POST data are equal to an empty string value.

[Daniel Sokolowski]

1. How does this proposal effect default values specified on model fields?
(ModelForm processing)
2. Forgive my ignorance but who has the final say if it goes in or not? And
since it should be a yes what's next?

On Thu, Jan 12, 2012 at 8:40 PM, Tai Lee  wrote:

> Ian,
>
> I agree that there are a lot of different ways that form data can be
> submitted to Django, including near endless combinations of multiple
> Django forms, multiple HTML forms, AJAX, etc.
>
> If we reduce the scope of our discussion and consider only a Django
> form (forgetting HTML forms and AJAX) and two possible scenarios:
>
> 1. Partial form data is bound to a Django form, and it is not expected
> to result in a call to the form's `save()` method and a change to the
> database. It is only intended to examine the form's validation state
> relating to the partial data that is bound to the form. In this case,
> the proposed change should have no impact.
>
> 2. Full form data is bound to a form, and it IS expected to validate
> and result in a call to the form's `save()` method and a change to the
> database. In this case, why would we ever want to assume that a
> character field which has no bound data, is actually bound to an empty
> string?
>
> This is a dangerous assumption, I think. If we intend to obtain
> complete data from the user, bind it to a form and save it to the
> database, we should be sure (as much as we can be) that the data is
> actually complete.
>
> Take the following pure Django example:
>
> {{{
> class Profile(models.Model):
>first_name = models.CharField(blank=True, max_length=50)
>last_name = models.CharField(blank=True, max_length=50)
>address = models.CharField(blank=True, max_length=50)
>
> class ProfileForm(ModelForm):
> class Meta:
>model = Profile
>
> profile = Profile.objects.create(first_name='Tai', last_name='Lee',
> address='Sydney')
> form = ProfileForm({}, instance=profile)
> if form.is_valid():
>form.save()
> }}}
>
> The profile will have no first name, last name or address. The form
> will produce no validation errors and will save the updated model to
> the database.
>
> This is very surprising and counter-intuitive to me.
>
> I think the only time we could safely make the assumption that fields
> with empty string values will be omitted by the UA is when we are
> confident that the source of the form data also makes a similar
> assumption that the back-end will re-normalise those missing fields
> back to an empty string.
>
> I'd be surprised if any UAs actually do make that assumption, because
> the way Django treats missing character fields does not appear to be
> based on any spec, and Django is not the only form processing back-end
> (or even the most popular one).
>
> I'm not sure I follow your simplest case example of one HTML form in a
> browser window and one Django Form in a view. If optional fields are
> left off the HTML form deliberately, without change the Form class or
> the view code, this is exactly when data loss will currently occur. I
> think you are confusing optional as in "may not be specified by the
> user" with optional as in "may not be processed by the form"?
>
> Cheers.
> Tai.
>
> --
> 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: Don't assume that missing fields from POST data are equal to an empty string value.

[Daniel Sokolowski]

Donald

Backward compatibility can be maintained with just a log warning to give
developer time to clean up code or throwing an exception when
`settings.DEBUG=True` and only log warning when `False`; I am not sure how
this ought to be implemented but again I am big +1 for this proposal.

On Thu, Jan 12, 2012 at 4:02 AM, Tai Lee  wrote:

> Donald,
>
> Thanks for sharing your feedback with everyone.
>
> I do believe that there should be some kind of validation error or at
> least a loud warning to the console or logs when a form is bound to
> incomplete data. The only time when this should occur is for
> "unsuccessful controls" such as unchecked radio buttons and
> checkboxes. These shouldn't be a problem for Django, which already
> normalises no value for a checkbox to False and any value for it to
> True.
>
> I'm not sure that there is a widespread practice of submitting partial
> forms with JS and still expecting the entire form to validate and save
> is widespread, or even valid according to the RFC and HTML4 specs
> which expect every successful control to be included in the form data.
>
> Sure, I can see that forms could be fully or even partially submitted
> via JS to perform AJAX validation in real time, but I don't see how
> the form as a whole being invalid and validation errors on the missing
> fields would impact that.
>
> If we can't find a clear definition or distinction between null and an
> empty string in the RFC or HTML4 specs, and we go to our browser (you
> mentioned Chrome), I think you will find that they consider text input
> fields with an empty string as the value are "successful controls", as
> these are included in the form data.
>
> Before knocking back this proposal on the grounds of ambiguous specs
> (multiple interpretations), I would like to know if there are actually
> any UAs that behave as you fear they might. If there are, then this
> change would definitely be a problem for those UAs.
>
> However, even in the event that this is deemed a backwards
> incompatible change and the potential silent data loss issue is not
> serious enough to override that, then a loud warning could still be
> added without changing the current behaviour.
>
> Cheers.
> Tai.
>
>
> On Jan 12, 3:29 am, Donald Stufft  wrote:
> > I'm very much -1 on this change.
> >
> > To "fix" this change would require throwing an error anytime an
> incomplete dictionary was passed as the data arg to a form. This would
> break any existing code that relies on this (in particular it's common
> practice to accept a subset of the fields via json). So this would be a
> backwards incompatible change.
> >
> > Further more I disagree with the interpretation of the RFC as provided.
> The RFC states that any UA may choose to not send along a form field if it
> contains a null value. So the question then becomes what is a null value in
> regards to the RFC? As I cannot find any mention of what constitutes a null
> value in the RFC I went to my browser. Using javascript I executed
> ``document.getElementById('textfield').value = null`` in the js console.
> The result was that the value was set to "". So in my browser (Chrome on OS
> X) it is treating null and "" with equivalence.
> >
> > Going by my personal interpretation of the RFC, and Chrome's behavior in
> my javascript test I can only conclude that the proposed change would cause
> Django forms to violate the RFC spec and while Violating the RFC spec in
> and of itself isn't always the wrong thing to do I do believe that it
> should only be done when RFC and implementations are at odds in a way that
> are incompatible with each other. In this case they are not, and the RFC is
> more permissive and should be followed as Django does not have a list of
> supported browsers so we must strive to follow the RFC's where we can (and
> where they are actually defined) and deviate only when the alternative is
> being broken in major browsers.
> >
> > Additionally I believe in this case there are two major error conditions.
> >
> > A) The proposed change is made, a visitor is using a UA that I believe
> follows the RFC and any Django forms with optional, and unfilled in values
> stop working for this visitor.
> > B) The proposed change is not made, and when an optional form field is
> left off of a form (or json, or any partially incomplete dictionary of
> values) the form assumes the default initial value of "".
> >
> > Neither error condition is optimal, however A has the additional
> downside that this error is completely outside of the control of the
> developer whereas B is the result of developer error and is under his
> control.
> >
> >
> >
> >
> >
> >
> >
> > On Tuesday, January 10, 2012 at 8:38 PM, Tai Lee wrote:
> > > There is a potential for data loss with optional form fields that are
> > > (for whatever reason) omitted from an HTML template.
> >
> > > For example, if we take an existing model form and template that
> 

Re: Don't assume that missing fields from POST data are equal to an empty string value.

[Daniel Sokolowski]

+1 even though I agree with what Babatunde said I support this change as
anything that minimizes a 'gotchas' during development is very good. I
raether get an exception instead of spending half an hour debuging why my
data is not being saved. Sure once I figure it out I would learn to pay
attention in similar situations in the future but realistically I shouldn't
and nor should the next python/django programmer re-discovering this caveat.

On Wed, Jan 11, 2012 at 9:11 AM, Babatunde Akinyanmi
wrote:

> -1
> I think a programmer should not specify a field that would contain
> important data as optional in the first place. If the data loss from
> not including it in the form is going to cause problems then it should
> not be optional.
>
> On 1/11/12, Tai Lee  wrote:
> > There is a potential for data loss with optional form fields that are
> > (for whatever reason) omitted from an HTML template.
> >
> > For example, if we take an existing model form and template that
> > works, add an optional character field to the model but fail to add a
> > corresponding field to the HTML template (e.g. human error, forgot
> > about a template, didn't tell the template author to make a change,
> > didn't realise a change needed to be made to a template), when that
> > form is submitted Django will assume that the user has provided an
> > empty string value for the missing field and save that to the model,
> > erasing any existing value. This is not a bug, but it is relatively
> > easy to trigger silent and unexpected data loss.
> >
> > I have briefly discussed this with PaulM and dstufft on django-dev,
> > but could did not reach any consensus.
> >
> > RFC1866 [1] says:
> >
> >> The fields are listed in the order they appear in the
> >> document with the name separated from the value by `=' and
> >> the pairs separated from each other by `&'. Fields with null
> >> values may be omitted. In particular, unselected radio
> >> buttons and checkboxes should not appear in the encoded
> >> data, but hidden fields with VALUE attributes present
> >> should.
> >
> > The HTML4 spec at W3C.org [2] says:
> >
> >> Users interact with forms through named controls.
> >>
> >> A control's "control name" is given by its name attribute. The scope of
> >> the
> >> name attribute for a control within a FORM element is the FORM element.
> >>
> >> Each control has both an initial value and a current value, both of
> which
> >> are
> >> character strings. Please consult the definition of each control for
> >> information about initial values and possible constraints on values
> >> imposed by
> >> the control. In general, a control's "initial value" may be specified
> with
> >> the
> >> control element's value attribute. However, the initial value of a
> >> TEXTAREA
> >> element is given by its contents, and the initial value of an OBJECT
> >> element
> >> in a form is determined by the object implementation (i.e., it lies
> >> outside
> >> the scope of this specification).
> >>
> >> The control's "current value" is first set to the initial value.
> >> Thereafter,
> >> the control's current value may be modified through user interaction and
> >> scripts.
> >>
> >> A control's initial value does not change. Thus, when a form is reset,
> >> each
> >> control's current value is reset to its initial value. If a control does
> >> not
> >> have an initial value, the effect of a form reset on that control is
> >> undefined.
> >>
> >> When a form is submitted for processing, some controls have their name
> >> paired
> >> with their current value and these pairs are submitted with the form.
> >> Those
> >> controls for which name/value pairs are submitted are called successful
> >> controls.
> >
> > as well as [3]:
> >
> >> A successful control is "valid" for submission. Every successful control
> >> has
> >> its control name paired with its current value as part of the submitted
> >> form
> >> data set. A successful control must be defined within a FORM element and
> >> must
> >> have a control name.
> >>
> >> However:
> >>
> >> * Controls that are disabled cannot be successful.
> >> * If a form contains more than one submit button, only the activated
> >> submit
> >>   button is successful.
> >> * All "on" checkboxes may be successful.
> >> * For radio buttons that share the same value of the name attribute,
> only
> >> the
> >>   "on" radio button may be successful.
> >> * For menus, the control name is provided by a SELECT element and values
> >> are
> >>   provided by OPTION elements. Only selected options may be successful.
> >> When
> >>   no options are selected, the control is not successful and neither the
> >> name
> >>   nor any values are submitted to the server when the form is submitted.
> >> * The current value of a file select is a list of one or more file
> names.
> >> Upon
> >>   submission of the form, the contents of each file are submitted with
> the
> >>   rest of the form data. The file 

Re: RFC: Query Methods

[Daniel Sokolowski]

Forgive me if I am missing something --- I use custom managers extensively
and do not see what your code can do that the django custom managers can't
? Can you provide an example please ?



On Tue, Jan 3, 2012 at 12:55 AM, Zachary Voase <zacharyvo...@gmail.com>wrote:

> At the moment it's very easy to add methods to individual models, just
> by putting a method on the model class itself which accepts 'self'.
> However, defining business logic on collections of records is
> currently pretty complicated — you have to create at least a custom
> Manager subclass, and if you want to chain those methods together
> you'll need a QuerySet subclass. An example of the desired behaviour,
> and the steps required for it, is shown in [1].
>
> I originally created django-qmixin [2] to tackle this problem; you can
> define methods which will be present on the manager and all querysets
> produced therefrom, including on relations. However, the django-qmixin
> approach of creating a mixin and then including that on the Manager
> class object doesn't really gel with the rest of Django core. I've
> worked out two approaches which are easier for novices to understand,
> and match the idioms of the rest of Django. They both involve adding a
> @models.querymethod decorator, which would be applied to methods which
> operate on collections of records (i.e. querysets). It's an analog to
> Python's @classmethod.
>
> The first approach [3] involves adding these querymethods to the model
> class itself; the second [4] adds them to a manager subclass (but
> without the trouble of the QuerySet subclass). I prefer the former,
> for simplicity, but you may believe otherwise.
>
> I'm working on a proof-of-concept implementation, but I feel it's more
> important to agree on the interface and rationale beforehand. Any
> thoughts?
>
> [1]: https://gist.github.com/1553675#file_old_queryset_method.py
> [2]: https://github.com/zacharyvoase/django-qmixin
> [3]: https://gist.github.com/1553675#file_model_querymethod.py
> [4]: https://gist.github.com/1553675#file_manager_querymethod.py
>
> --
> 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.
>
>


-- 
Daniel Sokolowski
Web Engineer
KL Insight
http://klinsight.com/
Tel: 613-344-2116 | Fax: 613.634.7029
993 Princess Street, Suite 212
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review re-transmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error please contact the sender immediately by return electronic
transmission and then immediately delete this transmission including all
attachments without copying distributing or disclosing same.

-- 
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: DoS using POST via hash algorithm collision

[Daniel Sokolowski]

Thanks

On Thu, Dec 29, 2011 at 11:36 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:

>
>
> On Thu, Dec 29, 2011 at 10:32 AM, Daniel Sokolowski <
> daniel.sokolow...@klinsight.com> wrote:
>
>> Would someone be so kind and explain why POST variables are stored in
>> hash tables? What is the reasoning behind it? Speed? Or is this simply done
>> at the Python level when using a dictionary type? Thank you
>>
>>
>> On Thu, Dec 29, 2011 at 11:19 AM, Christophe Pettus <x...@thebuild.com>wrote:
>>
>>>
>>> On Dec 29, 2011, at 8:12 AM, Daniel Sokolowski wrote:
>>>
>>> > So this would effect django because of the CSRF token check --- which
>>> requires the hash to be regenerated before comparing it yes?
>>>
>>> No, the problem is somewhat different.  The attacker constructs a POST
>>> request in which the field names are constructed to be a degenerate case of
>>> a hash table.  Since pretty much every web framework in existence
>>> (including Django) automatically takes the incoming POST fields and inserts
>>> them into a hash table (a Python dict being implemented as a hash table),
>>> the framework will grind through this degenerate case very, very slowly.
>>>
>>> If I'm reading the paper correctly, it only applies to 32-bit Python
>>> implementations, as the 64-bit ones are not practically vulnerable to this
>>> attack.
>>>
>>> It's an interesting result, but I'm not sure how much to be worried
>>> about it in the field.  A SlowLoris or similar attack would seem to be far
>>> more effective and less implementation-dependent.
>>> --
>>> -- Christophe Pettus
>>>   x...@thebuild.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.
>>>
>>>
>>
>>
>> --
>> Daniel Sokolowski
>> Web Engineer
>> KL Insight
>> http://klinsight.com/
>> Tel: 613-344-2116 | Fax: 613.634.7029
>> 993 Princess Street, Suite 212
>> Kingston, ON K7L 1H3, Canada
>>
>>
>> Notice of Confidentiality:
>> The information transmitted is intended only for the person or entity to
>> which it is addressed and may contain confidential and/or privileged
>> material. Any review re-transmission dissemination or other use of or
>> taking of any action in reliance upon this information by persons or
>> entities other than the intended recipient is prohibited. If you received
>> this in error please contact the sender immediately by return electronic
>> transmission and then immediately delete this transmission including all
>> attachments without copying distributing or disclosing same.
>>  --
>> 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.
>>
>
> Well, what structure would you use to store them?  POST variables are
> "obviously" a mapping of key to value, and the way one does that in Python
> is generally a dict (which are presently backed by a hashtable on every
> Python VM I know of).
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>  --
> 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: DoS using POST via hash algorithm collision

[Daniel Sokolowski]

Would someone be so kind and explain why POST variables are stored in hash
tables? What is the reasoning behind it? Speed? Or is this simply done at
the Python level when using a dictionary type? Thank you

On Thu, Dec 29, 2011 at 11:19 AM, Christophe Pettus <x...@thebuild.com>wrote:

>
> On Dec 29, 2011, at 8:12 AM, Daniel Sokolowski wrote:
>
> > So this would effect django because of the CSRF token check --- which
> requires the hash to be regenerated before comparing it yes?
>
> No, the problem is somewhat different.  The attacker constructs a POST
> request in which the field names are constructed to be a degenerate case of
> a hash table.  Since pretty much every web framework in existence
> (including Django) automatically takes the incoming POST fields and inserts
> them into a hash table (a Python dict being implemented as a hash table),
> the framework will grind through this degenerate case very, very slowly.
>
> If I'm reading the paper correctly, it only applies to 32-bit Python
> implementations, as the 64-bit ones are not practically vulnerable to this
> attack.
>
> It's an interesting result, but I'm not sure how much to be worried about
> it in the field.  A SlowLoris or similar attack would seem to be far more
> effective and less implementation-dependent.
> --
> -- Christophe Pettus
>   x...@thebuild.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.
>
>


-- 
Daniel Sokolowski
Web Engineer
KL Insight
http://klinsight.com/
Tel: 613-344-2116 | Fax: 613.634.7029
993 Princess Street, Suite 212
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review re-transmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error please contact the sender immediately by return electronic
transmission and then immediately delete this transmission including all
attachments without copying distributing or disclosing same.

-- 
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: DoS using POST via hash algorithm collision

[Daniel Sokolowski]

So this would effect django because of the CSRF token check --- which
requires the hash to be regenerated before comparing it yes?

On Wed, Dec 28, 2011 at 9:26 PM, Luciano Pacheco <lucm...@gmail.com> wrote:

> Hi all,
>
> Have you guys seen this?
> http://www.ocert.org/advisories/ocert-2011-003.html
>
> PDF with some more explanation:
> http://www.nruns.com/_downloads/advisory28122011.pdf
>
> Regards,
> --
> Luciano Pacheco
> blog.lucmult.com.br
>  --
> 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.
>



-- 
Daniel Sokolowski
Web Engineer
KL Insight
http://klinsight.com/
Tel: 613-344-2116 | Fax: 613.634.7029
993 Princess Street, Suite 212
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review re-transmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error please contact the sender immediately by return electronic
transmission and then immediately delete this transmission including all
attachments without copying distributing or disclosing same.

-- 
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: SOPA bill question

[Daniel Sokolowski]

OMG - why don't we all go for a coffee and discuss if we are going to be
discussing what we think of discussing.

The above is meant as a a joke.

On Wed, Dec 28, 2011 at 12:04 PM, Andre Terra <andrete...@gmail.com> wrote:

> On Wed, Dec 28, 2011 at 10:29 AM, Etienne Robillard 
> <animelo...@gmail.com>wrote:
>
>> Further I disagree this is a bad list for discussing the implications
>> SOPA, and encourages everyone to sharpen their minds on this issue, so
>> please don't be "sorry" to talk about it.
>
>
> The fact that developers who have subscribed to this list should be (and
> probably are indeed) concerned about SOPA doesn't mean that the list is the
> best medium through which the matter should be discussed.
>
> There is some overlap between the members of this community and the people
> who could be affected by a bill like SOPA, but this is true for pretty much
> anything online.
>
> Yes, it concerns us. No, it doesn't belong here. SOPA is noise as far as
> Django *development* is concerned. It is not noise for django *developers*,
> but there's a difference between those two words that I hope you can accept.
>
>
>
> Regards,
> André Terra
> --
> 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.
>



-- 
Daniel Sokolowski
Web Engineer
KL Insight
http://klinsight.com/
Tel: 613-344-2116 | Fax: 613.634.7029
993 Princess Street, Suite 212
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review re-transmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error please contact the sender immediately by return electronic
transmission and then immediately delete this transmission including all
attachments without copying distributing or disclosing same.

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

Thoughts on defining and autoimporting signals.py

[Daniel Sokolowski]

Dear Django Developers,

Is there any consensus on where to define your signals for models and
how to import them? I ask because to me it seems very odd that there
doesn't appear to be a standard way to add your own signals and have
them auto imported by the framework. I for example create a /
project_root/project_app/signals.py file and auto import it in the
__init__ of my project app.

I have read and searched the 
https://docs.djangoproject.com/en/dev/topics/signals/
however it fails short to provide any gudiance on this.

How do you do it, what are your thoughts on the making the auto import
and signals.py file standard? Has this been already discussed?

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