Re: Support for MySQL `INSERT ... ON DUPLICATE KEY UPDATE ...`. proposed and code example

[Russell Keith-Magee]

Hi Matteius,

On Thu, May 29, 2014 at 8:49 AM, Matteius Davis  wrote:

> *Greetings Django Developers,*
>
> I am opening this thread based on my research and existing coding toward a
> solution of this issue, whereby Django today does not support effective
> usage of the MySQL specific construct `INSERT ... ON DUPLICATE KEY UPDATE
> ...`.
>
> First some background:  last month I solved a master-master MySQL
> replication problem we were having at my place of work whereby certain
> tables had records that were colliding during fail over events.  The
> issue originated from our optimistic collection of data, except that in
> fail over with master-master, we found it was possible to collect the same
> data in both centers and then the UNIQUE constrain on the keys would blow
> up.
>
> I solved the problem, by opening a mysql.py and writing two methods, which
> utilize the Django internals, to essentially extend the INSERT construct,
> and to generate what is essentially a valid Upsert construct.   It
> utilizes the MySQL functionality outlined here:
> http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html
>
>

> I now have the support of the development team to work towards a Django
> patch that which would adapt this functionality in the most transparent way
> possible to the ORM, in order to add further support for this MySQL
> specific feature.
>
> There are two calling patterns which are important here:
>
>1.
>
>The update idempotent field pattern, where we simply pass in the name
>of the primary key such that we assign the key to be equal to the key –
>essentially, if the record does exist, don’t truly update anything about 
> it.
>2.
>
>The update all fields pattern, where by if the original INSERT clause
>failed due to duplicate key it will intend to go ahead with updating all
>fields, as if the original INSERT had worked out of the box.
>
> The difference between the two, and why this is important, is because if
> we are creating a dummy record at some point (such as a FK constraint but
> prior to knowing how we want to fill out the record) then we don’t want
> this INSERT to collide and take out the creation of the real data within
> the record.  As a result we have two ways to call this.
>
> I hope this is about to become more clear as I share the code sample which
> I wish to adopt into a patch, such that I might fulfill my dream of
> becoming a Django contributor.
>
I certainly hope we can realise this dream :-)


> I now have permission to adapt this code to be a suitable patch for Django
> to adopt support of this MySQL specific feature.  So I am sharing it now
> here in its 37 lines of glory.
>
> https://gist.github.com/matteius/fff39563d1d8ddfc7168
>
>
>
> I am looking for general feedback as well as some specific feedback:
>
>1.
>
>Right now how I actually execute this custom logic is slightly ugly: I
>check if the settings DATABASE engine is MySql, and we call the specialized
>logic, otherwise I use the regular model.save() because it means the code
>is being run from unit tests on a sqlitedb.
>
> Roughly speaking, that's the right approach - however, you shouldn't do it
as an "if MySQL" check in the main ORM code. What you should be doing is
either:

 * Abstracting the block of functionality for which MySQL has a native
implementation, putting the current code into the "base" database backend,
and providing a MySQL-specific override in the MySQL backend, or

* Don't check for a backend - check for a database feature. You'll notice
that Database backends all define a list of supported features -- for
example, "interprets_empty_strings_as_nulls". This means that internal
logic of the ORM is determined by specific features that are (or are not)
supported by backends, rather than an "Is this MySQL" check. This is
analogous to best practice in front-end design - you don't check for "Is
this IE6?", you check for "Does the DOM support feature X?".

A combination of these two may be necessary - for example, a feature to
identify that the alternate logic is possible, and a backend call to
construct the specific command that implements that feature.

>
>1.
>
>To me it seems somewhat similar to update_or_create, but is still
>MySQL specific and has the calling patterns mentioned above.  Is there
>a way this might be a well suited MySQL specific override to a pattern such
>as `update_or_create` or is there another pattern more suited?
>
> We need to be careful about terminology here. Are we talking about a DB
specific feature, or a general concept that has an implementation specific
rendition?

Historically, Django doesn't provide much support for DB specific features
- we've tended to keep the ORM a "lingua franca" between databases.

However, that doesn't mean that every database has the same implementation.
Even basic things like quoting are completely different between platforms,
and Django 

Re: feature request - use logging in WSGIRequestHandler

[Russell Keith-Magee]

On Wed, May 28, 2014 at 3:35 AM, Martín Massera wrote:

> Hi sometimes when you are developing you get so much output in the
> console, especially when you have many medias on the page. It would be nice
> to use the logging system to remove those messages, but right now stderr is
> being used.
>
> Using the logging system for choosing whether we want to see this output
> or not sounds like a natural solution, right?
>
>
> http://stackoverflow.com/questions/23833642/django-how-to-filter-out-get-static-and-media-messages-with-logging/23845219
>
>
Well, logging *could* be used for this, sure.

However, there's a cost - we'd be adding the requirement for a logging
configuration for something that is only ever used during development. So
we'd end up complicating the process of deploying the devserver, which is
one of those things that is supposed to Just Work™ out of the box.

I *think* this would also mean losing the colorisation of devserver
messages, and for me, colorisation of output of the devserver is a higher
priority than the need to filter specific lines out of devserver output
(don't quote me on this one though -- it might be possible to preserve
colorisation. Some experimentation may be required).

It's also a feature that can be achieved using pipes and grep, which would
be more in line with the broader Unix philosophy.

In summary: I don't personally see a particularly compelling case for this
feature. However, the real test will be whether you can come up with an
implementation that doesn't overly complicate the deployment of the
devserver for the case that *most* users need it - a simple server that
Just Works™.

Yours,
Russ Magee %-)

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

Support for MySQL `INSERT ... ON DUPLICATE KEY UPDATE ...`. proposed and code example

[Matteius Davis]

*Greetings Django Developers,*

I am opening this thread based on my research and existing coding toward a
solution of this issue, whereby Django today does not support effective
usage of the MySQL specific construct `INSERT ... ON DUPLICATE KEY UPDATE
...`.

First some background:  last month I solved a master-master MySQL
replication problem we were having at my place of work whereby certain
tables had records that were colliding during fail over events.  The issue
originated from our optimistic collection of data, except that in fail over
with master-master, we found it was possible to collect the same data in
both centers and then the UNIQUE constrain on the keys would blow up.

