Re: #16779 - a tutorial for first time Django contributors

[Daniele Procida]

On Sat, Nov 10, 2012, Tim Graham  wrote:

>Any specific feedback on this paragraph, or the tutorial as whole, would be 
>appreciated:

My four thoughts:

Firstly: I like to see things like:

./runtests.py --settings=test_sqlite

include a comment when appropriate; in this case to say why we are using 
--settings=test_sqlite

Secondly: "For advanced users who wish to use virtualenv" - is this really 
implying that only advanced users would use virtualenv? 

I think that the most helpful thing to say to people who are not using 
virtualenv already is that they need spend 15 minutes learning to use it before 
they do anything else, because it's one of the most valuable and easy to learn 
tools they will ever encounter.

Thirdly: if everyone is using virtualenv, would that eliminate the difficulties 
trying to explain PYTHONPATH?

Fourthly: although this and the Working with Git and GitHub tutorial explain 
the technical part of the process well, they both somewhat assume that you're 
able to come up with complete if not perfect patch.

In reality I think a lot of back-and-forth refinement goes on before that point 
is reached - what would be handy is advice on how to proceed when your patch is 
incomplete and you need some feedback before going further.

But this looks great, I wish I had read it myself before trying to submit 
anything.

Daniele

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

Re: Class-based view improvement idea

[Kevin Veroneau]

Scratch this, I just noticed that the dev docs explain a lot more than the 
1.3/1.4 docs do.  Perhaps having this documentation in 1.3/1.4 as well, or 
at least mentioning there that the dev docs contain much more information.

On Sunday, 11 November 2012 11:31:41 UTC-6, Kevin Veroneau wrote:
>
> Hello Everyone,
>
>   I have been using class-based views for sometime now, and I am running 
> into an issue while subclassing CreateView, and think that this type of 
> thing could be placed into Django somehow to make it easier to implement.
>
>   Most multi-user websites connect models to a user by some means, so the 
> posts they make or articles they add list them as the owner/poster of it.  
> Assigning the object to the user when using class-based views at the moment 
> is annoying to say the least:
>
> def form_valid(self, form):
> self.object = form.save(commit=False)
> self.object.user = self.request.user
> self.object.save()
> return super(ModelFormMixin, self).form_valid(form)
>
>   This is what I currently do, and it looks messy and unorganized.  I 
> would like a way to easily assign additional data to the self.object 
> without going through all this.  You may notice that I am calling super() 
> on ModelFormMixin, when this is a CreateView, well the super() of 
> CreateView will attempt to re-create the self.object from a form.save(), 
> and since I already created the object here, with no easy way to just pass 
> self.object...  Anyways, you get the idea.
>
>   Perhaps a new overridable method that allows us to do something with an 
> uncommitted object before it is saved.  Here is a new form_valid I propose:
>
> class ModelFormMixin(...):
> def not_sure_of_naming(self):
> pass
> def form_valid(self, form):
> self.object = form.save(commit=False)
> self.not_sure_of_naming()
> self.object.save()
> return super(ModelFormMixin, self).form_valid(form)
>
>   This will allow us developers using class-based views to easily perform 
> tasks on a self.object before it is finally saved back into the database.  
> The above implementation is just an example of what I would love to see in 
> a future version of class-based views.
>
> Best Regards,
>   Kevin Veroneau
>   Python Diary
>   http://www.pythondiary.com/
>
>

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

Class-based view improvement idea

[Kevin Veroneau]

Hello Everyone,

  I have been using class-based views for sometime now, and I am running 
into an issue while subclassing CreateView, and think that this type of 
thing could be placed into Django somehow to make it easier to implement.

  Most multi-user websites connect models to a user by some means, so the 
posts they make or articles they add list them as the owner/poster of it.  
Assigning the object to the user when using class-based views at the moment 
is annoying to say the least:

def form_valid(self, form):
self.object = form.save(commit=False)
self.object.user = self.request.user
self.object.save()
return super(ModelFormMixin, self).form_valid(form)

  This is what I currently do, and it looks messy and unorganized.  I would 
like a way to easily assign additional data to the self.object without 
going through all this.  You may notice that I am calling super() on 
ModelFormMixin, when this is a CreateView, well the super() of CreateView 
will attempt to re-create the self.object from a form.save(), and since I 
already created the object here, with no easy way to just pass 
self.object...  Anyways, you get the idea.

  Perhaps a new overridable method that allows us to do something with an 
uncommitted object before it is saved.  Here is a new form_valid I propose:

