re: django template revision (for 1.4?)

[Daniel]

Hi, I was just referred here with a suggestion I posted on the django
ticket tracker. I've been studying the way we do template tags, and
had a suggestion for how to revise them to make them a bit easier. I
was thinking that out of the tags, I like the variable syntax the best
-- {{ variable.attribute }}. I realize that if we were to use the
double curly brackets on all of the tags, they might conflict with the
namespace, but it seems like having "block", "if", "elsif", "else",
"for", and "extends" and their respective 'end'ings as keywords would
not be burdensome. It's really unpleasant typing {%%} and left arrow
twice, space, the item name, and space for every tag and for its
closing tag.

An alternative that wouldn't affect the namespace but would still be
more convenient for both plain typing and possibly for code completion
(I don't know why eclipse pydev doesn't close these tags) would be
triple brackets --  {{{ block head }}}.

Thanks for your time,
-Dan

p.s. not sure if the code will show up appropriately in the above, but
hopefully you get the picture.  Also, I'm on Windows and/or Linux...

Here's the initial reply:
-
Change History
05/26/10 14:01:25 changed by adamnelson
status changed from new to closed.
needs_better_patch changed.
resolution set to invalid.
needs_tests changed.
needs_docs changed.

I think it's a reasonable request but this would require a rigorous
discussion on django developers newsgroup before even having a ticket
and would be more like a 1.4 thing:

http://groups.google.com/group/django-developers

You may want to try TextMate Django bundles to make this easier on a
Mac - I don't have any other suggestions though.

Cheers.

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

Re: django template revision (for 1.4?)

[Daniel]

Hello Gregor,

Thanks for taking a look.  My rationale is, "Why change all the
editors in the world for something that can be simplified with an
easier syntax?"

All of the previous code using the curly-modulo syntax -- {%%} would
still be functional for as long as the core developers chose to
support it.

The only possible breakage (as i understand it at least) would be if
the namespace issue I previously mentioned. That would mean people
have been naming their variables or tables things like "block","if",
etc, which would seem to be pretty poor programming practice in terms
of readability.  Finally, the triple bracket solution would avoid even
that issue if creating a few keywords were to be out of the question.
As to your last point, I don't know how many programming languages
have implemented their own versions of the DTL, but if this would be
an improvement, as I feel it would, then it seems all such
implementations would benefit as well.

Cordially,
Daniel

On May 26, 5:32 pm, Gregor Müllegger  wrote:
> Hi Daniel,
>
> I think your suggestion might make sense for some people using
> autoclosing brackets etc. But having better support for writing
> templatetags is just an issue with a text editor which might be
> configurable and easy to write a plugin or using a snippet completion
> to make life easier for you typing things.
>
> So in my opinion its unlikely that your proposal will be intergrated
> into django because it breaks backwards compatibility without having
> any functional improvement. You would need to update all existing
> django templates and it also breaks compatibility with implementations
> of the DTL in other programming languages.
>
> Gregor
>
> disclaimer: I'm not a core-developer and are not responsible for any
> design decisions.
>
> On 26 Mai, 20:24, Daniel  wrote:
>
>
>
> > Hi, I was just referred here with a suggestion I posted on the django
> > ticket tracker. I've been studying the way we do template tags, and
> > had a suggestion for how to revise them to make them a bit easier. I
> > was thinking that out of the tags, I like the variable syntax the best
> > -- {{ variable.attribute }}. I realize that if we were to use the
> > double curly brackets on all of the tags, they might conflict with the
> > namespace, but it seems like having "block", "if", "elsif", "else",
> > "for", and "extends" and their respective 'end'ings as keywords would
> > not be burdensome. It's really unpleasant typing {%%} and left arrow
> > twice, space, the item name, and space for every tag and for its
> > closing tag.
>
> > An alternative that wouldn't affect the namespace but would still be
> > more convenient for both plain typing and possibly for code completion
> > (I don't know why eclipse pydev doesn't close these tags) would be
> > triple brackets --  {{{ block head }}}.
>
> > Thanks for your time,
> > -Dan
>
> > p.s. not sure if the code will show up appropriately in the above, but
> > hopefully you get the picture.  Also, I'm on Windows and/or Linux...
>
> > Here's the initial reply:
> > -
> > Change History
> > 05/26/10 14:01:25 changed by adamnelson
> > status changed from new to closed.
> > needs_better_patch changed.
> > resolution set to invalid.
> > needs_tests changed.
> > needs_docs changed.
>
> > I think it's a reasonable request but this would require a rigorous
> > discussion on django developers newsgroup before even having a ticket
> > and would be more like a 1.4 thing:
>
> >http://groups.google.com/group/django-developers
>
> > You may want to try TextMate Django bundles to make this easier on a
> > Mac - I don't have any other suggestions though.
>
> > Cheers.

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

Re: django template revision (for 1.4?)

[Daniel]

@Luke: I haven't used custom template tags, so I don't know the effect
that switching to {{}} would do to that.   this sounds like the first
real issue that could just kill it.
@Josh:  it's true that my fingers won't wither away from typing {%
stuff %}.

i guess i'll spend more time studyin' pydev.  switching editors every
weekend kinda sucks, and generally with autocomplete I prefer things
to just work.

@Mike: didn't even know people were including Latex within Django.. I
don't know Latex, and I don't really understand the example.
something about autoescaping?

@Charlie: The bikeshed should be a light blue, with white trimming.  I
kinda assumed the dev's picked modulo (yes, shift 5) since it was one
of the more obscure buttons.

whatever happened to lazy is good?
-D

On May 26, 8:43 pm, Charlie Nolan  wrote:
> I'm mostly just a user, and maybe I'm being dense, here, but I just
> don't see the point of this change.  Why is {%%} any harder a syntax
> than {{{}}} is?  Is it an issue of key placement (% is shift-5 for US
> keyboards)?  And why would you type {%%} and then go back to insert
> the keyword when you can just type {% keyword %} straight up?
>
> If typing it is slow (and I don't see why it would be), any editor
> more complex than Notepad should be able to have a macro that drops in
> {% | %}, where | is the insertion pointer.  That doesn't even really
> count as "changing the editor".
>
> It seems like we're discussing the color of the bikeshed long after
> the thing was already painted.  There's no significant benefit to the
> change (that I can see), and it's already been noted that it can break
> existing behaviour.  Why would we change it?
>
> -FM
>
>
>
> On Wed, May 26, 2010 at 11:05 PM, Mike Axiak  wrote:
> > Hello,
>
> > Also keep in mind that the triple brackets introduce their own set of
> > issues. For example, in LaTeX templates I've seen::
>
> >   \title{{{ publication.title }}}
>
> > Which works perfectly fine right now. Would this work under your proposal?
>
> > Cheers,
> > Mike
>
> > On Wed, May 26, 2010 at 6:28 PM, Daniel  wrote:
> >> Hello Gregor,
>
> >> Thanks for taking a look.  My rationale is, "Why change all the
> >> editors in the world for something that can be simplified with an
> >> easier syntax?"
>
> >> All of the previous code using the curly-modulo syntax -- {%%} would
> >> still be functional for as long as the core developers chose to
> >> support it.
>
> >> The only possible breakage (as i understand it at least) would be if
> >> the namespace issue I previously mentioned. That would mean people
> >> have been naming their variables or tables things like "block","if",
> >> etc, which would seem to be pretty poor programming practice in terms
> >> of readability.  Finally, the triple bracket solution would avoid even
> >> that issue if creating a few keywords were to be out of the question.
> >> As to your last point, I don't know how many programming languages
> >> have implemented their own versions of the DTL, but if this would be
> >> an improvement, as I feel it would, then it seems all such
> >> implementations would benefit as well.
>
> >> Cordially,
> >> Daniel
>
> >> On May 26, 5:32 pm, Gregor Müllegger  wrote:
> >>> Hi Daniel,
>
> >>> I think your suggestion might make sense for some people using
> >>> autoclosing brackets etc. But having better support for writing
> >>> templatetags is just an issue with a text editor which might be
> >>> configurable and easy to write a plugin or using a snippet completion
> >>> to make life easier for you typing things.
>
> >>> So in my opinion its unlikely that your proposal will be intergrated
> >>> into django because it breaks backwards compatibility without having
> >>> any functional improvement. You would need to update all existing
> >>> django templates and it also breaks compatibility with implementations
> >>> of the DTL in other programming languages.
>
> >>> Gregor
>
> >>> disclaimer: I'm not a core-developer and are not responsible for any
> >>> design decisions.
>
> >>> On 26 Mai, 20:24, Daniel  wrote:
>
> >>> > Hi, I was just referred here with a suggestion I posted on the django
> >>> > ticket tracker. I've been studying the way we do template tags, and
> >>> > had a suggestion for how to revise t

Lazy registration with django.contrib.auth

[Daniel]

Greetings,

I'm developing an application where http://ajaxpatterns.org/
Lazy_Registration">Lazy Registration is on my feature list, and I
believe this can be accomplished pretty cleanly using the django auth
system.

I would like to implement this as an extension of the existing auth
code.  Is there any interest in a trunk patch to achieve this?  If so,
any suggestions on best practices?

I still looking into the auth code, but it looks like the way to
handle this would be to create a sort of "hybrid" user class, half way
between AnonymousUser and a registered User, called (for instance)
SessionUser or LazyUser.  Via the AuthenticationMiddleware class, a
global flag would trigger the initialization of the user instance to a
LazyUser instead of AnonymousUser (or alternately, a replacement of
the AuthenticationMiddleware would be created for this purpose).  The
details of how to model the LazyUser would need to be hashed out, but
I can see a couple options which build off the existing system.

Before I look into this further - someone clue me in on whether or not
I should bother working in contrib.auth, or should I be looking for a
higher level (user-land) solution?  Or is there anyone out there who's
already solved this problem with Django?

Thanks,
Dan


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

feature request: insensitive 'in'?

[Daniel]

I understand that there's a workaround using iregex (http://
stackoverflow.com/questions/2667524/django-query-case-insensitive-list-
match), but an 'iin' seems like it would be a nice feature to have in
the query syntax.

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