I solved the problem, by opening a mysql.py and writing two methods, which
utilize the Django internals, to essentially extend the INSERT construct,
and to generate what is essentially a valid Upsert construct.   It utilizes
the MySQL functionality outlined here:
http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html

I now have the support of the development team to work towards a Django
patch that which would adapt this functionality in the most transparent way
possible to the ORM, in order to add further support for this MySQL
specific feature.

There are two calling patterns which are important here:

   1.

   The update idempotent field pattern, where we simply pass in the name of
   the primary key such that we assign the key to be equal to the key –
   essentially, if the record does exist, don’t truly update anything about it.
   2.

   The update all fields pattern, where by if the original INSERT clause
   failed due to duplicate key it will intend to go ahead with updating all
   fields, as if the original INSERT had worked out of the box.

The difference between the two, and why this is important, is because if we
are creating a dummy record at some point (such as a FK constraint but
prior to knowing how we want to fill out the record) then we don’t want
this INSERT to collide and take out the creation of the real data within
the record.  As a result we have two ways to call this.

I hope this is about to become more clear as I share the code sample which
I wish to adopt into a patch, such that I might fulfill my dream of
becoming a Django contributor.

I now have permission to adapt this code to be a suitable patch for Django
to adopt support of this MySQL specific feature.  So I am sharing it now
here in its 37 lines of glory.

https://gist.github.com/matteius/fff39563d1d8ddfc7168



I am looking for general feedback as well as some specific feedback:

   1.

   Right now how I actually execute this custom logic is slightly ugly: I
   check if the settings DATABASE engine is MySql, and we call the specialized
   logic, otherwise I use the regular model.save() because it means the code
   is being run from unit tests on a sqlitedb.
   2.

   To me it seems somewhat similar to update_or_create, but is still MySQL
   specific and has the calling patterns mentioned above.  Is there a way
   this might be a well suited MySQL specific override to a pattern such as
   `update_or_create` or is there another pattern more suited?
   3.

   When we look at a database specific feature such as a MySQL statement
   such as this, what kind advice or guidance can be given around unit testing
   a database specific feature?  My only though about this so far is it
   might be possible to test the semantic construct being generated, and to
   even mock out the sql execution in the test.  – this brings me to a
   sub-question I’d like to know more about Django …

   3.b.) What DB powers the Django unit tests (sqllite?) and Does Django
   ever mock out function calls in the test—I often use the mock library but I
   doubt that is being used here.

   4.) I hope this is well received, I think supporting this DB
specific features that helps solve problems that arise out of more
complicated configurations is important to Django maturing as a product.

I had found a couple older items out there referencing the lack of support,
but this solution to the problem is technically my own and I think could be
well adapted for Django.  Since this is a MySQL specific feature, it is not
totally clear to me how this best fits within the scope of the ORM.

I wrote here first rather than opening a ticket, because I read the
guidelines.  Despite attending the DjangoCon 2013 sprints, I am still not
technically a contributor to Django—this is my best shot yet.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Re: django.utils.six.bytes_types?

[Shai Berger]

On Wednesday 28 May 2014 22:38:20 Aymeric Augustin wrote:
> The name seems confusing to me: it's called bytes_type but its main purpose
> is to exclude bytes on Python 2. Otherwise you'd just write
> isinstance(value, (bytes, six.memoryview)).
> 

I renamed it to "buffer_types"  -- because English doesn't like plurals in the 
first part of such noun-combinations, but also because this way it makes more 
sense as a concept...

> If indeed you want "bytes or bytes-like on Py 3, bytes-like but not bytes on
> Py 2" then your if clause is perfectly clear and reasonable as is.
> (Remember that bytes is an alias for str on Py 2.)
> 

...and I also threw bytearray in. https://github.com/django/django/pull/2732.

> FYI django.utils.six.memoryview is a lazy hack to get the test suite to pass
> on Python 2 and 3, I wouldn't be surprised if it's used inappropriately :-/

So, the PR can be merged without documentation ?

[No, it can't. But perhaps we can leave memoryview out of it]

Shai.

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

Re: django.utils.six.bytes_types?

[Aymeric Augustin]

The name seems confusing to me: it's called bytes_type but its main purpose is 
to exclude bytes on Python 2. Otherwise you'd just write isinstance(value, 
(bytes, six.memoryview)).

If indeed you want "bytes or bytes-like on Py 3, bytes-like but not bytes on Py 
2" then your if clause is perfectly clear and reasonable as is. (Remember that 
bytes is an alias for str on Py 2.)

FYI django.utils.six.memoryview is a lazy hack to get the test suite to pass on 
Python 2 and 3, I wouldn't be surprised if it's used inappropriately :-/

-- 
Aymeric.

> Le 28 mai 2014 à 17:38, Shai Berger  a écrit :
> 
> Hi all,
> 
> While solving #22715[1], I found myself writing these lines:
> 
>elif (isinstance(value, six.memoryview) or 
>  six.PY3 and isinstance(value, bytes)):
>   
> 
> six.memoryview -- django.utils.six.memoryview, to be accurate, there's no 
> memoryview in the original six library -- is defined to be `memoryview` on 
> python3, and `buffer` on python2. But having written this code, I thought the 
> distinction might have more general value, and so we should maybe add a 
> "bytes_types" -- similar to six.string_types -- which would be defined as 
> `buffer` on python2, but `(memoryview, bytes)` on python3. The above would 
> change to 
> 
>elif isinstance(value, six.bytes_types):
>   
> 
> which is obviously nicer.
> 
> The question to you is, is it just me? Do you think "bytes_types" can be 
> useful?
> 
> Thanks,
>Shai.
> 
> [1] https://code.djangoproject.com/ticket/22715
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/201405281838.15889.shai%40platonix.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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6E968B1F-62E7-49A8-BDDC-181B18E8F1CE%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: SMTP configuration in a dict

[Aymeric Augustin]

Still, it's a good idea, please file a Trac ticket if there isn't one already.

-- 
Aymeric.