class ModelFormMixin(...):
def not_sure_of_naming(self):
pass
def form_valid(self, form):
self.object = form.save(commit=False)
self.not_sure_of_naming()
self.object.save()
return super(ModelFormMixin, self).form_valid(form)

  This will allow us developers using class-based views to easily perform 
tasks on a self.object before it is finally saved back into the database.  
The above implementation is just an example of what I would love to see in 
a future version of class-based views.

Best Regards,
  Kevin Veroneau
  Python Diary
  http://www.pythondiary.com/

-- 
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/-/qRIihOsXQDoJ.
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: post-collectstatic signal

[Justin Holmes]

My sense is that there are a growing number of use cases, but the one that
I currently have in mind is for django-coldbrew.  I want to be able to
compile all the coffeescript in a project during the collectstatic
process.  Currently, we have a management command, "collect_coldbrew" - but
I'd like to allow users to have this occur automatically during
collectstatic.

I'm not sure if the best timing for the signal is at the end of the
complete collectstatic process or at the end of each iteration (ie, one
signal for each static directory that django finds).


On Sun, Nov 11, 2012 at 4:55 AM, Alex Gaynor  wrote:

> What's the use case?
>
> Alex
>
>
> On Sat, Nov 10, 2012 at 8:48 PM, Justin Holmes wrote:
>
>> Currently, our only built-in management signal is post-syncdb.
>>
>> I propose (and, notwithstanding objection, will build)
>> post-collectstatic.
>>
>> Is this reasonable?  Is there another, less invasive way to hook logic
>> into collectstatic?
>>
>>
>> --
>> Justin Holmes
>> Chief Chocobo Breeder, slashRoot
>>
>> slashRoot: Coffee House and Tech Dojo
>> New Paltz, NY 12561
>> 845.633.8330
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To 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.
>>
>
>
>
> --
> "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.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To 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: #16779 - a tutorial for first time Django contributors

[william ratcliff]

And I should say, thanks for the effort on this!


On Sun, Nov 11, 2012 at 10:18 AM, william ratcliff <
william.ratcl...@gmail.com> wrote:

> I develop on windows, linux, and macos--for windows, I have to say that I
> tend to use tortoise-git (somehow, I still prefer it to github for
> windows), whereas for linux, the command line is greatFrom my
> experience leaping between platforms, it's rather painful to try to
> shoehorn the way of doing things on one platform into another...It's more
> work, but perhaps a linux/windows section would work best for those areas
> that are more platform specific (for example, environment variables in
> windows, vs linux)?
>
> Anywho, just my 2 cents...
>
>
> On Sun, Nov 11, 2012 at 4:17 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Le 11 nov. 2012 à 06:53, Shai Berger  a écrit :
>>
>> > On Sunday 11 November 2012, Tim Graham wrote:
>> >>
>> >> I think the part that has the most potential to confuse new
>> contributors is
>> >> the introduction of PYTHONPATH.  Claude suggested we could simply
>> instruct
>> >> users to run the tests like so:
>> >>
>> >> PYTHONPATH=/path/to/django ./run_tests.py --settings=test_sqlite
>> >>
>> >> I'm not particularly in love with that, but it would eliminate the
>> need to
>> >> try to explain things
>>
>> I've always been running the tests with:
>>
>> $ cd tests
>> $ PYTHONPATH=.. pythonX.Y runtests.py --settings=test_
>>
>> It's straightforward and easy to understand: "Python will look for django
>> in the parent directory".
>>
>> If you're just running Django's test suite on a reasonably configured
>> system, you're starting with an empty PYTHONPATH; you don't really need
>> PYTHONPATH=..:$PYTHONPATH.
>>
>> The alternatives are:
>> - either prone to mistakes and side effects (setting a systemwide
>> PYTHONPATH — what if I move my checkout?);
>> - or even more complicated to explain (mkvirtualenv djang && pip install
>> -e .)
>>
>>
>> > It would leave a lot to explain to Windows users (which I note you are
>> still
>> > trying to cater for).
>>
>>
>> If you're using the default options of the git installer on Windows,
>> you're getting a fairly decent environment (MINGW32). It creates a "Git
>> Bash" icon on the desktop, which starts a Bash shell where `git` works.
>> After adding `export PATH=/c/Python27:$PATH` to `~/.bashrc`, `python` also
>> works in that shell.
>>
>> If we tell Windows users to use "Git Bash", we can skip most of the
>> Windows-specific instructions. It's likely to make the tutorial a better
>> experience for them.
>>
>> Otherwise, `set PYTHONPATH=..` works in `cmd.exe`, but I can't recommend
>> `cmd.exe` with a straight face :/
>>
>> --
>> Aymeric.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
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: #16779 - a tutorial for first time Django contributors