newforms validator_list

[Daniel]

Hello,

This is a cross-post from django-users (http://groups.google.com/group/
django-users/browse_thread/thread/7de549e13f4ec2e5).  As it pertains
to implementation details, the developers group may have more insight.

As I understand it the model field paramater "validator_list" is now
being phased out with newforms.  I'm using newforms-admin, and am in
need of a similar way of doing validation.  Are there any hooks or
even hacks available that could achieve this?

I understand the preferred method is to create a custom form Field,
and do validation in its clean() method.  However, this appears to be
lacking in a couple ways.

First of all, it assumes you're generating the form manually.  What
if
you're using form_for_model, or more critically, using the admin
interface?  Is there a way to specify custom form Field instances for
a corresponding model Field in the admin?

Secondly, in the admin the potential to do multi-field validation is
gone (or seems to be).  The old validator function passed the values
(field_data, all_data), allowing one to check the value of other
fields in the form via the all_data field.  Is it no longer possible
to, for instance, trigger validation of one field off another via the
admin in newforms-admin?  (ie, if field1 is None, field2 is required;
if field1 is filled, field2 is not required.)

Any suggestions would be much appreciated.

Thanks,
Dan


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Looking for a project

[Daniel Watkins]

Hello all,

As part of the third year of my computer science degree (at the
University of Warwick), I need to complete an individual project.  I'd
quite like to use this to do something for Django.  The project is meant
to be done entirely individually, which means that something that works
as a standalone app (rather than being a branch of Django itself) would
be preferable.

The project needs to be completed between the beginning of October and
April, with about 5 hours a week being spent on it.

I have a few half-formed ideas of my own, but if anyone else has an idea
of what I could do, I'd like to hear about it.


Cheers,

Dan


--~--~-~--~~~---~--~~
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: Looking for a project

[Daniel Watkins]

Hi Dougal,

On Sun, 2009-09-20 at 21:10 +0100, Dougal Matthews wrote:
> It would probably be worth you listing your ideas even if they are
> half baked. This would show people what you are interested in and we
> could possibly help you develop them further.

Thanks for the reply.  I had a couple of ideas, but I can actually only
recall one of them now[0]: a Django calendar app.  This would probably
break down into a couple of parts, a CalDAV server implementation and a
frontend (similar to the role of, but not as impressive as, Google
Calendar).  The intention would be that the two should be decoupled
enough to run on separate servers.  If the former proves to be complex
(as it may well do), I'm happy to lose the latter part.

> Otherwise, you could look at the wiki for discussed features or even
> get involved in 1.2?

As I said, I'd like to avoid working on the core as part of my project,
as there may be some problems with submitting work based on an existing
free software codebase.


Dan


[Footnote 0: If only I'd written them down at the time, maybe in some
sort of email to the Django developers list.]


--~--~-~--~~~---~--~~
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: Looking for a project

[Daniel Watkins]

Hey,

On Sun, 2009-09-20 at 09:45 -0700, corn13r...@gmail.com wrote:
> A django webmail app

That'd be interesting, I'll add that to my list.


Dan


--~--~-~--~~~---~--~~
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: Looking for a project

[Daniel Watkins]

On Sun, 2009-09-20 at 16:26 -0700, Richard wrote:
> django-schedule is under active developement and is a great
> calendaring app.

Looking at django-schedule's website, it only seems to do the front-end
part of what I was suggesting.  Is my understanding correct?


Dan


--~--~-~--~~~---~--~~
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: Design and code review requested for Django string signing / signed cookies

[Daniel Pope]

The timestamp is necessary to limit replay attacks, and so it should
probably be more than optional - always issued, and checked by
default. The danger is that users might think "signing" is a
bulletproof guarantee that the cookie as received is exactly the
latest cookie issued to that unique user and use them where a replay
attack would be unacceptable for security. There is still a max_age
window for replay attacks, which I don't know of any way to close.

Encrypting the cookies as well would make replay attacks a little
trickier, forcing the attacker to use trial-and-error rather than
identifying targets by inspection. Security through obscurity only,
though cookies being opaque to the user can be useful in its own
right.

The API could accept a user-supplied "check" string so that if the
user can supply some other details - maybe an IP - and have the API
verify this for them (thus preventing replay attacks for different
IPs).

> unsigned_value = signer.unsign(signed_value)

On an API level, 'unsign' isn't an obvious choice. The operation you
are doing is verifying and stripping a signature, so I'd expect
'verify' in the name. You also might want access to the signature
data.

So for example, something like this:

>>> s = SignedString(signed_value)
>>> s
'Hello world'
>>> s.timestamp
1262612904
>>> s.is_key_current()
True
>>> s = SignedString(old_signed_value, max_age=3600)
...
SignatureExpired: signature older than max_age

Dan

--

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

Re: Proposal: Revised form rendering

[Daniel Greenfeld]

I agree with Eric and my experiences back it up. Most of the people
who want to custom form widgets are the ones who are unprepared to dig
into Django/Python code. The easier we can make creating/extending
form widgets the better.

This looks like what I'll be sprinting on at DjangoCon. :)

Danny

On Jul 11, 1:14 pm, "flo...@gmail.com"  wrote:
> I'm glad to see that some serious thought is going into this issue!
> This proposal sound very good (to me, at least) on the whole.
>
> One thing that occurs to me, though, is that the people who are going
> to want to customize form output are very frequently going to be the
> people working mostly in the templates: the designers. It looks like
> you're not fully settled on the interface, but I think that exposing
> it on the form class like as_* means that it's going to be difficult
> for designers to customize that output.
>
> It seems to me that one way to give designers the ability to customize
> that output is to move some of that output logic out of Python and
> into templates.  Widgets could load up a template from a well-known
> location--something like e.g. django/widgets/textarea.html--and then
> template authors could customize that by providing their own template
> in that same path.  There would be some issues to sort out there, like
> the fact that Django would have to install some implicit Django-
> provided template directory at the end of TEMPLATE_DIRS, but I don't
> think that's too onerous.
>
> I'm not 100% sure that that's the answer, but whatever the answer is,
> I think it's important to note that the target audience for
> customizing form output isn't always going to be the Python
> programmer.
>
> Thanks,
> Eric Florenzano

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

Re: Proposal: Revised form rendering

[Daniel Greenfeld]

On Jul 12, 8:12 am, Russell Keith-Magee 
wrote:
> On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson  wrote:
> > Good proposal overall. One thought I have in order to try and combat
> > the massive parameter list of {% form %} is to optionally add an
> > ending tag, as well as sub-tags:
>
> > {% form myform %}
> >    {% using birthday=calendar %}
> >    {% renderer "as_ul" %}
> >    {% autocomplete "name_autocomplete" %}
> >    {% doctype xhtml1 %}
> > {% endform %}