> Le 28 mai 2014 à 13:22, Tim Graham  a écrit :
> 
> Ramiro tried to do something similar, moving the cookie settings to a 
> dictionary, see #21051, but gave up due to backwards compatibility concerns. 
> Not saying it's impossible, but it may be a bit trickier than it looks at 
> first.
> 
>> On Wednesday, May 28, 2014 7:06:00 AM UTC-4, Julian Wachholz wrote:
>> Hi django-developers
>> 
>> I'd like to propose a relatively small change to the way we configure our 
>> SMTP email backends.
>> Up until now, configuring your SMTP backend took up to 6 individual 
>> settings, ranging from EMAIL_HOST to EMAIL_USE_SSL etc.
>> 
>> We already have a dictionary to configure things like caches and databases, 
>> so why not for sending email (at least with the SMTP backend).
>> I've already created a POC branch complete with docs and deprecation 
>> warnings here: 
>> https://github.com/julianwachholz/django/tree/feature/12factor-smtp
>> 
>> Please let me know what you think!
>> 
>> Cheers
>> Julian
>> 
>> PS: This change is only so altruistic, as it would enable me to include 
>> email settings in my dj-database-url fork 
>> (https://github.com/julianwachholz/dj-config-url).
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/2a94dfa5-e087-4d5f-9b34-620652611c82%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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2884B9B1-D40B-4F31-8902-28B91DDC69E0%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Make url patterns group kwargs more simple

[Alexandr Shurigin]

happy Urls doesn’t look simpler, just splitter configuration to parts .. This 
doesn’t make urls more readable i think. Sometimes this way is good, but not 
always.


-- 
Alexandr Shurigin

From: Tamlyn Marc marc.tam...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 2:51:41
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple  

I'm in favour of introducing another URL resolver, as a simpler option not as a 
replacement. My motivation is not "because it's nicer", rather to lower the 
boundary to entry. The Regex syntax is difficult for beginners.

There are many competing options, those mentioned and also hurl 
(github.com/oinopion/hurl). There are probably more around.

At the moment, I'm unsure about which format is preferable, and I'd be more 
interested to see changes to Django to make it easier to change the URL 
resolving system, including reversal. Having a standards API documented which 
allows patterns/URL/resolve to be intermingled with analogues with different 
rules is a good idea. It's not quite a 'urlbackend' as I'd like different ones 
to work in the same project, but that's the idea. This would also make handling 
complex URL resolving concepts easier to do outside of Django (e.g. a 
ContinueResolving exception views can raise to try later patterns)

I'm not saying any of this is not currently possible - it is. But I'd prefer to 
introduce a stable, robust API and then look at exact implementations of format.

Marc

On 28 May 2014 18:23, "Alexandr Shurigin"  wrote:
surlex library looks little bit simpler then smarturls.

http://amitu.com/smarturls/

surl('/year//', 'year.view'),
surl('/year///', 'month.view’),
And surlex example

/articles///(/)
Surlex looks more user-friendly.
I think need to have a look for such libraries, make choose about patterns 
formatting and implement this right way into django.

Ruby rails way looks simplest of this two. Also we can check ror routing 
patterns and make choose.
What you think?
alex.
-- 
Alexandr Shurigin

From: Graham Tim timogra...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 0:19:00
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

There was also a mention in IRC by a core dev (Jannis, I think) about the 
possibility of merging http://amitu.com/smarturls/ into core.  I agree URL 
regexes is something that we could improve, but as there are many solutions out 
there, this would require discussion and a consensus.

On Wednesday, May 28, 2014 1:05:29 PM UTC-4, Alexandr Shurigin wrote:
Thank you for your answer.

yes, that’ is not big problem in coding this feature locally or in django core. 
i just wanted to show interesting feature for django users. This feature can 
help new users with urls patterning and make existing code more readable.

Yes i will make component for django with supporting this feature and will try 
to publish it anywhere available to community. Maybe people will like it :)

For me this feature looks very usable.

Sorry for my english. Not native language.

-- 
Alexandr Shurigin

From: Berger Shai sh...@platonix.com
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 28 мая 2014 г. at 23:53:52
To: django-d...@googlegroups.com django-d...@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

Hi Alexendr,

On Wednesday 28 May 2014 18:54:05 Alexandr Shurigin wrote:
> Hi all.
>
> What do you think about adding some extra default and more simpler syntax
> for url patterns?
>
[looking for a way to re-write...]
>
> url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',...
>
[...as...]
>
>
> url(r'^:slug_genre/:slug/news/:slug_item$', ,,,
>
> This will make urls very short, fast-readable and writable.
>
I agree -- but there are two points:

1) The kind of expressions you'd want to use is probably very project-specific;

2) Something very close is easy to achieve, without any change to Django. For
example, for the case you gave above, add this near the top of your urls.py:

import re
def t(tag_url):
"""
Take a URL pattern with parts marked as :tag, and return
the appropriate Django url-pattern
"""
tag = re.compile(r':([\w]+)')
pat, _ = tag.subn(r'(?P<\1>[^/]+)', tag_url)
return pat

and now, you can write your urls as

