Re: Contributing to Django

[rishucoding]

Hi Abdulrahman

I am glad you helped me. I am learning python on Coursera, (Fundamentals of 
Computing Specialization). I think I will be learning a lot in this course 
and become an intermediate programmer.

On Monday, September 12, 2016 at 2:17:28 AM UTC+5:30, Abdulrahman Alotaibi 
wrote:
>
> Hi Rishu,
>
> Welcome and I am glad that you choose Django as your first project. You 
> mentioned that you did a course in C and that's great. You need to know 
> Python because Django is written in it http://www.diveintopython3.net/ . 
> Also, you need to learn Git https://git-scm.com/ . Like other open source 
> project, Django has a process for accepting code and this link has 
> information about it https://docs.djangoproject.com/en/1.10/internals 
> 
> /contributing/ 
>  . 
>
> Abdulrahman
>
> On Sun, Sep 11, 2016 at 4:30 PM > wrote:
>
>> Hi everyone!
>>
>> I found Django interesting and so, I want to contribute to it. I am 
>> learning OOP , web development. I have done a course in C language. My 
>> mathematics is good. Please suggest in detail, how can I contribute and 
>> where and how to start? I haven't contributed anything till now but have a 
>> urge to do so. Please give directions in the sense  what to learn. Your 
>> help is highly appreciated. 
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/9b38a592-dfa6-4e50-8207-dcf44e711bc3%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Sincerely,
> Abdulrahman Alotaibi
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c14e160d-9dcc-4611-b3fd-cef3196648c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[Chris Foresman]

Is this one worker each? I also don't really understand the implication of 
the results. There's no context to explain the numbers nor if one result is 
better than another.

On Sunday, September 11, 2016 at 7:46:52 AM UTC-5, Robert Roskam wrote:
>
> Hello All,
>
> The following is an initial report of Django Channels performance. While 
> this is being shared in other media channels at this time, I fully expect 
> to get some questions or clarifications from this group in particular, and 
> I'll be happy to add to that README anything to help describe the results.
>
>
> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>
>
> Robert Roskam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9578e218-8c95-4357-a67c-7763a3ff9b54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Challenge teaching Django to beginners: urls.py

[Emil Stenström]

Hi Djangonauts,

I'm just back from my second year of teaching Django to absolute beginners. 
The course is a combination of HTML, CSS, Python, and Django, and after 
five days of coding they have a real live website that they can show to 
friends. It's always such a great experience to see the look in their eyes 
when they finally understand how they can tame Django to do what they want.

There's one big thing that keeps tripping them up is urls.py. When 
specifying URL:s I get lots of questions about the regexes that they have 
to specify. First: there's a strange "r" in front of each line: r"regex". 
That means I will have to explain string escaping to them. Then there's the 
"^" and "$" signs, both which requires explaining regular expressions at 
length. Then there's [0-9]+ and finally there's the parenthesis around the 
regex. All in all, looking at URLs from a beginners perspective, they are a 
bunch of hieroglyphs, and very hard for beginners to grasp right away. 

I'm not suggesting that urls.py are changed for most users, I'm suggesting 
that *simple_url* method (name inspired by simple_tag) is added to 
django.conf.urls 
that new users can use to get started quickly. This means that most 
beginners can postpone learning regexes a couple of months. The exact 
syntax that simple_url takes isn't important to me, as long it's a lot more 
beginner friendly than what we have today:

https://docs.djangoproject.com/en/1.10/topics/http/urls/#example

Just to get the ideas flowing, here's a suggestion, inspired by rails 
(again, exact syntax isn't important to me, simplicity to beginners is, so 
feel free to suggest something else if you agree that this is an important 
issue):

from django.conf.urls import simple_url
from . import views
urlpatterns = [ 
simple_url('articles/2003/', views.special_case_2003), 
simple_url('articles/:year)/', views.year_archive), 
simple_url('articles/:year/:month/', views.month_archive), 
simple_url('articles/:year/:month/:day/', views.article_detail), 
]

All parameters would be passed to the view as keyword parameters with the name 
given and as a string, and validation would happen there instead. 

I'm thinking there should be no settings with simple_url, and that any more 
advanced use-case should switch to using url instead.

Two questions:

A) What do you think about the prospect of simplifying urls.py for beginners?
B) What do you think about the specific suggestion to mimic Rails urls with a 
simple_url tag?