In django-uni-form (http://github.com/pydanny/django-uni-form) we pass
into the form tag a 'form helper' object that contains attributes as a
parameter. This means that assembling the special qualities of the
form can happen in the view.py or forms.py.

helper = FormHelper()
helper.use_csrf_protection = True

{% uni_form myform helper %}

This approach has been popular in the community that uses django-uni-
form although mostly it is used to add buttons and layout options that
come in django-uni-form. People do really complex forms using the
layout extension of the project (especially using BartTC's Layout
module).

Its possible to extend this approach to include other options and
capabilities and work that into the proposed forms changes:

helper = FormHelper()
helper.doctype = 'xhtml1'
helper.use_csrf_protection = True

{% form myform helper %}
  {% form myform errors %}
  {% form myform hidden %}
  {% form myform field name using autocomplete:"name_autocomplete" %}
  {% form myform field birthdate using calendar important %}
{% endform  %}

I'm not sure this is the right way to do things here. The FormHelper
object as implemented needs to be controlled outside the templates.
Which possibly defeats some of Russ' goals in this effort. Also, from
experience, when people put a lot of functionality in the FormHelper
object (django-uni-form's Layout module comes to mind), it means that
the layout controls are in view.py, not in the template. Which
arguably means that the controls are out of the hands of the designer
and in the hands of the developer.

Until I get around to refactoring django-uni-form,

Daniel Greenfeld
pydanny.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-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RequestContext not working?

[Daniel Poelzleithner]

Andreas Neumeier wrote:

> It looks like RequestContext just dies silently, but I couldn't tell
> you for sure.
> 
> I also figured out, there is another installation (rev. 2893 on Ubuntu
> Dapper), which looks that it works perfectly. rev 2917 on Breezy seams
> to fail for some reason i cannot describe. Where could I have a deeper
> look? Does django depend on certain mod_python versions?

Did you overwrite TEMPLATE_CONTEXT_PROCESSORS ?

I made the mistake once, because I didn't knew this variable is filled
by default. You have to write something like:

TEMPLATE_CONTEXT_PROCESSORS = DEFAULT.TEMPLATE_CONTEXT_PROCESSORS +
('my.preprocessor',)

Took me some time to figure out why admin was not working anymore :)

The difference of Context and RequestContext is not a deep one, so I
don't think its a python issue here.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: svn merge problem

[Daniel Ericsson]

On 17 maj 2006, at 12.45, Michael Radziej wrote:

> Nicola Larosa (tekNico) wrote:
>
>>> /me makes another note to spend some serious time with BZR...
>>
>> Try spending some time with Mercurial, too. It's simpler, smaller and
>> faster than Bazaar-NG, while also being written in Python, with a
>> little C.
>
> Hmm. I'm using git for django. There's a tool that can synchronize svn
> to git, and with git I can manage my own branches for patches I create
> without bothering anybody. Works fine once you've got used to the,
> admittedly, strange ways of git.

I use Tailor[1] to sync the trunk from Subversion to a Mercurial[2]  
repo which I then use to merge my local changes. There is an  
experimental Mercurial-plugin[3] for Trac. I maintain the Mercurial  
port in DarwinPorts[4].

[1] http://www.darcs.net/DarcsWiki/Tailor
[2] http://www.selenic.com/mercurial/wiki/index.cgi
[3] http://projects.edgewall.com/trac/wiki/TracMercurial
[4] http://www.darwinports.org/

- Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping (and branch request)

[Daniel Poelzleithner]

Simon Willison wrote:
> 
> On 19 Jun 2006, at 21:00, [EMAIL PROTECTED] wrote:
> 
>> anyway, i suppose i will wait for you to elaborate on your  
>> reasoning in
>> the wiki this evening.  :)
> 
> I've written up a proposal for how we can implement auto escaping  
> while hopefully keeping most people happy:
> 
> http://code.djangoproject.com/wiki/AutoEscaping

I like much of this stuff.

Here some further ideas:

I don't like the {% endautoescape %} just to print a unescaped variable.
Maybe the idea of the python string type prefix would help here and
would allow further improvments to be implemented nicely (thinking about
unicode problems...)