url(t(r'^:slug_genre/:slug/news/:slug_item$'), ,,,

or even add further:

def turl(pat, *args, **kw): return url(t(pat), *args, **kw)

and write urls as

turl(r'^:slug_genre/:slug/news/:slug_item$', ,,,

Thus, I'm not sure anything needs to be changed in Django to support this.

You can, of course, make some generalization of this and offer it to the
community -- if it becomes very popular, it then may be a good candidate for
inclusion in Django. Just to be clear, 

Re: Make url patterns group kwargs more simple

[Alexandr Shurigin]

How many functions for now url api requires?

I know about resolve view by path and reverse url to path by namespace, name 
and params.

I forgot something else?


-- 
Alexandr Shurigin

From: Kaplan-Moss Jacob ja...@jacobian.org
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 2:56:57
To: django-developers django-developers@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple  

On Wed, May 28, 2014 at 2:51 PM, Marc Tamlyn  wrote:
I'm not saying any of this is not currently possible - it is. But I'd prefer to 
introduce a stable, robust API and then look at exact implementations of format.

I completely agree -- rather than pick something from a bunch of good options, 
I'd rather us introduce an API to make resolution pluggable and customizable 
(and then, maybe, choose a good default that's easier than regexes).

I've done some looking into this. It's possible, but going to be pretty 
difficult: resolution is one of the last great superglobals hanging around 
Django, and it's very tightly coupled into the core http/wsgi server. It'd take 
quite a bit of refactoring and cleaning to make this happen, unfortunately. I'm 
all for it, but it's not going to be easy.

Jacob
--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAK8PqJFvwXw65BZ7jQEgGbiigv5AHDXsGd-4rDXUXBQq%2Bztx5Q%40mail.gmail.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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.538640d3.6b8b4567.46e3%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.

Re: Make url patterns group kwargs more simple

[Jacob Kaplan-Moss]

On Wed, May 28, 2014 at 2:51 PM, Marc Tamlyn  wrote:

> I'm not saying any of this is not currently possible - it is. But I'd
> prefer to introduce a stable, robust API and then look at exact
> implementations of format.
>
> I completely agree -- rather than pick something from a bunch of good
options, I'd rather us introduce an API to make resolution pluggable and
customizable (and then, maybe, choose a good default that's easier than
regexes).

I've done some looking into this. It's possible, but going to be pretty
difficult: resolution is one of the last great superglobals hanging around
Django, and it's very tightly coupled into the core http/wsgi server. It'd
take quite a bit of refactoring and cleaning to make this happen,
unfortunately. I'm all for it, but it's not going to be easy.

Jacob

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

Re: Make url patterns group kwargs more simple

[Marc Tamlyn]

I'm in favour of introducing another URL resolver, as a simpler option not
as a replacement. My motivation is not "because it's nicer", rather to
lower the boundary to entry. The Regex syntax is difficult for beginners.

There are many competing options, those mentioned and also hurl (
github.com/oinopion/hurl). There are probably more around.

At the moment, I'm unsure about which format is preferable, and I'd be more
interested to see changes to Django to make it easier to change the URL
resolving system, including reversal. Having a standards API documented
which allows patterns/URL/resolve to be intermingled with analogues with
different rules is a good idea. It's not quite a 'urlbackend' as I'd like
different ones to work in the same project, but that's the idea. This would
also make handling complex URL resolving concepts easier to do outside of
Django (e.g. a ContinueResolving exception views can raise to try later
patterns)

I'm not saying any of this is not currently possible - it is. But I'd
prefer to introduce a stable, robust API and then look at exact
implementations of format.

Marc
On 28 May 2014 18:23, "Alexandr Shurigin" 
wrote:

> surlex library looks little bit simpler then smarturls.
>
> http://amitu.com/smarturls/
>
> surl('/year//', 'year.view'),
> surl('/year///', 'month.view’),
>
> And surlex example
>
> /articles///(/)
>
> Surlex looks more user-friendly.
>
> I think need to have a look for such libraries, make choose about patterns 
> formatting and implement this right way into django.
>
> Ruby rails way looks simplest of this two. Also we can check ror routing 
> patterns and make choose.
>
> What you think?
>
> alex.
>
> --
> Alexandr Shurigin
>
> From: Graham Tim timogra...@gmail.com
> Reply: django-developers@googlegroups.com
> django-developers@googlegroups.com
> Date: 29 мая 2014 г. at 0:19:00
> To: django-developers@googlegroups.com django-developers@googlegroups.com
> Subject:  Re: Make url patterns group kwargs more simple
>
>  There was also a mention in IRC by a core dev (Jannis, I think) about
> the possibility of merging http://amitu.com/smarturls/ into core.  I
> agree URL regexes is something that we could improve, but as there are many
> solutions out there, this would require discussion and a consensus.
>
> On Wednesday, May 28, 2014 1:05:29 PM UTC-4, Alexandr Shurigin wrote:
>>
>>  Thank you for your answer.
>>
>>  yes, that’ is not big problem in coding this feature locally or in
>> django core. i just wanted to show interesting feature for django users.
>> This feature can help new users with urls patterning and make existing code
>> more readable.
>>
>>  Yes i will make component for django with supporting this feature and
>> will try to publish it anywhere available to community. Maybe people will
>> like it :)
>>
>>  For me this feature looks very usable.
>>
>>  Sorry for my english. Not native language.
>>
>>  --
>> Alexandr Shurigin
>>
>> From: Berger Shai sh...@platonix.com
>> Reply: django-d...@googlegroups.com django-d...@googlegroups.com
>> Date: 28 мая 2014 г. at 23:53:52
>> To: django-d...@googlegroups.com django-d...@googlegroups.com
>> Subject:  Re: Make url patterns group kwargs more simple
>>
>>  Hi Alexendr,
>>
>> On Wednesday 28 May 2014 18:54:05 Alexandr Shurigin wrote:
>> > Hi all.
>> >
>> > What do you think about adding some extra default and more simpler
>> syntax
>> > for url patterns?
>> >
>> [looking for a way to re-write...]
>> >
>> > url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P> item>[^/]+)$',...
>> >
>> [...as...]
>> >
>> >
>> > url(r'^:slug_genre/:slug/news/:slug_item$', ,,,
>> >
>> > This will make urls very short, fast-readable and writable.
>> >
>> I agree -- but there are two points:
>>
>> 1) The kind of expressions you'd want to use is probably very
>> project-specific;
>>
>> 2) Something very close is easy to achieve, without any change to Django.
>> For
>> example, for the case you gave above, add this near the top of your
>> urls.py:
>>
>> import re
>> def t(tag_url):
>> """
>> Take a URL pattern with parts marked as :tag, and return
>> the appropriate Django url-pattern
>> """
>> tag = re.compile(r':([\w]+)')
>> pat, _ = tag.subn(r'(?P<\1>[^/]+)', tag_url)
>> return pat
>>
>> and now, you can write your urls as
>>
>> url(t(r'^:slug_genre/:slug/news/:slug_item$'), ,,,
>>
>> or even add further:
>>
>> def turl(pat, *args, **kw): return url(t(pat), *args, **kw)
>>
>> and write urls as
>>
>> turl(r'^:slug_genre/:slug/news/:slug_item$', ,,,
>>
>> Thus, I'm not sure anything needs to be changed in Django to support this.
>>
>> You can, of course, make some generalization of this and offer it to the
>> community -- if it becomes very popular, it then may be a good candidate
>> for
>> inclusion in Django. Just to be clear, I'm *not* saying that it won't be
>> --
>> just that, before adding something like this to Django, we'd want to see
>> how
>> it gets used, so the feature we finally 

shown all active users in template

[Ali hallaji]

Hi,
I write forum and need to shown all users on it pages.
how to shown all user online on my template

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/085daade-61b1-4ed8-9f97-a8795bfc8eb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make url patterns group kwargs more simple

[Tim Graham]

There was also a mention in IRC by a core dev (Jannis, I think) about the 
possibility of merging http://amitu.com/smarturls/ into core.  I agree URL 
regexes is something that we could improve, but as there are many solutions 
out there, this would require discussion and a consensus.

On Wednesday, May 28, 2014 1:05:29 PM UTC-4, Alexandr Shurigin wrote:
>
> Thank you for your answer.
>
> yes, that’ is not big problem in coding this feature locally or in django 
> core. i just wanted to show interesting feature for django users. This 
> feature can help new users with urls patterning and make existing code more 
> readable.
>
> Yes i will make component for django with supporting this feature and will 
> try to publish it anywhere available to community. Maybe people will like 
> it :)
>
> For me this feature looks very usable.
>
> Sorry for my english. Not native language.
>
> -- 
> Alexandr Shurigin
>
> From: Berger Shai sh...@platonix.com 
> Reply: django-d...@googlegroups.com  
> django-d...@googlegroups.com 
> Date: 28 мая 2014 г. at 23:53:52
> To: django-d...@googlegroups.com  
> django-d...@googlegroups.com 
> Subject:  Re: Make url patterns group kwargs more simple 
>
> Hi Alexendr, 
>
> On Wednesday 28 May 2014 18:54:05 Alexandr Shurigin wrote: 
> > Hi all. 
> > 
> > What do you think about adding some extra default and more simpler 
> syntax 
> > for url patterns? 
> > 
> [looking for a way to re-write...] 
> > 
> > 
> url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',... 
>
> > 
> [...as...] 
> > 
> > 
> > url(r'^:slug_genre/:slug/news/:slug_item$', ,,, 
> > 
> > This will make urls very short, fast-readable and writable. 
> > 
> I agree -- but there are two points: 
>
> 1) The kind of expressions you'd want to use is probably very 
> project-specific; 
>
> 2) Something very close is easy to achieve, without any change to Django. 
> For 
> example, for the case you gave above, add this near the top of your 
> urls.py: 
>
> import re 
> def t(tag_url): 
> """ 
> Take a URL pattern with parts marked as :tag, and return 
> the appropriate Django url-pattern 
> """ 
> tag = re.compile(r':([\w]+)') 
> pat, _ = tag.subn(r'(?P<\1>[^/]+)', tag_url) 
> return pat 
>
> and now, you can write your urls as 
>
> url(t(r'^:slug_genre/:slug/news/:slug_item$'), ,,, 
>
> or even add further: 
>
> def turl(pat, *args, **kw): return url(t(pat), *args, **kw) 
>
> and write urls as 
>
> turl(r'^:slug_genre/:slug/news/:slug_item$', ,,, 
>
> Thus, I'm not sure anything needs to be changed in Django to support this. 
>
> You can, of course, make some generalization of this and offer it to the 
> community -- if it becomes very popular, it then may be a good candidate 
> for 
> inclusion in Django. Just to be clear, I'm *not* saying that it won't be 
> -- 
> just that, before adding something like this to Django, we'd want to see 
> how 
> it gets used, so the feature we finally implement is useful for many 
> people. 
>
> HTH, 
> Shai. 
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group. 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com . 
> To post to this group, send email to 
> django-d...@googlegroups.com. 
>
> Visit this group at http://groups.google.com/group/django-developers. 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/201405281953.35201.shai%40platonix.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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/83f9b1db-8585-4499-bcb7-b1fe160e8299%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make url patterns group kwargs more simple

[Alexandr Shurigin]

Thank you!

Just checked it, looks really what i mean.

Will check this library more deep.

First comment from developers site 
http://codysoyland.com/2009/sep/6/introduction-surlex/

>> This is pretty cool. You should build this as a drop-in into django!

:-)

Write clean regular expressions i think is little bit hard for some part of 
django users, because regexp is not simple for some developers. If allow users 
use url predefined patterns out of the box users will appreciate it  i think.



-- 
Alexandr Shurigin

From: Bleier Sean seble...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 0:01:43
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple  

You might want to check out Surlex[1], written by Cody Soyland.  It basically 
does what you want.

[1] http://codysoyland.com/projects/surlex/documentation/


On Wed, May 28, 2014 at 8:54 AM, Alexandr Shurigin 
 wrote:
Hi all.

What do you think about adding some extra default and more simpler syntax for 
url patterns?

Now patterns looks little bit difficult, especially if you have long urls with 
2-3 params.

For example take a look into url.

url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$', 
views.GameNewsItem.as_view(), name="view_news_view")

This is ‘good seo url’ for big project. This url have game genre, game slug 
name, /news/ and news slug name.

For example this matches path /arcade/pacman/news/new-update-2014/

This is pretty cool when site have such urls and support all url subpaths, user 
can simple remove some path in url and go other pages of site catalog structure.

In presented example i wanted to show you this url entry shard to read (but not 
so difficult to write) when you supporting your project.

When you have about 20-30 same style urls in one file, this makes your urls 
file unreadable :)

