Re: #django-dev IRC channel

[Anthony King]

It might be worth while setting up something that isn't just IRC.
Yes, it's simple, and just works. However not everyone enjoys it.

An option might be to use Matrix, which allows for connecting to multiple
platforms, including the existing IRC channels.

As an added bonus, Matrix supports "communities", essentially a group of
rooms/channels. This could help with centralisation of various ways of
chatting at meetup groups.
The London Django Meetup, uses its own Slack, for instance.

On Fri, 27 Apr 2018, 07:30 Alexander Lyabah,  wrote:

> If it requires any source code changing
>
> On Friday, April 27, 2018 at 9:24:29 AM UTC+3, Kenneth wrote:
>>
>> Thank you for the reply, Josh.
>>
>> Should I post it as an issue in the djangoproject.com repository (
>> https://github.com/django/djangoproject.com/issues) and not as a ticket
>> in the ticket tracker (https://code.djangoproject.com) because this is
>> an issue with the website?
>>
>> On Thursday, April 26, 2018 at 9:11:06 PM UTC-4, Josh Smeaton wrote:
>>>
>>> Yes - that's probably a good idea!
>>>
>>> On Thursday, 26 April 2018 05:11:33 UTC+10, Kenneth wrote:

 Hello,

 I was just curious about the #django-dev IRC Channel.
 Currently, the only mention for this channel is on the Code of Conduct
 FAQ  page.
 Should it also be mentioned on the Contributing to Django
  page?

 --
> 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/5b5a8930-cbab-4a37-aa2e-0fb88ddfdb01%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/CALs0z1b%3DPWtNBGceHXFzk4M7_rgzbFGRq62FBxSmx4qXQW3-%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Anthony King]

I entirely agree with renaming `mark_safe`. Though it's name is correct, it
doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
dangerous to trust the literal "Some Content", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton  wrote:

> The concern isn't overusing an API. It's not understanding the proper use
> case for it.
>
> "mark safe" can sound like the API is doing sanitation so it can encourage
> developers to use it incorrectly. I'm fairly sure I've done this myself.
>
> The intended meaning is "this output is **already** safe" but the name
> doesn't convey that meaning clearly enough.
>
> What the proposal is designed to do is convey the "I trust this output"
> meaning of the API. I'm just wary of enforcing users to change code when
> they already use the API correctly.
>
> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>
>> Yeah, I am also worried about the churn for no gain in my eyes. If users
>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>
>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>>
>>> I agree that the names are misleading and we should probably provide
>>> better names. I'm wary of deprecating the old names because it'll create a
>>> lot of churn (some of which would be the right thing to do). Maybe we could
>>> just alias and warn when using the old name, leaving a decision on
>>> deprecation until some time in the future.
>>>
>>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:

 In my experience, misuse of mark_safe() — i.e. marking stuff safe
 which *isn’t* actually safe (e.g. HTML from a rich text input) — is
 one of the biggest causes of XSS vulnerabilities in Django projects.

 The docs warn to be careful, but unfortunately I think Django devs have
 just got too used to mark_safe() being *the way* to insert HTML in a
 template. And it’s easy for something that was safe when it was authored
 (e.g. calling mark_safe() on a hard-coded string) to be copied /
 repurposed / adapted into a case which is no longer be safe (e.g. that
 string replaced with a user-provided value).

 Some other frameworks use scary sounding names to help reinforce that
 there are dangers around similar features, and that this isn’t something
 you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.

 Relatedly, this topic
 
  suggested
 making it more explicit that mark_safe() refers to being safe for use
 in *HTML* contexts (rather than JS, CSS, SQL, etc).

 Combining the two, it would be great if Django could rename mark_safe() to
 dangerously_trust_html(), |safe to |dangerously_trust_html,
 @csrf_exempt to @dangerously_csrf_exempt, etc.

 Developers who know what they’re doing with these could then be
 encouraged to create suitable wrappers which handle their use case safely
 internally — e.g.:

 @register.filter
 def sanitize_and_trust_html(value):
 # Safe because we sanitize before trusting
 return dangerously_trust_html(bleach.clean(value))


 --
> 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/db4ac958-89e1-4286-a616-
> 99e9854c9bbb%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/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: models.CalculatedField feature

[Anthony King]

Hey,

this is something I'd like to get involved in.
Last year I began prototyping something (albeit with an awful name) that
resembled sqlalchemy's hybrid properties.

I'll spend a bit of time in a few hours sprucing it up to better match
their naming, and link it here if anyone is interested.

On 15 November 2017 at 17:06, Tom Forbes  wrote:

> SQLAlchemy has this, through a feature called Hybrid Attributes:
> http://docs.sqlalchemy.org/en/latest/orm/extensions/hybrid.html
>
> Every Django project i've worked on has had to tackle this problem, often
> poorly. You usually end up with an instance method and a kind of duplicate
> manager method, or some specific queries spread throughout the code.
>
> The annotate feature is quite cool, but I think Django would benefit from
> something like this.
>
>
> On 15 Nov 2017 16:49, "Matthew Pava"  wrote:
>
> I handle that situation quite differently.
>
> I have a model manager that annotates different fields to the queryset
> depending on when I need them.
>
> For your example, I would have something like this:
>
>
>
> class CustomerQuerySet(models.QuerySet):
>def with_allowed_to_drink(self):
>   return self.annotate(allowed_to_drink=Case(When(age__gte=18, 
> then=True), default=False))
>
>
>
>
>
> Then I actually created a decorator that applies the manager to instances
> on a model.  It is not as generic as it could be since it depends on
> function names having the word “with” in them, but I’m sure we could make
> it more general.
>
> def queryset_on_instance(model: Model):
>
>
>
>
>
>
>
> *"""Takes the queryset of a model and creates new properties for each
> instance of the model based on the custom queryset class.  Some code is
> copied from django.models.managers; most of this was inspired by it.
> The queryset methods that are copied must have 'with' in their name.
> Tip: Use this as a decorator on model classes """ *def
> create_method(method_name):
> def the_method(self):
> return getattr(model._default_manager, method_name)().get(pk=
> self.pk)
>
> return the_method
>
> queryset_class = getattr(model._default_manager, "_queryset_class",
> None)
> predicate = inspect.isfunction
> for name, method in inspect.getmembers(queryset_class, predicate
> =predicate):
> if 'with' in name:
> # Only copy missing attributes.
> if hasattr(model, name):
> continue
> # Only copy public methods or methods with the attribute
> `queryset_only=False`.
> queryset_only = getattr(method, 'queryset_only', None)
> if queryset_only or (queryset_only is None and
> name.startswith('_')):
> continue
> # Copy the method onto the model.
> setattr(model, name, create_method(name))
> return model
>
>
>
>
>
> And then on your Customer model:
>
> @queryset_on_instance
> class Customer(models.Model):
>age = models.IntegerField()
>objects = CustomerQuerySet.as_manager()
>
>
>
>
>
> In your code or template, you would access the value like so:
>
> customer.with_allowed_to_drink.allowed_to_drink
>
>
>
> And you can filter by the value like so:
>
> Customers.objects.with_allowed_to_drink().filter(allowed_to_drink=True)
>
>
>
> I do agree that it would be nice to have something out of the box that
> could handle custom properties in the QuerySet calls, or, as you put it,
> calculated fields.
>
>
>
>
>
> *From:* django-developers@googlegroups.com [mailto:django-developers@goog
> legroups.com] *On Behalf Of *ilya.kazakev...@jetbrains.com
> *Sent:* Wednesday, November 15, 2017 7:21 AM
> *To:* Django developers (Contributions to Django itself)
> *Subject:* models.CalculatedField feature
>
>
>
> Hello.
>
>
>
> I think I just invented very useful feature.
>
> I have the following model
>
>
>
> class Customer(models.Model):
>
> age = models.IntegerField()
>
>
>
> I want to show special link in template for customer if she is allowed to
> drink.
>
>
>
> class Customer(models.Model):
>
> age = models.IntegerField()
>
>
>
> @property
>
> def allowed_to_drink(self):
>
> return self.age >= 18
>
>
>
> And in template I can do
>
>
>
> {% if customer.allowed_to_drink %}.
>
>
>
> But in another view I want to show only those customers, who are allowed
> to drink.
>
> So, in view I write
>
>
>
> drinkers = [customer for customer in models.Customer.objects.all() if
> customer.allowed_to_drink].
>
>
>
> But what if I have one million customers? It is insane to check this field
> on Python side instead of database side.
>
> I use ORM:
>
> models.Customer.objects.filter(age__gte=18).all()
>
>
>
> And DRY principle is now violated.
>
> See, I have knowledge "allowed_to_drink -> (age >= 18) " and I want to
> write in once, and then use both in ORM queries and object method.
>
>
>
> And I am not alone here:
>
> https://stackoverflow.com/questions/31658793/django-filter-
> query-on-with-property-fields-a

Re: Automatic prefetching in querysets

[Anthony King]

Automatically prefetching is something I feel should be avoided.

A common gripe I have with ORMs is they hide what's actually happening with
the database, resulting in beginners-going-on-intermediates building
libraries/systems that don't scale well.

We have several views in a dashboard, where a relation may be accessed once
or twice while iterating over a large python filtered queryset.
Prefetching this relation based on the original queryset has the potential
to add around 5 seconds to the response time (probably more, that table has
doubled in size since I last measured it).

I feel it would be better to optimise for your usecase, as apposed to try
to prevent uncalled-for behaviour.



On Aug 15, 2017 23:15, "Luke Plant"  wrote:

> I agree with Marc here that the proposed optimizations are 'magical'. I
> think when it comes to optimizations like these you simply cannot know in
> advance whether doing extra queries is going to a be an optimization or a
> pessimization. If I can come up with a single example where it would
> significantly decrease performance (either memory usage or speed) compared
> to the default (and I'm sure I can), then I would be strongly opposed to it
> ever being default behaviour.
>
> Concerning implementing it as an additional  QuerySet method like
> `auto_prefetch()` - I'm not sure what I think, I feel like it could get
> icky (i.e. increase our technical debt), due to the way it couples things
> together. I can't imagine ever wanting to use it, though, I would always
> prefer the manual option.
>
> Luke
>
>
>
> On 15/08/17 21:02, Marc Tamlyn wrote:
>
> Hi Gordon,
>
> Thanks for the suggestion.
>
> I'm not a fan of adding a layer that tries to be this clever. How would
> possible prefetches be identified? What happens when an initial loop in a
> view requires one prefetch, but a subsequent loop in a template requires
> some other prefetch? What about nested loops resulting in nested
> prefetches? Code like this is almost guaranteed to break unexpectedly in
> multiple ways. Personally, I would argue that correctly setting up and
> maintaining appropriate prefetches and selects is a necessary part of
> working with an ORM.
>
> Do you know of any other ORMs which attempt similar magical optimisations?
> How do they go about identifying the cases where it is necessary?
>
> On 15 August 2017 at 10:44, Gordon Wrigley 
> wrote:
>
>> I'd like to discuss automatic prefetching in querysets. Specifically
>> automatically doing prefetch_related where needed without the user having
>> to request it.
>>
>> For context consider these three snippets using the Question & Choice
>> models from the tutorial
>>  
>> when
>> there are 100 questions each with 5 choices for a total of 500 choices.
>>
>> Default
>> for choice in Choice.objects.all():
>> print(choice.question.question_text, ':', choice.choice_text)
>> 501 db queries, fetches 500 choice rows and 500 question rows from the DB
>>
>> Prefetch_related
>> for choice in Choice.objects.prefetch_related('question'):
>> print(choice.question.question_text, ':', choice.choice_text)
>> 2 db queries, fetches 500 choice rows and 100 question rows from the DB
>>
>> Select_related
>> for choice in Choice.objects.select_related('question'):
>> print(choice.question.question_text, ':', choice.choice_text)
>> 1 db query, fetches 500 choice rows and 500 question rows from the DB
>>
>> I've included select_related for completeness, I'm not going to propose
>> changing anything about it's use. There are places where it is the best
>> choice and in those places it will still be up to the user to request it. I
>> will note that anywhere select_related is optimal prefetch_related is still
>> better than the default and leave it at that.
>>
>> The 'Default' example above is a classic example of the N+1 query
>> problem, a problem that is widespread in Django apps.
>> This pattern of queries is what new users produce because they don't know
>> enough about the database and / or ORM to do otherwise.
>> Experieced users will also often produce this because it's not always
>> obvious what fields will and won't be used and subsequently what should be
>> prefetched.
>> Additionally that list will change over time. A small change to a
>> template to display an extra field can result in a denial of service on
>> your DB due to a missing prefetch.
>> Identifying missing prefetches is fiddly, time consuming and error prone.
>> Tools like django-perf-rec 
>> (which I was involved in creating) and nplusone
>>  exist in part to flag missing
>> prefetches introduced by changed code.
>> Finally libraries like Django Rest Framework and the Admin will also
>> produce queries like this because it's very difficult for them to know what
>> needs prefetching without being explicitly told by an experienced user.
>>
>> A

Re: To keep or not to keep: logging of undefined template variables

[Anthony King]

-1 for removing logs. Like Vlastimil, it's helped me spot a couple of stray
bugs.

What I'd actually like to see is this becoming stricter, with the end goal
of errors raising when using undefined variables.

For the verbosity, perhaps there's a middle ground? only log once per
variable access per template context, and provide a formatter that will
clean up the output?

I believe in debug mode, you have access to line numbers and character
positions, so the final output could look something like this:

``
some_app/home.html:32:24: Undefined variable: *missing_variable*
``

I'm unsure how much effort this would take, but it would definitely make
the logging a lot more user + developer friendly.

On 20 June 2017 at 08:48, Vlastimil Zíma  wrote:

> -1 to the removal. I was annoyed by the logging at first, but then I
> started to clean individual logs. Half way through, I found several usages
> of long removed variables, one unused template (as a side effect) and I
> updated several views to always provide defined context variables.
>
> All in all, I consider the warnings very useful for a cleaning, though I
> wouldn't be against an option to silence them. Which can already by
> accomplished by LOGGING, can't it?
>
> Vlastik
>
> Dne neděle 26. března 2017 11:14:23 UTC+2 Melvyn Sopacua napsal(a):
>>
>> On Thursday 16 March 2017 12:03:07 Tim Graham wrote:
>>
>> > Ticket #18773 [0] added logging of undefined template variables in
>>
>> > Django 1.9 [1], however, I've seen several reports of users finding
>>
>> > this logging more confusing than helpful.
>>
>>
>>
>> With channels hitting 2.0 and the already large stack of moving parts
>> surrounding Django you need some basic system administration skills and
>> programming experience to work with the system. And there are quite a few
>> examples to link to from the user's list that deal with those moving parts
>> rather then Django itself. It is not an application that you download,
>> install and run.
>>
>>
>>
>> An introduction "What you need to know before starting Django" would help
>> a lot in this respect and explaining the noisiness of some logging belongs
>> in there.
>>
>>
>>
>> Because it *is* useful if you defined that variable to True in your
>> settings, and it's working in all projects but this one. It could be
>> there's an extra piece of context middleware that uses the same name and
>> deletes the variable from the context. It could be there's a Mixin missing
>> in the view hierarchy. Or a typo you don't notice anymore after plowing
>> through 20+ included template bits.
>>
>>
>>
>> Noisy logging is exactly what you want when debugging. It should log
>> things that may be working as designed, especially things that are
>> ambiguous (like undefined and false).
>>
>>
>>
>> Another thing is that logging is the ugly duckling of Django. It's not
>> mentioned much if at all in the tutorial. It is not mentioned at all in
>> "How to write reusable apps" and it shows in the eco system. It's like
>> finding a diamond when an app actually has logging implemented.
>>
>>
>>
>> But it also means that novice users touching the LOGGING configuration
>> are exceptions and I don't think Django should cater to the exceptions.
>>
>>
>>
>> --
>>
>> Melvyn Sopacua
>>
> --
> 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/80fafa13-ef3b-4b8c-9376-
> cc63b1776cb8%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/CALs0z1YDm5OYt%2B_spdXz4pgoA652fPg8V9kuW_sMWTV-qHyeEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

standardised approach for packaged apps to define default settings

[Anthony King]

Yesterday, I posted a new ticket asking about the potential for adding a 
standardised approach for packages to define default settings. [0]

I was writing an app, and when looking for a way to set settings, there was 
no clear solution.


Looking at what other projects do, the goto was something like this:
#myapp/settings.py
from django.conf import settings
MYAPP_SOME_SETTING = getattr(settings, 'MYAPP_SOME_SETTING', 'default')

This would then be accessed via myapp.settings, which will not reflect 
dynamic updates (specifically, override_settings).


What I feel is needed is this:
  - have apps access their settings via django.conf.settings, always
  - Allow to define default settings as cleanly as it is for settings to be 
written for projects.
  - Allow for dynamic settings that are calculated by default, but can be 
overridden by the project. [1]
  - *Nice to have: *This should ideally be written as a DEP so that it's 
usable on Django 1.11


*These are by no means final solutions. *I'm just looking to get the ball 
rolling.

I'd like to propose a couple of solutions for this to discuss.

- First, Load default_settings.py during the setup sequence.
I'm not sure how feasible this would be. What order would the settings app 
loads? what happens if your setting depends on another setting?

- Second, This could be done in AppConfig.
This introduces a fundamental new way of doing settings, and looks magical 
when using it.

class MyAppConfig(AppConfig):
...
class DefaultSettings:
MYAPP_SOME_SETTINGS = 'default'

@property
def MYAPP_DYNAMIC_SETTING(self):
# set a default dynamically, based on environment or settings?

accessing settings.MYAPP_SOME_SETTINGS feels kind of strange though, as 
there's no direct relation between this new class and the 
django.conf.settings.

[0] https://code.djangoproject.com/ticket/27798
[1] 
https://github.com/YPlan/nexus/blob/620efbb7d13100848346c45717ca63d01ec301e5/nexus/conf.py

-- 
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/5498fb86-7fb9-4027-85ab-e3325b3c5ed5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Authenticating with Django without the password being sent to the server

[Anthony King]

Chris, then the password is the hash itself. It doesn't really have any
security benefits.

Disclaimer: I'm not a security expert

On 14 Jan 2017 18:24, "Chris Priest"  wrote:

> The way django's authentication system works is that when you register,
> you send the password to the server, then the server runs that password
> through some hashing algorithms, then the resulting hash is stored in the
> database. When the user logs in, the password again is sent to the server,
> and the hash is calculated and then compared to the hash that was
> calculated when they registered.
>
> This results in the plain text password not being stored in the database,
> but the password is still being sent back to the server. A better way would
> be for the hash to be calculated on the front end, in javascript, and then
> sent back to be stored in the database. This way, the user *knows for sure*
> that the password isn't being saved in plain text because the server
> doesn't even know the plain text password.
>
> Has anyone ever tried building an authentication system that worked this
> way? If someone built such a thing, could it get included in django contrib?
>
> --
> 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/440694cb-853e-4150-a356-
> 1f176f59b3c7%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/CALs0z1bHYebAL0DPxOiamtMJ%2B8YDXbepHN%2BUFVH0nXMbh6dZRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing aliased imports ("from") in generated migration files to prevent conflicts

[Anthony King]

There may be a 5th way, which would be to make an alias under the clash
conditions.

from django.db import models as django_models

However this could also lead to mistakes in assume the django models would
still be called models.


On 9 Jan 2017 21:59, "Alexey Kotlyarov"  wrote:

As stated in https://code.djangoproject.com/ticket/26099, it is possible
for a project with an unfortunately named application to result in a
migration file being generated which will raise an error on attempting to
migrate, without any prior warning. The problem is that the following
imports can all be generated:

from django.db import migrations, models
from django.conf import settings
from django.utils.timezone import utc

If an application module is named models, migrations, settings or utc and
there is, for example, a function in one of those modules used for a
default of a field, its module will be imported as is and shadow the Django
import.

While the above names arguably aren't good choices for a module name, they
are valid, don't conflict with anything else within Django and the behavior
isn't mentioned in the documentation.

Here are several proposed solutions to the problem:

1. Mention the module names causing the bug to manifest in the
documentation, keep the behavior. This isn't likely to help the affected
users, and the name list must be kept in sync if new imports are added to
the generated migrations.

2. Warn about the name clash, refuse to generate the migration and tell the
user that they must rename a module. This might not be possible in case the
offending name is from a third party library.

3. Generate the imports without aliasing them (e.g. import django.db.models)
to make clashes impossible. This, however, makes the migration files harder
to read to a human, as all the imported names, like Model and Migration,
use full module names: django.db.models.Model,
django.db.migrations.Migration.

4. Only generate the un-aliased imports if there is a module name clash.

I have naively gone with option 3 and provided a patch (
https://github.com/django/django/pull/7810), but Tim Graham pointed out
that the deficiencies I was pondering too.

What is the best way forward here? I have an understanding of what's needed
to implement 4 and 2 (won't be much easier than 4) and can change the patch
accordingly.

Alexey

-- 
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/daba352d-5e97-4d70-b61f-b42f9eb65ca5%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/CALs0z1YzVLuvGixpm44ohzA9v6GcLyk_gAVh57szehoKMymkzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing {% include %} to strip a trailing newline

[Anthony King]

Tim, yes I meant the keep_trailing_newline option.

Digging through the code (as I mentioned on IRC), it's possible to have the
form rendering to use different options.
Here is a proof of concept [0], which forces removal of trailing whitespace
in forms, and adds it as an option for settings.

I'm unsure of the behaviour in Jinja. The naming seems wrong for it to be
for {% include %} only, however this is just a proof of concept.

If you're happy with it, I'll contribute it to the currently open PR.

[0] https://gist.github.com/anonymous/098c076f626466dc3154e3a6da02d996

On 4 January 2017 at 20:32, Tim Graham  wrote:

> Anthony, I assume you're referring to the keep_trailing_newline  option?
> If we don't enable it for existing projects, then forms will render with
> extra newlines. I think it's better to have projects opt-out of the
> behavior if they're unable to audit their non-HTML templates due to time
> constraints. Only enabling it for new projects means that the tests for
> projects like django-money will break until the option is enabled. I
> consider the keep_trailing_newline option a temporary backwards
> compatibility measure and would like to eventually remove it.
>
> Sam, re: "Could this be set within the template rather than the include
> tag?"
> I'm not an expert in the inner workings of the Django template language,
> but based on how template tags usually work, that doesn't feel feasible. To
> be clear, I'm not proposing to add an option to the {% include %} tag. That
> seems like the wrong approach to me since if {% include %} already strips
> the trailing newline of its output, then you can control newlines by how
> you structure the {% include %} tag. This seems far more intuitive and
> readable.
>
> I also considered a technique we've used to change template tag behaviors
> previously: {% load include from future %} however, I feel that would be
> really disruptive to force all projects to go through that deprecation.
>
>
> On Wednesday, January 4, 2017 at 3:15:31 PM UTC-5, Sam Willis wrote:
>>
>> Could this be set within the template rather than the include tag? So for
>> example have a new tag such as {% strip_final_new_line %} that when
>> included at the end of a template immediately before the final new line
>> would instruct it to be striped.
>>
>> This stops the user from having to remember to use a special option on
>> the include tag for each use of a template that requires it - it also work
>> on a normal (not included) template render as well, if that is wanted.
>>
>> An alternative tag could be {% endtemplate %} that can be placed anywhere
>> in the template, forcing the end of rendering?
>>
>> On Wednesday, January 4, 2017 at 7:58:42 PM UTC, Tim Graham wrote:
>>>
>>> Shortly after template widget rendering was merged, an issue about extra
>>> newlines appearing in the rendered output was reported [0]:
>>>
>>> For example, from django-money:
>>>
>>> UIC-Franc
>>> \n\n
>>> US Dollar
>>> \n\n
>>>
>>> The newlines aren't useful and they break assertions like this:
>>>
>>> US Dollar in form.as_p
>>>
>>> --- end report---
>>>
>>> The reporter suggested removing the trailing newline in the attrs.html
>>> template but Adam Johnson reported: "POSIX states that all text files
>>> should end with a newline, and some tools break when operating on text
>>> files missing the final newline. That's why git has the warning \ No
>>> newline at end of file and Github has a warning symbol for the missing
>>> newline."
>>>
>>> I suggested that perhaps {% include %} could do .rstrip('\n') on
>>> whatever it renders.
>>>
>>> Preston pointed out that Jinja2 does something similar:
>>>
>>> http://jinja.pocoo.org/docs/dev/templates/#whitespace-control
>>>
>>>- a single trailing newline is stripped if present
>>>- other whitespace (spaces, tabs, newlines etc.) is returned
>>>unchanged
>>>
>>> I noted that the issue of {% include %} adding extra newlines was raised
>>> in #9198 [1] but Malcolm said, "For backwards compatibility reasons we
>>> cannot change the default behaviour now (there will be templates that rely
>>> on the newline being inserted)." I was skeptical this would be a burdensome
>>> change.
>>>
>>> Carl replied:  "It seems quite likely to me that there are templates in
>>> the wild relying on preservation of the final newline. People render
>>> preformatted text (e.g. text emails) using DTL. I probably have some text
>>> email templates in older projects myself that would break with that change.
>>>
>>> We could add a new option to {% include %}, though." Adam also said, "I
>>> too have used DTL for text emails that would break under that behaviour.
>>> New option to include sounds good to me."
>>>
>>>
>>> Me again: In the long run, having {% include %} remove the trailing
>>> newline seems like a more sensible default. For example, I wouldn't expect
>>> this code to have a newline inserted between it:
>>>
>>>
>>> {% include "foo.txt" %}
>>> {% include "bar.txt" %}
>>>
>>

Re: Changing {% include %} to strip a trailing newline

[Anthony King]

I think adding the option would be the better approach, and add it in as
default for new projects.
Having used templates for text emails, I do find it unintuitive to write
them because of the newline behaviour.

On 4 Jan 2017 19:58, "Tim Graham"  wrote:

> Shortly after template widget rendering was merged, an issue about extra
> newlines appearing in the rendered output was reported [0]:
>
> For example, from django-money:
>
> UIC-Franc
> \n\n
> US Dollar
> \n\n
>
> The newlines aren't useful and they break assertions like this:
>
> US Dollar in form.as_p
>
> --- end report---
>
> The reporter suggested removing the trailing newline in the attrs.html
> template but Adam Johnson reported: "POSIX states that all text files
> should end with a newline, and some tools break when operating on text
> files missing the final newline. That's why git has the warning \ No
> newline at end of file and Github has a warning symbol for the missing
> newline."
>
> I suggested that perhaps {% include %} could do .rstrip('\n') on whatever
> it renders.
>
> Preston pointed out that Jinja2 does something similar:
>
> http://jinja.pocoo.org/docs/dev/templates/#whitespace-control
>
>- a single trailing newline is stripped if present
>- other whitespace (spaces, tabs, newlines etc.) is returned unchanged
>
> I noted that the issue of {% include %} adding extra newlines was raised
> in #9198 [1] but Malcolm said, "For backwards compatibility reasons we
> cannot change the default behaviour now (there will be templates that rely
> on the newline being inserted)." I was skeptical this would be a burdensome
> change.
>
> Carl replied:  "It seems quite likely to me that there are templates in
> the wild relying on preservation of the final newline. People render
> preformatted text (e.g. text emails) using DTL. I probably have some text
> email templates in older projects myself that would break with that change.
>
> We could add a new option to {% include %}, though." Adam also said, "I
> too have used DTL for text emails that would break under that behaviour.
> New option to include sounds good to me."
>
>
> Me again: In the long run, having {% include %} remove the trailing
> newline seems like a more sensible default. For example, I wouldn't expect
> this code to have a newline inserted between it:
>
>
> {% include "foo.txt" %}
> {% include "bar.txt" %}
>
>
> An option for {% include %} seems superfluous given that if you were
> writing
>
>
> {% include "foo.txt" %}{% include "bar.txt" %}
>
>
> now you can write the first thing which is much more intuitive.
>
>
> How about a keep_trailing_newline TEMPLATES option for backwards
> compatibility for those who don't want to adapt their templates for the new
> behavior? Jinja2 has that option.
>
> Carl replied: An engine option may be better than an option to {% include
> %}, though it doesn't allow us to ensure that we strip the newline in the
> specific case of attrs.
>
> How we default the engine option I guess just depends on how seriously we
> take backwards compatibility. If we default it to strip and make people add
> the config to preserve the old behavior, that's not really backwards
> compatible. Historically (as seen in Malcolm's comment) we would choose to
> err on the side of actual backwards compatibility in a case like this, even
> if it didn't result in the ideal future behavior. But the adaptation isn't
> hard in this case, so I won't object if the choice is to break back-compat.
>
>
> If it's not a per-include choice, of course, we have to break overall
> back-compat to preserve form-attr-rendering back-compat.
> 
>
> What do you think?
>
> [0] https://github.com/django/django/pull/7769
> [1] https://code.djangoproject.com/ticket/9198
>
> --
> 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/8124d314-eb26-4465-9fc8-
> 5b04fe2ba618%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 o

Re: Feature idea

[Anthony King]

Sending a link to set a password isn't much better.
Perhaps a way to force a password change on login would be better, which
has more use elsewhere, such as being able to periodically force password
changes

On 16 Nov 2016 8:13 p.m., "Aymeric Augustin" <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I wouldn’t dismiss the idea so quickly. Adding staff users from your
> company is a fairly common use case.
>
> Currently you have to email them a password and ask them to change it.
> This doesn’t set a good example.
>
> The better solution is SSO with the corporate directory (often
> ActiveDirectory or Google Apps), but not every project has taken the time
> to configure that.
>
> Best regards,
>
> --
> Aymeric.
>
> On 16 Nov 2016, at 20:59, Tim Graham  wrote:
>
> I don't think this registration model is common on most websites.
>
> On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da
> Silva wrote:
>>
>> Hello everyone,
>>
>> I have this simple idea that I think django could benefit from, which
>> would be the option to create a user by an invitation from the django admin
>> page. So the person who is creating a new user doesn't have to type a
>> password neither a username for this new user. He would only fill a form
>> with an email that the invitation would be sent to. Something like a reset
>> password link but to add a new user.
>>
>> Do you think it would be useful? That would be accepted as a PR for some
>> version in the future? What are your thoughts?
>>
>> I would like to implement it and contribute to django, but I need
>> feedback from you guys.
>>
>>
>> Thanks!
>>
>> --
>> Bruno Ribeiro da Silva
>> Python Dev and Homebrewer!
>>
>
> --
> 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/2c949269-59f5-4332-8803-
> c2958f789336%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/A7A9A23F-24C3-495D-93C4-
> 12A9B859E9FC%40polytechnique.org
> 
> .
> 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/CALs0z1bNRW072KZNJkkxiU3wjOfELZZ0fP51DJUWiBSX64A%2Bow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should the Django session-id be hashed?

[Anthony King]

I have noticed that session id's are included in Django debug emails, with
no clear way to filter them out. I'm unsure of the behaviour with 1.9+, but
this is what I've experienced with 1.8.

The way around that issue though is to sign the cookie, so that people
can't just drop the session-id in.

On 22 September 2016 at 12:33, Florian Apolloner 
wrote:

>
>
> On Thursday, September 22, 2016 at 1:26:19 PM UTC+2, Violet Gibson wrote:
>>
>> Unless I'm missing something, these ids could be
>> vulnerable to SQL injection attacks, if any are discovered or if
>> developers misuse features like extra().
>
>
> Same is true for literally any field a user can write into.
>
>
>> What is your opinion on this matter?
>>
>
> Not worth it imo,
>
> --
> 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/3c8e5034-b0ed-4dbc-b60c-
> a2f9b280926e%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/CALs0z1Y3QmWivi72ym0pYf5-fhBDVdD7zQGN5oJk8BVNCPdWpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Anthony King]

In my opinion, it should remain a string. That's the behaviour it is now,
and it'll mean it can remain as a 3rd party package.

Perhaps to show it isn't being cast, it could be renamed to "integer",
which would avoid confusion

On 15 Sep 2016 8:03 a.m., "Sjoerd Job Postmus"  wrote:

> Hi :).
>
> Yes, I also added the other syntax yesterday evening, so the 
> syntax is now fully supported. (But it does not yield an int!!).
>
> Currently only `'int'` is registered as a valid type, with the regex
> r'[0-9]+'. More can be registered using `django_simple_url.register('hex',
> '[0-9a-fA-F]+')`.
>
> One downside (still) is that it does not get cast to an int. Although I'm
> not really sure if I find it logical that it gets cast.
>
> I don't really have that much time to work on it, but I'm hoping to add
> the `setup.py` either later today or shortly after the weekend.
>
> Kind regards,
> Sjoerd Job
>
> On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström wrote:
>>
>> Great initiative!
>>
>> I really think you should use the flask syntax instead of the rails one
>> that I first suggested. Seems this is the consensus from this thread, and
>> that makes it more likely to get it to core one day.
>>
>> /Emil
>>
>> On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wrote:
>>>
>>> Hi all,
>>>
>>> Since it seemed like an interesting idea to me, I started development of
>>> a third-party plugin.
>>>
>>> It's currently at:
>>> https://github.com/sjoerdjob/django-simple-url
>>>
>>> Since I only started today, I have no readme/setup.py yet. Will come
>>> later this week I hope.
>>>
>>> Current usage is
>>>
>>> from django_simple_url import simple_url
>>>
>>> urlpatterns = [
>>> simple_url('hello/world/', hello_world_view),
>>> simple_url(':year/:month/', posts_for_month_view),
>>> ]
>>>
>>> It works proper with includes (not adding a $ to the URL), and leaf
>>> views (adding a $ to the URL).
>>>
>>> Maybe this week, or early next week I will also add support for the
>>> '' syntax.
>>>
>>> Kind regards,
>>> Sjoerd Job
>>>
>>> On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim Graham wrote:

 I would like to see if this could be done as a third-party project
 (allow "pluggable URLs" which could use any syntax). If not, then let's
 accept a patch to Django to support it. Over time, if there's some strong
 consensus about a particular third-party package, then we could bring it in
 to core. I think this approach is less controversial then Django adopting
 some new, untested syntax right now.

 On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström
 wrote:
>
> So it looks to me that the consensus is that this IS in fact a good
> idea, to supply a simpler, regex-free method to define URL:s.
>
> It also seems that the best liked version is something that's similar
> to what flask uses: /articles///.
>
> I've never written a DEP before, but it sounds like a fun challenge.
> I'll try to look at existing DEPs for a pattern and then apply that.
>
> Does anyone have something in particular that they would like to add
> to the DEP? I figure I'll try to keep this first version as simple as
> possible, while maintaining extension points for features that can be 
> added
> later on.
>
> --
> 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/d11376c9-8a6f-45bd-940d-
> bc72589bf8e4%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/CALs0z1bz7NyuSL%2B43M1zZqSfsZTV0fgZx_aYGJp79kpsAgGhiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Anthony King]

This is actually an interesting concept, and wouldn't incur an, overheard
at runtime if simple_url translated in to full regex format at launch time
(or on first request, which is when the urls get loaded if I recall
correctly).

I don't think this would get in the way of includes, and if it's a
translator to full regex format, it can be done in a separate format.

Your example of flask's is interesting. What if we could define regex for
our urls to have it pluggable.

simple_url.register('integer', r'[0-9]+')

On 13 Sep 2016 07:26, "Ares Ou"  wrote:

> 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

Re: Challenge teaching Django to beginners: urls.py

[Anthony King]

This is actually an interesting concept, and wouldn't incur an overheard at 
runtime if simple_url translated in to full regex format at launch time (or 
on first request, which is when the urls get loaded if I recall correctly).

I don't think this would get in the way of includes, and if it's a 
translator to full regex format, it can be done in a separate format. 


The example from flask is interesting. What if we could define regex for 
our urls to have it pluggable.


simple_url.register('integer', r'[0-9]+')


On Monday, 12 September 2016 21:32:45 UTC+1, 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/545a0c83-07c5-4468-b14a-bacfb949b7ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.