{{r#somevariable}} or {{r:somevariable}}

Even the last one looks strange at first, but is logical under the idea
that r ist just like any other function and generates a escapedstr out
of a string, or escapedunicodestring out of a unicode

2. Currently the autoescape, or better escape in general escapes <>, etc.
But what if you have some different type of output, then you have to do
everything by hand or write other filters, but could be messy.

{% escape_type tex|cvs|something... %}

would set a reference to the escape function of this template instance,
which is default to html. escape and autoescapestring would use this
reference instead of fixed coded escape function. This would allow to
write clean templates, with nearly no bloat in implementation.

kindly regards
  Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Development Growing Pains: Patch Acceptance

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> Thanks for the comments. I'd like to restructure our Trac installation
> into more useful categories, such as: "Still thinking about it,"
> "Patch is good and should be committed with caveats," "Patch isn't
> good enough," and stuff like that. I think more granular categories
> like that would help us get more on top of the tickets/patches.

Keywords like "request_for_review" etc would help, too. The only thing
which would be required is a wiki page with all keywords listed and
explained.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: URL confs should take callables as well as strings

[Daniel Poelzleithner]

Simon Willison wrote:

> Allowing callables in urlconfs opens up a whole bunch of other  
> opportunities as well. Setting up generic views could be made much  
> less fiddly:

What i still missing is a possibility to use other values to find the
right view (most likely the http host header).
I suggested http://code.djangoproject.com/ticket/1192 but Adrian doesn't
like it for some reason I can't understand :)

Anyway, maybe there could be some nice and clean way to use callables in
urlconfs to allow such things.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: The viability of adding ifless and ifgreater to Django Templates

[Daniel Poelzleithner]

[EMAIL PROTECTED] wrote:

> I've been using Django for a project, and one thing I have sorely
> missed is having an ifless and ifgreater template tag. Other internal
> projects have had similar problems, and made at best hacks to work
> around this missing feature. I understand however that there is some
> hesitance to add more tags to the templating system though in an effort
> to separate display and logic.

I think sooner or later you will find all kinds of cases where the
standard tags are not sufficient enough. In FFSomething, I generate a
DOT file out of a network dump of the topology and have to calculate the
color of the lines depending on the link quality. This is surly a layout
not a view code thing. For such cases i just use the expr tag (
http://code.djangoproject.com/wiki/ExprTag ) because it's simply so
flexible for such rare cases where the if and ifequal tags are not
sufficient enough. I don't think ifgreater and ifless are really used
that much that it should result in a additional default tag, maybe the
if tag should simply be more flexible then it is now.

i'm -0 on this.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Multi-db branch feedback/questions

[Daniel Poelzleithner]

> OK, thoughts, anyone?

When i first heard of multi-db i more thought about support for
clustering then moving some apps/models to other databases, which is
great, too of course.

for example: having one master db and some slave dbs that mirror the
master db. requests should go to slaves in some sort of changeable round
robin style and changes should go directly to the master db.
this scenario popped into my mind the first time i heard of multi-db. is
such a scenario supported somehow. i think it will be useful for very
large sites and should be kept in mind when the db layer is redesigned.

kindly regards
 daniel



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Auto-escaping patch

[Daniel Poelzleithner]

Malcolm Tredinnick wrote:

> Damn. Your phrasing tipped me off to a case we need this more: RSS feeds
> and Atom content elements with type="html". :-(
> 
> We might need a "mark as unsafe" filter for these cases (so that {{ var|
> escape|unsafe|escape }}) works (or just make "escape" not mark the
> string as safe, but I suspect that will have unintended annoying
> side-effects).

I suggest {{var|escape|escape:force}}

force as an optional argument to escape already escaped strings.

But an unsafe filter may be usefull, too.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

flat values() in querysets

[Daniel Poelzleithner]

Hi,

Currently it's kinda verbose to get just a list of id's from a query to
put it in a bulk_in or process it further.

example:

>>> NetworkState.objects.all().order_by("-stopdate")[:5].values("id")
[{'id': 2738}, {'id': 2737}, {'id': 2736}, {'id': 2735}, {'id': 2734}]

Then i have to unpack it to get a [2738, 2737,...] list, which is what I
wanted in the first place.

I suggest Object.objects.all().values("id", flat=True). Flat as a
optional argument, which is only allowed when only one field is
requested and returns a list with only the values.

Any better ideas ?

kindly regards
  Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: flat values() in querysets

[Daniel Poelzleithner]

jrs wrote:

> What would the result be if multiple fields were selected?  or should
> this be valid only when a single field is requested?
> 
> NetworkState.objects.all().order_by("-stopdate")[:5].values("id",
> "name")

I couldn't think of a nice solution at first, so i said for one key only.

What do you think about returning n tupples for n arguments. if n > 1
and a pure list for only one argument ?

.values("id", "name", flat=True) would return
[(id,name),(id,name),...]

.values("id", flat=True) would return
[id,id,...]

?

kindly regards

PS: yes i will provide a patch :)

kindly regards
  Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Graham Dumpleton about mod_python

[Daniel Ericsson]

On 18 aug 2006, at 15.07, Malcolm Tredinnick wrote:
>
> On Fri, 2006-08-18 at 05:54 -0700, olive wrote:
>> Hi folks,
>>
>> Have you read the following from Django Comments, what do you  
>> think of
>> it ?
>
> This seems to be in response to some question. What is the context,
> though? What was the original question and where was this posted? Was
> there a particular point you wanted to know about?

The comments is from http://www.djangoproject.com/documentation/ 
modpython/

- Daniel


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: App portability

[Daniel Poelzleithner]

Martin Glueck wrote:

> Be careful ... in one of the next releases of python, support for
> relative import will be dropped! So I would suggest that you don't
> rely on relative import in new written code and change it whenever you
> find it in old code.

It will not be droped in 2.5 but it will be made clear (horray), which
is exactly what we have problems with.

in myapps/views.py:
from .models import Somemodel

which will import from myapps/models.py Somemodel

from ..otherapp.models import Othermodel

imports from myapps/../otherapp/models.py -> otherapps/models.py

This is exactly what we need for our apps to be portable :)

kindly regards
  Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: list_filters does not work for models with one-to-one relationship, why?

[Daniel Roseman]

Honza Král wrote:

> Hi all,
> in django.contrib.admin.ChangeList.get_filters
> there is a line:
>
> if self.lookup_opts.admin.list_filter and not
> self.opts.one_to_one_field:
>
> does anybody know why there is the second part of the condition?
> when I commented the second part out, the filters worked fine.
>
> I spent some time tracking this down, thinking there was something
> wrong with my models, since this behaviour is not documented.
>
> thanks for any reactions
> Honza

I raised a ticket on this issue (#2145) four months ago but it hasn't
received any attention from the developers. In the meantime, I
commented out the condition as you also suggest, and have not had any
problems since. I also see that someone has just opened ticket 2718
which is the same problem.

I suppose I could submit a patch but I'm not clear enough on what that
code is supposed to do.
--
Daniel.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Ticket spam

[Daniel Poelzleithner]

Matthew Flanagan wrote:

> In one project I know of that uses trac they just have a single login
> for users to create tickets and submit patches rather than requiring
> every user to register. This eliminated 99% of their trac spam. They
> just documented the login/password in their 'contributing' docs. This
> saves someone having to manage trac users.

Nice idea. I use the trac Admin UsersManagerSomething Plugin, so users
can easily register an account and then change wiki pages, submit
tickets, etc. I don't use any other spam blocking and spam stopped after
that.

kindly regards
  daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: metaapi: Django Meta-API - Invitation to Criticize!

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> Some of these ideas sound really cool! I'd suggest focusing on one or
> two of them rather than attempting to do the whole shebang. In my
> opinion, the Python Imaging Library functions as generic views would
> be a really useful thing to have.

If such a Interface is specified, it should be flexible enough to switch
backends. In my optinion PIL has a total terrible quality when compared
to ImageMagick.

kindly regards
 Daniel


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

Re: Upcoming Django release, and the future

[Daniel Roseman]

On 26 Feb, 04:56, "James Bennett" <[EMAIL PROTECTED]> wrote:
> If there's a bug that's been annoying the heck out of you and you want
> it fixed before the release, this would be the time to speak up about
> it.

Because you did ask, the one that's annoying me most at the moment
(and preventing me from using newforms) is ticket 3268 -
form_for_model and fields with choices. This was accepted a month ago
but hasn't been included, and in fact the patch no longer installs
against current trunk.

It looks like it needs a design decision and tests - I'd love to help
but I don't know anything about writing tests.
--
Daniel.


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

Re: Constraints and MySQL

[Seattle Daniel]

>From the MySQL docs:
Deviation from SQL standards: Like MySQL in general, in an SQL
statement that inserts, deletes, or updates many rows, InnoDB checks
UNIQUE and FOREIGN KEY  constraints row-by-row. According to the SQL
standard, the default behavior should be deferred checking. That is,
constraints are only checked after the entire SQL statement has been
processed. Until InnoDB implements deferred constraint checking, some
things will be impossible, such as deleting a record that refers to
itself via a foreign key.

As I read it, there is not a way to force InnoDB to check constraints
at commit. And once there is it will be quite some time before the
mass of MySQL instances support it.


On Feb 27, 9:16 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Hi all,
>
> Adrian has finally had a chance to look at, and approve the acceptance
> of, the test fixtures patch. I sat down tonight to check in the patch,
> did a last little check, and hit a snag - the trunk model tests break
> under MySQL. Personally, I'm a Postgres jockey, so I need some
> guidance from the MySQL-using community.
>
> The problem seems to have been introduced in [4610], and highlights in
> MySQL the same problem that [4610] fixed in Postgres - when using the
> InnoDB backend, foreign key constraints are checked per command, not
> per-transaction, and as a result, saving forward references causes the
> serializer model test to fail. If you have your MySQL setup to use
> MyISAM (the default backend), you won't see the problem, because
> MyISAM doesn't enforce constraints.
>
> This also ties in with #2720, which identified the fact that many
> foreign key constraints aren't being created correctly under MySQL.
>
> Postgres has similar behaviour to InnoDB by default, but [4610]
> modified the table declarations to disable constraint checking until
> the end of a transaction using DEFFERABLE INITIALLY DEFERRED. However,
> apparently MySQL doesn't implement this feature or an equivalent.
>
> One way around the problem would be to use SET FOREIGN_KEY_CHECKS at
> the start and end of each transactions - but if I'm reading the docs
> right, this wouldn't validate any keys modified while the checks were
> disabled.
>
> Or, is there another approach that I am not aware of?
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Single-argument filters: really a benefit?

[Daniel Brandt]

On 4/11/07, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> I consider this a wart and it's been bugging me for a while. So,
> sparked by some discussion in #django, here goes...
>
> I'd like it if template filters supported multiple arguments for real.
> Currently filters that need multiple arguments just have to come up
> with a delimiter and then do string parsing to get the arguments. This
> is not a very good approach and if django.template could recognize
> multiple arguments it would relieve filters of this annoying duty.

We recently came upon this when my collegue made a patch for the
truncate filter last week (ticket #3963). The argument handling really
isn't pretty and wanting it to work differently has nothing what so
ever to do with trying to make templates too advanced.

Yesterday I did some work with Jinja templates
(http://jinja.pocoo.org/) which are very much alike django templating.
I was very much relieved to see it uses sane argument handling:

{{ variable|replace('foo', 'bar')|escape }}

I don't believe the function-call syntax is alien to anyone doing web
work today, what with javascript being part of the daily routine.

I know Jinja is "not invented here", but this approach really is a
better way to go, since the argument to the filter is passed to a
function anyway.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

The locmem patch and development progress

[Daniel Brandt]

Something has been bugging me for a while..

Check out http://code.djangoproject.com/ticket/3012 for a pretty
critical patch to the locmem cache backend. The patch is accepted and
ready for checkin, and more than two weeks have passed since. The bug
itself was filed in february. What am I missing here? I ran into this
problem every single day, until I found that ticket and the patch.

I love django.. I have spent roughly 3½ months working with it with
far better results than I initiallty thought and I see no good
alternative to switch to.

A lot of times when people complain about that it takes a long time to
get something from being a ticket in trac to be commited to the tree,
the reply is that it has to do with keeping django stable, assuring
trunk is usable at all times. A nice mindset, sure, but what more is
needed from the ticket above to get it commited? It has already been
approved!

I do not wish to step on anyones toes here, but this is a major
concern for me. I am about to move a really large existing site to
django in the next 6 months and I know I will probably write and
submit patches to django during that time, but I am starting to loose
the motivation to contribute back. What is the use of writing patches
when it takes such a long time before it's committed or even
concidered for inclusion, even for critical stuff like the locmem
patch above. It is demotivating, and I think more people than me think
so too. What is needed to speed up the development while maintaning
your standards? Or perhaps another approach to the code base is
needed? More committers is needed, I'm sure, but those need to grow
out of the community effort, proving themselves, and that obviously
takes a lot of time.

With the quick growth of django users lately I'm sure the amount of
reported bugs and submitted patches will grow, and django development
needs to get up to speed to stay on top of the situation.

As it stands, I don't think it's clear enough to outsiders if the
percieved slowness of development is intentional or due to not enough
people helping.

If anyone gets upset reading this. please accept my apologies, I am
not out to troll. I am just trying to get a grip on how my help would
be most effective as I dig deeper into django.

Regards,
Daniel

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

Re: The locmem patch and development progress

[Daniel Brandt]

On 4/18/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 4/18/07, Daniel Brandt <[EMAIL PROTECTED]> wrote:
> > Something has been bugging me for a while..
>
> This type of complaint seems to come up every few months. I'm always tempted 
> to
> ignore it because I have a hard time responding in a way that doesn't end up
> making me sound like a dick; usually that temptation wins out.
>
> I'm gonna give an answer a try this time. I'll try as hard as I can to not be 
> a
> jerk -- that's totally not my intention -- but if I fail I hope you'll forgive
> me.

First of all: Thank you a lot for taking the time to respond..

<..>
> Like the vast majority open-source projects, Django is 100% volunteer-driven.
> Every single bit of work is done by somebody in his or her spare time. We all
> have some combination of full-time jobs, wives, families and hobbies competing
> for our time. Obviously spending time on mailing lists is Yet Another Time 
> Suck.
>
> I know this isn't your intention, but when I see an email like yours I feel 
> like
> I'm being reprimanded for having a real life. I suspect most other developers
> feel the same way.

I understand exactly what you are saying here (family man myself),
open source is a "hard hat zone", and it wares you out at times taking
all the comments and keep on working.

> I think it's very easy to underestimate the amount of work required in
> checking in a patch. It seems like a simple handful-of-lines patch like yours
> should be a no-brainer, but there's a whole bunch of steps I (or any
> other bug fixer) has to go through before we can check a fix in:

Just to be clear, I'm not the author of the patch, I simply found it useful.

<..>
> And adding new developers to a project is *hard*. We want to be completely 
> sure
> that we trust someone before giving them commit access. Sure, we could switch 
> to
> a model like PHP where anyone with a patch gets commit access, but then we'd
> risk turning out like, well, PHP.
>
> Finally: this is open source. Nothing prevents you from modifying your
> code in any way you want; you don't need my permission or the checkin
> of your patch in order to use it.

Fully agree.. What I am interested in finding out is if this really is
a good direction to turn, maintaning what essentially is a private
fork, and then use it in a production environment? The issue with it
being in the "official" django tree is that there are alot more people
out there  using that codebase and improving on it. Keeping my own
fork would mean less to no peer review.

> Once again I'm very sorry if any of the above comes off as dickish. I
> really do feel your pain, and I wish more than anything that I could
> spend more time on Django (while still being able to pay the
> mortgage).

Man, I'd pay your mortgage if I could as a thank you for helping to
bring dajngo about. Thank you again for taking the time to respond,
this answered of things I've been thinking about..

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Add a minimal Gitignore

[Daniel Azubuine]

I think it will be a little bit helpful to add a very minimal .gitignore 
file to the django project.
Maybe one that just ignores the environments, test files

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3c71bbfb-b205-434b-8a1c-c15ceaba3dbbn%40googlegroups.com.

Re: Add a minimal Gitignore

[Daniel Azubuine]

Yeah

What I meant is for the default ‘startproject’ template to include a
minimal .gitignore file.

I've added the template.
Just wanted to ask before I push

On Thu, Mar 9, 2023, 20:00 James Bennett  wrote:

> On Thu, Mar 9, 2023 at 10:27 AM 'Adam Johnson' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> The Django project has a .gitignore file:
>> https://github.com/django/django/blob/main/.gitignore
>>
> I think this person was asking for the default ‘startproject’ template to
> include a minimal .gitignore file.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg9ySuiTEcyUQQiPKzP_Q6qCu2JBV6jZeE-0QdEFoimYAg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHRz_NZ-6rNNN53f6VGVJ4vv827G165yksFK%2BkMXz_vztz5Q8A%40mail.gmail.com.

Re: Add a minimal Gitignore

[Daniel Azubuine]

Yeah.

Nice idea! Arthur!
I'll do that

On Thu, Mar 9, 2023, 20:40 Arthur Pemberton  wrote:

> I like the idea as I've seen novices commit all their .pyc files, but
> maybe this should only triggered by a flag to startproject, --git perhaps.
>
> Arthur Pemberton
>
> On Thu, Mar 9, 2023, 14:13 Daniel Azubuine 
> wrote:
>
>> Yeah
>>
>> What I meant is for the default ‘startproject’ template to include a
>> minimal .gitignore file.
>>
>> I've added the template.
>> Just wanted to ask before I push
>>
>> On Thu, Mar 9, 2023, 20:00 James Bennett  wrote:
>>
>>> On Thu, Mar 9, 2023 at 10:27 AM 'Adam Johnson' via Django developers
>>> (Contributions to Django itself) 
>>> wrote:
>>>
>>>> The Django project has a .gitignore file:
>>>> https://github.com/django/django/blob/main/.gitignore
>>>>
>>> I think this person was asking for the default ‘startproject’ template
>>> to include a minimal .gitignore file.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAL13Cg9ySuiTEcyUQQiPKzP_Q6qCu2JBV6jZeE-0QdEFoimYAg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAL13Cg9ySuiTEcyUQQiPKzP_Q6qCu2JBV6jZeE-0QdEFoimYAg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAHRz_NZ-6rNNN53f6VGVJ4vv827G165yksFK%2BkMXz_vztz5Q8A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAHRz_NZ-6rNNN53f6VGVJ4vv827G165yksFK%2BkMXz_vztz5Q8A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQQHWGsGhXs1pM85cBRBJ6cQ%2Bvsi6DA4cNhMXVzNbZtizg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQQHWGsGhXs1pM85cBRBJ6cQ%2Bvsi6DA4cNhMXVzNbZtizg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHRz_NZop_sBeP%3DjvfM-aHbwhOrmA5Gtc8ZpSFFQ59xCUh5dew%40mail.gmail.com.

Select API choice when starting new project.

[Daniel Azubuine]

When starting a new Django project, the user can select if he wants to
build an API or use the Django template.
If he chooses API, then Django-rest framework will be installed, and then
serializers.py will be added to the folders.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHRz_NYh8NpHzVGZ4PFNFc86Fz51uuwz%2BiTQAyR7hvXJFop7eg%40mail.gmail.com.

Re: Select API choice when starting new project.

[Daniel Azubuine]

thank you i didn't know.


On Mon, Apr 17, 2023 at 8:26 AM Florian Apolloner 
wrote:

> Hi, this is something which is already supported via the template argument
> to startproject/startapp.
>
> Cheers,
> florian
>
> On Sunday, April 16, 2023 at 11:47:44 PM UTC+2 Daniel Azubuine wrote:
>
>> When starting a new Django project, the user can select if he wants to
>> build an API or use the Django template.
>> If he chooses API, then Django-rest framework will be installed, and then
>> serializers.py will be added to the folders.
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e6df6bae-b417-4a0c-97bd-c2de927728dcn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/e6df6bae-b417-4a0c-97bd-c2de927728dcn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 

Best regards,
[image: Daniel Azubuine]
[image: photo]
Daniel Azubuine
He/Him
Music Composer and Software Engineer, Dflat

+2349071177001  |  azubuinedanie...@gmail.com
[image: github] <https://github.com/Danimoz> [image: facebook]
<https://facebook.com/azubuine.daniel> [image: linkedin]
<https://linkedin.com/in/DanielAzubuine> [image: twitter]
<https://twitter.com/DanielAzubuine>

"Love, Trust, Few A fool thinks himself to be wise, but a wise man knows
himself to be a fool." - William Shakespeare
Create your own email signature
<https://www.wisestamp.com/create-own-email-signature/?utm_source=promotion&utm_medium=signature&utm_campaign=create_your_own&srcid=>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHRz_NZN4%3D8g7zbUPUbrQicyUH17eAyXbeWQfUsfPvax1ix5eQ%40mail.gmail.com.

Re: More than two-levels of inline editing?

[Daniel Ericsson]

On 16 nov 2005, at 11.41, Bjørn Stabell wrote:


Is there any work underway to implement more than two-levels of inline
editing in the admin interface?  I.e., Company/ Department/ Team/
Person in one interface?

I see this talk about 'new-admin' so I'd thought I'd ask.


What I've gathered from lurking is no, it's not possible and new- 
admin isn't the simple solution. There needs to be a merge of new- 
admin and after that elimination of core fields for this to be  
implemented.


see: http://groups.google.com/group/django-users/browse_thread/thread/ 
11c5adb4a4b1b9f/3f71cdab836adad4?tvc=2&fwc=2


Also, you say "two-levels of inline" when I think you mean "one-level  
of inline" because afaik. that's what the admin supports atm.


hth,
- Daniel

Re: A fix for all that futzing around with paths

[Daniel Ericsson]

On 18 nov 2005, at 18.03, Adrian Holovaty wrote:


On 11/18/05, David Ascher <[EMAIL PROTECTED]> wrote:

I guess I wasn't clear.  What p4 does (and I propose django-admin  
does) is
look for an environment variable called DJANGO_SETTINGS_NAME, and  
use "
settings.py" if it doesn't find such an environment variable.  It  
then looks
for a file with that name in the CWD.  If it doesn't find one  
there, it
looks in parent directories, until it finds one.  That's the  
settings file

that is used.


Oooh, this is a nice idea! Is anybody willing to submit a patch?


http://code.djangoproject.com/ticket/904

- Daniel

--
Daniel Ericsson
http://monowerks.com/ | http://lounging.com/

Re: Removing the magic

[Daniel Ericsson]

On 7 dec 2005, at 06.21, Adrian Holovaty wrote:


But my rationale for changing to the magic object approach is: If we
move to class-based lookups (Person.objects.get_list() rather than
people.get_list()), the class will have been imported *anyway*, so
it's not too much of a big deal to have to use it.


The other magic-thread was too hot for me, I'll jump in here instead...

I find the use of "objects" as a way of namespace separation a bit  
off-putting. Enforcing an invocation-style via stack inspection would  
cut down on the line-noise. Not a terribly big deal, just how I'd try  
to do it unless there'd be something that precludes it...


import inspect

class TestClass:
@classmethod
def get_list(*args):
frame = inspect.currentframe()
frame = frame.f_back
if not frame.f_locals:
# called via Class
print 'class'
else:
# called via an instance, raise InvalidInvocationError  
or something...

print 'instance'
raise Exception

def main():
TestClass.get_list('test')
test = TestClass()
test.get_list('test')

if __name__ == '__main__': main()


regards,
- Daniel

Re: Removing the magic

[Daniel Ericsson]

On 7 dec 2005, at 10.53, Daniel Ericsson wrote:

I find the use of "objects" as a way of namespace separation a bit  
off-putting. Enforcing an invocation-style via stack inspection  
would cut down on the line-noise. Not a terribly big deal, just how  
I'd try to do it unless there'd be something that precludes it...


import inspect

class TestClass:


...

Actually this didn't do at all what I thought it did... sorry for the  
noise... at least I found a bug with that test.


- Daniel

Re: Request params problem

[Daniel Poelzleithner]

plisk wrote:
> Yeah, its OK to have more than one value of the same param and wrap all
> of them in the list. But when you have only one parameter value passed
> making a list for it is at least inconsistent with the value you get
> from request.GET['param'] which is just a scalar and this also breaks
> some parts in admin as was mentioned.

If you have only one parameter simply use [0] to access it. Returning a
list or a string depending on the number of arguments is a bad idea,
because you have to check everytime which type of value it is.
Generating more code and a easy target for mistakes and security flaws.
You can't trust any values comming from the client, somebody could try
to attack your site by altering the urls by hand. I think its the best
solution that way.

request.GET['param'] should also return a list or tuple of values.

kindly regards
  Daniel

Re: Moving auth and core models to contrib -- and dependencies

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> So how is this implemented? The simplest way we could do it is a
> __dependencies__ variable in the __init__.py of the app. For example,
> this would go in django/contrib/admin/__init__.py:
> 
> __dependencies__ = ('django.contrib.auth',)
> 

+1 for dependencies, but not so simple. Imagine what will happen when
django 1.0 is released and apps are starting poping up. On app may
require a specific version of another app, or is incompatible with a
specific app.

Apps sould define a __version__ in __init__.py wich sould be checked on
the dependencies check.

maybe a syntax like:
__dependencies__ = (('django.contrib.auth',
">=0.1,!=0.2"),('my.app.bla', "==0.3"))

would require a version of contrib.auth that is greater as 0.1 but not
0.2 and version 0.3 of bla :)

kindly regards
 daniel

Re: subdomain specific settings file - new idea

[Daniel Poelzleithner]

Amit Upadhyay wrote:
> Hi,
> 
> Wish you all a very happy and fruitful new year!
> 
> Djando URL resolution causes some problem with applications hosted in
> different subdomains. Consider www.example.com <http://www.example.com>
> and blog.example.com <http://blog.example.com>. Both of them are running
> off the same database and share common admin, and so on, but are hosted
> in different subdomain, which causes problem with URL resolution. To
> solve this we can copy the settings file and change ROOT_URLCONF to
> point to different locations. I propose splitting settings.py into
> common_settings.py and www_settings.py. www_settings.py contains
> something equivalent to:
> 
[...]
> 
> What do you think?

I think the right approach would be to make the urlresolver in
handlers.base configurable through a settings variable.
The default value would be something like

URL_RESOLVER = "django.core.urlresolvers.RegexURLResolver"

This would allow to write custom resolvers.
Also a resolver that also checks the hostname would be nice to be
included. it would uses a different ROOT_URLCONF like:

urlpatterns = {
r'www\.bla\.com': patterns('',
...
   (r'^admin/', include('django.contrib.admin.urls.admin')),
)
r'.*\.bla\.com': patterns('',
...
)
}

You could do very nice things with this approach, like using a database
to resolve the url, or even change the other settings depending on the
hostname you resolve...
The speed impact would be minimal and the posibilities enormous.

kindly regards
 Daniel

Re: subdomain specific settings file - new idea

[Daniel Poelzleithner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ivan Fedorov wrote:

>>URL_RESOLVER = "django.core.urlresolvers.RegexURLResolver"
> 
> +1
>
>>You could do very nice things with this approach, like using a database
>>to resolve the url, or even change the other settings depending on the
>>hostname you resolve...
> 
> 
> I'm already have database-driven URL Resolver. It's built over standard
> Django resolver, so anybody can use it with unmodified Django.
> 
> Does anybody interesting in it?..

Maybe something for contrib ?

I'm working on a patch for the URL_RESOLVER. This patch will include a
the default behaviour as django.core.urlresolvers.URLResolver and a
simple HostURLResolver, that allows matching for hostnames, too.
URLResolver is just a small wrapper, because i changed the paramters for
the resolver to be
def __init__(self, request, urlconf_name):
Maybe even remove the urlconf_name and look it up in the resolver class
rather then the http base class. What do you think ?

The HostURLResolver is so small, that i think it doesn't make sense to
put it into contrib.

kindly regards
  Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDwWMhy/mkIQp7AD0RAh5zAJ42iWYOgzQ5vMjfLk3lLx3a99lIWACgj6M9
06QNiFOQh5SOUH9+OoIH10g=
=ZgV3
-END PGP SIGNATURE-

Re: subdomain specific settings file

[Daniel Poelzleithner]

Amit Upadhyay wrote:

> This makes clear on what to do incase there are different subdomains, we
> can just add other subdomains specific setting files blog_settings.py
> and so on, which point to different ROOT_URLCONF and so on [we can
> overwrite other things too if required].

Look at http://code.djangoproject.com/ticket/1192 if it fits your needs,
please.

It doesn't have subdomain specific settings, but I think the
HostURLResolver is a very usefull thing. Also you could write a custom
resolver trough the new config setting.

kindly regards
 daniel

Re: Proposal: Django namespace simplification

[Daniel Ericsson]

On 13 jan 2006, at 03.32, Adrian Holovaty wrote:


While we're at it, let's rename DjangoContext to something that
reflects the fact that you pass in an HttpRequest object and it has
context processors. RequestContext, SuperContext, FlexContext,
AdvancedContext -- those ideas are all pretty lame. Ideas?


It doesn't lend itself to succinct naming :) I'll throw  
DelegatedContext, ProcessingContext, IncreasedContext,  
AccessoryContext, AuxContext (for Auxiliary, but that'd be a pain to  
write), AugmentedContext, PseudoContext and ProxyContext into the mix.


Lastly, HttpRequestProcessingContext which I think is very  
descriptive. Which is good right? :]


- Daniel

Re: magic-removal: "Change subclassing syntax"

[Daniel Poelzleithner]

Jeremy Dunck wrote:

> This makes me think the world needs a wiki whose wikitext syntax is
> restructured text.

In general ?
At least trac has a macro for restructured text I think.

kindly regards
  daniel

using accounts to prevent ticket spam ?

[Daniel Poelzleithner]

Hi,

I think it has become to much spam in django trac. I suggest to use
http://trac-hacks.org/wiki/AccountManagerPlugin so only registered users
can change stuff and comment bugs. I think this would prevent much of
the spam currently comming in, or at least allows to ban those accounts.

Maybe ip may help, but i think they will most likly use a botnet or so.

kindly regards
  daniel

Re: Food for Thought: Yahoo User Interface Library

[Daniel Poelzleithner]

limodou wrote:

> I agree! But dojo seems too large? I also havenot played with it so far.

dojo is large but very modular. it can load stuff on demand if you make
it right, so there is not much blow there. what sense does it make to
use a toolkit that implements only a small subset for widgets that seems
usefull for a wide range, so everybody has to use another toolkit or
bake one for their purposes. such a thing gets only messy when there is
no standard interface.
the guys at dojo are working hard to make it better and better and i
think its the most promising toolkit around.

also there is a question about how the yahoo toolkit will get
development in the future, its not a very open development process as
much as i have seen. something i don't like.

kindly regards
 daniel

Re: [Changeset] r2386 - django/branches/magic-removal/django/core

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> django-admin.py startproject foo
> 
> # generated settings file contains INSTALLED_APPS with the basics,
> # such as sessions, auth, etc.. Advanced users can remove any or all of 
> that
> # if they don't want to use it.
> 
> python foo/manage.py synchdb   # creates tables for all INSTALLED_APPS
> 
> # When you write some new models, just run "manage.py synchdb" again
> # to make sure things are in sync. This can later be expanded to include
> # ALTER TABLE statements.

i was working on a patch that allows to use globs in manage.py install
so you could write "install *" to install all INSTALLED_APPS, but with
the syncdb which later can alter tables this seems even better.

my patch is a extended version of #1371 which allows also simple
depedencies to other apps. in myapp/default_settings.py you could write
DEPENDS_ON=('somethingelse.app',) which would be automaticly appended to
INSTALLED_APPS if it's not there and on "install app" be created before
the myapp is installed.

Thoughts ?

kindly regards
  daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: urlconf, applications..coupling

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> Yes, I realize __name__ + '.views' will result in something like
> 'myproject.polls.urls.views' -- some extra string mangling would have
> to be done.

how about using the python 2.5 relative import syntax and emulating it
accoringly.

urlpatterns = patterns('.views',

for a views in the current directory

urlpatterns = patterns('..views',

views in the partens directory

etc.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Bug in admins search function (trunk)

[Daniel Bimschas]

Hi,

just found a bug in the admin interface (trunk version). When you
enable searching and type a simple " " empty space in the search
field, you'll get a TypeError with:

reduce() of empty sequence with no initial value

Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/django/core/handlers/base.py"
in get_response
  74. response = callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python2.3/site-packages/django/contrib/admin/views/decorators.py"
in _checklogin
  54. return view_func(request, *args, **kwargs)
File "/usr/lib/python2.3/site-packages/django/contrib/admin/views/main.py"
in change_list
  235. cl = ChangeList(request, app_label, module_name)
File "/usr/lib/python2.3/site-packages/django/contrib/admin/views/main.py"
in __init__
  64. self.get_lookup_params()
File "/usr/lib/python2.3/site-packages/django/contrib/admin/views/main.py"
in get_lookup_params
  228. lookup_params['complex'] = reduce(operator.and_, complex_queries)

  TypeError at /isp_bib/admin/bib/articles/
  reduce() of empty sequence with no initial value

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Fwd: Admin interface using CharField as a primary key

[Daniel Bimschas]

Hi! I posted this on django-users before, but without success.

If a field of "meta.CharField(primary_key=True)" is used in a model,
you get problems with the links in the admin interface, if there are
colons or special characters in the string. They should be urlencoded
and decoded i think.

Is there a reason that Django doesn't do this? Is the philosophy to
use a SlugField here? In my case I really NEED to use CharField as a
primary key. And I think, that if there is the possibility to use
CharField as pk, it should also work in admin!?


Regards, Daniel



-- Forwarded message ------
From: Daniel Bimschas <[EMAIL PROTECTED]>
Date: 30.03.2006 19:16
Subject: Re: Admin interface using CharField as a primary key
To: django-users@googlegroups.com


If have a model like this:

 class Article(meta.Model):
cite_key = meta.CharField(maxlength=255, primary_key=True)
...

where "cite_key" is a unique string used in a bibtex-file. The problem
now are the links to the edit pages created by the admin interface.
The html-code is for example:

   

which should link to
"http://host/bibtexapp/admin/bib/articles/AAMG:05/"; but the browser
interpretes this as "aamg:05/" because of the colons in the url. So
the thing would be to url-encode the key I think.

I was using 0.91 before, but switched to the trunk now.





2006/3/30, Andy Dustman <[EMAIL PROTECTED]>:
>
> On 3/30/06, Daniel Bimschas <[EMAIL PROTECTED]> wrote:
> >
> > Hi there!
> >
> > I'm currently trying to convert an old webapp written in PHP into a
> > django-based app. The PHP-System used VARCHAR-Fields as primary keys
> > in the MySQL - DB.
> >
> > Now, if i convert the data for the new tables created by Django, I
> > have the problem that the admin interface can't edit any entries where
> > the title contains colons (":"), because the admin interface uses the
> > primary keys in the url created.
> >
> > I'm currently using Django 0.92.
>
> What sort of field (i.e. models.XXXField) are you using for your
> primary key? Sounds like maybe a SlugField? Unless you are using the
> default primary key (implicit id = models.AutoField(), which is
> INTEGER AUTO_INCREMENT)? You might then need to set primary_key in
> Meta to prevent the default PK from being created. See the model-api
> docs.
>
> (All this assumes you are using the magic-removal branch, because you
> did say 0.92.)
>
> --
> The Pythonic Principle: Python works the way it does
> because if it didn't, it wouldn't be Python.
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Fwd: Admin interface using CharField as a primary key

[Daniel Bimschas]

Thank you Malcolm,

again it sounds like work is mainly being done on the magical-removal
branch. I wonder if it would be the best to switch to MR now? Is it
"stable"? Or when do you expect it to become stable?

I started my project using 0.91 last week as a totally django-noob and
I am close to completing this first project now.


Regards, Daniel


2006/3/31, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
> Hi Daniel,
>
> On Fri, 2006-03-31 at 12:23 +0200, Daniel Bimschas wrote:
> > Hi! I posted this on django-users before, but without success.
>
> Apologies for not seeing this on django-users (I am more than one day
> behind on reading that).
>
> >
> > If a field of "meta.CharField(primary_key=True)" is used in a model,
> > you get problems with the links in the admin interface, if there are
> > colons or special characters in the string. They should be urlencoded
> > and decoded i think.
> >
> > Is there a reason that Django doesn't do this? Is the philosophy to
> > use a SlugField here? In my case I really NEED to use CharField as a
> > primary key. And I think, that if there is the possibility to use
> > CharField as pk, it should also work in admin!?
>
> It's a bug. I submitted a patch and it's fixed on the magic-removal
> branch (a few weeks ago), but not on the trunk. If you want to grab the
> patch and apply it to your local (trunk) copy, have a look at ticket
> 1375.
>
> Note that URL-quoting is not the correct solution here, because it
> generates false-looking URLs: browsers decode the string too early in
> some cases and display the incorrect URL in the status bar (this is
> probably not so relevant for colons, but is significant if you have
> slashes in your primary key string). So that is why the patch implements
> quoting slightly differently.
>
> Cheers,
> Malcolm
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: New feature: Defining fieldsets in form class (Ticket #17301)

[Daniel Swarbrick]

+1

I've often wondered why fieldsets have been possible in the Django
admin interface for a while now, but not possible with ModelForms.
Looking forward to this.

On Nov 27, 12:43 am, Mikołaj Siedlarek  wrote:
> Hi,
>
> I've just posted a new ticket with everything the feature proposal needs -
> motivation, idea and actual implementation.
>
> https://code.djangoproject.com/ticket/17301
>
> It definitely needs some discussion, so please -- ask, discuss, criticize,
> share some thoughts and one day, hopefully +1. :)
>
> Thanks,

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

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

> On Wed, Dec 28, 2011 at 10:29 AM, Etienne Robillard 
> 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.

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

[Daniel Sokolowski]

Thanks

On Thu, Dec 29, 2011 at 11:36 AM, Alex Gaynor  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 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: 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 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: 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 contents are packaged according to the
> >>   fo

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
> > > works, add an optional character field to the mo

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: Digest for django-developers@googlegroups.com - 3 Messages in 1 Topic

[Daniel Greenfeld]

> Adrian Holovaty  Jan 13 12:07PM -0600

> The ultimate solution is: don't use model forms. I never use them for
> anything, precisely because of things like this, where the framework
> is trying to do too much behind the scenes. It's too magical for my
> tastes, and while I understand why we added it to the framework, I see
> it as a crutch for lazy developers. C'mon, it's not a lot of work to
> create a "normal" (non-model) form class and pass its cleaned data to
> a model's save() method.
>
> End rant. :-)


I pretty much agree with Adrian. I use ModelForms when I'm grinding
out stuff fast, but for real, detail work, I rely on normal
forms.Forms.

My reasons match Adrian's reasons. I use them as a crutch, but the
magic can hurt at the worst time. So when I have time, I refactor to
make thing simpler and less atomic.

I leave all the magic stuff to smart people. ;)

-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.blogspot.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: 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.

More about test speedup

[Daniel Moisset]

Somewhat independently from the recent thread, I had been working in
getting tests running faster. I essentially reimplemented an idea that
Erik Rose[1] posted here last year, but I did it in a way that I think
is more DB independent (although... I'm using it and have tested it
only under PostgreSQL which is what I needed :) )

My customized TestCase is quite simple and available at
https://github.com/machinalis/django-fasttest

It's a bit rough but I'm using it for a real project with a ~2x
speedup (my tests make heavy use of fixtures so YMMV).

If there's interest, something like this could be polished into a
django patch; I'd like to hear the opinion of the core devs if they
are aligned with the idea, so I can polish the implementation and
submit a patch

Regards,
D.

[1] The idea is loading fixtures once per TestCase instead of once per
test method, and use DB rollbacks after each test to return the DB to
the after-fixtures-just-loaded state.

-- 
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: More about test speedup

[Daniel Moisset]

On Tue, Jan 24, 2012 at 2:22 AM, Anssi Kääriäinen
 wrote:
> On Jan 24, 3:07 am, Daniel Moisset  wrote:
>> [1] The idea is loading fixtures once per TestCase instead of once per
>> test method, and use DB rollbacks after each test to return the DB to
>> the after-fixtures-just-loaded state.
>
> So, the idea is to do the following for each TestCase:
>
> begin
> load fixtures
> savepoint s1
> do test 1
> rollback to savepoint 1
> do test 2
> rollback to savepoint 1
> ...
> # all methods ran
> rollback
>
> I think that should work. It would be great to write this in a way
> that just checks if the connection supports savepoints. If not, then
> run the tests in the old-fashioned way, if yes, do the above trick.

OK, I can change that... there are a few other drawbacks: my current
code does not support multi-db setups, And I don't feel experienced
enough on that scenario to feel sure how to proceed in that case or
what is safe to do.

Anyway what I can do is: if connection support savepoints AND is
single db, follow this approach

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

Feature request: read-only admin view

[Daniel Greenfeld]

> Russell Keith-Magee  Jan 28 10:28AM +0800
>
>> 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.

I agree 100%. The admin should remain the admin.

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

Working with NoSQL these days I found the first big problem in Django
was the lack of a reliable django.contrib.admin alternative that works
with NoSQL. I looked into various third party apps that stapled
themselves into the Django Admin, and was unhappy. Why? Because the
Django Admin was designed for the ORM, and stapling additional non-ORM
functionality on it was outside it's original design scope.

I think increasing that design scope is a bad idea. The admin should
remain pretty much as it is, just incrementally changed to match the
rest of Django.

However, I think there is a viable alternative available right now.
And that is using CBVs and *perhaps* the existing css/js from the
admin to create 3rd party comparable tools that could include
non-editable views, NoSQL views and more all following a relatively
common pattern. It's not that hard, and it is certainly easier than
trying to either extend django.contrib.admin to a crazy extent or
rolling a new hyper-abstracted newadmin.

My first effort is django-mongonaut. It's still pretty new, but we are
using a more feature complete version in production now
(django-mongonaut is basically an extraction like Django was extracted
from Ellington). It has non-editable views for non-staff users and
fully editable views for people with rights.

In any case, I'm not advocating of django-mongonaut, I'm advocating
it's approach. Which is new code in 3rd party apps to solve new
problems but using the old patterns established by
django.contrib.admin. I think this is is the better, easier way to go
because it keeps Django's core scope smaller. Which makes advancement
of the framework easier for the hard-working people who contribute to
it.

-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.blogspot.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: 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  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: Getting a traceback out of connection.queries

[Daniel Moisset]

On Tue, Jan 31, 2012 at 8:34 PM, josharian  wrote:
> Hi all,
>
> We're using connection.queries to log all sql executed during
> development. I find myself wishing that in addition to 'sql' and
> 'time', there was a 'traceback' entry, so that troublesome/mysterious
> queries could quickly be tracked back to their origins.
>
> Adding it is a pretty small patch -- an `import traceback` and a
> couple of `'traceback': traceback.extract_stack(),`s. My question is:
> Is there a better way to get at this data currently? Is there any
> interest in such a patch?
>
> Thanks,
> Josh

Using django-debug-toolbar provides that functionality, without having
to modify the django core

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 
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: Revisiting multiline tags

[Daniel Moisset]

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

Re: Revisiting multiline tags

[Daniel Moisset]

On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor  wrote:
>
> 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.
>

It's useful because it helps some templaets in some cases be more readable

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

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 received this message b

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

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

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&D 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]

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&D 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: 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: django admin missing meta tag for charcter encoding in the head