[william ratcliff]

I develop on windows, linux, and macos--for windows, I have to say that I
tend to use tortoise-git (somehow, I still prefer it to github for
windows), whereas for linux, the command line is greatFrom my
experience leaping between platforms, it's rather painful to try to
shoehorn the way of doing things on one platform into another...It's more
work, but perhaps a linux/windows section would work best for those areas
that are more platform specific (for example, environment variables in
windows, vs linux)?

Anywho, just my 2 cents...


On Sun, Nov 11, 2012 at 4:17 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Le 11 nov. 2012 à 06:53, Shai Berger  a écrit :
>
> > On Sunday 11 November 2012, Tim Graham wrote:
> >>
> >> I think the part that has the most potential to confuse new
> contributors is
> >> the introduction of PYTHONPATH.  Claude suggested we could simply
> instruct
> >> users to run the tests like so:
> >>
> >> PYTHONPATH=/path/to/django ./run_tests.py --settings=test_sqlite
> >>
> >> I'm not particularly in love with that, but it would eliminate the need
> to
> >> try to explain things
>
> I've always been running the tests with:
>
> $ cd tests
> $ PYTHONPATH=.. pythonX.Y runtests.py --settings=test_
>
> It's straightforward and easy to understand: "Python will look for django
> in the parent directory".
>
> If you're just running Django's test suite on a reasonably configured
> system, you're starting with an empty PYTHONPATH; you don't really need
> PYTHONPATH=..:$PYTHONPATH.
>
> The alternatives are:
> - either prone to mistakes and side effects (setting a systemwide
> PYTHONPATH — what if I move my checkout?);
> - or even more complicated to explain (mkvirtualenv djang && pip install
> -e .)
>
>
> > It would leave a lot to explain to Windows users (which I note you are
> still
> > trying to cater for).
>
>
> If you're using the default options of the git installer on Windows,
> you're getting a fairly decent environment (MINGW32). It creates a "Git
> Bash" icon on the desktop, which starts a Bash shell where `git` works.
> After adding `export PATH=/c/Python27:$PATH` to `~/.bashrc`, `python` also
> works in that shell.
>
> If we tell Windows users to use "Git Bash", we can skip most of the
> Windows-specific instructions. It's likely to make the tutorial a better
> experience for them.
>
> Otherwise, `set PYTHONPATH=..` works in `cmd.exe`, but I can't recommend
> `cmd.exe` with a straight face :/
>
> --
> Aymeric.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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: #16779 - a tutorial for first time Django contributors

[Aymeric Augustin]

Le 11 nov. 2012 à 06:53, Shai Berger  a écrit :

> On Sunday 11 November 2012, Tim Graham wrote:
>> 
>> I think the part that has the most potential to confuse new contributors is
>> the introduction of PYTHONPATH.  Claude suggested we could simply instruct
>> users to run the tests like so:
>> 
>> PYTHONPATH=/path/to/django ./run_tests.py --settings=test_sqlite
>> 
>> I'm not particularly in love with that, but it would eliminate the need to
>> try to explain things

I've always been running the tests with:

$ cd tests
$ PYTHONPATH=.. pythonX.Y runtests.py --settings=test_

It's straightforward and easy to understand: "Python will look for django in 
the parent directory".

If you're just running Django's test suite on a reasonably configured system, 
you're starting with an empty PYTHONPATH; you don't really need 
PYTHONPATH=..:$PYTHONPATH.

The alternatives are:
- either prone to mistakes and side effects (setting a systemwide PYTHONPATH — 
what if I move my checkout?);
- or even more complicated to explain (mkvirtualenv djang && pip install -e .)


> It would leave a lot to explain to Windows users (which I note you are still 
> trying to cater for).


If you're using the default options of the git installer on Windows, you're 
getting a fairly decent environment (MINGW32). It creates a "Git Bash" icon on 
the desktop, which starts a Bash shell where `git` works. After adding `export 
PATH=/c/Python27:$PATH` to `~/.bashrc`, `python` also works in that shell.

If we tell Windows users to use "Git Bash", we can skip most of the 
Windows-specific instructions. It's likely to make the tutorial a better 
experience for them.

Otherwise, `set PYTHONPATH=..` works in `cmd.exe`, but I can't recommend 
`cmd.exe` with a straight face :/

-- 
Aymeric.



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