Maybe allow user enter url masks in simpler way by adding some magic?

For django is not problem make url regexps from string with ‘meta tags’ and 
process it way like it work now. But i think user will be really happy to enter 
simpler (and shorter!) urls.

I mean we allow user only describe his urls simpler.

For example in ruby on rails user can enter urls like
get 'products/:id/purchase' => 'catalog#purchase', as: :purchase

Where :id is just shortcut for regexp pattern group.

I think we (or me, no difference) can do same way.

We can do it 2 ways:

1. hardcode some usually used tags (for example id, day, year, slug, any other) 
and words built from them (for example we understand that :id and :product_id 
have the same path type ([0-9]+)).
2. Make library for registering such tags like template tag library and add 
rules from #1 to it. Allowing way for users to extend library tags with their 
own.

Using this way, we can get very simple and fancy urls. For example my game news 
url will look like:

url(r’^:slug_genre/:slug/news/:slug_item$', views.GameNewsItem.as_view(), 
name="view_news_view")

This will make urls very short, fast-readable and writable.

Also we can skip in pattern masks ?P, for example from url pattern

([^/]+)

we can simple compile 
(?P[^/]+)

I think a lot of users will appreciate this feature. What you think?

Django urls are not simple right now for users and looks little ugly, because 
99% users reuse standard types of masks (id like - [0-9]+, slug like - 
[a-z0-9]+, year [0-9]{4}, month [0-9]{2}, day [0-9]{2}).