Thanks for reading!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d002c25-9d98-49b1-b84c-55bc39c6a0f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration Questioner and String-Type Fields

[Markus Holtermann]

Thank you for your input, Jarek.
  
Assuming I have an existing model, adding
  
   models.CharField(blank=True, max_length=150)
  
to it, doesn't invoke the questioner on current master. Changing this field 
to
  
   models.CharField(max_length=150)
  
doesn't call the questioner either.
  
Looking at the SQL Django generates, the first change results in
  
   ALTER TABLE "example_mymodel" ADD COLUMN "name2" varchar(150) DEFAULT '' 
NOT NULL;
   ALTER TABLE "example_mymodel" ALTER COLUMN "name2" DROP DEFAULT;
  
and the second in a noop.
  
I'm trying to understand what change you're proposing in order to figure 
out if going forward with your proposal is something we should do.
  
Cheers,
  
Markus

On Monday, September 12, 2016 at 12:08:39 AM UTC+12, Jarek Glowacki wrote:
>
> Mm, convenience over strict correctness. Perhaps all that's needed is a 
> slight rephrasing of the prompt and we can have both?
>
> Adding field with no `blank=True` and no `null=True`:
>
> You are trying to add a non-nullable field '%s' to %s without a default; 
> we can't do that (the database needs something to populate existing rows). 
> [provide default | cancel]
>
> Removing `null=True` from field:
>
> You are trying to change the nullable field '%s' on %s to non-nullable 
> without a default; we can't do that (the database needs something to 
> populate existing rows). [provide default | fix later | cancel]
>
> Removing `blank` from field:
>
> ?? (I only skimmed the code; not sure if this even opens up questioner) 
>
>
> This kind of implies to the user that they're doing something wrong. Maybe 
> if, for string fields, it read something more along the lines of:
>
> You are adding/altering a field without setting `blank=True`. This will 
> populate existing rows with emptystring despite it being an invalid form 
> input. Are you sure? [yes | let me provide a one-time default for existing 
> rows | cancel]
>
>
> So basically changing "you can't do this!" (exception-esque) to "are you 
> sure you want this?" (warning-esque).
>
> Anyway I think I'll leave it here. I've exhausted my discussion points 
> now, and you already resolved my particular use case back in the ticket, so 
> I no longer feel so strongly about this to continue trying to push for a 
> change (though am willing to submit a PR if any of the suggested changes 
> are approved).
>
> Cheers,
>
>
> On Saturday, September 10, 2016 at 10:08:27 AM UTC+10, Tim Graham wrote:
>>
>> Sure, but I don't think that use case should take priority. It's not much 
>> work to type an empty string into the questioner if that's what you want. 
>> If we remove the prompt, it's significantly more work (editing a migration 
>> file or using RunPython) for a developer to set a non-empty value.
>>
>> On Friday, September 9, 2016 at 7:19:37 PM UTC-4, Jarek Glowacki wrote:
>>>
>>> Instances created afterwards, via `MyModel.objects.create()`, with this 
>>> field unset won't pass form validation either.
>>> The use case is where this field is not expected to appear on a Django 
>>> form.
>>>
>>> On Friday, September 9, 2016 at 11:58:38 PM UTC+10, Tim Graham wrote:

 If blank=False, then a new column with a non-blank value means that all 
 existing objects won't pass form validation. Therefore, I don't see why a 
 prompt for a value isn't helpful.

 On Friday, September 9, 2016 at 6:42:02 AM UTC-4, Jarek Glowacki wrote:
>
> I made a rant/ticket regarding the hidden usage of `blank` here: 
> #27197 .
>
> In short, I don't think that `blank` should dictate whether or not the 
> migration questioner runs.
> Building on this, I don't think it should run for for string-type 
> fields at all. If they have `default` set, use that for existing rows. 
> Else 
> if they have `null=True`, set existing rows to `NULL`. Else, set existing 
> rows to empty string.
>
> See linked rant/ticket for some (hopefully) compelling arguments..
>
> Thoughts?
>


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/05deaeaf-49da-4b07-9641-8a996863960b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[Robert Roskam]

Hey Chris,

The goal of these tests is to see how channels performs with normal HTTP 
traffic under heavy load with a control. In order to compare accurately, I 
tried to eliminate variances as much as possible. 