[Daniel Moisset]

On Tue, Apr 3, 2012 at 12:37 PM, Ric  wrote:
> hi,
>
> the default django template need a meta tag for character encoding in
> the head
>
> 
>

why? the Content-Type should be properly served in the HTTP headers...
(if it isn't, then you have a genuine bug)

Regards,
   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 
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]

Alex I have looked over your proposal and I agree on both your concerns with 
LFK, and Jacob’s approach; however I still find the profile approach is the 
most flexible solution. 

Correct me if I’m wrong but both LFK or a swappable user model approach like 
your fail to address issue of extensibility. If today my project is authorizing 
with username and password and tomorrow I wish to add OpenAuth then my User 
model is replaced, whereas with Jacobs approach I add another profile model, 
yes? What about auth apps, you could only use one, with profiles many could co 
exist; one for Facebook, Twitter, etc. 

Your point 4 claiming it’s undiscoverable is not entirely true, AUTH_PROFILE 
setting can be examined just as apps examine INSTALLED_APPS settings at run 
time. Your point 2 that being able to change the functionality so quickly is 
actually superior in my mind, it’s a lot more work to do a schema migration 
then the creation a of  new profile table.  Points 5 and 3 are good points and 
remind that there is no perfect solution to new auth.

To sum up I am curious to know how your approach handles additional user data 
and authorization schemes. 