But of course user can combine url shortcuts with their custom regexps.



-- 
Alexandr Shurigin
--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.5386069d.57e4ccaf.406%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFtT_0KEgdyusp%3DhSn0z361zp%3DQvsy0f3-AOgi0UncveNNdsQ%40mail.gmail.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" group.
To unsubscribe from this group and stop receiving emails from it, 

Re: Make url patterns group kwargs more simple

[Alexandr Shurigin]

Thank you for your answer.

yes, that’ is not big problem in coding this feature locally or in django core. 
i just wanted to show interesting feature for django users. This feature can 
help new users with urls patterning and make existing code more readable.

Yes i will make component for django with supporting this feature and will try 
to publish it anywhere available to community. Maybe people will like it :)

For me this feature looks very usable.

Sorry for my english. Not native language.

-- 
Alexandr Shurigin

From: Berger Shai s...@platonix.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 28 мая 2014 г. at 23:53:52
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple  

Hi Alexendr,  

On Wednesday 28 May 2014 18:54:05 Alexandr Shurigin wrote:  
> Hi all.  
>  
> What do you think about adding some extra default and more simpler syntax  
> for url patterns?  
>  
[looking for a way to re-write...]  
>  
> url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',...  
>  
[...as...]  
>  
>  
> url(r'^:slug_genre/:slug/news/:slug_item$', ,,,  
>  
> This will make urls very short, fast-readable and writable.  
>  
I agree -- but there are two points:  

1) The kind of expressions you'd want to use is probably very project-specific; 
 

2) Something very close is easy to achieve, without any change to Django. For  
example, for the case you gave above, add this near the top of your urls.py:  

import re  
def t(tag_url):  
"""  
Take a URL pattern with parts marked as :tag, and return  
the appropriate Django url-pattern  
"""  
tag = re.compile(r':([\w]+)')  
pat, _ = tag.subn(r'(?P<\1>[^/]+)', tag_url)  
return pat  

and now, you can write your urls as  

url(t(r'^:slug_genre/:slug/news/:slug_item$'), ,,,  

or even add further:  

def turl(pat, *args, **kw): return url(t(pat), *args, **kw)  

and write urls as  

turl(r'^:slug_genre/:slug/news/:slug_item$', ,,,  

Thus, I'm not sure anything needs to be changed in Django to support this.  

You can, of course, make some generalization of this and offer it to the  
community -- if it becomes very popular, it then may be a good candidate for  
inclusion in Django. Just to be clear, I'm *not* saying that it won't be --  
just that, before adding something like this to Django, we'd want to see how  
it gets used, so the feature we finally implement is useful for many people.  

HTH,  
Shai.  

--  
You received this message because you are subscribed to the Google Groups 
"Django developers" group.  
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.  
To post to this group, send email to django-developers@googlegroups.com.  
Visit this group at http://groups.google.com/group/django-developers.  
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201405281953.35201.shai%40platonix.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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.53861747.7644a45c.406%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.

Re: Make url patterns group kwargs more simple

[Sean Bleier]

You might want to check out Surlex[1], written by Cody Soyland.  It
basically does what you want.

[1] http://codysoyland.com/projects/surlex/documentation/


On Wed, May 28, 2014 at 8:54 AM, Alexandr Shurigin <
alexandr.shuri...@gmail.com> wrote:

> Hi all.
>
> What do you think about adding some extra default and more simpler syntax
> for url patterns?
>
> Now patterns looks little bit difficult, especially if you have long urls
> with 2-3 params.
>
> For example take a look into url.
>
> url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',
> views.GameNewsItem.as_view(), name="view_news_view")
>
> This is ‘good seo url’ for big project. This url have game genre, game
> slug name, /news/ and news slug name.
>
> For example this matches path /arcade/pacman/news/new-update-2014/
>
> This is pretty cool when site have such urls and support all url subpaths,
> user can simple remove some path in url and go other pages of site catalog
> structure.
>
> In presented example i wanted to show you this url entry shard to read
> (but not so difficult to write) when you supporting your project.
>
> When you have about 20-30 same style urls in one file, this makes your
> urls file unreadable :)
>
> Maybe allow user enter url masks in simpler way by adding some magic?
>
> For django is not problem make url regexps from string with ‘meta tags’
> and process it way like it work now. But i think user will be really happy
> to enter simpler (and shorter!) urls.
>
> I mean we allow user only describe his urls simpler.
>
> For example in ruby on rails user can enter urls like
>
> get 'products/:id/purchase' => 'catalog#purchase', as: :purchase
>
> Where :id is just shortcut for regexp pattern group.
>
> I think we (or me, no difference) can do same way.
>
> We can do it 2 ways:
>
> 1. hardcode some usually used tags (for example id, day, year, slug, any
> other) and words built from them (for example we understand that :id and
> :product_id have the same path type ([0-9]+)).
> 2. Make library for registering such tags like template tag library and
> add rules from #1 to it. Allowing way for users to extend library tags with
> their own.
>
> Using this way, we can get very simple and fancy urls. For example my game
> news url will look like:
>
> url(r’^:slug_genre/:slug/news/:slug_item$', views.GameNewsItem.as_view(),
> name="view_news_view")
>
> This will make urls very short, fast-readable and writable.
>
> Also we can skip in pattern masks ?P, for example from url pattern
>
> ([^/]+)
>
> we can simple compile
> (?P[^/]+)
>
> I think a lot of users will appreciate this feature. What you think?
>
> Django urls are not simple right now for users and looks little ugly,
> because 99% users reuse standard types of masks (id like - [0-9]+, slug
> like - [a-z0-9]+, year [0-9]{4}, month [0-9]{2}, day [0-9]{2}).
>
> But of course user can combine url shortcuts with their custom regexps.
>
>
>
> --
> Alexandr Shurigin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/etPan.5386069d.57e4ccaf.406%40MacBook-Pro-dude.local
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Make url patterns group kwargs more simple