So yes, there was one worker for both Redis and IPC setups. I provided the 
supervisor configs, as I figured those would be helpful in describing 
exactly what commands were run on each system.

Does that help bring some context? Or would you like for me to elaborate 
further on some point?

Thanks,
Robert


On Monday, September 12, 2016 at 2:38:59 PM UTC-4, Chris Foresman wrote:
>
> Is this one worker each? I also don't really understand the implication of 
> the results. There's no context to explain the numbers nor if one result is 
> better than another.
>
> On Sunday, September 11, 2016 at 7:46:52 AM UTC-5, Robert Roskam wrote:
>>
>> Hello All,
>>
>> The following is an initial report of Django Channels performance. While 
>> this is being shared in other media channels at this time, I fully expect 
>> to get some questions or clarifications from this group in particular, and 
>> I'll be happy to add to that README anything to help describe the results.
>>
>>
>> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>>
>>
>> Robert Roskam
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7fdb4db1-7458-409f-94f5-d1dad3973616%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Box - A vagrant virtual machine for testing Django

[Josh Smeaton]

Hi all, a quick update.

https://github.com/django/django-box now has a live compiled box available 
from https://atlas.hashicorp.com/djangoproject/boxes/django-box-1.11

What this means is that a minimal Vagrantfile can now be:

Vagrant.configure("2") do |config|
  config.ssh.forward_agent = true
  config.vm.synced_folder "../django", "/django", nfs: true
  config.vm.network "private_network", ip: "1.2.3.4"
end

If we choose to compile the box with a Vagrantfile approximating the above, 
then getting a vagrant image would be as simple as:

mkdir djangobox
cd djangobox
vagrant init djangoproject/django-box-1.11
vagrant up

No need for cloning the djangobox repository at all, but does still require 
the image to be installed in a folder beside the django directory.

There's a further step we could go to, which would be bundling only the 
Vagrantfile within the django repo. It'd look something like this (provided 
we bundle the previous Vagrantfile within the image):

Vagrant.configure("2") do |config|
  config.vm.synced_folder ".", "/django", nfs: true
end

We might want to play with that a bit more to be solid on 
linux/windows/osx, but it removes the concept of compiling a system and 
places it within the django-box repo, but still allows a user to checkout 
django, and bring up a VM immediately to do testing. I'm liking this avenue 
a lot more than I had previously, because it only involves bundling a 
Vagrantfile and not the entire ansible roles needed to compile it.

I should say that I'm OK with waiting and proving that this project has 
some following before moving down that road. No point bundling a 
Vagrantfile if no one is going to use it. But I can see the value and 
simplicity now. In the mean time, I'll try and get around to updating the 
Wiki to point people to the django-box image, and the various docs around 
the place.

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c636a035-fb24-4266-9692-d04301ac7906%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Constantine Covtushenko]

Hi Emil,

It is a very interesting idea.

+1 from me

On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström  wrote:

> Hi Djangonauts,
>
> I'm just back from my second year of teaching Django to absolute
> beginners. The course is a combination of HTML, CSS, Python, and Django,
> and after five days of coding they have a real live website that they can
> show to friends. It's always such a great experience to see the look in
> their eyes when they finally understand how they can tame Django to do what
> they want.
>
> There's one big thing that keeps tripping them up is urls.py. When
> specifying URL:s I get lots of questions about the regexes that they have
> to specify. First: there's a strange "r" in front of each line: r"regex".
> That means I will have to explain string escaping to them. Then there's the
> "^" and "$" signs, both which requires explaining regular expressions at
> length. Then there's [0-9]+ and finally there's the parenthesis around the
> regex. All in all, looking at URLs from a beginners perspective, they are a
> bunch of hieroglyphs, and very hard for beginners to grasp right away.
>
> I'm not suggesting that urls.py are changed for most users, I'm suggesting
> that *simple_url* method (name inspired by simple_tag) is added to 
> django.conf.urls
> that new users can use to get started quickly. This means that most
> beginners can postpone learning regexes a couple of months. The exact
> syntax that simple_url takes isn't important to me, as long it's a lot more
> beginner friendly than what we have today:
>
> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>
> Just to get the ideas flowing, here's a suggestion, inspired by rails
> (again, exact syntax isn't important to me, simplicity to beginners is, so
> feel free to suggest something else if you agree that this is an important
> issue):
>
> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [
> simple_url('articles/2003/', views.special_case_2003),
> simple_url('articles/:year)/', views.year_archive),
> simple_url('articles/:year/:month/', views.month_archive),
> simple_url('articles/:year/:month/:day/', views.article_detail),
> ]
>
> All parameters would be passed to the view as keyword parameters with the 
> name given and as a string, and validation would happen there instead.
>
> I'm thinking there should be no settings with simple_url, and that any more 
> advanced use-case should switch to using url instead.
>
> Two questions:
>
> A) What do you think about the prospect of simplifying urls.py for beginners?
> B) What do you think about the specific suggestion to mimic Rails urls with a 
> simple_url tag?
>
> Thanks for reading!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/3d002c25-9d98-49b1-b84c-
> 55bc39c6a0f9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Challenge teaching Django to beginners: urls.py