From: Alex Ogier 
Sent: Tuesday, April 03, 2012 10:28 AM
To: django-developers@googlegroups.com 
Subject: Re: auth.user refactor: the profile aproach

Hi developers, 

I have written up a little bit about the alternate proposal that I made a while 
ago, Solution 2a from 
https://code.djangoproject.com/wiki/ContribAuthImprovements

In addition to other arguments, there is a point-by-point breakdown of what I 
feel are the weaknesses in Jacob's proposal.

You can find it at  https://gist.github.com/2289395 

Best,
Alex Ogier


On Mon, Apr 2, 2012 at 8:35 PM, 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 
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.

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

Re: Proposal: 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: 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 to

Re: Proposal: upgrading the choices machinery for Django

[Daniel Greenfeld]

On Wednesday, April 4, 2012 9:41:23 AM UTC-7, Adrian Holovaty wrote:

> 2012/4/3 Łukasz Langa :
> > Explicit choice values::
> >
> >  GENDER_MALE = 0
> >  GENDER_FEMALE = 1
> >  GENDER_NOT_SPECIFIED = 2
> >
> >  GENDER_CHOICES = (
> >  (GENDER_MALE, _('male')),
> >  (GENDER_FEMALE, _('female')),
> >  (GENDER_NOT_SPECIFIED, _('not specified')),
> >  )
> >
> >  class User(models.Model):
> >  gender = models.IntegerField(choices=GENDER_CHOICES,
> >  default=GENDER_NOT_SPECIFIED)
> >
> >  def greet(self):
> >  if self.gender == GENDER_MALE:
> >  return 'Hi, boy.'
> >  elif self.gender == GENDER_NOT_SPECIFIED:
> >  return 'Hello, girl.'
> >  else: return 'Hey there, user!'
> >
> > This is a saner way but starts getting overly verbose and redundant. You 
> can
> > improve encapsulation by moving the choices into the ``User`` class but 
> that on
> > the other hand beats reusability.
>
> I don't see the immediate need for Yet Another Sub-framework, as
> described in this proposal. This is what I normally do, and it works
> fine:
>
> class User(models.Model):
> MALE = 0
> FEMALE = 1
> GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
> gender = models.IntegerField(choices=GENDERS)
>
> def greet(self):
> return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
>
> If people aren't understanding that, we should improve our documentation.
>
> Also, the fact that we *don't* have a sub-framework for this lets
> people do whatever they want -- including using the dj.choices module.
> So I am -1 on including this in Django proper.
>
> Adrian
>


+1 to what Adrian says. In fact...

On two occasions now I've had to do serious debugging on implementations 
done by other people who used a technique not dissimilar to what Łukasz 
proposes. In both cases, while the inheritance and better control 
structures were nice, the issue was that if you give people enough rope to 
hang themselves, they will.

The current system works very well, especially when you follow Adrian's 
pattern. Lukasz' system works well too. Therefore...

I submit that we keep Django core for choices as is and let people who want 
to use another system implement 3rd party packages. 
 

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

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]

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 poi

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 coming up over and over again, making 
otherwise pluggable apps incompatible 

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 Ja

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

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: Implementation of Object Permissions

[Daniel Sokolowski]

 listen to the 
class_prepared signal. This function adds the object_permissions field to each 
model, that has 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: 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  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 g

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

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.