[Shai Berger]

Hi Alexendr,

On Wednesday 28 May 2014 18:54:05 Alexandr Shurigin wrote:
> Hi all.
> 
> What do you think about adding some extra default and more simpler syntax
> for url patterns?
> 
[looking for a way to re-write...]
> 
> url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',...
> 
[...as...]
> 
> 
> url(r'^:slug_genre/:slug/news/:slug_item$', ,,,
> 
> This will make urls very short, fast-readable and writable.
> 
I agree -- but there are two points:

1) The kind of expressions you'd want to use is probably very project-specific;

2) Something very close is easy to achieve, without any change to Django. For 
example, for the case you gave above, add this near the top of your urls.py:

import re
def t(tag_url):
"""
Take a URL pattern with parts marked as :tag, and return
the appropriate Django url-pattern
"""
tag = re.compile(r':([\w]+)')
pat, _ = tag.subn(r'(?P<\1>[^/]+)', tag_url)
return pat

and now, you can write your urls as 

url(t(r'^:slug_genre/:slug/news/:slug_item$'), ,,,

or even add further:

def turl(pat, *args, **kw): return url(t(pat), *args, **kw)

and write urls as 

turl(r'^:slug_genre/:slug/news/:slug_item$', ,,,

Thus, I'm not sure anything needs to be changed in Django to support this.

You can, of course, make some generalization of this and offer it to the 
community -- if it becomes very popular, it then may be a good candidate for 
inclusion in Django. Just to be clear, I'm *not* saying that it won't be -- 
just that, before adding something like this to Django, we'd want to see how 
it gets used, so the feature we finally implement is useful for many people.

HTH,
Shai.

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

Make url patterns group kwargs more simple

[Alexandr Shurigin]

Hi all.

What do you think about adding some extra default and more simpler syntax for 
url patterns?

Now patterns looks little bit difficult, especially if you have long urls with 
2-3 params.

For example take a look into url.

url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$', 
views.GameNewsItem.as_view(), name="view_news_view")

This is ‘good seo url’ for big project. This url have game genre, game slug 
name, /news/ and news slug name.

For example this matches path /arcade/pacman/news/new-update-2014/

This is pretty cool when site have such urls and support all url subpaths, user 
can simple remove some path in url and go other pages of site catalog structure.

In presented example i wanted to show you this url entry shard to read (but not 
so difficult to write) when you supporting your project.

When you have about 20-30 same style urls in one file, this makes your urls 
file unreadable :)

Maybe allow user enter url masks in simpler way by adding some magic?

For django is not problem make url regexps from string with ‘meta tags’ and 
process it way like it work now. But i think user will be really happy to enter 
simpler (and shorter!) urls.

I mean we allow user only describe his urls simpler.

For example in ruby on rails user can enter urls like
get 'products/:id/purchase' => 'catalog#purchase', as: :purchase

Where :id is just shortcut for regexp pattern group.

I think we (or me, no difference) can do same way.

We can do it 2 ways:

1. hardcode some usually used tags (for example id, day, year, slug, any other) 
and words built from them (for example we understand that :id and :product_id 
have the same path type ([0-9]+)).
2. Make library for registering such tags like template tag library and add 
rules from #1 to it. Allowing way for users to extend library tags with their 
own.

Using this way, we can get very simple and fancy urls. For example my game news 
url will look like:

url(r’^:slug_genre/:slug/news/:slug_item$', views.GameNewsItem.as_view(), 
name="view_news_view")

This will make urls very short, fast-readable and writable.

Also we can skip in pattern masks ?P, for example from url pattern

([^/]+)

we can simple compile 
(?P[^/]+)

I think a lot of users will appreciate this feature. What you think?

Django urls are not simple right now for users and looks little ugly, because 
99% users reuse standard types of masks (id like - [0-9]+, slug like - 
[a-z0-9]+, year [0-9]{4}, month [0-9]{2}, day [0-9]{2}).

But of course user can combine url shortcuts with their custom regexps.



-- 
Alexandr Shurigin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.5386069d.57e4ccaf.406%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.

django.utils.six.bytes_types?

[Shai Berger]

Hi all,

While solving #22715[1], I found myself writing these lines:

elif (isinstance(value, six.memoryview) or 
  six.PY3 and isinstance(value, bytes)):
   

six.memoryview -- django.utils.six.memoryview, to be accurate, there's no 
memoryview in the original six library -- is defined to be `memoryview` on 
python3, and `buffer` on python2. But having written this code, I thought the 
distinction might have more general value, and so we should maybe add a 
"bytes_types" -- similar to six.string_types -- which would be defined as 
`buffer` on python2, but `(memoryview, bytes)` on python3. The above would 
change to 

elif isinstance(value, six.bytes_types):
   

which is obviously nicer.

The question to you is, is it just me? Do you think "bytes_types" can be 
useful?

Thanks,
Shai.

[1] https://code.djangoproject.com/ticket/22715

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

Re: That's enough.

[Cal Leeming [Simplicity Media Ltd]]

I'd like to thank you both for acknowledging this post and offering to do
something about it.

I'll certainly follow up on this with a more detailed post about specifics,
I owe the community that much.

Cal