[Ares Ou]

Hi,

Actually flask uses a style very similar to what you want.

To my knowing, you must use this pattern for Django because it has the
concept of *including *
URLs.

Routing in flask:

@app.route('post/', methods=['GET'])
def post_view(post_id=None):
# do something to render the post
return render_template('post.html', post=post)

But the problem is, you have to specify the whole URL for every view you
define.

Django avoids this by separating URL patterns into different levels, that's
why it uses regex to
identify the exact path. I guess it is hard for Django to organize URLs in
different apps by using
such simple method.

Looking forward to more ideas!

Best regards,
Ares Ou

*Software Engineer / Full-Stack Python Developer  |  **Phone:* (510) 328 -
5968

*Blog:* http://aresou.net  |  *Github:* https://github.com/aresowj  |  *Stack
Overflow:* http://stackoverflow.com/users/5183727/ares-ou

Ares Ou

On Mon, Sep 12, 2016 at 10:20 PM, Constantine Covtushenko <
constantine.covtushe...@gmail.com> wrote:

> Hi Emil,
>
> It is a very interesting idea.
>
> +1 from me
>
> On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström  wrote:
>
>> Hi Djangonauts,
>>
>> I'm just back from my second year of teaching Django to absolute
>> beginners. The course is a combination of HTML, CSS, Python, and Django,
>> and after five days of coding they have a real live website that they can
>> show to friends. It's always such a great experience to see the look in
>> their eyes when they finally understand how they can tame Django to do what
>> they want.
>>
>> There's one big thing that keeps tripping them up is urls.py. When
>> specifying URL:s I get lots of questions about the regexes that they have
>> to specify. First: there's a strange "r" in front of each line: r"regex".
>> That means I will have to explain string escaping to them. Then there's the
>> "^" and "$" signs, both which requires explaining regular expressions at
>> length. Then there's [0-9]+ and finally there's the parenthesis around the
>> regex. All in all, looking at URLs from a beginners perspective, they are a
>> bunch of hieroglyphs, and very hard for beginners to grasp right away.
>>
>> I'm not suggesting that urls.py are changed for most users, I'm
>> suggesting that *simple_url* method (name inspired by simple_tag) is added
>> to django.conf.urls that new users can use to get started quickly. This
>> means that most beginners can postpone learning regexes a couple of months.
>> The exact syntax that simple_url takes isn't important to me, as long it's
>> a lot more beginner friendly than what we have today:
>>
>> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>>
>> Just to get the ideas flowing, here's a suggestion, inspired by rails
>> (again, exact syntax isn't important to me, simplicity to beginners is, so
>> feel free to suggest something else if you agree that this is an important
>> issue):
>>
>> from django.conf.urls import simple_url
>> from . import views
>> urlpatterns = [
>> simple_url('articles/2003/', views.special_case_2003),
>> simple_url('articles/:year)/', views.year_archive),
>> simple_url('articles/:year/:month/', views.month_archive),
>> simple_url('articles/:year/:month/:day/', views.article_detail),
>> ]
>>
>> All parameters would be passed to the view as keyword parameters with the 
>> name given and as a string, and validation would happen there instead.
>>
>> I'm thinking there should be no settings with simple_url, and that any more 
>> advanced use-case should switch to using url instead.
>>
>> Two questions:
>>
>> A) What do you think about the prospect of simplifying urls.py for beginners?
>> B) What do you think about the specific suggestion to mimic Rails urls with 
>> a simple_url tag?
>>
>> Thanks for reading!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/3d002c25-9d98-49b1-b84c-55bc39c6a0f9%
>> 40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at htt