On Wed, May 28, 2014 at 3:34 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> Hi Cal,
>
> I'd like to reiterate what Jacob has said - some change in communities is
> inevitable, but we'd aspire to those changes being positive for the most
> part. I'm saddened that your experience of those changes in the Django
> community hasn't been positive.
>
> I'd also like to make the same offer Jacob has made -- if you feel like
> going into specifics, either in public or in private, please get in touch.
> I'd be only too happy to discuss the problems as you see them, and if
> there's something we (i.e., the core team as stewards of the community) can
> do to improve things, I'd be very happy to explore those options with you.
>
> Yours,
> Russ Magee %-)
>
>
>
> On Wed, May 28, 2014 at 10:23 AM, Jacob Kaplan-Moss wrote:
>
>> I'm sorry you feel that way, Cal; your contributions have been
>> appreciated, and I've personally appreciated having you around. Thanks for
>> all you've done.
>>
>> If you ever feel up to sharing with me more specifics, so perhaps we can
>> try to change things to be more welcoming to contributions, well, you know
>> how to reach me.
>>
>> Good luck,
>>
>> Jacob
>>
>>
>> On Tue, May 27, 2014 at 7:49 PM, Cal Leeming [Simplicity Media Ltd] <
>> cal.leem...@simplicitymedialtd.co.uk> wrote:
>>
>>> I remember the first day that I discovered Django after moving from CI
>>> (PHP) back in 2009, it opened me up to a whole new world of design
>>> principles and ideas that I hadn't even considered before.
>>>
>>> The community was absolutely fantastic, I took huge pleasure in helping
>>> other people with their problems and got my first real taste for open
>>> source contribution.
>>>
>>> Over the years I perfected my techniques and design methodologies,
>>> sharing what I learnt as I went along whilst spreading the word of Django,
>>> having a really swell time.
>>>
>>> I've selflessly defended the core maintainers when criticized with lack
>>> of innovation or particular handling of a ticket, holding many of the core
>>> maintainers in the highest regard, despite their sometimes awkward bedside
>>> manner.
>>>
>>> Five years later, and I can barely recognise the project and community
>>> that I once loved. I've seen several events of genuine arguments being shot
>>> down with no solid logic, questionable design methodologies, lengthy
>>> debates taking place over subjects that shouldn't even be a problem to
>>> begin with, contradictory arguments made by several core maintainers, and a
>>> previously smooth contribution process reduced to a political nightmare.
>>>
>>> Should you care what I have to say? Not really, I'm not a core
>>> maintainer, just another programmer.
>>>
>>> Perhaps this post will encourage others to speak up, perhaps it will be
>>> met with hostility, perhaps many of you will disagree with me, or perhaps
>>> it's just me.
>>>
>>> Am I going to continue to use Django? Probably, until someone makes a
>>> better alternative.
>>>
>>> Cal
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAHKQagGWFiik4aYXtYzRW%2BGOJNQX1rJnAPzo4O1vo3h4%3DHK_bw%40mail.gmail.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" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAK8PqJEnCyyQRe8mU8f-Kq1NznC1O8tbuWdw8boV351ShxXfxw%40mail.gmail.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" group.
> To unsubscribe 

Re: SMTP configuration in a dict

[Andi Albrecht]

Hi,

On Wed, May 28, 2014 at 1:06 PM, Julian Wachholz  wrote:
> Hi django-developers
>
> I'd like to propose a relatively small change to the way we configure our
> SMTP email backends.
> Up until now, configuring your SMTP backend took up to 6 individual
> settings, ranging from EMAIL_HOST to EMAIL_USE_SSL etc.
>
> We already have a dictionary to configure things like caches and databases,
> so why not for sending email (at least with the SMTP backend).
> I've already created a POC branch complete with docs and deprecation
> warnings here:
> https://github.com/julianwachholz/django/tree/feature/12factor-smtp
>
> Please let me know what you think!

I've came across this too while working on
https://code.djangoproject.com/ticket/20743 (add support for ssl
keyfile/certfile). If support for keyfile/certfile would be added two
additional settings for the SMTP backend would be required to
configure the file paths.

The current settings for emails is confusing IMO since some settings
are for emails in general (EMAIL_BACKEND, EMAIL_SUBJECT_PREFIX) and
others are backend related (EMAIL_FILE_PATH for the file backend,
several others for the SMTP backend).

IMO it's a good idea to make it clear which settings belong to which
backend and a dictionary-based solution sounds good to me.

--
Andi

>
> Cheers
> Julian
>
> PS: This change is only so altruistic, as it would enable me to include
> email settings in my dj-database-url fork
> (https://github.com/julianwachholz/dj-config-url).
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3ed1fa0e-8676-412e-8265-aaa196465ffb%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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFKCSkSOCcWkU3QKk0g3E2bRx1J52e9OaU7ShMBR9jZ%2B1FmRXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: SMTP configuration in a dict

[Tim Graham]

Ramiro tried to do something similar, moving the cookie settings to a 
dictionary, see #21051 , but 
gave up due to backwards compatibility concerns. Not saying it's 
impossible, but it may be a bit trickier than it looks at first.

On Wednesday, May 28, 2014 7:06:00 AM UTC-4, Julian Wachholz wrote:
>
> Hi django-developers
>
> I'd like to propose a relatively small change to the way we configure our 
> SMTP email backends.
> Up until now, configuring your SMTP backend took up to 6 individual 
> settings, ranging from EMAIL_HOST to EMAIL_USE_SSL etc.
>
> We already have a dictionary to configure things like caches and 
> databases, so why not for sending email (at least with the SMTP backend).
> I've already created a POC branch complete with docs and deprecation 
> warnings here: 
> https://github.com/julianwachholz/django/tree/feature/12factor-smtp
>
> Please let me know what you think!
>
> Cheers
> Julian
>
> PS: This change is only so altruistic, as it would enable me to include 
> email settings in my dj-database-url fork (
> https://github.com/julianwachholz/dj-config-url).
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2a94dfa5-e087-4d5f-9b34-620652611c82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

SMTP configuration in a dict

[Julian Wachholz]

Hi django-developers

I'd like to propose a relatively small change to the way we configure our 
SMTP email backends.
Up until now, configuring your SMTP backend took up to 6 individual 
settings, ranging from EMAIL_HOST to EMAIL_USE_SSL etc.

We already have a dictionary to configure things like caches and databases, 
so why not for sending email (at least with the SMTP backend).
I've already created a POC branch complete with docs and deprecation 
warnings here: 
https://github.com/julianwachholz/django/tree/feature/12factor-smtp

Please let me know what you think!

Cheers
Julian

PS: This change is only so altruistic, as it would enable me to include 
email settings in my dj-database-url fork 
(https://github.com/julianwachholz/dj-config-url).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3ed1fa0e-8676-412e-8265-aaa196465ffb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.