from:"Curtis Maloney"

Re: Sonar for the Django rpoject

2016-09-03 Thread Curtis Maloney

If there will be sweeping commits to remove six and other py2 concessions, can 
the cleaning be included then?

On 4 September 2016 9:38:05 AM AEST, Sergei Maertens  
wrote:
>I kind of like these reports, since they can take away some of the
>early 
>review work. I would put it on the same level as the `isort` checks we
>have 
>now. On the other hand, adapting the existing codebase to 'resolve'
>this 
>code smells will introduce quite some 'stupid' commits, so it might be
>best 
>to get it done with in one or two go's.
>
>If it can be applied to pull-requests, it would be nice I guess.
>
>One final question: why use sonar instead of something like pylint/pep8
>- 
>these tools also provide static analysis and report common violations
>in 
>the Python world.
>
>On Wednesday, August 31, 2016 at 7:50:38 PM UTC+2, Ivan Sevastoyanov
>wrote:
>>
>>
>>
>
>> I'm posting the the 11 criticals. In my opinion, they are not
>critical, 
>> they are just code smells. I will try to export the report so you can
>
>> review the major issues by groups.
>>
>> Regards,
>> Ivan
>>
>> On Wednesday, August 31, 2016 at 2:15:48 PM UTC+3, Tim Graham wrote:
>>>
>>> Any security issues should be reported to secu...@djangoproject.com,
>
>>> otherwise it's fine to share the information here.
>>>
>>> On Wednesday, August 31, 2016 at 2:25:55 AM UTC-4, Ivan Sevastoyanov
>
>>> wrote:

 All the rules are with a default severity so there might be some
>major 
 issues that it's worth reviewing them. I will post the critical
>issues this 
 evening because I'm at work now. Do you want to post them somewhere
>else 
 because it's a sensitive information? I will try to find out how to
>export 
 the whole report in a convenient format.

 Regards,
 Ivan

 On Wednesday, August 31, 2016 at 12:55:35 AM UTC+3, Tim Graham
>wrote:
>
> Perhaps you could tell us about some of the critical issues so we
>could 
> get a sense for that.
>
> On Tuesday, August 30, 2016 at 4:26:42 PM UTC-4, Ivan Sevastoyanov
>
> wrote:
>>
>>
>>
>
>> That is the report from the Sonar with all the rules included. 
>> Unfortunately, I cannot export it as a PDF or some more
>convenient format. 
>> I can describe all the steps in my blog so some of the Django
>members could 
>> set up Sonar on his/her machine and see a lot more details and
>figure out 
>> if it's worth it to fix some of the issues.
>>
>> On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeric Augustin
>
>> wrote:
>>>
>>> On 28 Aug 2016, at 21:43, Ivan Sevastoyanov
> 
>>> wrote: 
>>>
>>> > My question is do you consider using SonarQube for code
>quality 
>>> analysis, static analysis and find bugs because it's able to do
>that. 
>>>
>>>
>>> I guess that depends on the signal / noise ratio in the things 
>>> SonarQube flags. 
>>>
>>> Perhaps you could do an initial run and see whether SonarQube
>spots 
>>> interesting bugs? 
>>>
>>> I have no idea what the results could be because I’m not
>familiar 
>>> with static analysis of Python code. 
>>>
>>> -- 
>>> Aymeric. 
>>>
>>>
>
>-- 
>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/21d19365-ab7f-4870-9140-e8ec2f786b87%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/5DB3699E-959B-40C9-852C-5A9CB41DA436%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Any inerest in Zlib pre-compressed HTML generator responses?

2016-08-16 Thread Curtis Maloney


On 16/08/16 09:10, Bobby Mozumder wrote:

Hi,

I also use generators for my views, and I use Django’s streaming views
with my generators to stream responses, so that the web browser receives
early responses and start rendering immediately before the view is
completely processed.  The web browser receives the first HTML fragment
before I even hit the database.


The hazard here is if anything raises an exception you've already sent 
headers to say it didn't... typically this results in pages terminating 
part way through.


Other than this, it is certainly a great way to overlap some transport 
latency with work.  I've done the same with a generator-based JSON 
serialiser.


--
Curtis

--
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/94bee6c6-da25-b427-f44b-510d857c7945%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

2016-07-31 Thread Curtis Maloney

As I watch this discussion I am reminded of a talk I saw a few years ago
at PyConAU:

https://www.youtube.com/watch?v=_V4q0o-nKp4=PLs4CJRBY5F1KDIN6pv6daYWN_RnFOYvt0=33

--
Curtis

On 01/08/16 09:34, James Pic wrote:

On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton wrote:

I think having a single name field is reasonable for the vast majority of
cases, but it fails where projects really do need to identify two names for
things like sorting or categorising.

I'd be willing to believe that a project requires storing names as an
array of words for sorting. I can see how that would be helpful to do
sorting. Even I have a full name of 5 words and I only use two of them
because it's my culture. In this situation how to convince someone
that it's not a waste of time to have to fill in several form fields,
when they are going to the usage name they want anyway which is
conceptualized rather as an array of words than a pair of words. Some
people won't even want their real name on some projects.

I'd be willing to argue that if you did
need to differentiate between parts of a full name then you could customise
your User model to account for that. The issue is backward compatibility. We
can't just use migrations to remove the last name field because that would
break working code and potentially delete data. It'd break a lot more than
simply increasing the size of existing labels.

Deporting the issue on the user project is an option, but I'd like to
suggest that we keep on trying to find a curative solution for this
issue which has been brought up on regularely. It should be possible
to make a migration to add and provision the full name column and make
first and last name column read-only if they exist - but not be
provided on new projects. Even then, the backward incompatibility will
be an easy fix, it's not like we were splitting data the other way,
that would be a lot more difficult and require esoteric code, again,
just like when we try to make people fit in two distinct inputs.

Free users from our culture, open django.contrib.auth to the world.

Rock'on

James B)

--
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/c4e945a3-61bd-3917-dec5-9758b0d2790e%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Middleware error framework, high level logging for database queries

2016-07-22 Thread Curtis Maloney




On 19/07/16 05:16, Rishi Gupta wrote:

Hi django-developers,

(1) Middleware error framework.

Zulip has some exception middleware to allow 40x errors to be returned
to the user from anywhere within the view code via raising a special
exception, which we’ve found to be a really nice, convenient
programming style.  With this model, validation code called anywhere
from within a view can pass nice, clear user-facing errors up to the
frontend.  You can do this by writing something like:


I did something like this [actually, the code was handed to me by Matt 
Schinckel]... which I use in django-nap.


It's HtppResponse melded with Exception so you can raise it.

I submitted it for consideration some time ago, and it was rejected 
because it bound source and action too tightly.


However, it looks like your solution doesn't suffer from this shortcoming.

As was mentioned by Tim, I think this can readily grow outside django, 
until it's matured.




(2) High level logging for database queries.

We've currently monkey-patched a system to add the following
information to our log lines:

...  52ms (db: 4ms/8q) /url ...


Some years back I wrote some middleware to do just this originally 
logging the count / total time, and later sending it to the browser in a 
cookie with a 0 time to live.



Currently there isn't a great way to do this "natively"; Django’s
database cursors either logs the whole query (in DEBUG mode) or
nothing at all.


In debug mode the queries [and their execution times] are kept on the 
connection.


import time

class CookieDebugMiddleware(object):
'''Show query counts, times, and view timing in Cookies'''

def process_request(self, request):
request.start_time = time.time()

def process_response(self, request, response):
response.set_cookie('QueryCount', '%d (%s s)' % (
len(connection.queries),
sum([float(q['time']) for q in connection.queries])
), max_age=0)
response.set_cookie('ViewTime', '%s s' % (time.time() - 
request.start_time), max_age=0)

return response


--
Curtis

--
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/ff91610e-9a8e-2c8a-554b-ca2c880de95b%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Problem with caching template loader

2016-07-07 Thread Curtis Maloney


Hey,

a client of mine was having a strange bug with the caching template 
loader, which we've yet to identify, but as I was looking at the code, I 
saw the following:


def load_template(self, template_name, template_dirs=None):
key = self.cache_key(template_name, template_dirs)
template_tuple = self.template_cache.get(key)
# A cached previous failure:
if template_tuple is TemplateDoesNotExist:
raise TemplateDoesNotExist
elif template_tuple is None:
template, origin = self.find_template(template_name, 
template_dirs)

if not hasattr(template, 'render'):
try:
template = Template(template, origin, 
template_name, self.engine)

except TemplateDoesNotExist:
# If compiling the template we found raises 
TemplateDoesNotExist,
# back off to returning the source and display name 
for the template
# we were asked to load. This allows for correct 
identification (later)

# of the actual template that does not exist.
self.template_cache[key] = (template, origin)
self.template_cache[key] = (template, None)
return self.template_cache[key]


Now... in that "except" clause at the end, it updates the cache dict 
with (template, origin).. only then to fall through to set it AGAIN 
_immediately_ with (template, None)


Surely this is wrong one way or the other?

--
Curtis

--
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/b5d6fdd0-303a-68b0-c0c3-41732683910b%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

2016-05-15 Thread Curtis Maloney


On 16/05/16 15:10, Carl Meyer wrote:

On 05/15/2016 11:01 PM, Curtis Maloney wrote:

So this seems to leave us only part way to removing rendering decisions
from the form code -- your widgets can be templated, but your form code
still needs to decide which widgets...



Yep, one step at a time. With django-floppyforms templated widgets I've
used a template filter that allows switching a widget's template path in
the template that's rendering the form, placing more control into
templates. I think integrating something like that could make sense as a
next step.


Sniplates works by pulling {% blocks %} from a nominated template as 
widgets -- these are widgets in the "macro" sense, rather than 
specifically the form field sense.


It lets you load multiple widget templates, each in its own namespace.


(Since widgets are Python classes that control not only markup
generation but also data retrieval, control over widgets themselves
needs to remain in Python code. But the rendering template could be
given the option to customize the template used to render the widget.)


The way I handle this in sniplates is the {% form_field %} tag 
"explodes" all the relevant details from the BoundField into the context.


Since the field tag can select the widget set to use, as well as the 
specific widget template, and other context overrides, it puts pretty 
much all the rendering decisions into the template.


--
Curtis

--
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/573958C0.6070102%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

2016-05-15 Thread Curtis Maloney


On 12/05/16 01:04, Preston Timmons wrote:

Hey Curtis,

I think you're asking how this patch will help with form and field layouts?
If so, not that much. It only addresses moving the widget HTML that
currently is hardcoded in Python into templates.


No... was all to do with widget rendering...

Currently when you render a form field, its label comes along with it.

Does this patch _only_ changes the rendering of the input field, and not 
the label?



There's nothing in this patch that would hinder further development to
convert the form rendering methods, like `Form.as_p()` to be template
based also, or providing better rendering methods altogether.

With that said, yes the renderer class is able to be set per form class
and as an argument to `Form.__init__()`.


So this seems to leave us only part way to removing rendering decisions 
from the form code -- your widgets can be templated, but your form code 
still needs to decide which widgets...


--
Curtis

--
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/5739541C.9040301%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

2016-05-10 Thread Curtis Maloney

Sorry for the late entry to the discussion, but I was looking over the 
code and wondered about something.


In projects where I've used my django-sniplates for form rendering, it's 
been helpful that I can have several different form widget sets within 
the one project -- for instance, for side-by-side labels, or top-labels, 
etc.


From what I can see so far of the code/docs, there's no way to override 
which set of form widgets get used on a per-form basis... let alone 
per-field.


Is this correct?

The only possible avenue I see is a custom renderer class that somehow 
mangles the widget template paths...


--
Curtis

On 11/05/16 13:21, Preston Timmons wrote:

+1. I like the simpler fallback solution Carl has suggested also.

Preston

--
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/a5f5ad63-71f0-4ba5-bd21-028d79b0a3b4%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/5732A7B7.7090403%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

2016-05-02 Thread Curtis Maloney

On 03/05/16 14:08, Gavin Wahl wrote:

 > with MyModel.objects.lock():
 > ... do stuff ...

This is misleading as it implies the lock is released when the context
manager exists, but in postgres at least the lock will be held until the
end of the transaction.

Hah!  Shows how much I know about table locking :P

What advantage does implementing an ORM API for table locking have over
`cursor.execute("LOCK TABLE mymodel")`?

Much the same as the rest of the ORM API : Abstraction and convenience.

Even if it's just so you can pass a ModelClass instead of having to know 
the table name... and avoid having to access cursor directly.

Perhaps transaction.lock_table(model) since, as you say, it's related to 
the term of the transaction?

--
Curtis

--
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/57282559.2080408%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

2016-05-02 Thread Curtis Maloney


On 03/05/16 09:47, Russell Keith-Magee wrote:

Hi Geoffrey

Have you given any thought to what the API for a table lock would look like?


Since it's a table-wide action, having it on the Manager makes some 
sense... though it would be, I suspect, implemented via _meta.


I can see something like:

with MyModel.objects.lock():
... do stuff ...

Being an intuitive, inoffensive and hookable API.

--
Curtis

--
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/5727E7A3.8090100%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

2016-04-15 Thread Curtis Maloney


On 14/04/16 05:57, Carl Meyer wrote:

Hi James et al,

In general, I like the idea of adding a helper to Django to read
settings from the environment. I think this helper should be kept as
simple and non-magical as is reasonable. Thus:

- I'm in favor of a flexible helper function that can be manually used
in a settings file to read an explicitly-named env var and coerce it
using any arbitrary callable (that gives enough power to "coerce" using
something as simple as `int` or something as complex as
`parse_database_url` that turns a DSN string into a Django db dict),
with some handling of defaults. Below I give some usage examples of the
function I use for that, and link to its code.


+1

This I've found works well in d-c-s...


- I'm opposed to anything more magical than that, e.g. anything that
tries to set up an all-dancing automatic mapping or translation between
env var names and setting names, or tries to enforce some particular env
var prefix. The minor gains in conciseness with this kind of thing
aren't nearly worth the losses in flexibility in how you construct your
settings file or name your env vars.


+1

Adding more policy will only complicate matters... if you just provide 
the mechanism, people will surprise you with innovative policies :)



- I'm also opposed to conflating the issue of reading env vars with
orthogonal stuff like class-based settings or patterns for using
multiple settings files.


+1

Once again, there's no need to dictate more than necessary.

--
C

--
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/57108E2C.9050803%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

2016-04-11 Thread Curtis Maloney


On 12/04/16 04:26, Aymeric Augustin wrote:

On 11 Apr 2016, at 19:39, Curtis Maloney <cur...@tinbrain.net> wrote:

1. All env vars can have a fallback value (the method in my case)
2. You can mark an env var as not having a fallback value, and it will raise an 
error at start up if not set.


There’s an additional complexity here.

Usually, it’s best for settings read from environment variables:

a. To use a default value in dev, even if that means a small degradation in
functionality. This allows developers to start working on the project without
adding dozens of exports to their $VIRTUAL_ENV/bin/postactivate, and to add
just the values they need when they work on specific parts like integrations
with third-party systems.

b. To crash if no value is provided in prod, in order to catch configuration
errors upfront.

One might think of switching the behavior depending on settings.DEBUG, but
that won't work because the switch is required to load settings properly.


This is all true it's generally not an issue when using 
django-classy-settings as it was engineered to make it easy to switch 
between settings environments such as dev/staging/testing/production.



I’ve seen lots of wrapper that don’t add enough value to be worth it. These
days I just write:

# settings/base.py

...

# settings/dev.py

FOO_TOKEN = os.environ.get('FOO_TOKEN', '')

# settings/prod.py

FOO_TOKEN = os.environ['FOO_TOKEN']

It isn’t as dry as it could be, but at least it’s simple.


This is one thing d-c-s helps you avoid... by letting you declare it all 
in one file, inherit complex/dependent settings through classes, and

switch between those with an env var [or whatever mechanism you like]

However, this is slightly tangential to the actual discussion

--
C

--
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/570BED47.7040602%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

2016-04-11 Thread Curtis Maloney


Just want to throw my 3c in here...

Firstly, for reference, I wrote django-classy-settings to help with 
various settings related problems, one of which being env-based setting.


https://github.com/funkybob/django-classy-settings

As my env decorators are written to be class properties, they don't 
quite fit this discussion... however, things to consider:


1. All env vars can have a fallback value (the method in my case)
2. You can mark an env var as not having a fallback value, and it will 
raise an error at start up if not set.

3. Non-trivial value types are not easy.

The URL series of settings helpers deal with many of these cases fairly 
well, as they allow us to specify a backend (protocol), username, 
password, host, port, and positional and keyword arguments.


Registering more protocols is actually quite easy, all told.

However, it becomes tricky when we allow multiples, such as database and 
cache backends.  Do we settle on, for instance, a pattern of 
"DJANGO_DATABASE_{name}="? Or some other scheme?


Email settings are certainly another big one, IME... as well as AWS keys...

--
C

--
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/570BE142.3000209%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Add documentation to address OWASP Top 10?

2016-04-06 Thread Curtis Maloney


On 06/04/16 11:35, Josh Smeaton wrote:

I like the idea of addressing the OWASP top 10. Further, I think the
advice of obscuring keys is wrong. The problem is actually addressed in
the OWASP Top 10[0]

*4 Insecure Direct Object References:*
A direct object reference occurs when a developer exposes a reference to
an internal implementation object, such as a file, directory, */or
database key/*. Without an access control check or other protection,
attackers can manipulate these references to access unauthorized data.

The proper solution is *Access Controls* like the Permissions system
provides.


Exactly... or just filtering the queryset according to the logged in 
User, and returning a 404 otherwise -- get_object_or_404 can make this 
trivial...


(yes 404, as 403 potentially admits the existence of the record in 
question -- see GitHub's behavior)


--
Curtis

--
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/5704BE62.1040706%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

2016-03-20 Thread Curtis Maloney

+1 for me, too... this aligns with "safe/secure by default".

--
C

On 21/03/16 09:13, Aymeric Augustin wrote:

I agree with Karen.

--
Aymeric.

On 18 Mar 2016, at 22:15, Karen Tracey > wrote:

This is the 2nd major issue I can recall caused by MySQL default of
REPEATABLE READ transaction isolation level. I think Django should
simply switch itself to a default of using READ COMMITTED, consistent
with (all?) other supported database backends, and document how, if a
user really really wants to use REPEATABLE READ, they can do so (I
assume Django could allow that?), and what known problems when using
basic Django functions they may run into if they do so.

I fear our existing approach of documenting how certain functions
don't work by default on MySQL (e.g. get_or_create) is not really
helping the majority of our users. I believe switching instead to
making Django code itself work by default on MySQL would be a better
long-term solution for those who use MySQL with Django, and avoid
future cases like this one that has been discovered (years after we
knew get_or_create was broken by default transaction isolation level
on MySQL).

On Mon, Mar 14, 2016 at 11:15 AM, Tim Graham > wrote:

Could some MySQL users take a look at ticket #26347 [0] and
recommend how to proceed? I think it's probably not a new issue
but I'm a bit surprised it hasn't come up before if so.

[0] https://code.djangoproject.com/ticket/26347

--
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/286b0efb-673f-42d7-a1f3-5de76fc039c5%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/CACS9rae4U0e80-h%3DesTXFUi%3DLxWQ-XiMAp%3DAdkXcR0FnJVT2Cg%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 (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/176B63AA-95D8-4D8B-B8EB-6A0AF95EEB9B%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/56EF311B.701%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: [ GSOC 2016 ] providing standard interface for NoSQL databases

2016-03-15 Thread Curtis Maloney

It sounds like by "NoSQL DBS" you mean specifically "Document store
DBMS". Is this correct?

(I'm sure most people know my rant about how "NoSQL" is a misnomer, and
it's really "Non-relational" that people mean - it's not SQL per se
they're avoiding, it's the relational model)

The NoSQL/Non-rel name is really too vague, as it covers "anything
that's not SQL / Relational"... which can cover key/value, document,
graph, log, and even filesystem or email, when it comes down to it.

I think it will help if you clarify what model you _do_ target, not
which you do _not_.

All that said/vented, I agree it would be nice to have a common
abstraction layer atop various document stores. The trick now will be
finding sufficient commonalities.

I feel that the ORM's relation-span/transforms/lookups syntax would be
equally viable on nested documents.

One of the benefits of an abstraction layer is allowing other tools to
generically interact with these new objects. What plans do you have for
how to support non-flat documents in, for instance, Forms?

--
Curtis

On 16/03/16 05:29, girish ramnani wrote:

Hello,

I would like to propose providing a standard interface for NoSQL
databases . Some the points to consider are:

1. The /Fields /which are used to define the schema of the sql
databases can also be used to provide in No sql databases.
2. In NoSQL dbs ,developers usually store data in denormalized form. so
in two related collections a meta tag /denormal = True /can be
provided. Which would make that collection a child of the other
model ( related ). In normal scenario the collections will be
connected using _id used as a foreign key.
3. providing contrib.mongo with Field such as GridFSField for providing
support for GridFS
4. considering the database transaction transaction blocking ( PyMongo
provides blocking api for mongo )
5. creating Mixins such as /FlexibleMixin /which would allow Models to
have dynamic fields. i.e directly insert fields which are not listed
in the Model schema.

there are lot more things (Migrations, settings etc) to consider but
before that needed to know that I am going in the right direction or
not?. Please suggest.

--
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/b2477318-9252-4241-a9fe-0972acb1b1cf%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/56E88390.40005%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django startproject template enhancement proposal

2016-03-14 Thread Curtis Maloney


Well, you could use:

mkdir my_client_name
django-admin startproject project my_client_name/

So it will create my_client_name/project/settings.py, and leave the 
namespace clear for you to create my_client_name/my_client_name/ as your 
app...


--
Curtis


On 15/03/16 10:51, Ramez Ashraf wrote:

May i add to the proposal suffixing the project_name inner directory
(the one containing settings.py) with '_proj'
Usually i start project called 'my_client_name', then i want an app
called 'my_client_name' too,
usually i do NOT want my main app called "my_client_name_app"..  table
names just looks ugly and unnecessarily long in this case.
Nor i want my main/parent directory to be called "my_client_name_proj" ,
unnecessarily long for nginx/uwsgi/other paths.


tl;dr
project_name/
   ..
   project_name+ "_proj"/
   app1/
   ..

Regards;



On Saturday, March 12, 2016 at 6:29:55 PM UTC+2, is_null wrote:

Hi all,

There's a pattern I like to use in my projects which I'd like to
suggest for django startproject.

It looks like:

project_name/
   setup.py
   src/
 myapp1/
 myapp2/
 project_name/
   settings.py
   urls.py
   manage.py
   wsgi.py

My settings.py here uses environment variables for everything to
override defaults.

Setup.py here allows:

- Adding an entry point,
- Installing all apps as packages,
- Installing test dependencies with extra_requires and pip install
project_name[test],
- Adding runtime dependencies.

For example, with that:

 entry_points = {
 'console_scripts': [
 'project_name = project_name.manage:main',
 ],
 },

And such a manage.py:

   def main():
 os.environ.setdefault("DJANGO_SETTINGS_MODULE",
"project_name.settings")
 from django.core.management import execute_from_command_line
 execute_from_command_line(sys.argv)

   if __name__ == "__main__":
 main()

Installing the package will add the project_name command, allowing to
run `project_name migrate` for example from any directory.

I know it's too opinionated to add that to django, but I'd like to
open a discussion here and perhaps there's something we might find
worth changing in django's default project template.

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/de495e35-ecad-409c-a5d2-f30512c36931%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/56E756BF.905%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

2016-03-11 Thread Curtis Maloney




On 12/03/16 11:47, Nathan Cox wrote:

I don't understand why this conversation has had to go on for this long.



The original post was in February of 2012, and it is now March of 2016.
That's four years of discussion that basically boils down to a couple of
purists insisting that their coding style is the only coding style, fits
every possible scenario and is beautiful, while a much larger group
comes up with scenarios where the given style guide is counterintuitive
and difficult to read.


I think, really, the core issue is a philosophical one, and it comes 
down to this:


Will making this change encourage people to put more work in templates?

Or, more, will it stop discouraging people from providing clean, simple 
interfaces in the context, instead of requiring template authors to do 
more work?


Personally, I think it's a tiny issue drastically outweighed by the 
advantages -- especially for the translation cases raised.



I think the salient fact here is that templating languages are supposed
to be supersets of HTML, and as supersets should respect the native
abilities of their parents.


I disagree here.  Whilst the most common use is for rendering HTML, it 
is frequently used for other cases.


Also, DTL quite specifically is NOT html-like to make it more widely usable.


With HTML it is common and accepted to break
tags with many attributes across multiple lines so that the code itself
is easy to read (i.e., "visually parse", a term used frequently in this
thread). This same convention extends into the Python world, where long
lines can easily be broken down using parenthesis to maintain language
constraints while allowing for ease of readability. In fact, PEP8
specifically prohibits lines longer than 80 characters, and even people
who break that generally respect something along the lines of 99. Two
Scoops will tell you that any community software should be a hard limit
of 80, while internal projects can be allowed to go to 99 with group
consensus.


From memory, Django itself uses a 119 char line limit - in deference to 
the prevalence of widescreen monitors.


Even so, I do agree long lines reduce readability.


So you have a python templating language for generating HTML, two
languages which both embrace multi-line statements merging together, but
we can't agree that it should probably also support this?


Well, we have a templating language... implemented in Python - but quite 
specifically _not_ python itself... primarily for rendering HTML, but 
specifically engineered to not be limited to it...


So you can see how some might think this argument is weak...


I think this conversation needs to come to a conclusion, and that
conclusion should be simple. Several people have asked a very simple
question of the purists: what is the "correct" way of writing tags which
by nature need to be very long, without line breaks and without them
being 400 characters long. If no acceptable answer can be given, we need
to just implement the line break mechanic and give the developers back
their whitespace.


As pointed out by Josh in another email, I wrote a patch to permit 
multi-line tags.  I asked for feedback.  I got _none_.


If people really wanted this feature, why didn't we hear more about it? 
 What can we do to get more people to know about it, and to give more 
feedback?


I would recommend you review the history of this discussion, collect the 
pros and cons, formulate a DEP, and we can go from there.


I'm quite sure the patch will still work fine.

--
C

--
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/56E39BA0.2070007%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Admin hstore widget

2016-03-08 Thread Curtis Maloney




On 08/03/16 20:47, Marc Tamlyn wrote:

Doing something better with the admin hstore is definitely something I'd
like to see land.

1. I'd like more input on the features people feel are essential.
Something that allows you to add/change/delete keys is all you need to
start with. Features like soft delete can be added later.


OK, well, I'll pare down the code and make a PR soon.


2. Is there a guide somewhere to styles and markup to be used in admin
templates?
No, in short. Keep it simple seems to be the best advice I can give -
most of the code is very old.


So nobody understands the HTML and CSS used in Admin?

Someone must, since there are a few skins for it, and someone just redid 
our skin for 1.9...



3. I plan to pull in another icon from FA, but it appears the one we
currently use for "inline delete" is customised from the original.  Does
anyone know who made these changes and how?
No idea sorry.


I had hoped the person "git blame" showed was reading this list... oh well

--
C

--
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/56DEAC33.1090600%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Admin hstore widget

2016-03-07 Thread Curtis Maloney




On 08/03/16 02:43, Tim Graham wrote:

1. Merging something minimal always help to get feature requests. :-)





2. Could you be more specific about what you're looking for? All the
existing documentation for style related stuff is at
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/.
I also thought of ticket https://code.djangoproject.com/ticket/14831.


This is no way covers the HTML or CSS structures used in admin.

Given the deafening roar of absolutely no interest in this feature, I 
guess I'll drop it.


--
C

--
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/56DDF031.10803%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Refactor Form class

2016-03-04 Thread Curtis Maloney


Hi,

On 04/03/16 07:00, 'Moritz Sichert' via Django developers 
(Contributions to Django itself) wrote:

Hello,

I want to propose a refactor of the Form class to make it
easier to customize and subclass.


I've recently had thoughts in this direction, so seeing your post 
intrigued me...


However, I feel some of your assertions are a bit off the mark...


Motivation:

Currently the Form class (combined with Field, Widget and
BoundField) has many responsibilities and combines much
functionality into a single class. It currently does:

- data validation (using Field validators and clean*
   methods)


Correct - this is the main purpose of Forms.


- parsing HTTP form data and handling special cases like
   file upload (using Widget.value_from_datadict() and
   Field.to_python())


Well, Widgets and Fields are involved in determining how to extract data 
from the submitted dict... but they don't actually "parse" the http form 
data -- Django does that much further down the stack in the HttpRequest 
object.




- displaying values as HTML input fields (using
   Widget.render(), BoundField.value(), Field.prepare_value()
   and even the Media class)




Although those three functionalities are closely related one
can easily think of situations where only one is needed.
Following Django's principle of loose coupling it would also
be desirable to be able to exchange components.



For example, it's conceivable that the form data doesn't
come from a HTTP request with x-www-form-urlencoded or
multipart/form-data content but gets transferred as JSON. In
this case it should be easy to replace the HTTP parsing


As mentioned above, Forms don't handle this parsing.  You can pass _any_ 
dict-like for them to validate.  In fact, I (and many others) have used 
this for a simple and effective way to import csv files, in combination 
with stdlib's csv.DictReader.


I also frequently use Forms for validating JSON data...


Also HTML forms may not be the only place where data
validation is needed. An application may get an untrusted
dict of Python objects that doesn't have to be parsed but
should still be validated. In that case it would be nice to
be able to just use the data validation component.



Therefore I propose splitting the Form class into multiple
components that can be easily exchanged and used without
another.


Here we somewhat agree.

My view was Forms involve the following actions:

1. Validation - the most important.
2. Rendering - currently handled by widgets
3. Sourcing - pulling in data, initial, defaults [POST, Form initial, 
ModelForm instance, etc]

4. Sinking - pushing out validated data [cleaned_data, ModelForm.save()]

I feel the current validation pattern is very powerful and flexible, and 
don't see much need to alter it.


In prior discussions about improving rendering in forms [a long time 
bugbear of mine] there are a number of subtleties that are not so 
obvious at first blush, where the current implementation blurs the Field 
and Widget.


ModelForm's show a reasonable example for how to overlay extensions for 
sourcing and sinking, but a more formalised approach could certainly 
benefit the wider range of practices in the modern web.



Rationale:

To give you a better idea about the proposal I already
prepared a general architecture of how I think this could be
implemented. This is of course in no way final and I'll be
happy to receive feedback and suggestions!

Components:

Each of the aforementioned components is implemented in a
class of its own:

- FormValidator:
   Implements the data validation as the name suggests. It
   uses Field instances that can be declared declaratively as
   it is possible with the old Form class. Furthermore it
   provides all methods of the old Form class that dealt with
   data validation, i.e. clean*(), is_valid(), errors(), etc.


Agreed.


- DataProvider:
   Implements the "parsing and providing data" component. It
   has only one method "get_value(name)" that must be
   overwritten by subclasses and returns the data for a given
   field name.


So that would be a "get_field_value"?


   HtmlFormProvider is a subclass of DataProvider that
   provides the parsing of HTTP form content by using Widget
   objects and their "value_from_datadict()" method in
   particular. The widgets of a HtmlFormProvider can be
   specified declaratively just like the fields of a
   FormValidator.



- HtmlForm:
   Implements the "displaying values as HTML input fields"
   component. Same as HtmlFormProvider it uses Widget objects
   and their "render()" method in particular. It also
   features all methods of the old Form class that were used
   mainly in templates, like __iter__(), __getitem__(),
   __str__(), as_p(), etc.



   Furthermore it fetches its data from a given
   HtmlFormProvider instance and provides handling of error
   messages with a FormValidator instance. It is also
   possible to decouple HtmlForm and HtmlFormProvider such
   that HtmlForm works with

Re: Should tutorial start with minimal Django?

2016-03-01 Thread Curtis Maloney

When we were teaching MelbDjango, I did start by writing views in the 
root urls.py  this avoided students having to create a bunch of 
files and apps and references and imports and...


For some of the students transitioning from PHP, it was much easier to 
deal with only learning one thing at a time...


However, we didn't go quite so far as that example... still using 
"startproject" etc.


--
Curtis

On 02/03/16 12:03, Bobby Mozumder wrote:

Hi,

Here’s an example of minimal Django, where one can output run an full site from 
a single file:
  https://github.com/rnevius/minimal-django

The author made the comparison to Flask.

I believe the tutorial should start out with this, as the initial Part 0, to 
introduce the audience to the framework, before introducing 
apps/models/subdirectories/etc.  I think a lot of people are turned off by the 
heavy-handed immediate introduction of many files and directories of a Django 
setup - I know I was when I first started with Django.

Anyways just putting this out there.

-bobby



--
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/56D63CBD.1070501%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Add warning or prohibit module level queries?

2016-02-25 Thread Curtis Maloney

At the very least we need to provide better feedback or errors to help
isolate _where_ this is happening.

I've helped quite a number of people on IRC with this problem...
firstly, people aren't understanding _what_ the problem is, but also
discerning where it's happening is often quite difficult, even with a
full traceback.

--
C

On 26/02/16 04:29, Tim Graham wrote:

Simon proposed [0]: "I wonder if we should prevent django.db from
executing queries until django.apps.apps.ready or at least issue a
RuntimeWarning. We would have to go through deprecation but I'm pretty
sure this would uncover a lot of existing application bugs and prevent
future ones. This is related to #25454
[1] and probably a large
number of closed tickets."

We have this restriction in some places, for example: "Executing
database queries with the ORM at import time in models modules will also
trigger this exception. The ORM cannot function properly until all
models are available."

We also have a warning about using the ORM in AppConfig.ready():
"Although you can access model classes as described above, avoid
interacting with the database in your |ready()| implementation. This
includes model methods that execute queries (|save()|, |delete()|,
manager methods etc.), and also raw SQL queries via
|django.db.connection|. Your |ready()| method will run during startup of
every management command. For example, even though the test database
configuration is separate from the production settings, |manage.py test|
would still execute some queries against your *production* database!"

There's also a warning in the testing docs: "Finding data from your
production database when running tests? If your code attempts to access
the database when its modules are compiled, this will occur /before/ the
test database is set up, with potentially unexpected results. For
example, if you have a database query in module-level code and a real
database exists, production data could pollute your tests. /It is a bad
idea to have such import-time database queries in your code/ anyway -
rewrite your code so that it doesn’t do this. This also applies to
customized implementations of |ready()|."

What do you think? Prohibiting such queries might be too strict at this
point as I guess some users might rely on them. I suppose warnings could
be selectively silenced as/if needed. We could start with a warning and
ask users to let us know if they believe they have a legitimate usage.
If we don't hear anything, we could proceed with the deprecation.

Related tickets:

[0] https://code.djangoproject.com/ticket/26273
[1] https://code.djangoproject.com/ticket/25454

--
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/7f41ba58-09ed-4f78-b5ce-be6d7d5a6fc7%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/56CF8327.6080202%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

2016-02-11 Thread Curtis Maloney

On 11/02/16 20:11, Andy Baker wrote:

 > As customisable as it can be, I find the problem to be it is
a data-centric view of your system, closely tied to the database models.

You're correct that a truly 'task-centric' UI would be a lot of effort -
but really - how common are such interfaces in their fullest sense? In
reality nearly every admin UI is a fairly clear mirror of the underlying
data schema. Show me a web app and I've got a fairly good chance of
predicting the db tables.

I think this is a matter of scale... for many small to medium scale 
apps, you can run close to the schema.  But for some of the large 
projects I've worked on, we really needed to hide a lot of complexity 
from the users.

I suspect that what is much more common is the ability to have
'cross-cutting concerns' - i.e. actions that involved and orchestrate
changes over multiple tables. There are many places that you can enable
such things without needing to twist the admin too far out of shape:
usertools, admin actions, custom changelist columns etc etc.

I absolutely agree with this.  Again, for the cases where admin fits, it 
works well.  But going beyond that, there's not a lot of clarity in how 
to fit in with it.

I'm not claiming any of this results in the 'perfect ui' and given the
budget - yes - a ground-up custom admin would probably be superior. But
real-life projects are nearly always budget constrained - especially
away from the public-facing side - and quite frankly - the Django admin
has enabled me to complete projects that would have been financially
impossible to develop without it.

Unfortunately, what I've seen time and again is when people finally hit 
the wall in admin customisation, they're too invested in admin to go any 
other path.  So I always advise caution in this - make sure people go in 
with "eyes open".

 > Is it possible to add other views to admin?  Sure... though it's
not clear, or well documented.

I would argue that it's also fairly clear as it's mostly "just django".
At its simplest an admin view is just a Django view that uses the admin
base template. What's unclear about that? How to incorporate linkage
between the admin-proper and custom views is fairly simple but maybe not
immediately obvious to a beginner. The various hooks for this are fairly
well documented although the documentation is scattered through various
places on this rather monolithic
page: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/

Well, part of the problem is, I believe, that admin is structured very 
differently to almost every other part of Django.  It follows that has 
been called a "publisher" pattern, where all related views, etc, for a 
given resource are provided in a single class (more or less).

This monolithic nature is quite different to the "collection of views in 
a module" approach used elsewhere.

I'm not saying this is wrong, but it does mean you have to learn a whole 
new approach in order to work with it on anything beyond a superficial 
level.

A single 'common ways to customize the admin' page could go a long way
to helping here.

+1

--
Curtis

--
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/56BD14D1.4020505%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django & django-polymorphic

2016-02-10 Thread Curtis Maloney




On 11/02/16 15:05, 'Hugo Osvaldo Barrera' via Django developers 
(Contributions to Django itself) wrote:

 > There was some research by Sebastian Vetter on "single-child
 > auto-resolve" solutions for MTI and how they scaled (from memory,
 > model-utils' InheritanceManager, polymorphic, and generic-m2m)
 > https://github.com/elbaschid/mti-lightbulb



Django already uses MTI. The only difference I'm proposing is,
basically, making life simpler for those wanting to get all objects as
their native class, rather than parent class (while not affecting those
that don't use them).


I know Django uses MTI.  This thread is, after all, talking about a tool 
for a _specific_ use case of MTI.


This investigation was specifically comparing the _scalability_ of 3 
solutions to the same problem.


The implementations differ as:

polymorphic:
- has a "hidden" content_type field to indicate which child model to 
link for this "parent" record

- uses prefetch_related to resolve
- results in 1+N queries

InheritanceManager (admin-tools):-
- uses select_related to grab _all_ the child models
- selects the first one that exists
- always results in 1 query
- can blow your DB server's brains out with the number of joins (if you 
have a couple of hundred child models).

- can select the "wrong" child if you somehow made two for the same parent

Generic M2M:
- quite a different solution, but could be used in the same way for 
Seb's purposes.

- don't recall specifics
- scaled dramatically better than the other two


--
C

--
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/56BC2770.1090707%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

2016-02-10 Thread Curtis Maloney




On 11/02/16 00:55, Andy Baker wrote:

I can't help but feel that the "admin is very rudimentary and hard to
customize" is perpetually overplayed by many in the community. Maybe I'm
suffering Stockholm Syndrome but I'd like to raise a dissenting voice.


I must admit I'm a large proponent of warning against getting caught up 
in "Admin as my management console".


As customisable as it can be, I find the problem to be it is a 
data-centric view of your system, closely tied to the database models.


IMHO a management interface for site should be a _process_ centric view, 
abstracting away the implementation details of tables and fields.


Perhaps a better way to think of it as the difference between a 
"management" and a "maintenance" interface.


True, in a lot of cases these can be the same thing, and for simpler 
sites Admin works "just fine".  However, I've been on too many projects 
that wind up spending a lot of time and effort customising Admin to do 
things that would have been simpler in a custom view.


Worse still, I've seen projects alter their schema design to accommodate 
Admin's limitations [like lack of nested inlines]


Is it possible to add other views to admin?  Sure... though it's not 
clear, or well documented.


Can documentation alone overcome this problem?  I'm not convinced it can.

For some years now I've been proposing an investigation into slicing 
Admin into two layers: a base "management interface framework" layer, 
and "admin" built atop this framework.


Then we can keep providing the Admin we all know and love, and also make 
it easier for people to build their own management interfaces.


However, I don't currently have the time [or admin familiarity] to 
undertake this work.


--
Curtis

--
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/56BBE4BB.3060805%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django & django-polymorphic

2016-02-10 Thread Curtis Maloney




On 11/02/16 09:22, 'Hugo Osvaldo Barrera' via Django developers 
(Contributions to Django itself) wrote:

Hi there,

I'd love to see some (most?) of the features from django-polymorphic on
django itself. I'm very much be willing to work on this myself. Of
course, there's several details that need to be discussed too, HOWEVER,
but before I even start, I'd like to know if they'd even be acceptable
in django, or, for some reason, the functionality has been kept out of
django-core.


As I recall it, the general approach here is:  is there a reason this 
can't live as a 3rd party app?


Would it benefit significantly by being more deeply integrated into 
core, and if so, does it bring sufficient benefit to users to warrant 
the changes?


There was some research by Sebastian Vetter on "single-child 
auto-resolve" solutions for MTI and how they scaled (from memory, 
model-utils' InheritanceManager, polymorphic, and generic-m2m) 
https://github.com/elbaschid/mti-lightbulb


--
Curtis

--
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/56BBE052.8000205%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Admin hstore widget

2016-02-07 Thread Curtis Maloney


So, I've been working on https://code.djangoproject.com/ticket/25197

I have it as part of my own project, with a view to contributing to core 
once it's polished.


Currently it has basic functionality - a JS widget that fires on load, 
hides the textarea, and produces a table of (name, value, actions).


It records original values for existing keys, so you can "undo" your 
changes.  And I'm just adding detection of duplicate keys.


I also hope to add a "soft delete" so you can mark a key for deletion, 
instead of immediately discarding it...


However, I've run into two problems:

1. I'd like more input on the features people feel are essential.

2. Is there a guide somewhere to styles and markup to be used in admin 
templates?


3. I plan to pull in another icon from FA, but it appears the one we 
currently use for "inline delete" is customised from the original.  Does 
anyone know who made these changes and how?


--
Curtis

--
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/56B7CF18.9010007%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

2016-02-06 Thread Curtis Maloney

I kept meaning to weigh in on this... but all my points have been made.

It sounds like the middle ground is to:

1) remove them from the default list
2) keep them in the codebase
3) make them noisy (raise warnings)
4) provide docs/tools on how to upgrade

Then we get "secure by default" (1), as well as "encouraging upgrades"
(3), whilst also "supporting slow-to-update installs" (4), and
"encouraging best practices" (3).

--
C

On 06/02/16 19:51, Aymeric Augustin wrote:

Yes, that would be good from the “security by default” standpoint. This
would also allow us to trim the full list of hashers which is repeated
several times in the docs.

--
Aymeric.

On 6 févr. 2016, at 00:03, Tim Graham > wrote:

I would guess most users aren't customizing the default list of
hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS
setting and let anyone who needs to use a weak hasher define their own
setting (at which point a warning probably isn't needed). Does that
seem okay?

On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin wrote:

Adding a check for weak password hashers could be a good
compromise to drive attention to the issue but make it reasonably
easy to ignore it if you need MD5 for compatibility with other
systems.

--
Aymeric.

On 5 févr. 2016, at 21:11, Sergei Maertens wrote:

This is my main concern as well. I often migrate old Joomla or
other PHP things that use md5, and it's really convenient that
Django upgrades the passwords for free for me.

Although I guess I could just write the hasher as part of the
project and add it to the setting, but then that's an additional
burding because you need to keep track of potential new hashers
that get added in the default settings.

On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:

Will I still be able to implement unsalted hasher if I so desire?

Don't get me wrong, I understand thats pretty crappy way to
store password, but there are times when you inherit large
set of data from site that you are moving from some old PHP
contraption that happens to be around since 2006, is big
(>100 users), ran by company that dominates one of
nation's markets and says "absolutely no" on making all those
housewifes reset passwords, and your passwords happen to use
md5(md5(pass) + md5(pass)) for passwords?

https://groups.google.com/d/msgid/django-developers/56677162-c020-4c2f-8d1f-b35ec0b9874d%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/9e184cd6-69cc-4fe8-835e-055bc7121ac9%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/5081977A-64B0-4443-ADDE-CEFCC5704E72%40polytechnique.org

Re: Deprecate Cache.has_key()?

2016-01-29 Thread Curtis Maloney

Isn't this so it complies with the dict interface? True, it's discouraged now, 
but it's still there.



On 30 January 2016 10:42:12 am LHDT, Tim Graham  wrote:
>Also the template BaseContext class has an undocumented has_key()
>method. I 
>wonder if that can be removed without a deprecation?
>
>https://github.com/django/django/pull/6066
>
>On Friday, January 29, 2016 at 6:11:54 PM UTC-5, Tim Graham wrote:
>>
>> Any opposition to deprecating Cache.has_key()? Cache already
>implements 
>> __contains__() so converting has_key() to "in" can be done with
>existing 
>> versions of Django. Anyone using flake8 will get a warning about
>has_key() 
>> usage: W601 .has_key() is deprecated, use 'in'.
>>
>
>-- 
>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/afbb78c6-3288-4544-b934-26b48acd9192%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/4018585A-9B06-4796-9D10-31EF6CDDF633%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

2016-01-17 Thread Curtis Maloney

I should probably finish off my toy working on the same lines... but 
introducing my earlier comments about per-source paths and permissions 
mixins...


Very much a WIP, but I'm sure you'll see the idea:

https://gist.github.com/funkybob/a89c10e24716a4ce55cf

--
C

On 18/01/16 09:58, Gordon wrote:

I put together a simple django middleware based off the functionality of
whitenoise except that it uses the staticfiles storage for
finding/serving files.  I am sure there are lots of improvements to be
made on it but it demonstrates using the filestorage api to accommodate
remote static files.  It is roughly 100 lines.
https://gist.github.com/thenewguy/a92e05a3568fb6f1cc7c

On Saturday, January 16, 2016 at 6:11:46 PM UTC-5, Gordon wrote:

Apologies if this has already been mentioned but I read this thread
in full awhile ago and now everything is collapsed.

If staticfiles serving is brought into django proper it would be
nice if the storage api was used so that staticfiles can be stored
remotely.  I just ran into this looking at whitenoise so I figured I
would mention it here to be taken into consideration when putting an
implementation together.

On Friday, January 8, 2016 at 12:11:12 PM UTC-5, David Evans wrote:

I've just pushed a simple middleware wrapper that lets you
install WhiteNoise by adding:

MIDDLEWARE_CLASSES = (
...
 'whitenoise.middleware.StaticFilesMiddleware',
...
)


See:

https://github.com/evansd/whitenoise/blob/master/whitenoise/middleware.py



No messing with wsgi.py!

This approach will be marginally less efficient than handling
things at the WSGI layer, but the integration is much cleaner.

On Tuesday, 29 December 2015 17:31:02 UTC, David Evans wrote:

I'd be very happy to help with this. Two things to mention:

1. When I first wrote WhiteNoise the FileResponse class
didn't exist and so the only way I could access
`wsgi.file_wrapper` was by wrapping the wsgi application
directly and bypassing Django. Now we have the FileResponse
class it would be possible to implement WhiteNoise as
standard Django middleware without having to edit wsgi.py. I
think this would be a much cleaner approach, and I don't
think it will be too much work to implement. I should have
time to look at this next week.

2. Serving media files is a slightly different case.
WhiteNoise was designed around the assumption that it's
serving a set of developer-supplied, public files which
remain unchanged during the lifetime of the process. This
simplifies a lot of performance and security concerns that
come with serving mutable, user-supplied files. At present,
if you use `add_files(settings.MEDIA_ROOT,
prefix=settings.MEDIA_URL)` as you suggested then WhiteNoise
won't pick up any files that were uploaded after the
application was started -- at least, not unless you enable
the "autorefresh" setting which I explicitly don't recommend
for production.

Obviously it's possible to support this if we decide this is
an important goal but it will need more thought and will
definitely be more work than just supporting static files.

On Tuesday, 29 December 2015 00:36:06 UTC, Tim Graham wrote:

I'd like to work together with Dave to develop a proof
of concept that integrates whitenoise into Django. I
spent about an hour looking through whitenoise and our
own static file serving code, and I think integrating
whitenoise will yield a simpler user experience with
about the same amount of code as have now.

Essentially, we'd recommend adding something like this
to existing wsgi.py files (it would be in the default
startproject template)

from whitenoise.django import DjangoWhiteNoise
application = DjangoWhiteNoise(application)
application.add_files(settings.MEDIA_ROOT,
prefix=settings.MEDIA_URL)

which would have the benefit of working out of the box
in production too, I think. Of course, you could disable
that based on settings.DEBUG or some other toggle.

We could then deprecate:

* django/contrib/staticfiles/views.py
*
django/contrib/staticfiles/management/commands/runserver.py
* django/contrib/staticfiles/handlers.py
*

Re: Vote on Jira as bugtracker

2016-01-08 Thread Curtis Maloney


On 09/01/16 13:08, Hugo Osvaldo Barrera wrote:

Not an actual django developer (I'm a user lurking here really), but I'd
still like to chime in:


Doesn't make your input any less valid... in fact, perhaps makes it more 
valuable :)



  * Jira is too complex. Devs may end up understanding it, but users
will have a harder time, especially since they won't be using it as much.


I agree here... having used it in projects in the past, I've found is 
bizarrely slow, and tedious.



  * Moving from a FLOSS tool to a proprietary solution really gives
mixed signals. It'd confuse me why a team who clearly appreciates
open-sourceness would make such a move with so many great alternatives
out there.


Absolutely agree here... but, could you mention some of these "great 
alternatives"?  Several others have espoused their position that "they 
all suck" [and I don't believe they're limiting that to just OSS ones :)]


I certainly believe it would be a coup if we could wind up with a Django 
based one... for obvious reasons.


--
Curtis

--
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/569094D3.3020400%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

group-by promotion

2016-01-08 Thread Curtis Maloney


Hey all,

I'm trying to write a PR for adding Postgres9.4's "FILTER" syntax for 
aggregates, but I've hit a bug I can't figure how to fix [and nobody's 
awake on IRC :)]


https://github.com/django/django/pull/5956

Basically, for the query:

qset = FilterAggParentModel.objects.annotate(
zero_count=FilterAgg(Count('filteraggtestmodel'), 
Q(filteraggtestmodel__integer_field=1)),

child_count=Count('filteraggtestmodel'),
)

It generates the SQL:

SELECT "postgres_tests_filteraggparentmodel"."id",
COUNT("postgres_tests_filteraggtestmodel"."id") FILTER(WHERE 
"postgres_tests_filteraggtestmodel"."integer_field" = 0) AS "zero_count",

COUNT("postgres_tests_filteraggtestmodel"."id") AS "child_count"
FROM "postgres_tests_filteraggparentmodel"
LEFT OUTER JOIN "postgres_tests_filteraggtestmodel" ON 
("postgres_tests_filteraggparentmodel"."id" = 
"postgres_tests_filteraggtestmodel"."parent_id")
GROUP BY "postgres_tests_filteraggparentmodel"."id", 
"postgres_tests_filteraggtestmodel"."integer_field"



The problem being that 
"postgres_tests_filteraggtestmodel"."integer_field" is included in the 
GROUP BY clause...


Does anyone who understands this part of the ORM have a suggestion for 
how to fix this?


--
Curtis

--
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/56909414.2020600%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

2016-01-08 Thread Curtis Maloney


In general, I love it.

It's MUCH simpler for people to write and comprehend... requires no 
classes [but IMHO the callable class is "cleaner"] and allows for 
configurable middlewares easily...


I do wonder, though... how the anti-import-strings factions will 
react... I'm sure it can, at least, support direct callables being in 
the MIDDLEWARE list, not just strings?


--
Curtis


On 08/01/16 13:50, Carl Meyer wrote:

Hi all,

Back at the Django Under the Hood sprints in November, Florian and I
started batting around some ideas for fixing some of the problems with
the existing middleware abstraction. Florian put together an initial
pull request with a POC for some of those ideas. I've now updated the
proposal (incorporating some implementation ideas from Pyramid's
middleware equivalent) and written it up in the form of a DEP. You can
find the DEP at

https://github.com/django/deps/blob/master/draft/0005-rethinking-middleware.rst

and I'm also pasting the full text below, to ease in-line commenting via
email.

Comments welcome!


DEP 0005: Re-thinking middleware


:DEP: 0005
:Author: Carl Meyer
:Implementation Team: Florian Apolloner
:Shepherd: Carl Meyer
:Status: Draft
:Type: Feature
:Created: 2016-01-07
:Last-Modified: 2016-01-07

.. contents:: Table of Contents
:depth: 3
:local:


Abstract


The existing Django "middleware" abstraction suffers from an absence of
strict layering and balanced in/out calls to a given middleware. This
DEP proposes an improved abstraction for wrapping the request cycle in
strictly layered pre-view and post-view actions.


Motivation
==

In theory, and per `the documentation`_, ``process_request`` will be
called for each incoming request, ``process_response`` will be called
for each outgoing response, and ``process_exception`` will be called in
case of an uncaught exception.

This description seems to imply the invariant that if
``process_request`` is called, either ``process_response`` or
``process_exception`` will later be called on that same middleware in
that same request cycle. Django itself has in the past included
middleware (the now-defunct ``TransactionMiddleware``) that implicitly
relied on this invariant.

In fact, due to the short-circuiting and exception-handling behavior of
various middleware methods, this invariant does not hold. It is possible
for a middleware to have its ``process_request`` method called, but then
never see its ``process_response`` or ``process_exception`` called for
that request (e.g. in case of an uncaught exception in a "later"
middleware method).

It is also possible for a middleware to never see its
``process_request`` method called for a given request (because an
earlier middleware's ``process_request`` returned a response), but still
have its ``process_response`` or ``process_exception`` method called on
that response.

This lack of strict in/out layering makes it impossible to safely
implement some types of middleware (such as ``TransactionMiddleware``),
and requires verbose defensive programming: e.g. even if
``process_request`` sets a certain attribute on the request,
``process_response`` on that same middleware can't assume that that
attribute will be present on the request it receives.

This is the primary problem that this DEP intends to solve.

.. _the documentation:
https://docs.djangoproject.com/en/stable/topics/http/middleware/


Acknowledgment
==

The proposed API in this DEP is modelled on Pyramid's `Tween`_ concept
(the author and implementor of this DEP developed a very similar idea
independently at a Django sprint before reading about Tweens).

.. _Tween:
http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/hooks.html#registering-tweens

Specification
=

This DEP introduces a new setting, ``MIDDLEWARE``, which contains an
ordered list of dotted paths to middleware factories.

A middleware factory can be written as a function that looks like this::

 def simple_middleware(get_response):
 # one-time configuration and initialization

 def middleware(request):
 # code to be executed for each request before
 # the view is called

 response = get_response(request)

 # code to be executed for each request/response after
 # the view is called

 return response

 return middleware

Or it can be written as a class with a ``__call__`` method, like this::

 class SimpleMiddleware(object):
 def __init__(self, get_response):
 self.get_response = get_response

 # one-time configuration and initialization

 def __call__(self, request):
 # code to be executed for each request before
 # the view is called

 response = self.get_response(request)

 # code to be executed for each request/response after
 # the view is

Re: delegating our static file serving

2016-01-01 Thread Curtis Maloney


On 01/01/16 15:49, Fabio Caritas Barrionuevo da Luz wrote:

A question: are there any plans to also improve MEDIA files (user
uploaded files) in any foreseeable future?

Perhaps this is outside the scope of Django, but I believe Django could
provide by default, any option to get a little more control over who can
and can not access the MEDIA files.


I certainly agree that at least some basic form of access control ought 
be provided in core/contrib.



Most Django deployment tutorials with Nginx and Apache that saw out
there do not say anything on the issue of data security.

I believe it is a common use case, that not every file sent by a User
should be available and accessible to anyone on the web.


I was talking with Tom Eastman about a related topic at PyConAU this 
year, and I believe the solution is multiple storage engines.


Basically, for each realm of access, have a separate file storage 
instance with its own access policy.


We could then register each storage engine we want published with the 
static/media server machinery, with its associated policy...


Hmm... I think I've just created myself a new project...

--
Curtis

--
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/56864707.5030007%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: A community Poll

2015-12-23 Thread Curtis Maloney

To clarify a few points:

In general, I'm in favour of removing string references for things... 
however, when it comes to relation fields, I'm on the side of "alway lazy".

Also, I don't want this discussion to be about my specific issue with 
contenttypes... more a general "community opinion of best practices"

--
Curtis

-- 
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/3505d049-ca72-411c-8657-4c2ff8b5c832%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling the ORM

2015-12-17 Thread Curtis Maloney


I've identified one new "issue".
There is an implicit assumption that primary keys are useful for
ordering by the current QuerySet API methods `.first()` and `.last()`.


I believe the case here is that first and last are meaningless without 
an ordering, so in lieu of any programmer supplied ordering, a 
"fallback" consistent ordering of 'pk' is used.


Remember the DBMS is under no obligation to return a query in consistent 
order without an ORDER BY clause.


So, without an ordering, two successive calls to first() [or last()] 
may, in fact, return different records even without modifications to the 
table.


It's not expected people should _rely_ on the ordering of PK, and, 
indeed, it's frequently recommended against inferring any meaning from 
PK values [sqlite, IIRC, assigns them pseudo-ramdomly]


That said, the assumption that a PK is sortable and will provide a 
deterministic ordering shouldn't be much to ask, surely?


--
Curtis

--
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/567353FA.6030105%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: MOSS Award to Django

2015-12-15 Thread Curtis Maloney


On 16/12/15 12:05, Ben Liyanage wrote:

And, beyond that, there are plenty of non-critical tasks that
applications could easily offload until after a response has been
sent - like saving things into a cache or thumbnailing
newly-uploaded images.

http://channels.readthedocs.org/en/latest/concepts.html#concepts

I mean this example sounds like celery to me.  You don't want an image
to maybe have a thumbnail generated.  And you have no return value to
the client when the thumbnail is generated.


There are certainly some cases, AIUI, where channels can obviate the 
need for Celery... like sending emails, or thumbnailing uploaded image, 
and so on.


However, given the different reliability profiles, there's still room 
for both.


--
Curtis

--
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/5670E575.9020106%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF middleware conflicts with request.upload_handlers

2015-11-19 Thread Curtis Maloney

Yeah... good name for it...

https://github.com/django/django/pull/5688

--
Curtis


On Tuesday, 17 November 2015 00:45:27 UTC+11, Collin Anderson wrote:
>
> Maybe @csrf_check_header_only? I usually put the token in POST for my ajax 
> calls.
>
> On Monday, November 16, 2015 at 12:51:18 AM UTC-5, Curtis Maloney wrote:
>>
>>
>> So I recently ran into the csrf/upload_handlers conflict as mentioned in 
>> the not 
>> https://docs.djangoproject.com/en/1.8/topics/http/file-uploads/#id1 
>>
>> I'd like to propose an additional option to solve this -- a decorator to 
>> mark a view as "ajax-only" ... so the CSRF middleware will _only_ check 
>> the header for the value, and skip request.POST. 
>>
>> Of course, this sort of change should involve a serious consideration to 
>> the security ramifications of such a change. 
>>
>> So please... weigh in, one and all :) 
>>
>> -- 
>> Curtis 
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a15f8d3d-6231-4a18-ac98-b76895bdb4a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CSRF middleware conflicts with request.upload_handlers

2015-11-15 Thread Curtis Maloney



So I recently ran into the csrf/upload_handlers conflict as mentioned in 
the not https://docs.djangoproject.com/en/1.8/topics/http/file-uploads/#id1


I'd like to propose an additional option to solve this -- a decorator to 
mark a view as "ajax-only" ... so the CSRF middleware will _only_ check 
the header for the value, and skip request.POST.


Of course, this sort of change should involve a serious consideration to 
the security ramifications of such a change.


So please... weigh in, one and all :)

--
Curtis

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56496EC3.8040301%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecating old keyword syntax in DTL

2015-08-08 Thread Curtis Maloney

For reference, the old PR is here 
: https://github.com/django/django/pull/1619/files

Unfortunately, it doesn't rebase cleanly onto master... some very odd stuff 
shows up... but it wouldn't take much to regenerate this work.

--
Curtis

On Saturday, 8 August 2015 21:33:22 UTC+10, Curtis Maloney wrote:
>
> Long ago, the keyword syntax in Django templates was: 
>
>expr as name 
>
> but was changed to look more like Python as: 
>
> name=expr 
>
> However, the facility to parse the old syntax is still there, but will 
> silently fail unless you pass "support_legacy" to token_kwargs. 
>
> In fact, it is enabled for "with" and "blocktrans" only. 
>
> I'm proposing we deprecate this syntax to help clean up this code path 
> and have only one way to do it. 
>
> This would start with adding a deprecation warning for when 
> support_legacy=True _and_ we match a "x as y" syntax argument. 
>
> After a version [or two?] with this, we can remove the code.  I wrote 
> a patch for this some moons ago, but it was rejected for having no 
> deprecation path. 
>
> -- 
> Curtis 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1146799b-e468-4bbe-91d8-e71a44972ced%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Deprecating old keyword syntax in DTL

2015-08-08 Thread Curtis Maloney

Long ago, the keyword syntax in Django templates was:

   expr as name

but was changed to look more like Python as:

name=expr

However, the facility to parse the old syntax is still there, but will
silently fail unless you pass "support_legacy" to token_kwargs.

In fact, it is enabled for "with" and "blocktrans" only.

I'm proposing we deprecate this syntax to help clean up this code path
and have only one way to do it.

This would start with adding a deprecation warning for when
support_legacy=True _and_ we match a "x as y" syntax argument.

After a version [or two?] with this, we can remove the code.  I wrote
a patch for this some moons ago, but it was rejected for having no
deprecation path.

--
Curtis

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSC3RUo%3D-eno9-%2BT5W1ASD33e4j6XjoMrZz15RFo%3DgMO-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #25236: Remove ifequal from the template language

2015-08-06 Thread Curtis Maloney

I'd probably go with updating the documentation to say they're legacy
tags, you're better off using {% if %} now, and warn they may be
removed in a later release.

This way (a) people are warned off it, and (b) we're confusing people
who find it and want to check what it does [even though it's quite
clear from the name]

--
Curtis


On 7 August 2015 at 13:05, Josh Smeaton  wrote:
> Fair enough, I don't necessarily disagree with you. Would removing the
> documentation for ifequal be OK? At least that would prevent new projects
> from using it or being confused about multiple ways to compare values.
>
> On Friday, 7 August 2015 12:49:37 UTC+10, Karen Tracey wrote:
>>
>> We certainly weren't discussing removing without deprecating, were we? I'm
>> saying removing isn't worth the hassle to users, period. My opinion from
>> working on a fair number of inherited sites, plus sites where I don't get to
>> choose who contributes code I'm responsible for maintaining. I've reported I
>> have code I have to maintain written last year that uses these tags, it's
>> not just ancient crufty old stuff. These tags don't cause a massive "brain
>> stop" to figure out what "ifequal" might mean when encountering them in
>> existing templates.They are not that bad. This wart isn't worth the pain to
>> users to remove, in my opinion. Finding and fixing all templates used by a
>> site is NOT trivial. Fixing url was worth it. This is not.
>>
>>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/44ee5d1f-1071-4dd7-a1dd-fe798c0dc2de%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSBPO35aTAemeP2%2BtFs2v-dacUHR3NiYoOFC8%3D4sYmgXhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #25236: Remove ifequal from the template language

2015-08-06 Thread Curtis Maloney

Given the [currently] low burden, I agree with a more gradual
deprecation... document against their use to help encourage people to
move away from them, then we're in a better position to more
painlessly remove them in the future.

--
Curtis

On 7 August 2015 at 11:43, Karen Tracey  wrote:
> Believe me I understand what technical debt is. In my opinion the cost of
> this debt in Django is not sufficient to warrant the cost to users of Django
> to remove it. Find and fix (or figure out if it's necessary to fix) all
> templates (some of which may be coming from 3rd party packages)  used in a
> site is not that trivial of a task for a large site with many 3rd party
> dependencies. By contrast documenting why these two tags exist is pretty
> painless.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CACS9rafSuot0xati8HLOe2QEV7QpNny7d4bZDnVGzwsiAgDP7A%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCwn53hms4SBCR5bLyAf-Cwnqk1jgcOwmv-FNPSoR2R1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

2015-08-06 Thread Curtis Maloney

Just my $0.02...  I quite like the idea of adding update_instance and
commit, with save calling both...

To me, this provides a clean and obvious place to customise updating
the instance before saving... as well as a clear place to get an
updated instance without saving.

--
Curtis


On 7 August 2015 at 10:14, Tim Graham  wrote:
> That sounds like a more promising proposal in my mind.
>
> So in a view instead of:
>
> if form.is_valid():
>obj = form.save(commit=False)
>obj.author = request.user
>obj.save()
>form.save_m2m()
>
> it might look like:
>
> if form.is_valid():
>form.instance.author = request.user
>form.save()
>
> I'm not sure if this will work (or result in simpler code) for model
> formsets though as there is the interaction with deleted formsets to
> consider.
>
>
> On Thursday, August 6, 2015 at 7:41:54 PM UTC-4, Javier Candeira wrote:
>>
>> Hi, Tim,
>>
>> Thanks for taking the time to address my ticket and patch.
>>
>> At this point I'm aware that I might be doing this just to practice
>> writing well-formed contributions to Django. At the very least I'll have
>> learnt a lot about how Django works on the inside, both the code and the
>> project.
>>
>> However, other developers have agreed with me that the save(commit=False)
>> is an antipattern. My goal is to remove that from tutorials, not to add a
>> get_updated_model() method. This was only a means to an end.
>>
>> For that reason I still think it's worth for me to have one more go at the
>> problem, and see if I can propose a different solution.
>>
>>> If we reevaluate as to whether super().save(commit=False) is needed at
>>> all, I think the forms.errors check isn't of much value (you will only hit
>>> that if you have in error in your code where you forgot to call is_valid())
>>> and save_m2m() could possibly be regular method that doesn't need to be
>>> conditionally added. But really, I don't think the current situation is so
>>> bad that we need to churn this. It doesn't seem feasible for the commit
>>> keyword to be deprecated, so now we would two ways of doing something.
>>
>>
>> In that case, a possible approach could be to turn `save(commit=False)`
>> into a does-nothing path, and suggest that the new way of doing things is:
>>
>> class ThingForm(ModelForm):
>> def save(self, commit=True):
>> self.instance.author = request.user
>> if commit:
>> super(ThingForm, self).save()
>>
>> As a first step to eventually deprecating commit, since it doesn't do
>> anything useful except return the instance, and suggest that the recommended
>> idiom is:
>>
>> class ThingForm(ModelForm):
>> def save(self):
>> self.instance.author = request.user
>> super(ThingForm, self).save()
>>
>> Cheers,
>>
>> Javier
>>
>>>
>>>
>>> On Thursday, August 6, 2015 at 6:51:23 PM UTC-4, Javier Candeira wrote:

 On Friday, 7 August 2015 08:38:33 UTC+10, Tim Graham wrote:
>
> I took a look at the code, found a bug, and proposed some
> simplifications in https://github.com/django/django/pull/5111


 Thanks, will check.

> The simplifications help make it clearer what get_updated_model() would
> do in the usual case:
> 1. Throw an error if the form has any errors: "The model could not be
> changed because the data didn't validate."
> 2. Adds a save_m2m() method to the form.
>
> It doesn't actually update the instance at all, so I guess the proposal
> is a bit misleading (unless I missed something).


 Yeah, I thought it did, but what it changes is the form (adding the
 save_m2m method). Maybe change name to get_model()?

>
> p.s. You can give your code a "self-review" with the patch review
> checklist:
> https://docs.djangoproject.com/en/1.8/internals/contributing/writing-code/submitting-patches/#patch-review-checklist


 Thanks. I've noticed that github tells me my code doesn't pass flake8
 either. I've recently changed to Spacemacs and couldn't get flake to work
 with it yesterday. I'll try before I update the PR/Ticket and write here
 again.

 Cheers,

 Javier

>
>
>
> On Thursday, August 6, 2015 at 6:09:54 PM UTC-4, Javier Candeira wrote:
>>
>> On Friday, 7 August 2015 07:19:01 UTC+10, Marc Tamlyn wrote:
>>>
>>> I agree that this is an anitpattern. I'm not fond of
>>> `get_updated_instance()` as a name, I'm not sure what the correct 
>>> option is
>>> here. Arguably we should split save() into two parts -
>>> ModelForm.update_instance() and ModelForm.commit(). ModelForm.save() 
>>> simply
>>> calls these two functions, with the latter only if commit=True.
>>
>>
>> get_updated_instance(form, instance, *args) is the module-level
>> function, parallell to save_instance(form, instance, *args). The exposed
>> method I suggest is

Re: Ticket #25236: Remove ifequal from the template language

2015-08-06 Thread Curtis Maloney

Let me open by saying I am in no way averse to the removal of these
two tags... and this reminds me I need to also re-work my "remove the
'x as y' argument syntax" patch again...

On 7 August 2015 at 07:08, Marc Tamlyn  wrote:
> However, as with all technical debt, it has a cost. It's additional code,
> tests, documentation to maintain, low as the burden is. There is now "more
> than one way to do it" - when as a new developer who has learned {% if x ==
> y %} I then stumbles across {% ifequal x y %}, which is better? Does it
> matter? Is one more efficient?

As a small point, and I have met people for whom it was beneficial,
ifequal/ifnotequal _are_ more efficient than smart-if... it's a tiny
margin, but they are, and inside an inner loop, it can make quite a
difference.

I'm not advocating we keep them, just putting the info out there.

Personally, I'll just add another yak to my quiver of optimising if
... perhaps putting my AST skills to good use :)

--
C

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSA0fp2GeQ1-rf2NtxW8gQ1GYJ52mwT%3D_1pZwhdWnZ-_vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Speedy Mail 2.0 - a new webmail platform in Python and Django

2015-07-21 Thread Curtis Maloney

Guess I should sign up on django-users so I can throw my hat in for
this... I've yearned for a Python-based webmail that has a featureful
UI :)

So far there's only Modoboa, excellent as it is.  Competition is healthy, so...

--
Curtis


On 22 July 2015 at 05:20, Shai Berger  wrote:
> Hi Uri,
>
> On Tuesday 21 July 2015 21:05:03 Uri Even-Chen wrote:
>> To Django developers,
>>
>
> This list is for discussions about the development *of* Django. For issues of
> development *with* Django, please write to django-users.
>
> Thanks,
> Shai.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSA-3dxHi5hRm6t1eFUjQuVKJ8AdXL5Xx6uOp6eCFbiR%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for UNLOGGED tables in PostgreSQL

2015-07-19 Thread Curtis Maloney

I second what Aymeric say rather than take on the burden of
maintaining correct warnings, let's point at the people whose
responsibility it really is :)

--
Curtis

On 20 July 2015 at 06:44, Aymeric Augustin
 wrote:
> I agree with pointing to the relevant section of the PostgreSQL 
> documentation. It will always be more complete, accurate and up-to-date that 
> what we could write.
>
> --
> Aymeric.
>
>
>
>> On 19 juil. 2015, at 19:43, Christophe Pettus  wrote:
>>
>> This can be achieved by pointing to the relevant section in the PostgreSQL 
>> documentation with a general "Test execution may be sped up by adjusting the 
>> data integrity parameters in PostgreSQL; be sure to read the appropriate 
>> warnings before making any changes" warning.
>>
>> Putting actual recommended settings in the Django documentation seems, at a 
>> minimum, pointlessly duplicative, and ties the Django documentation to the 
>> current state of the world in PostgreSQL gratuitously.
>>
>>
>> On Jul 19, 2015, at 10:32 AM, Luke Plant  wrote:
>>
>>> I agree with Federico on this - as long as we slap a big warning on it — 
>>> "This is dangerous - it could make your database more likely to lose data 
>>> or become corrupted, only use on a development machine where you can 
>>> restore the entire contents of all databases in the cluster easily" — I 
>>> don't see a problem in this being in our docs.
>>>
>>> If people refuse to read a clear warning, they shouldn't be doing web 
>>> development. They are just as likely to find similar instructions on the 
>>> internet, but without warnings, and having it in our docs with the warning 
>>> will be helpful.
>>>
>>> Having a fast test suite is such an important part of development that it 
>>> shouldn't be held back by  attempting to protect the world from people who 
>>> cannot be helped.
>>>
>>> Luke
>>>
>>> On 16/07/15 16:49, Christophe Pettus wrote:
 On Jul 16, 2015, at 1:16 AM, Federico Capoano 
 wrote:


> I also don't like the idea of believing django users are too stupid to
> understand that this advice si valid for development only. Generally
> python and django users are intelligent enough to properly read the
> docs and understand what's written on it.
>
 It's not a matter of being "intelligent" or not.  Developers are busy and 
 can simply google things, see a particular line, and drop it in without 
 fully understanding exactly what is going on.  (Simply read this group for 
 a while if you don't believe this to be the case!)  People already turn 
 off fsync, in production, after having read the PostgreSQL documentation, 
 without actually realizing that they've put their database in danger.

 Among other things, developers often have local data in their PostgreSQL 
 instance that is valuable, and advising them to do a setting that runs the 
 risk of them losing that data seems like a bad idea.

 The Django documentation is not the place to go into the ramifications of 
 fsync (or even synchronous_commit, although that's significantly less 
 risky).

 --
 -- Christophe Pettus

 x...@thebuild.com



>>>
>>> --
>>> "I was sad because I had no shoes, until I met a man who had no
>>> feet. So I said, "Got any shoes you're not using?"  (Steven Wright)
>>>
>>> Luke Plant ||
>>> http://lukeplant.me.uk/
>>>
>>> --
>>> 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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/55ABDF21.9060106%40cantab.net.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> -- Christophe Pettus
>>   x...@thebuild.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To 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/648BE2F3-E869-4E9D-BCB9-248E425D5A1C%40thebuild.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

Re: Support for UNLOGGED tables in PostgreSQL

2015-07-15 Thread Curtis Maloney

On 16 July 2015 at 05:01, Shai Berger  wrote:
> This is a shot in the dark: Could it be that rolling back transactions
> involving unlogged tables is harder? The idea does make sense, and running the
> test suite does an extremely untypical amount of rollbacks.

I thought at some point I read that unlogged tables didn't support
transactions... however, the docs don't agree.

I was also considering going to the PG people and asking if the
UNLOGGED docs needed review... there could be all manner of reasons
why, on modern hardware, going via the WAL is as fast now...

--
C

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCcZ%3Df-919dSdOif0ZVMT6fma5yE3xy20%2Bw7E04y2E3kQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: deprecate and remove egg template loader

2015-07-13 Thread Curtis Maloney

so _that's_ why I've been adding zip_safe=False to all my setups for
years :P

+1 to encouraging the world to move forward :)

--
Curtis

On 14 July 2015 at 10:40, Russell Keith-Magee  wrote:
>
> On Mon, Jul 13, 2015 at 11:00 PM, Donald Stufft  wrote:
>>
>> I’m fine with this, but just be warned that it does mean anything
>> that ships a Django app will need a zip_unsafe=True or else they
>> no longer support being installed with easy_install.
>
>
> ... and I'm sure both the people who still use easy_install will be
> devastated by this. :-)
>
> Seriously - is easy_install compatibility really a thing these days? Unless
> someone can mount a case that eggs and easy_install are actively being used
> in some segment of the Django community, +1 to this.
>
> Yours,
> Russ Magee %-)
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq848%2BPAmrhV7_5E2VvR%2BNAh6KgkpeqYq1JyqsSZd84S%3DwjQ%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCT%3DgA4POONnrEhzuD%3Ddcvqtb1LEj95XUOmAs2LQjZ_DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allauth user fields and userProfile fields save in one registrationform

2015-07-08 Thread Curtis Maloney

This is a list for discussion of the development _of_ Django, not
development _with_ Django.

This question is better suited to the django-users list.

In general, if you need to edit two models in one form submission, you use
two ModelForms... I have a blog post on this topic:
http://musings.tinbrain.net/blog/2015/jun/10/updating-two-models-single-post/

--
Curtis


On 8 July 2015 at 02:08, Marco Neumann  wrote:

> Hi All
>
> Can someone point me in the right direction.
>
> On registration I would like to fill in the UserFields(Username-password
> etc) and the ProfileFields (City, phonenumber etc)  and save theme both in
> the models User and UserProfile
>
> Need i to expaned the sigupform or put two form on one page and then save?
> (Hoe is this working?)
>
> has somebody a example i can look at?
>
> Thanks in advanced.
>
> Marco Neumann
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f653afbf-dcac-4ffa-b716-cab7d02e61fe%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAw2fM07xwT9f0toka0d%3DB8iQUp5rYqTcuG-oKDCr7Mbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django urls and Angular ui-router

2015-07-01 Thread Curtis Maloney

This question really belongs on django-users ... this list is for
discussion about the development _of_ Django, not _with_ django.

That said, it's quite specific in Django that URLs do not map to Templates
- they map to View functions.  So, depending on your case you should easily
be able to have one url pattern [with arguments] map to a single view that
can serve a multitude of templates, based on the arguments.

--
Curtis


On 1 July 2015 at 18:00, ABEL D  wrote:

> Hi,
>
> I am front end developer in django & angularjs app.  For each templates
> and partials do i need to define its urls or is there a way to get files
> from server withour defining the template's url. Without defining its
> giving 404 error.  It is a pretty big app. So there are lots of templates
> and partials do i need to define each one of them in django url?
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/377bc0ea-6191-408d-8781-48066309b252%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDkLN6%3DnkLDJBAFK%2BPJkyiKdakMTB2WNEO5oQTr42iWpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

2015-06-09 Thread Curtis Maloney

This sounds a bit like combining django-sniplates with django-amn, and
going a bit further...

Fragments of templates, list of JS/CSS dependencies, and a way to collect
it all together and ensure your page has everything  you need...

Sounds interesting to me... I'd be happy to collaborate on it with you...
once we see where it goes, and compare it with the existing implementation,
people will have more food for thought :)

--
Curtis


On 31 May 2015 at 02:52, Emil Stenström  wrote:

> Hi,
>
> This is the first feature proposal as part of my general drive for getting
> Django to work better for javascript heavy sites.
>
> Template Components
> ---
>
> React.js popularized the notion that in front-end development, code
> organization should be based on interface components, not split up into
> HTML, Javascript and CSS. Here's the original presentation and the
> rationale behind organizing around components:
> https://www.youtube.com/watch?v=x7cQ3mrcKaY=2m7s
>
> In Django, adding a Javascript calendar to you site requires changes to
> four different locations in your project:
>
> - /app/templatetags/calendar_tags.py <- A custom inclusion template tag
> - /app/templates/calendar.html <- Some HTML in the template dir
> - /static/css/style.css <- Add some CSS to style.css
> - /static/js/script.js <- Add some JS to scipt.js
>
> There is no connection within Django between HTML and the CSS + JS. Django
> does not help you, or even suggest a structure for you, like it does with
> all Python code.
>
> On the other hand, we have Form Assets:
> https://docs.djangoproject.com/en/1.8/topics/forms/media/
>
> Example:
>
> from django import forms
> class CalendarWidget(forms.TextInput):
> class Media:
> css = {'all': ('calendar.css',)}
> js = ('calendar.js',)
>
>  w = CalendarWidget()
 print(w.media)

>>> 
> 
>
> ... which define a kind of component, but one that is tied to a form
> field. My suggestion is a new package: django.template.component, that
> builds on the Media class from Form Assets, and allows you to define your
> components like this:
>
> from django.template import component
> class Calendar(component.Component):
> def context(self, date):
> return {"date": date}
> class Media:
> template = "app/components/calendar/calendar.html"
> css = {'all': ('app/components/calendar/calendar.css',)}
> js = ('app/components/calendar/calendar.js',)
>
> component.register(name="calendar", component=Calendar)
>
> ... and later in your template:
>
> {% load components %}
> {% block extra_media %}{% component_dependencies %}{% endblock %}
> {% block main %}
> {% component "calendar" date=custom_date %}
> {% endblock %}
>
> ---
>
> Advantages:
> - You to keep the python, html, css, and javascript in one location, and
> explicitly define the dependencies between them.
> - All  and

Re: Using `SECRET_KEY` in password hashers

2015-06-09 Thread Curtis Maloney

So, the benefit of your case is it's one more step for an attacker if they
want to brute-force your password database -- that they _also_ need to
steal your PASSWORD_SECRET.

The downside is, in the very case where they _do_ steal it, you must
immediately invalidate every password by changing your PASSWORD_SECRET.
Which at least gives you a simple knob for doing just that, but may not be
desirable.

IIRC you should be able to easily implement this as a custom password
hasher...

--
C


On 9 June 2015 at 16:01, Ram Rachum <r...@rachum.com> wrote:

> If the leak happened because someone got into your code repo, you're
> right. (I can't rule out a scenario where someone got your SECRET_KEY with
> some other method, like analyzing data that was generated with the secret
> key.)
>
> But even if there's a leak, then you're in a situation not worse than
> where we are today. Since you're still using a random salt in addition to
> the SECRET_KEY and you're using a hash function that takes non-negligible
> time. So best-case scenario, passwords become harder to crack, worst-case
> scenario, they're as hard to crack as they are with the current
> implementation. So isn't this an improvement?
>
> On Tue, Jun 9, 2015 at 8:55 AM, Shai Berger <s...@platonix.com> wrote:
>
>> On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote:
>> > On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney <
>> cur...@acommoncreative.com>
>> > wrote:
>> > > On 9 June 2015 at 15:16, Ram Rachum <ram.rac...@gmail.com> wrote:
>> > >>
>> > >> What do you think about using the project's `SECRET_KEY` as an
>> > >> additional salt in Django's password hashers?
>> >
>> > > I think it'd royally screw you over if you ever had to change your
>> secret
>> > > key [due to suspected leak, for example] as now all your passwords are
>> > > invalid.
>> > >
>> > Okay, so how about if we use a separate secret?
>> >
>>
>> How is it different? If you suspect a leak that forces you to change the
>> secret
>> key, wouldn't you be forced to change this secret as well?
>>
>> Shai.
>>
>
>  --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANXboVavc8o3HZ%3DuP54PaD9CYgV25S8gPjBLfJhoBJSLSKtwKA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CANXboVavc8o3HZ%3DuP54PaD9CYgV25S8gPjBLfJhoBJSLSKtwKA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDFPjTX%3DwxXz%2BFc5wrwC02YCmy3w5JNobDpa9gk9wx1gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

2015-06-08 Thread Curtis Maloney

I think it'd royally screw you over if you ever had to change your secret
key [due to suspected leak, for example] as now all your passwords are
invalid.

--
Curtis


On 9 June 2015 at 15:16, Ram Rachum  wrote:

> Hi,
>
> What do you think about using the project's `SECRET_KEY` as an additional
> salt in Django's password hashers? The advantage would be that they'll be
> harder to crack, as an attacker would need access both to the database
> table and the code for the secret key. The disadvantage I can think of is
> that you couldn't change your `SECRET_KEY` without breaking old passwords
> (so maybe we need a separate secret in the settings.)
>
> What do you think?
>
>
> Thanks,
> Ram.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/617aecb6-3156-49d1-859a-f55efb9f54f2%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAS2o1EMSn5HQd-60Q2KutQ5uUUmYORQxsZeVM8rWbWpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

2015-05-31 Thread Curtis Maloney

I think the real questions are:

1. What is stopping a 3rd party product from providing the features you
want?

If there is something Django can do to make it easier, point it out, and
I'll gladly champion a good feature.

2. Why should your solution be the "blessed" solution?

The discussion clearly shows there are several ways to skin this cat... why
is your way better than any other?  Until there is a clear winner [see
migrations and South] it should live as a 3rd party app, with Django
providing whatever mechanisms/support it can.

Personally, I've used DOM-SSE to implement a simple chat service in Django,
using Redis for the PUB-SUB server.  It was only really feasible because
(a) I used gevent, (b) no ORM means no need for async DB adapter, and (c)
the py-redis module is Pure Python, so can be monkey patched.

[FYI I've also translated that same code to raw WSGI app, and using
async-io, available on github if you're interested ]

--
Curtis


On 1 June 2015 at 08:03, Emil Stenström  wrote:

> On Sunday, 31 May 2015 15:56:09 UTC+2, Florian Apolloner wrote:
>>
>> On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote:
>>>
>>> Client A clicks a button on the site, that sends an normal ajax request
>>> to Django. In the view a message is passed from Django to the SSE process.
>>>
>>
>> How, you still need some kind of interprocess communication
>>
>
> Yes, interprocess communication is needed. The simplest way to get the two
> programs to talk would be to use a HTTP POST to the other program (which
> would run on another port). This would also make it possible for other
> programs to send messages through the same connection.
>
>
>> So the SSE process is VERY simple. It just connects to clients and passes
>>> on messages the all clients connected.
>>>
>> VERY simple is an oversimplification in my opinion. I also do not see any
>> reason for supporting it inside Django currently when things like
>> autobahn.ws
>> 
>> exist, the only thing missing there is the communication between the
>> processes.
>>
>
> Is the argument here that "since there are other ways of doing it I see no
> reason to do it in Django?". Autobahn is a huge dependency on your program,
> when all you need for most usecases is a small event loop and a way to pass
> messages. Setting up websockets and redis pubsub is also a huge hassle. I
> see the need for something simple, something you could get up and running
> quickly.
>
>
>> I am not sure what people are expecting here from Django (and from your
>> explanations I am still not really convinced or see a usecase at all).
>>
>
> A simple use-case is Facebook style notifications. When something happens
> to a user you want to send that user a notification right away, not 10
> seconds later because that's how often you were polling the server. Another
> use-case is a user chat. When a user sends a message you want that message
> to show up right away. Or maybe you keep track of server uptime on a status
> page. When a server goes down you want your users to be notified
> immediately, not later.
>
>
>> Since the message passing between the server processes should be
>> language/framework agnostic anyways, this would be better suited for a
>> third party project anyways. Reimplementing one of the existing
>> SSE/Websockets implementations does not really seem like a win to me either.
>>
>
> I agree that they should be language/framework agnostic, that's why I
> think a HTTP Post would work great to send messages. And I agree this could
> be developed as a separate project to start with. I *don't* agree that
> this wouldn't be something worthwhile to include in Django.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d1148851-7ced-4463-9bf5-02a54d5a5ade%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 http://groups.google.com/group/django-developers.
To view this

Re: Why can't templates access properties

2015-05-26 Thread Curtis Maloney

Feel free to open a ticket, as it will give a place to retain the
discussion.

Perhaps start with the use case for having additional properties on a
QuerySet :)

--
Curtis

On 27 May 2015 at 07:14, Ram Rachum  wrote:

> I found the cause of my problem: `django.db.models.Manager.from_queryset`
> copies all the methods from the `QuerySet` class to the `Manager` class,
> but it doesn't copy the properties.
>
> What do you think about opening an issue for
> making `django.db.models.Manager.from_queryset` copy over properties as
> well?
>
>
> On Tuesday, May 26, 2015 at 10:19:25 PM UTC+3, Tim Graham wrote:
>>
>> Accessing properties in templates should work as far as I know. Maybe
>> there is an error in your application.
>>
>> On Tuesday, May 26, 2015 at 2:27:40 PM UTC-4, Ram Rachum wrote:
>>>
>>> Hi,
>>>
>>> I noticed that when I use variables in Django templates that access
>>> object properties, it doesn't work. (e.g. I have {{ foo.bar }} while bar is
>>> a Python property.)
>>>
>>> See the documentation for variables in Django templates:
>>>
>>> https://docs.djangoproject.com/en/1.8/ref/templates/language/#variables
>>>
>>> It indeed doesn't mention properties.
>>>
>>> Why should properties not work through template? I can't think of a good
>>> reason.
>>>
>>>
>>> Thanks,
>>> Ram.
>>>
>>  --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7188bfd5-632d-4333-868f-180540a8193c%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCa5%3DS3JNyJ0zNwBAmkObj9%2B3oyOeKUE_1a8yYu7%3DgoNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: templates: override inner nested block

2015-05-24 Thread Curtis Maloney

Could you provide a solid, minimal example of how you get this case?

I have seen duplicate rendering of nested blocks happen in the past, and it
was because in the resulting template, two  blocks wind up with the child
defined in them [this actually lead to me writing a {% reuse %} tag to take
advantage of this :)]

--
Curtis


On 24 May 2015 at 21:28, anentropic  wrote:

> Currently there is a problem (correct me if wrong) when you need to
> override the content of an inner nested block.
>
> {% block parent %}
>   some stuff
>   {% block child %}
>  child stuff
>   {% endblock %}
>   some other stuff
> {% endblock %}
>
> if you are in a template which extends the one above and you want to
> override just the content of 'child' block you are stuck
>
> if you just do:
>
>   {% block child %}
>  new child stuff
>   {% endblock %}
>
> ...you get two of the 'child' block, because you haven't overridden the
> parent block, so there's another one from there.
>
> But then if you need to override the parent block you have to copy and
> paste all the content that you *don't* want to change, since {{
> block.super }} can't be used (the part you want to override is going to
> be reproduced by the super).
>
> Possible implementation difficulties aside, is it a namespacing problem?
> Do we need a syntax for saying like:
>
>   {% block parent:child %}
>  new child stuff
>   {% endblock %}
>
> ...then Django can know you want to just override the inner nested block,
> with everything else from the parent blocks being reproduced verbatim
> (without having to copy and paste it breaking DRY)
>
>
>  --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/26e7d546-0a49-408b-8480-b8d6b4aba608%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSA0yp48fybRubE-_fNwE5y5P1jzdro%2BUUkBUaQoHckCSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving Test Speed for Projects that use django.contrib.postgres

2015-05-05 Thread Curtis Maloney

I looked into using UNLOGGED some time ago, but the create table method was
misnamed, and the actual create table function was inflexible.

Now the code is much cleaner, and each DB can specify how to enact create
table and friends.

Which leaves us with the question -- is it possible to alter the Schema
strings based on if we're running tests?

The closest I can see is sql_table_creation_suffix...

If there were a similar function which allowed us to pass additional
arguments for substing into sql_create_table...

--
C


On 5 May 2015 at 16:45, Aymeric Augustin  wrote:

> 2015-05-05 6:15 GMT+02:00 David Muller :
>
>> Haven't had a chance to try and throw everything into RAM disk but that
>> sounds pretty cool.
>>
>
> Actually, that's the reason why I added support for tablespaces on
> PostgreSQL in Django 1.4 :-)
>
> https://docs.djangoproject.com/en/1.8/ref/settings/#default-tablespace
>
> https://docs.djangoproject.com/en/1.8/ref/settings/#default-index-tablespace
>
> I remember that it was easy to set up and worked well. It made a good
> difference on the CI server, which had traditional hard disks, but not an
> appreciable change locally on my laptop, which has a SSD.
>
> --
> Aymeric.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANE-7mXx9FvgU8k1mqi2WjTXGHYjUvOdhtwmqkVEkv9LLbAQ5Q%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDc9Mygd1o5hheEenW_O9jFiW12AqmuUyJixz6qw%2BfFdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unneeded index created with unique=True and db_index=False in TextField

2015-04-14 Thread Curtis Maloney

Was the OP referring to the unique index, or the index created for the LIKE
lookups?

I was involved in a discussion recently [was there something on list too?]
wanting to be able to opt-out of the second index because they knew they
didn't need it, and it was _huge_ on their database.

--
C


On 15 April 2015 at 11:58, Tommy Beadle  wrote:

> I believe that Postgres will *always* create an index on a column with a
> UNIQUE constraint.
>
> regression=> create table yo (id serial primary key, blah varchar(32)
> unique);
> CREATE TABLE
> regression=> \d yo
> Table "public.yo"
>  Column | Type  |
> Modifiers
>
> +---+-
>  id | integer   | not null default
> nextval('yo_id_seq'::regclass)
>  blah   | character varying(32) |
> Indexes:
> "yo_pkey" PRIMARY KEY, btree (id)
> "yo_blah_key" UNIQUE CONSTRAINT, btree (blah)
>
> regression=> drop index yo_blah_key;
> ERROR:  cannot drop index yo_blah_key because constraint yo_blah_key on
> table yo requires it
> HINT:  You can drop constraint yo_blah_key on table yo instead.
>
>
> On Tue, Apr 14, 2015 at 9:01 PM, Some Developer  > wrote:
>
>> Using Django 1.8, psycopg2 2.6 and PostgreSQL 9.4.1.
>>
>> I have a model with a models.TextField(unique=True, db_index=False,
>> primary_key=False) field in it.
>>
>> I understand that an index is created because of the comment shown in
>> this code:
>>
>> https://github.com/django/django/blob/master/django/db/
>> backends/postgresql_psycopg2/schema.py#L17
>>
>> but even though the index is suggested for LIKE queries using non C
>> locales I would have thought the addition of db_index=False would have
>> negated that.
>>
>> I feel that this is a bug. An index is not required by PostgreSQL on a
>> unique constraint (it may be recommended but that is beside the point) and
>> if I explicitly state db_index=False then the Django ORM should remove the
>> index even though the index is recommended.
>>
>> Thoughts?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/552DB881.1090006%40googlemail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Grace and Peace,
> Tommy B.
>
> I want to live like I know what I'm leaving.
> --Switchfoot, "Awakening"
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAKfxM0LJNbT%2BWtBW0n%3DD9K3QxNjLas7H3t2ZpMWfuaxXh1uxbQ%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSBPGBr%3DPNAgiVKUzK%2Bv%2BCKgf5An-AO13NZqHrXnuNBEiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Wsgi Traceback on Django 1.8

2015-04-08 Thread Curtis Maloney

At a guess, one of your views is returning a string instead of a
HttpResponse object.

This is the wrong forum for this question.  This list is for discussing the
development _of_ django, not _with_ django.  Your question belongs in
django-users.

On 9 April 2015 at 14:56,  wrote:

>
> Error on Django 1.8:
>
> My site do not use session and cookies, its basic a static site and some
> forms.
>
> Django 1.7.7 it's OK.
>
>
> Traceback (most recent call last):
>   File
> "/usr/local/envs/wscep/lib/python3.4/site-packages/django/core/handlers/wsgi.py",
> line 195, in __call__
> for c in response.cookies.values():
> AttributeError: 'str' object has no attribute 'values'
>
>
>
> Enviado via UCSMail.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7bb3179f-1d0a-47cf-a46a-f1b7d0ed47a9%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSB64gXMVmtLX6bQMsmven4rQnokzLOPchppxsZn6RnV1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using AbstractBaseUser without django.contrib.auth

2015-04-01 Thread Curtis Maloney

Does your model inherit from PermissionsMixin?

If you're using Admin, or any of Django's permissions machinery, you will
need django.contrib.auth in there to use the Group and Permission models.

--
Curtis

On 2 April 2015 at 13:47, Dan Watson  wrote:

> While trying out Django 1.8 with one of my sites that uses a custom User
> model (and doesn't have django.contrib.auth in INSTALLED_APPS), I noticed a
> few unexpected deprecation warnings:
>
> /Users/dcwatson/Documents/Environments/reader/lib/python3.4/site-packages/django/contrib/auth/models.py:41:
> RemovedInDjango19Warning: Model class django.contrib.auth.models.Permission
> doesn't declare an explicit app_label and either isn't in an application in
> INSTALLED_APPS or else was imported before its application was loaded. This
> will no longer be supported in Django 1.9.
>   class Permission(models.Model):
>
> Same thing for User and Group. Is it required to have django.contrib.auth
> installed to use custom User models now? Seems like it would be easy enough
> to move AbstractBaseUser (and probably UserManager/BaseUserManager) to a
> separate modules and import them from django.contrib.auth.models, so sites
> could use them without triggering these errors. If this sounds reasonable,
> I can open a ticket/PR.
>
> Dan
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/02f98a6f-9fbf-4c57-8285-80f3c2c3e2ef%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCbwNzsJMKHVDjf%2B2XnQbnPe9UgbsDZ_FvAgW3L17NC4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

2015-03-24 Thread Curtis Maloney

Let's not get bogged down in minutiae just yet :)

How to implement a grid and what level of browser support is something that
can be threshed out in the process.

I love the idea of a Dashboard with custom Widgets.

Allowing the existing "App list" widgets, along with new custom non-model
widgets will open Admin a lot.

This idea is so good, grappelli have had it for years :p

Does this also, then, imply the need for sub-dashboards, as Admin has
currently per-app?  Or would we use our new-found flexibility to, for
instance, accordion-out "folders" of widgets?

And I may as well suggest allowing widgets to hint at their size [e.g.
 1x1, 2x1, 1x2, etc..]


... I'll comment more when I can focus better ...

--
C

On 25 March 2015 at 04:33, Patrick Guido  wrote:

> About IE 9 support it is possible to use a polyfill for flexbox, even
> thought this causes performance problems and/or it (the polyfill) could not
> implement the full spec. https://github.com/doctyper/flexie
>
> Another options is to go mobile first *even* on IE 9 (eg, everything on
> one column), I saw an article where someone was describing this approach
> (for ie8), if I find the link I'll post it here. If we add some IE9
> specific css it could look good.
>
> Patrick
>
> On Tue, Mar 24, 2015 at 5:16 PM Aaron C. de Bruyn 
> wrote:
>
>> On Tue, Mar 24, 2015 at 9:10 AM, Germano Gabbianelli
>>  wrote:
>> > Uhm, missing IE9 support. It is the default browser on vista, which has
>> > extended support until 2017 :|
>>
>>
>> "Beginning January 12, 2016, only the most current version of Internet
>> Explorer available for a supported operating system will receive
>> technical support and security updates."
>>
>> https://support.microsoft.com/en-us/lifecycle/search?sort=
>> PN=internet%20explorer
>>
>> I'm not a Windows guy, so I'm not sure if newer versions of IE run on
>> Vista.  If they do, it looks like we're less than a year away from IE9
>> being unsupported.
>>
>> Then again, I know my company has clients that still have ~40% of
>> machines running Windows XP due to upgrade costs. ;)
>>
>> -A
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/CAEE%2BrGq%2Bn%2Bi5LA%
>> 2B1Fs47LY3xKCvCZ%3DZBVDjZRnB8%2BBPw%3DdyTNw%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 (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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAOUxZcsur_mn0q3EoXPe-QEZ1dRHYgw9jJycSUJVJqUBnyxLhQ%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAZE8u9V-N3c9obN4rp8Kz20m0pyQoELGWF09N2hWeiqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL matching problem

2015-03-23 Thread Curtis Maloney

Firstly, this is really a question for django-users ... this mailing list
is for discussion of the development _of_ Django, not _with_ Django.

On 24 March 2015 at 13:16, Ma Yuping  wrote:

> django V1.6.8
>
> Let URL be:
>
> url(r'^blog/(?P\d+)/$', views.index, name='index'),
>
> url(r'^blog/(?P\d+)/article/(?P\d+)/view/$',
> views.article, name='article'),
>

Are you certain these are the exact patterns you have, and the only
patterns starting with blog/ ?

Either you've not restarted your app server after making changes, or you
have another url pattern that's catching all of these.

--
Curtis

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDf3FnB5cM0fjmwa92c68L6KZfc%2BnivgrJ1EQwHLgRFzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite fields

2015-03-18 Thread Curtis Maloney

Dev discussions typically happen on #django-dev on the Freenode IRC network.

--
C


On 18 March 2015 at 19:54, Thomas Stephenson  wrote:

> IRC discussion sounds fine with me, but I'd like to be involved. What's
> the channel?
>
> Thomas
>
> On 18 March 2015 at 15:47, Asif Saifuddin  wrote:
>
>> but? IRC discussion?
>>
>> On Tuesday, March 17, 2015 at 9:09:49 PM UTC+6, Thomas Stephenson wrote:
>>>
>>> Not impatient or anything, but...
>>>
>>> Bump.
>>>
>>> On 13 March 2015 at 14:07, Thomas Stephenson  wrote:
>>>
 All the null handling stuff has been removed from the specification and
 replaced with slightly more stringent restrictions on `value_to_dict`.
 There is an updated version which includes that change, plus a couple more
 alterations that were discussed here and on the PR available here.
 

 Thomas

 On 9 March 2015 at 17:43, Anssi Kääriäinen  wrote:

> On Mon, Mar 9, 2015 at 8:06 AM, Thomas Stephenson 
> wrote:
> >> It doesn't result in good table design and adds
> restrictions/complication
> >> to the ORM/migrations.
> >
> > Well, honestly, making all subfields always nullable (whether it is
> or not)
> > in order to support the composite field being potentially nullable
> doesn't
> > really result in good table design either.
> >
> >> Enforcing that both x and y have a value should be handled with a
> >> constraint and/or validators.
> >
> > There is _no_ problem that is better handled with validators than an
> > equivalent database constraint unless you assume that the framework
> is the
> > only client your database will ever have.
>
> You'll likely need both. The database constraint is there to catch all
> errors, whether generated by the framework or some other client. The
> validator will supply nice user-facing error messages. This is how
> unique constraints work for example: there is a model validator that
> says "this value already exists in the database", but we also have
> database level constraint to make sure there is no way to store
> invalid values.
>
> >> -1 on silently changing the field definition. At best this would
> result in
> >> an unnecessary migration when the error is discovered. Django
> should error
> >> out with a message that the composite field definition is invalid.
> >
> > Changing the subfield definitions in the composite field constructor
> has to
> > be supported, there's no way of passing parameters to subfields if
> you
> > don't. What mistake is there to be found? Either you want the
> composite
> > field to be nullable or you don't. You're being explicit about it by
> passing
> > `null=True` into the field definition and it's a standard field
> parameter.
>
> If the user supplies the fields, then we don't want to change them
> silently. We could have checks framework error for incompatible
> settings however. If the field auto-creates the subfields, then it can
> alter them in any way it wishes.
>
> Making the composite field null only when all of its subfields are
> null seems the right behavior to me. Otherwise you'd have strange
> cases where .filter(money__amount=10) is true, but
> .filter(money__isnull=True) is also true for the same row.
>
>  - Anssi
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CALMtK1GCSfemy%2BN0HLPMbsovwgcSy%2BwEw6QF-%
> 2BoZ-tfBCTSkUw%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 (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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/0f8b0979-7e15-45d2-ab76-88dc747a0bf7%40googlegroups.com
>>

Re: About Class Based views

2015-03-17 Thread Curtis Maloney

No... I'm well aware of CCBV, and think it's a great tool... however, I had
in mind something that would more clearly show (a) the stratified layers of
interface, and (b) the typical call paths [through the layers] of the
various Views and Mixins.

Such a visualisation, I feel, would help many people more readily grasp how
all the pieces fit together, and where to hook in to get the results they
want.

--
C


On 18 March 2015 at 10:19, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

>
> On Wed, Mar 18, 2015 at 5:38 AM, Curtis Maloney <
> cur...@acommoncreative.com> wrote:
>
>> I found when taking the CBGV session in MelbDjango School, it was best to
>> approach teaching CBV as an exercise in Interfaces.
>>
>> Once the students were familiar with writing basic views, and the
>> patterns therein, much of CBGV became "obvious", and the lesson focused
>> more on the power of interfaces.
>>
>> As I've said many times on IRC I'd love a site that shows the layers of
>> interfaces in various CBGV so it becomes clearer how they interact.
>> Unfortunately, I don't have the time or skills to pull this off :/
>>
>>
> You mean something like:
>
> http://ccbv.co.uk
>
> or did you have something else in mind?
>
> Yours,
> Russ Magee %-)
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq848-7%3D%2BL_foUTvkH3rDw1n_c-zDbpqUtkHdVA0wKJbY3_w%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAJxq848-7%3D%2BL_foUTvkH3rDw1n_c-zDbpqUtkHdVA0wKJbY3_w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSBb3iT9RXS87HHY2WJekR53LuDbTpCZ_sW3%3DhmyRA-sTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: About Class Based views

2015-03-17 Thread Curtis Maloney

I found when taking the CBGV session in MelbDjango School, it was best to
approach teaching CBV as an exercise in Interfaces.

Once the students were familiar with writing basic views, and the patterns
therein, much of CBGV became "obvious", and the lesson focused more on the
power of interfaces.

As I've said many times on IRC I'd love a site that shows the layers of
interfaces in various CBGV so it becomes clearer how they interact.
Unfortunately, I don't have the time or skills to pull this off :/

--
C


On 18 March 2015 at 08:07, Moritz S.  wrote:

> Am Dienstag, 17. März 2015 20:41:53 UTC+1 schrieb poiati:
>>
>> The problem with CBV is the learning curve.
>>
>
> Totally agree with that!
> Personally I really like CBVs and I also write my own subclasses and
> mixins regularly, but I think you'll really have a hard time even writing a
> simple mixin if you have never heard of mro or metaclasses.
>
>
>
>> On Tue, Mar 17, 2015 at 4:23 PM Gaurav Dadhania 
>> wrote:
>>
>>> IMHO, Class-based views — either ones provided by Django or a 3rd party
>>> library or your own —  are an inheritance pattern, like any other design
>>> pattern, use it if it suits your use case. Like a lot of things, there is
>>> no one, right answer.
>>>
>>> I've enjoyed using CBVs for CMS-y projects (list products, product
>>> detail, product edit OR list posts, post detail, post edit, etc.) and
>>> functional views for endpoints which don't really have much in common eg:
>>> payment processing, authentication/authorization endpoints, etc. (use
>>> decorators for common simple guard checks, rate limiting, response
>>> serialization/template rendering if you need). YMMV.
>>>
>>> Cheers,
>>> G
>>>
>>> On Tue, Mar 17, 2015 at 8:53 PM, Asif Saifuddin 
>>> wrote:
>>>
 Hi,

 I found this blog post about class based views of django

 http://lukeplant.me.uk/blog/posts/my-approach-to-class-based-views/


 what do you guys think about?

 Regards

 --
 You received this message because you are subscribed to the Google
 Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to django-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/django-developers/e84fd370-044e-456e-b2f3-
 fd028f41232e%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-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/CAHgJS%3D_OCgApx6SBdqYCQysLU6MFR%
>>> 3DganAwYv7LNBE4gzzucaA%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 (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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/19d912c9-3dc2-4a13-a4bd-e2f0354e95b1%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit

Re: GSoC 2015: Template engine optimisation

2015-03-12 Thread Curtis Maloney

I have convinced my self [with absolutely no hard evidence, just
familiarity with the code] that the template engine is overly cautious when
it comes to ensuring values are strings and are escaped properly.

After a while I believe layers and layers of caution have accrued, and
nobody is sure any more where these have overlapped excessively.

I believe a motivated person could create a call graph and find at least
some cases where some of these cases could be removed to the benefit of
rendering performance.

My prior experience with the template engine has convinced me there is
little benefit to optimising the _parsing_ of templates, as anyone
concerned about template parsing speeds should generally be using the
caching template loader.  [Yes, I realise there are other cases, but I
don't believe there is a lot left to optimise in the parsing -- happy to be
proven wrong]

--
Curtis


On 12 March 2015 at 15:31, Preston Timmons  wrote:

> Hi Oleksii,
>
> I found that cProfile isn't that helpful when rendering templates. There
> are a lot
> of function calls and the output is too verbose to really reveal where
> Django
> spends it's time.
>
> Also, keep in mind that rendering is only one step of the template cycle,
> and
> usually only a small part of it. There are these steps to consider:
>
> * Template loading
> * Lexing, parsing and compiling
> * Rendering
>
> Here are some recent benchmarks I've done on the template engine:
>
> https://groups.google.com/d/msg/django-developers/VFBLAoPSplI/pPzOYm3PUVQJ
>
> From what I can tell, if we compare Django templates to Jinja2, which are
> considered quite fast, the biggest visible difference doesn't come because
> Jinja2 has a faster parser or renderer. It's because it maintains an
> internal
> cache. Jinja2 only recompiles templates when it has to.
>
> Depending how things go with ticket #15053, internal caching might become
> part of Django, though. If that's so, your proposal will need to hone in
> on
> identifying other specific areas you think performance can be improved.
>
> The Django parser and lexer are parts that could be completely rewritten,
> for example, while easily maintaining backward compatibility. Changing the
> rendering layer is much more difficult because multiple 3rd-party libraries
> depend on the Node class.
>
> If you're serious about working on this, I suggest digging into the
> benchmarks,
> identifying an area that can be improved, and providing a proposal for how
> you think it can be made faster.
>
> Good luck.
>
> Preston
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c16befb5-c12d-43cc-84a2-6931c245b8a5%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDwGquyEUsQ7s%3DUB1SuLje91Fwsh4pfanv77QxAj0U-3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite fields

2015-03-04 Thread Curtis Maloney

Have you reviewed all the existing works on trying to add composite fields?

I know several managed to reach a level of maturity that was almost merge
quality, and am sure I heard some of the recent ORM changes would ease
support.

On 5 March 2015 at 11:42, Thomas Stephenson  wrote:

> OK, no need for everyone to shout -- your message is heard loud and
> clear. I'll go and find something else to work on.
>
>
Wow... impatient much?  Not everyone works in your timezone, or to your
schedule.  I, for one, was planning to take some time to review your
proposal carefully, instead of "first thing in the morning whilst still
having my coffee", as I feel it's a topic that deserves careful
consideration.

Don't you think it's worth giving everyone a chance to read your email
before you give up and move on?  It's only been 11 hours.  Many of us were
asleep for most of that.

--
Curtis



> On 5 March 2015 at 00:16, Thomas Stephenson  wrote:
> > Considering the past two proposals I've made here, I doubt I'll get more
> > than an echo chamber effect on this one.
> >
> > For the past week or so I've spent a bit of time on a feature I've always
> > wanted to see land in django -- composite fields. The tickets have been
> open
> > in the bug tracker for quite some time (and there's a few related ones,
> such
> > as multi-column primary keys that can all be killed with the one stone).
> >
> > The work is available on this branch of my fork of django for the moment
> --
> > I haven't opened up a PR yet because there's still some features that are
> > still to be implemented that will be explained below, but I want to give
> > everybody a chance to tell me where I can stick it before I spend *too*
> much
> > time on it.
> >
> > So, without further ado, the proposal.
> >
> >
> > Composite Fields - Implemented
> >
> > A composite field is an encapsulation of the functionality of a subset of
> > fields on a model. Composite fields can be defined in one of two ways:
> >
> > 1. Statically declared composite fields
> >
> > A statically declared composite field is defined in the same way a django
> > model is defined. There are two customisable transformation functions,
> > CompositeField.value_to_dict(self, value) and
> > CompositeField.value_from_dict(self, value) which can be used to
> associate
> > the field with a python object.
> >
> > All the serialization functions are implemented via the implementations
> of
> > the subfields.
> >
> > For example,
> >
> > class MoneyField(models.CompositeField):
> >currency_code = models.CharacterField(max_length=3)
> >amount = models.DecimalField(max_digits=16, decimal_digits=4)
> >
> >## Overriding __init__ can be used to pass field parameters to the
> > subfields
> >
> >def value_from_dict(self, value):
> >if value is None:
> >   return None
> >return Money(**value)
> >
> >def value_to_dict(self, value):
> >   if value is None:
> >  return None
> >   return {attr: getattr(value, attr) for attr in ('currency_code',
> > 'amount')}
> >
> > 2. Inline composite fields.
> >
> > An inline composite field is declared at the field definition site on the
> > body of a model, by providing the subfields as the 'fields' argument of
> the
> > CompositeField constructor. There are no transformation parameters
> available
> > to override when declaring a composite field in this fashion -- the
> value of
> > the field is always available as a python `dict` as an attribute on the
> > MyModel
> >
> > class MyModel(models.Model):
> > id = models.CompositeField(fields = [
> >('a', models.IntegerField()),
> >('b', models.CharField(max_length=30)
> > ], primary_key=True)
> >
> > This method for defining composite fields has a few drawbacks, but can be
> > useful if the only reason to add the composite field to the model was to
> > implement a unique_together or index_together constraint *
> >
> > * Although it's still possible to do that directly on class Meta.
> >
> > 3. Null
> >
> > Setting the value of a multi-column field to NULL is different than
> setting
> > any of the individual subfields to NULL. But there are cases (e.g. Money)
> > where we would like to be able to set `null=True` on a composite field,
> but
> > still retain 'NOT NULL' constraints on each of the subfield columns.
> >
> > To solve this problem, every table which implements a CompositeField will
> > also add an implicit (semi-hidden) `isnull` subfield on the attribute,
> which
> > keeps track of whether it is the value of the composite field that is
> null,
> > or any of the particular subfields.
> >
> > 3. Querying.
> >
> > The syntax for querying over the subfields of a composite field will be
> > familiar to anyone who has queried over a relationship attribute in
> django.
> >
> > model.objects.filter(price__currency_code='USD',
> > price__amount__lt=Decimal('50.00')).all()
> >
> > In addition, composite fields

Re: Django Admin new look

2015-03-04 Thread Curtis Maloney

Looks pretty slick, but brings with it all the hassles of the past attempts
to re-skin admin: it breaks legacy custom pages.

I wish we could standardise a theming layer for admin... allow legacy
templates, or switching to new, clean, themable templates...

Perhaps this could be integrated with the work to break down admin into a
collection of CBGV?

... mostly thinking out aloud here :)

--
Curtis

On 3 March 2015 at 18:57, elky  wrote:

> Hi guys,
>
> I just made big front-end work on Django admin to make it look like new
> Django site - modern and clean.
>
> I think it's user friendly now and not so scary for users. Need your
> opinion, guys.
>
> See screenshots attached.
>
> Just thinking what to do next - publish my own app or make pull request.
>
> Thanks,
> Alex
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d3419ee7-2118-41ff-863e-55f4c05c43d1%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAO5usUba%3D_Aj64HcwKHW34kc7uZy5j3%2BgyKrXMVbrwhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

2015-03-02 Thread Curtis Maloney

On 3 March 2015 at 03:57, Marten Kenbeek  wrote:

> Hey all,
>
> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to
> provide a quick overview of the features I propose.
>
> I'd like to:
> - Allow matching based on request attributes such as the subdomain or
> protocol, and business logic such as the existence of a database object.
>

There was a "continue resolving" sort of exception proposed/implemented
that would obviate this, allowing the logic to remain in views [or view
decorators]... a much simpler solution, IMHO.

> - Make middleware configurable for a subset of views. It should be easy to
> add, reorder or replace middleware at any level in the (currently
> recursive) matching algorithm.
>

This has certainly been on the "wanted" list for many years now, however I
expect it would require the middleware re-design that so far has proven too
invasive to land.

That said, providing the "new" middleware-as-wrapper interface around url
patterns lists could be a good stepping stone to eventually removing the
existing middleware API.

> - Provide conventions for common patterns, such as an easy-to-configure
> URL router for all generic Model views. For generic views, this should be a
> one-liner. For custom views and other non-default options, this should
> still be relatively easy to configure compared to writing out all patterns.
>

Are you talking about pre-cooked url patterns for the various CBV?  Or
plugin routers for groups of CBV?  I'm certainly in favour of some tool
that makes it easier to express "common" regex matches [satisfying the
"protect from the tedium" rule of frameworks]

In the process, I'd like to formalize some classes used in the dispatcher.
> Currently, the RegexURLPattern and RegexURLResolver classes provide most of
> the functionality of the URL dispatcher. By abstracting these classes, and
> factoring out the loading mechanism and some other internals, I hope to
> provide an extensible dispatching framework for third-party apps.
>

As mentioned elsewhere, I would very much like to see a resolver system
based on the "parse" library [essentially, the inverse of str.format -
https://pypi.python.org/pypi/parse], and to do so would indeed require some
formal analysis / documentation of the existing resolver architecture.

--
Curtis

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSBaPz%2BJJs-CGLbZzdbpvSRo3vjpeWnpcxhVVq_tfs4gaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding context to docs

2015-02-19 Thread Curtis Maloney

On 20 February 2015 at 11:49, Diana Probst 
wrote:

> Never done either of those things, and I'm completely not set up to do
> them.  I will if creating this subject has made me the owner of it, but
> it's a lot more work for me than it would be for someone else.  I'd start
> with the Writing your First Django Patch part of the tutorial, yes?
>
>
Please don't feel pressured to write a patch to get this fixed.  If you
don't feel up to it, or don't have the time, I'm happy to do it - albeit at
my own pace.

I prefer to suggest people submit PRs simply to reinforce the fact that
anyone is welcome to contribute.

I highly recommend reading the contribution guide -
https://docs.djangoproject.com/en/1.7/internals/contributing/

If you'd like some guidance on getting set up to make PRs, come find the
helpful folks on IRC, in #django on the freenode network.

Thanks for the explanation.  I had a form in what I was pretty sure was the
> wrong place, and it was working, but it rankled so hard I had to look for
> why.
>

That's usually a sign of good instincts :)
If code doesn't "feel" right, it often leads to problems down the line.

--
Curtis

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDCkZFRDAbvj67pK7ZcDsdWd8%3Dh1BZxX%2B4WGSx7%3Dy2Pbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding context to docs

2015-02-19 Thread Curtis Maloney

In all cases in Django, if your code imports the class, you can put it
wherever you like - so long as Python can find it.  It's only things that
are "discovered" by Django [admin, models, etc] that must be in a specific
module.

By convention, forms are put into forms.py ... but that's so _humans_ will
know where to look.

That said, it certainly would be a good thing for the tutorial to explain
this, and for the forms docs to recommend using "mapp/forms.py".

Do you feel up to writing a patch and making a PR?

--
Curtis


On 20 February 2015 at 09:38, Diana Probst 
wrote:

> I've been struggling to add forms to an app I am building, because the
> context of where to put form classes is missing in the docs.  I don't want
> to take a guess, even if it's right, when I could be following best
> practice.  In the 1.7 tutorial, the namespacing and file naming is laid out
> pretty simply, but in the Working with Forms page,
> https://docs.djangoproject.com/en/1.7/topics/forms/ which is the start of
> the overview, there is nothing setting out that I should, say, be using
> /myapp/forms.py .  I think that would be a valuable thing to add to the
> docs.  I've searched for where else it might be, and I can't find it, so
> even if it does exist elsewhere, the difficulty of finding this information
> is high.
>
> The tutorials have the name of file at the top of each example, which is
> my favourite solution, but even a briefing at the top of the forms overview
> would be an improvement on what is currently a low information zone.
> Currently, I don't have access to info on how to namespace my forms, and
> where to create what I'm creating.  It's a small change that would make the
> docs clearer and easier to use.
>
> DP
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f5a8e89f-d9d8-46a3-95b7-0b075c15fec4%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDXPmp-Q_5V7aOY%2BajyaWVzFZe51KaffpDOFsuOEwvchw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Drop the TEMPLATE_DEBUG setting

2015-02-18 Thread Curtis Maloney

Just to chip in here... when TEMPLATE_DEBUG=True the template engine uses a
substantially different Lexer, based on re.finditer() instead of re.split().

There are about 10 hooks in the Parser class, too, that exist almost
exclusively to allow the DebugParser to change behavior.

If we always store the debug information [and do all the other parsing
checks] it's likely the template parsing will become _faster_, just because
of avoiding method calls.

For giggles, I'll run up a fork and see if I can get some meaningful
results from Preston's very welcome template benchmark tool.

--
Curtis


On 17 February 2015 at 16:03, Preston Timmons 
wrote:

> Here are some benchmarks I added here:
>
> https://github.com/prestontimmons/templatebench
>
> This is the cumulative time to do 1000 iterations:
>
> Basic.do_init: 0.1423451900
> BasicDebug.do_init: 0.1941769123
> 35% increase in parsing time
>
> Basic.do_parse_complex: 1.2230978012
> BasicDebug.do_parse_complex: 1.4190740585
> 15.5% increase in parsing time
>
> FileSystem.do_get_template_complex: 1.4923889637
> FileSystemDebug.do_get_template_complex: 1.7524909973
> 17.4% increase in parsing time
>
> FileSystem.do_get_template_index: 0.5193221569
> FileSystemDebug.do_get_template_index: 0.5603711605
> 9.8% increase
>
> If my benchmarks are right, the increase is measurable, although probably
> not enough to notice in most usage of Django templates. Increasing parsing
> time isn't ideal, though, since that's where Django templates seems to
> spend most of their cpu time.
>
>>   --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9cc2bb2d-0335-4d49-8529-9c3dbdd07467%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAtfngAGb9TKhugJuxg%2B6Og50%2BMP3V25kfZACuaMwsqiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: JsonResponse and list values

2015-02-16 Thread Curtis Maloney

Cheers for the quick reply... well, you learn more about how shit JS is
every day :P

--
C

On 17 February 2015 at 10:41, Florian Apolloner <f.apollo...@gmail.com>
wrote:

>
>
> On Tuesday, February 17, 2015 at 12:30:25 AM UTC+1, Curtis Maloney wrote:
>>
>> Ran into this bug this morning... what's the rationale behind
>> JsonResponse only accepting dict types unless you set safe=False to allow
>> _any_ type?
>>
>
> Cause dict maps to object which is somewhat safe.
>
>
>> Surely list/tuple should also be permitted?
>>
>
> No, the safeguard is especially for those! See
> http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/
> and
> http://incompleteness.me/blog/2007/03/05/json-is-not-as-safe-as-people-think-it-is/
> for details.
>
> Cheers,
> Florian
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c31944e1-a4f5-4ed9-91e0-aee9f2d7fb9c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c31944e1-a4f5-4ed9-91e0-aee9f2d7fb9c%40googlegroups.com?utm_medium=email_source=footer>
> .
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSB3ec354NhPGKxUiu07b%3DBM9qKXaRa%2BjUapi1don46AGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

JsonResponse and list values

2015-02-16 Thread Curtis Maloney

Ran into this bug this morning... what's the rationale behind JsonResponse
only accepting dict types unless you set safe=False to allow _any_ type?

Surely list/tuple should also be permitted?

There's a test explicitly ensuring lists fail.

I'm not comfortable turning off ALL type safe-guards just so I can send
lists as JSON results.

--
Curtis

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSBsM5Dm3FEHDzfF2_9erD8xD-%3DOSeit_zpoWsj%2BCTUOqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: discontinue shipping tests with contrib apps?

2015-02-09 Thread Curtis Maloney

That'll teach me to respond to email before coffee :)

--
C


On 10 February 2015 at 10:12, Tim Graham <timogra...@gmail.com> wrote:

> Is it a best practice? In my unscientific sampling, none of the following
> ship tests inside the application directory, but rather in a separate
> "tests" directory. Or did I misunderstand what you meant?
>
> - Django REST framework
> - django-nap
> - the apps that split out from contrib (formtools, comments, localflavor)
>
> On Monday, February 9, 2015 at 5:28:22 PM UTC-5, Curtis Maloney wrote:
>>
>> Just to shine a light on another perspective- I frequently tell people to
>> look at contrib for "best practices", and including tests within a 3rd
>> party app would fall under that.
>>
>> --
>> Curtis
>> On 10 Feb 2015 03:34, "Marc Tamlyn" <marc@gmail.com> wrote:
>>
>>> +1 to removing tests from contrib itself, so long as they remain
>>> obviously separated in the test section in case of future removals from
>>> core.
>>>
>>> On 9 February 2015 at 15:44, Preston Timmons <preston...@gmail.com>
>>> wrote:
>>>
>>>> I think the "need" is mainly conceptual--whether tests are more
>>>> appropriately grouped with their app or with the other tests. With the
>>>> discover runner it's uncommon that contrib tests are included in any local
>>>> test runs.
>>>>
>>>> I do prefer moving all tests into the tests directory. The logic to get
>>>> test_modules in runtests.py would be simplified quite a bit from it.
>>>>
>>>>
>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to django-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/django-developers/ba79f1b9-678e-4fdf-8f7a-
>>>> 26319e5ac4d3%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/ba79f1b9-678e-4fdf-8f7a-26319e5ac4d3%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> 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-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/CAMwjO1EJWzd0G0noSAHFL3ZsOP9kc
>>> 6He6%2Bb1a5%3DAe3KhxBBfVg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAMwjO1EJWzd0G0noSAHFL3ZsOP9kc6He6%2Bb1a5%3DAe3KhxBBfVg%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4588baf5-2c6f-463c-a994-0ed4fe9a83ba%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/4588baf5-2c6f-463c-a994-0ed4fe9a83ba%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSBPP9nSfpdwUGAamCLEinqYp3kiRPStVMQXdxseih5s8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: discontinue shipping tests with contrib apps?

2015-02-09 Thread Curtis Maloney

Just to shine a light on another perspective- I frequently tell people to
look at contrib for "best practices", and including tests within a 3rd
party app would fall under that.

--
Curtis
On 10 Feb 2015 03:34, "Marc Tamlyn"  wrote:

> +1 to removing tests from contrib itself, so long as they remain obviously
> separated in the test section in case of future removals from core.
>
> On 9 February 2015 at 15:44, Preston Timmons 
> wrote:
>
>> I think the "need" is mainly conceptual--whether tests are more
>> appropriately grouped with their app or with the other tests. With the
>> discover runner it's uncommon that contrib tests are included in any local
>> test runs.
>>
>> I do prefer moving all tests into the tests directory. The logic to get
>> test_modules in runtests.py would be simplified quite a bit from it.
>>
>>
>>  --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/ba79f1b9-678e-4fdf-8f7a-26319e5ac4d3%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1EJWzd0G0noSAHFL3ZsOP9kc6He6%2Bb1a5%3DAe3KhxBBfVg%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAcBXeKeC4H1h2eUwZ6G3yDOELp6fmJyQ-uTbDLo4Cmpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: new to django... looking to contribute to learn more

2015-02-08 Thread Curtis Maloney

Well, the discussion has people saying explicitly "propose a patch /
solution and we'll talk"... as well as others saying "I think this is a
good idea".

So I'd suggest you go for it, and jump on IRC #django-dev (freenode
network) to help.

--
Curtis


On 9 February 2015 at 13:21, Bob Remeika <bob.reme...@gmail.com> wrote:

> Yeah I think so although I don't know enough about it to know for sure.
> I'm hoping to come up with something rough and then get a little help from
> people that know better.
>
> On Sunday, February 8, 2015 at 5:24:28 PM UTC-8, Curtis Maloney wrote:
>>
>> Certainly sounds useful, and the research seems to suggest all (most?) of
>> the major backends support it.
>>
>> --
>> C
>>
>>
>> On 9 February 2015 at 11:26, Bob Remeika <bob.r...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm new to django and python in general but I've been a programmer for a
>>> while now.
>>>
>>> I was interested in trying to contribute to django in order to learn how
>>> to navigate the internals a little better and I had my eye on this ticket
>>> because I might actually need this functionality.
>>>
>>> https://code.djangoproject.com/ticket/10088
>>>
>>> Can anybody tell me what the status is on this?  Looks like it's wide
>>> open and a patch would be welcome assuming that it's not utter crap :)
>>>
>>> Thanks,
>>> Bob
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-developers/4365af12-ce4d-4117-944a-
>>> 472b5d7c1e1a%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/4365af12-ce4d-4117-944a-472b5d7c1e1a%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b58add74-7dd8-4780-8c12-bc200e781f13%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/b58add74-7dd8-4780-8c12-bc200e781f13%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDhiLMqxUSSRysB7j3fFbH0Q%2BNpJ5JQCheDtsBiYaLmnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: new to django... looking to contribute to learn more

2015-02-08 Thread Curtis Maloney

Certainly sounds useful, and the research seems to suggest all (most?) of
the major backends support it.

--
C


On 9 February 2015 at 11:26, Bob Remeika  wrote:

> Hi,
>
> I'm new to django and python in general but I've been a programmer for a
> while now.
>
> I was interested in trying to contribute to django in order to learn how
> to navigate the internals a little better and I had my eye on this ticket
> because I might actually need this functionality.
>
> https://code.djangoproject.com/ticket/10088
>
> Can anybody tell me what the status is on this?  Looks like it's wide open
> and a patch would be welcome assuming that it's not utter crap :)
>
> Thanks,
> Bob
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4365af12-ce4d-4117-944a-472b5d7c1e1a%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSB5NWsYaiJFrHbo3KgBqynHad%3DwFFEK-%3Dpea3Lro%3DNJnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug: makemigrations caching prior migrations after deletion

2015-02-08 Thread Curtis Maloney

Could you provide details about what sort of field you added, please?

I have seen cases where migrations will create two separate migrations for
an initial.

--
Curtis

On 9 February 2015 at 10:11, Yo-Yo Ma  wrote:

> Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before
> this writing), I created a model with a "name" field, then created a
> migration for it. Moments after, I added an "age" field to the model,
> deleted the 0001_initial.py migration, deleted __pycache__ directories in
> my entire project, deleted any *.py[cod] files in my project, then ran
> makemigrations again (the goal being to create a fresh 0001 migration with
> the latest fields again, since there is no SQLite3 database file (I
> verified this as well)). When I do this, Django creates the same 0001
> migration it did the first time, then creates a 0002 migration to add the
> new field. Firstly, how is this even possible? Second, is this a known
> issue in 1.8? I've never experienced this bug before, and it's always been
> my M.O. on a new project to recreate a 0001 migration when I'm first
> working on the models (to avoid having 30 migrations before the app is even
> on a dev server).
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

2015-02-04 Thread Curtis Maloney

I'm certainly leaning on the side of "strip by default" because, like many
others, I feel it's the expected default -- users just don't get it -- and
have been bitten by it before.

I think I'll have a PR for this later tonight...

--
Curtis


On 5 February 2015 at 14:23, charettes  wrote:

> Like Russ I think this should be at the form level.
>
> Since both db.CharField and db.TextField use a form.CharField the
> stripping implementation should be done there.
>
> I commented here because I recently fixed a related bug in an application
> I maintain where a trailing white-space was not striped from an URLField
> form input. Since browsers automatically strip trailing white-space in urls
> (e.g. href=" example.com/path " == href="example.com/path") the anchor in
> the widget we provide was pointing to the correct resource when clicked by
> the user. However, when our system appended a querystring (By using the
> urllib and urlparse modules) for analytics purposes (e.g "example.com/path
> ?param=value") the white-space ended up making the whole URL invalid since
> the "/path " lead to a 404.
>
> Simon
>
> Le mercredi 4 février 2015 21:25:02 UTC-5, Collin Anderson a écrit :
>
>> Hi All,
>>
>> I'd be ok with a well thought-out strip-by-default.
>>
>> - I think most of my problems have been with trailing whitespace on
>> CharFields.
>> - I once have seen a minor unintentional leading whitespace. I think I
>> also may have once used a leading whitespace for sorting purposes, but I'd
>> be ok with even having leading whitespace stripped by default.
>>
>> I can't think of many cases where trailing whitespace has been an issue
>> for TextFields. Has this been an issue for people? I could imagine some
>> people would want a trailing newline on TextFields. However, peeking at
>> what other frameworks do, I'd be ok with this by default too :)
>>
>> Also, did we decide if the Model-field-layer or Form-field-layer would be
>> better?
>>
>> Collin
>>
>> On Wednesday, February 4, 2015 at 5:51:30 PM UTC-5, Shai Berger wrote:
>>>
>>> On Wednesday 04 February 2015 11:00:50 Tom Christie wrote:
>>> > > it will be backwards incompatible for every Django installation out
>>> >
>>> > there, but also because throwing away data that the user actually
>>> entered
>>> > should be an opt-in, not opt-out behavior.
>>> >
>>> > If adequately called out I think there'd be a valid case that the
>>> current
>>> > and future issues it'll be causing to applications right now would
>>> outweigh
>>> > the risk of compatibility breakages. I can see a couple of cases where
>>> I
>>> > might not want stripped whitespace, but only in slightly contrived and
>>> edge
>>> > case situations.
>>> >
>>> > Validating and normalizing input at the field level in a way that
>>> supports
>>> > the common case by default seems like a good plan to me. I'm not sure
>>> I see
>>> > any great difference between a user entering "3.1" in an integer field
>>> and
>>> > having 3 returned is so very different from having "hello " return
>>> "hello"
>>> > on a char field. And we're not of course throwing anything away at the
>>> > `request.POST` or `Form` layer - it's only once we're validating an
>>> > individual field that the normalization is being applied.
>>> >
>>> > I don't have an great investment in this either way around, but I
>>> think
>>> > it's a valid user-focused improvement worth considering *if* someone
>>> > actually puts together a pull request for it.
>>>
>>> I agree with this as well; I'd argue, though, that there is a difference
>>> between leading and trailing whitespace. Leading whitespace is usually
>>> visible
>>> and, to my mind, much more likely to be intentional.
>>>
>>> Shai.
>>>
>>  --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ff91cec7-90a2-4db3-8747-97d333ad218b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit

Re: intended security model for templates

2014-12-28 Thread Curtis Maloney

I certainly like the idea of making public the API to load your tag lib by
default for your project.  It's there, it's clean, and it's been stable for
a looong time.  Of course, the multi-template-engine work may change this.

Also, I agree that "explicit is better than implicit", and thus reducing
the number of places Django "discovers" things, instead of being instructed
where to look, is probably a good idea.

--
Curtis


On 27 December 2014 at 10:18, Shai Berger  wrote:

> On Wednesday 24 December 2014 20:35:09 Tim Graham wrote:
> > I was hoping to get clarification on what security model we intend to
> > support for template authors. In ticket #12772
> >  it's proposed to allow
> > loading template tags using a dotted Python path. This would allow
> template
> > authors to trigger imports of anything on the Python path. I am not sure
> > the requirement to add a template tag library to INSTALLED_APPS is a big
> > burden these days (e.g. there is no more need to create an empty
> models.py
> > file), but perhaps I don't fully understand the ticket's rationale for
> > proposing these changes.
>
> In addition to what Curtis and Florian said, the ticket was made before the
> default-project-layout change that made project-apps common; since Django
> 1.4
> (or was it 1.3?) those have been a natural place for "common tags [to] be
> kept
> together".
>
> Reading also the ticket, I agree with Carl's argument that the libraries
> available for loading should be explicitly controlled from Python code. In
> fact, this point makes me wonder if it wouldn't be better (ignoring
> backwards
> compatibility, of course) to require custom tags to be passed in through
> the
> context ("project-global" custom tags could then be added in a context-
> processor).
>
> Shai.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDg_%2Bm-wnFqf_YDKtZub5q8hkX2WtCu26zh4QKYVBspxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: intended security model for templates

2014-12-24 Thread Curtis Maloney

Personally I feel it's exposing too much implementation to the template
authors.

Whilst I can understand the appeal of allowing namespacing of template
libs, I think exposing full python paths is the wrong approach.  Perhaps
allowing a "app_label:libname" approach to being more specific?

--
Curtis



On 25 December 2014 at 05:35, Tim Graham  wrote:

> I was hoping to get clarification on what security model we intend to
> support for template authors. In ticket #12772
>  it's proposed to allow
> loading template tags using a dotted Python path. This would allow template
> authors to trigger imports of anything on the Python path. I am not sure
> the requirement to add a template tag library to INSTALLED_APPS is a big
> burden these days (e.g. there is no more need to create an empty models.py
> file), but perhaps I don't fully understand the ticket's rationale for
> proposing these changes.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/643fdee1-dbc2-4113-b564-aa2fd741a0ba%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDe2LURrkYM%3DGRWgdNSsSZ63RyckbLAPZxU%2BqM%3Djj2VrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overriding Class-based View Form Validation

2014-12-11 Thread Curtis Maloney

Firstly, I think this query really belongs in django-users  ... this list
is about development _of_ django, not _with_ django.

Secondly, why not override get_form_kwargs [1] to add the user into
creating the form class?

But yes, validation all belongs inside the form class, ideally.

[1]
https://docs.djangoproject.com/en/1.7/ref/class-based-views/mixins-editing/#django.views.generic.edit.FormMixin.get_form_kwargs

On 11 December 2014 at 09:26, Greg Back  wrote:
>
> Sorry, I accidentally sent this before finishing the background. What I
> meant to say:
>
> I am writing an application where a model (I'll call it `Thing`) has a
> ForeignKey to User and a CharField ("name"), among some other fields. I
> would like "name" to be unique for any given user; I'm using
> `unique_together` in `class Meta:` to accomplish this. I have a CreateView
> subclass which allows users to create new Things; the `user` field is
> excluded from the form, and automatically set in the View (extracting from
> `self.request`). I was previously doing this in the `form_valid` function,
> but realized that this is being called after the form is already validated
> (without a User). By the time the object is saved to the database, the
> `user` field is set, so the database raises an IntegrityError.
>
> I hacked around this by overriding `get_form` to call the parent class,
> then adding the request.user to the form.instance. This works, but has the
> side effect of also being called during GET requests, which doesn't break
> anything but is suboptimal.
>
> Does that all make sense? Am I missing a more obvious way of doing this?
>
> Thanks,
> Greg
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3353afdb-7070-49bb-9d45-ea072ac9bbb5%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSARu6yQDKtP9hJ6CQuLRPuYEYgOXjDMyB-%3D%3DVy%2BNXv8LA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of #15619: logout via POST, but not GET

2014-12-03 Thread Curtis Maloney

Wasn't there a PR to turn all the auth views to CBV?

That would implicitly enforce the behaviour to POST-only, I would hope.

--
Curtis


On 4 December 2014 at 09:52, Tim Graham  wrote:

> Hi Tim,
>
> There's an open pull request ,
> but it was opened over a year ago and has gone stale. Maybe you'd like to
> review and update it.
>
> You can use the patch review checklist:
>
>
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
>
> If you are happy with the patch after that, please mark the ticket as
> "ready for checkin" for a final review from a core developer.
>
> Thanks!
> Tim
>
>
> On Wednesday, December 3, 2014 5:02:42 PM UTC-5, Tim Chase wrote:
>>
>> I've had a couple cases where browser link pre-fetching triggered
>> an unintended logout from my Django app (I haven't fully tracked down
>> the exact combination of triggering conditions, but I suspect they
>> similar to Israel Brewster's CherryPy issue mentioned on
>> comp.lang.python [1]) and was surprised that Django suffered the same
>> issue.
>>
>> Researching, I found https://code.djangoproject.com/ticket/15619
>> but see that it was last modified ~10mo ago, having been opened ~4yrs
>> ago.  The current (development HEAD from git) versions of
>>
>>   django/contrib/auth/views.py:logout()
>>   django/contrib/auth/__init__.py:logout()
>>
>> still don't seem to contain any checks to ensure logouts can only
>> happen via POST rather than GET requests.
>>
>> Is there any movement forward on resolving this so my browser
>> doesn't inconveniently boot me from the app when I don't intend to
>> log out?
>>
>> -tkc
>>
>> [1]
>> https://mail.python.org/pipermail/python-list/2014-December/682106.html
>>
>>
>>
>>
>>
>>
>> .
>>
>  --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c888627a-d1da-4755-ad77-055b7837c2e2%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSApWNAuS1xJF-LWPZU5%3DO6UaVihB4pNh4iZ9oMfs-LHqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template render performance

2014-11-18 Thread Curtis Maloney

It's been on my TODO list for some time to deep dive into DTL and find
where I can to remove excess work.

There's a LOT of defensive coding in there to ensure things are what we
expect, and to handle cases "just in case", and I've a gut feeling [nothing
more] that we can remove some of these safety catches.

However, to do this I would first require a credible template benchmark
suite.

It's been my experience that it's actually quite rare for the slowdowns to
be unavoidably DTLs fault... often a tiny more work in the view to put data
into better structures can affect drastic speedups.

So, in closing... if you're interested in helping me help you... let's talk.

--
Curtis


On 18 November 2014 13:39, Michael Manfre  wrote:

> Thanks to the work Aymeric recently started, Django will have more options
> with regards to templating. See his DEP on Multiple Template Engines.
> https://myks.org/en/multiple-template-engines-for-django/dep/
>
> Regarding changing the Django Template Language syntax for the sake of
> performance improvements, backwards incompatible changes are not likely to
> happen. There is a huge cost involved with forcing everyone to update their
> templates. Ideas on improvements that are backwards compatible would be
> welcomed by many!
>
> Regards,
> Michael Manfre
>
>
> On Mon, Nov 17, 2014 at 9:17 PM,  wrote:
>
>>  Hello,
>>
>> Mostly a question, but are there any work in progress to improve
>> templates render performance? Times when having medium to big data and/or
>> loops get excesively high, compared to jinja2 which sadly is not as easy to
>> use as django native template language. I would really trade a feature or
>> two in order to achieve better performance. For example, accessing
>> variables from a dict, or even calling functions, all with the same syntax,
>> I believe there's a huge overhead in there, and trading a xx.call for
>> xx.call() is not such a big deal.
>>
>> What about a high performance option inside a template which trades
>> flexibility for performance.
>>
>>   --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/546aacd0.caa7340a.6c15.29a8%40mx.google.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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBtLaij4G%2BF63qG8jVpaPHyp3oFLKD%2B9Axx3nxjrUvs%3DDg%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCXQiOg%2BSK8ZZF78SSXWbibppaVmTemqWE6NOSDWm%2BY7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please add exists subquery to queryset api

2014-11-10 Thread Curtis Maloney

Can you provide the "natural" SQL version you'd rather see generated?

Something like:

SELECT ... FROM myapp_a WHERE NOT EXISTS (SELECT 1 FROM myapp_b T1 WHERE
T1.a_id = myapp_a.id AND T1.criteria = True)

perhaps?


On 11 November 2014 16:18, George Ma <george.ma1...@gmail.com> wrote:

> Yes, the actual sql is very close to this one. But I just feel this
> approach is like a hack. Because I always have to reverse the logic first
> and then reverse again. Not as natural as exists subquery.
>
> On Monday, November 10, 2014 5:53:47 PM UTC-7, Curtis Maloney wrote:
>>
>> If you want to know the SQL generated for any particular queryset, you
>> can just:
>>
>> print str(qs.query)
>>
>> On 11 November 2014 11:39, George Ma <george...@gmail.com> wrote:
>>
>>> For simplicity, let's assume we have a model A and model B.
>>>
>>> class A(models.Model):
>>> name = models.CharField(max_length=200)
>>>
>>> class B(models.Model):
>>> a = models.ForeignKey(A)
>>> criteria = models.BooleanField(default = False)
>>>
>>> Let's say there's a requirement to find A that doesn't have a B with a
>>> true criteria. To me, it makes more sense to use a "not exists" subquery.
>>> Right now, I have to find all the A with the reverse conditions and exclude
>>> such cases. Something like:
>>>
>>> A.objects.exclude(pk__in = A.objects.filter(b__criteria = True))
>>>
>>
>> I think you'll find this would be something like:
>>
>> SELECT  FROM myapp_a WHERE NOT pk IN (SELECT id FROM myapp_a T1 INNER
>> JOIN myapp_b T2 ON (T1.id = T2.a_id) WHERE T2.criteria = True)
>>
>> The problem with this approach is that: first I don't know how the
>>> performance would be; second, it's not very natural from sql query's
>>> perspective.
>>>
>>
>> Performance should be ok, from what I can see...
>>
>> Would be interested to see what the actual SQL is.
>>
>> --
>> Curtis
>>
>>  --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/19f716f4-2367-492c-ac1e-a4f48c4a2c01%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/19f716f4-2367-492c-ac1e-a4f48c4a2c01%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSA%2Bo7Hjc4NicUTfqQ7TzvzfMOmyWms_aiez3B1eG43PKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: South's --update equivalent for Django 1.7 migrations

2014-10-08 Thread Curtis Maloney

Since I didn't know about the update feature in South... can you explain
how it would be different from migration squashing in 1.7?

--
C

On 8 October 2014 17:33, Petri Lehtinen  wrote:

> Hi!
>
> The database migration system in Django 1.7 is really great and
> seems to work very well. However, since I'm a long-time South
> user, there's one feature that I'm missing: the possibility to
> update an existing migration (the --update flag to South's
> schemamigration command).
>
> I think it's an important feature because it allows you to make
> massive changes to your models when developing a new feature, because
> it rolls back the migration and rewrites it, effectively wiping
> everything and starting from scratch for that migration. I can rename
> tables, change foreign keys to normal fields and vice versa,
> add/remove/rename M2M fields freely, etc., things that the migrations
> don't normally handle very well automatically. When developing,
> there's no need to retain data, so it's OK to roll back and lose all
> the data in newly created tables, for example. It's also not very
> efficient to leave all those intermediate steps in the migration
> history to wait until squashmigrations is used some time in the
> future.
>
> As a proof-of-concept, I created a shell script that does the
> migration updating for a given app. It's not an universal
> solution because it's tied to a certain directory hierarchy,
> though. Here it is:
>
> #!/bin/sh
>
> project=PROJECTNAME
> app=$1
>
> cur=$(./manage.py migrate --list $app | tail -n 1 | grep '\[X\]' | sed 's/
> \[X\] //')
> prev=$(./manage.py migrate --list $app | tail -n 2 | head -n 1 | grep
> '\[X\]' | sed 's/ \[X\] //')
> if [ -z "$cur" -o -z "$prev" ]; then
> echo "Unable to find out current or previous migration. Have you run
> all migrations?"
> exit 1
> fi
> echo "Rolling back to:" $prev
> echo "Deleting and updating:" $cur
> echo "Are you sure? [yN]"
> read x
> [ "$x" != "y" ] && exit 0
> ./manage.py migrate "$app" "$prev"
> rm $project/$app/migrations/$cur.py
> ./manage.py makemigrations "$app"
>
> What do you think? Could functionality like this be added to Django?
> Are there problems I've missed with this approach?
>
> Petri
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20141008063316.GE32167%40p29
> .
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSA19segRAgrz6942_PCuEe%3D-4G_eYe2C%2BD6X5vNc0adDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Storage engine aliases?

2014-10-02 Thread Curtis Maloney

On 2 October 2014 16:46, Jannis Leidel  wrote:

>
> On 01 Oct 2014, at 14:33, Collin Anderson  wrote:
>
> > In hindsight I regret not having pushed harder for integration of
> staticfiles into core instead, lots of confusion could have been prevented,
> IMO.
> >
> > Is it too late to move to core?
>
> Good question, if we’d left the public API in django.contrib.staticfiles
> following the deprecation policy intact we may be able to move it into
> django.core.files I guess.
>
> If something like that were be tried I would also recommend to fix the
> ambiguity with regard to “media” and “static” by renaming the first to
> “uploads”.
>

That would be misleading, as it's not just uploads.  For instance, if your
site generated report PDFs, I'd expect them to be stored in MEDIA.

I tend to characterise them as :

static -- What is an integral part of your site. What you keep in source
control, and is required for the site to function.

media -- what happens as a result of your site functioning.

--
Curtis

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAiWOOo9kdts_aejTx3-ypv5yJdHe1Bscr8PYz7gPCEGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Transaction management and atomic

2014-09-30 Thread Curtis Maloney

This is primarily a function of the DBMS.  When your operations cause a
DB-level error, the DB needs to roll back the transaction to clean up.

If you don't, you're operating on an unknown state.

Django can not control this beyond wrapping the "risky" operation in a
transaction.

Consider -- exactly what should Django do to clean up the database thrown
integrity error without a transaction point to roll back to?

--
Curtis


On 1 October 2014 11:47, Cristiano Coelho  wrote:

> Hello there,
>
> I have recently updated to django 1.7, from 1.5 and one of the main
> changes I had to do was to replace all deprecated
> transaction.commit_manually to transaction.atomic, so far so good.
>
> After this, I have found out that if an IntegrityError or DatabaseError
> exception happen inside a code that is decorated with @transaction.atomic
> (or inside a with transaction.atomic) and the exception is handled (not
> throwing it out from the atomic block) the whole transaction gets invalid,
> and any other database access will fail, just as described in the docs
> (silly me I didn't read them with enough depth).
>
> As mentioned in the docs, the solution is to also put the "exception
> throwing code" inside another atomic block, and catch the exception outside
> of it. I can not describe how anoying this is, compared to the old
> behaviour where I could easly decide when to commit or rollback, now I have
> to review my whole code to detect the places where a database save is
> performed and the exception is handled, and add another atomic block to it.
>
> I believe this was an issue heavily discussed with the develpers and they
> came to this as the best option, but there needs to be another easier way
> to handle this kind of issue.
> What are the complications of leaving the transaction in a correct state
> even if an operation raises a database error and the exception is handled
> silently (not thrown outside of the atomic block)? This was totally
> possible with the deprecated transaction functions, where you could do all
> your logic and just at the end handle the transaction commit or rollback,
> and didn't matter what happened inside of it. But now this is imposible,
> you need to keep a sharp eye on every database save you perform and
> surround it with another atomic block just in case it raises a database
> error exception.
>
>
> To make the issue clear, here's a sample code:
>
> First one shows what would my current code look like, where add_children()
> would raise an exception because generate_relationships() was not inside
> another atomic block.
> With the old transactions api, I could easily surround the whole code in
> another try/except, and at the very end commit or rollback, and everything
> would be fine even if generate_relationships() throws an exception, it
> would be siltently ignored.
>
> from django.db import IntegrityError, transaction
> @transaction.atomicdef viewfunc(request):
> create_parent()
>
> try:
> generate_relationships()
> except IntegrityError:
> handle_exception()
>
> add_children()
>
>
>
> Now this is how the code should actually be with current django 1.7 in
> order to prevent an error and get the excepted behaviour.
>
> from django.db import IntegrityError, transaction
> @transaction.atomicdef viewfunc(request):
> create_parent()
>
> try:
> with transaction.atomic():
> generate_relationships()
> except IntegrityError:
> handle_exception()
>
> add_children()
>
>
> It would be great, if the transaction api could work as the first code,
> with the results of the second one. Meaning, even if
> generate_relationships() raises an exception, and it is handled correctly,
> the transaction would still be valid to be used.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e347fe6d-78c8-4c15-848d-3a82415c3550%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

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

2014-09-03 Thread Curtis Maloney

Interesting idea... so much so I'd like to steal it :)  However, since it
can be implemented as a 3rd party app, I suspect you'll get some push-back
from trying to get it into core.

I've recently started work to reimagine my "sniplates" project [
https://bitbucket.org/funkybob/django-sniplates], which overlaps some of
these ideas.

My plan is to allow you to load "widget" sets from another template
[widgets are simply blocks in the template], and use them within your other
templates.

Since the widget sets are retained in the render_context, you can load them
in inherited templates and access them all the way down.

I was also going to include the {% reuse %} tag from formulation, which
lets you re-use any block tag from the current template context.

I'd be interested in including your idea into my app, if you're wiling to
collaborate.

--
Curtis



On 4 September 2014 02:10, Sam Willis  wrote:

> Hi All,
>
> I would like to propose a new template tag to be included in Django, it is
> sort of a cross between 'include' and 'extends'. You can find an
> implementation here:
> https://gist.github.com/samwillis/af3992f69c2597a16252
>
> The main use case for this tag is being able to create reusable
> 'components' for rendering a website. Say for example a page header, a
> panel with headers and footers, or a modal window (as seen in the Bootstrap
> framework). Rather than needing to repeat the html everywhere you need it
> and having to search out all occurrences to make a change to the structure
> you can create a simple template and include it.
>
> To some extent this can currently be done with either an included template
> using the '{% include "template.html" with var="value" %}' syntax or using
> a custom template tag. However, the former isn't suitable for changing
> whole blocks in the include template, and the latter can be overkill and
> may not be suitable for a designer with little knowledge of Python and the
> Django Template API.
>
> The 'use' tag loads a template and renders it with the current context
> similar to the 'include' tag. You can pass additional context using keyword
> arguments as well as override blocks in the included template.
>
> Example (simple) template:
>
> 
> {% block heading %}{% endblock %}
> 
>
> Example 'use' tag use with the above template:
>
> {% use "page_header.html" %}
> {% block heading %}Some Title{% endblock %}
> {% enduse %}
>
> {% use "page_header.html" with extra_class="large" %}
> {% block heading %}Some Title{% endblock %}
> {% enduse %}
>
> As with 'include' use the 'only' argument to exclude the current context
> when rendering the included template:
>
> {% use "page_header.html" only %}
> {% block heading %}Some Title{% endblock %}
> {% enduse %}
>
> {% use "page_header.html" with extra_class="large" only %}
> {% block heading %}Some Title{% endblock %}
> {% enduse %}
>
> The included template receives an additional context variable called
> 'used_blocks' which is a Dict indicating which blocks were overridden in
> the 'use' tag. Using this you can conditionally show content around the
> block. For example, if you had this template for generating a page heading:
>
> 
> {% block heading %}{% endblock %}
> {% if used_blocks.sub_heading %}
> {% block sub_heading %}{% endblock %}
> {% endif %}
> 
>
> and included it using:
>
> {% use "page_header.html" %}
> {% block heading %}My Page Title{% endblock %}
> {% enduse %}
>
> it would exclude the '' tags from the empty subheading.
>
> Finally, as syntactic sugar if you are just overriding a single block you
> can express it as:
>
> {% use "page_header.html" block heading %}
> My Page Title
> {% enduse %}
>
> These example are a little simple, but this could be incredibly useful for
> more complex components such a modal windows.
>
> I have made a first pass at an implementation here:
> https://gist.github.com/samwillis/af3992f69c2597a16252.
>
> Although I have implemented this with the 'use' word, there may be a
> better word. I considered 'embed' but thought 'use' was a little cleaner
>
> Thanks,
> Sam
>
>  --
> 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/0104008b-bb58-4730-a0dd-43c2875fa1b5%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

Re: Please don't kill the ecosystem

2014-09-01 Thread Curtis Maloney

Mostly for clarity and historical purpose, I'd like to expand on the points
you listed.

Do not take this in any way as a dismissal of the issues you've raised.

On 2 September 2014 06:45, Pkl  wrote:

>
> Hello,
>
> I once was once lured to an ideal of long-term stability and
> retrocompatibility, by nice docs like this one :
> https://docs.djangoproject.com/en/dev/misc/api-stability/
>
> But for some years, stuffs have actually been getting worse and worse,
> with each django release bringing its little crowd of nightmares.
>
> In random order, I stumbled upon:
> - removal of django.conf.urls.defaults
>
This was moved into django.conf.urls ...


> - removal of markup contrib lib (adios built-in RST support)
>
>From memory, this was due to a security issue with the Markdown library
used.  I, too , was hit by this, and ended up vendoring the tag library
into my project.


> - removal of request.raw_post_data (thus breaking about all existing
> webservice libs)
>
It was renamed to request.body, not removed.  This is because it represents
the request body, no matter the HTTP method used.


> - lots of changes in mandatory settings, like allowed_hosts or DB conf
> format,
>
ALOWED_HOSTS was added as a security measure.
The only significant DB config format I can recall was adding multi-DB
support.  Was there another?

- future removal of the very basic "mimetype" argument from django objects
> (how many apps impacted ? quite MANY I guess)
>
IIRC this was renamed to content-type, since "mime type" is, in fact, for
email.


> - future removal of request.REQUEST (aka "we're not all consenting adults,
> let's remove all tools that people could misuse")
>
I remember the discussion for this.  Primarily it was because it did cause
security issues, as well as being unclear as to which was looked up first-
GET or POST.

As someone who has been using Django since 0.91... I've seen  a lot of
change over the years, some more drastic than others.

I don't get this relentlessness at breaking, for the sake of purity, all
> stuffs that are not actively maintained, yet could be perfectly working.
>

Whilst it could be argued that, for instance, request.body and
requset.REQUEST were removed for "purity", it can also be said they were
removed for clarity (to avoid confusion) and safety (to avoid real security
issues).

As for breaking unmaintained 3rd party apps... sorry, that's how the world
works.  If you want that project to keep up to date with Django, either
incentivise the devlopers to do so, or contribute to them yourself.  Such
is open source.


> What is easier, in a deeply dynamic language like python, than keeping
> retrocompatibility ?
>
I do like this idea... it should be possible to monkey-path in at least
some of these ideas.
Open a ticket, CC me, and I'll happily work with you on a PR.
If nothing else, we can make it a 3rd party app.


> Why not keep "raw_post_data" as an undocumented alias for "body" ? Why not
> keep "mimetype" as a silent alias for "content_type" ?
>
mimetype _was_ an alias for content_type for, IIRC, much longer than the
usual 2-release deprecation cycle.


> What harm did the "markup" support in django, since no one expects such
> extensions to be 100% secure anyway (no software on earth is) ? If code
> "purity" is wanted, then why not have all these monkey-patched from a
> builtin, but removable, "django.compatibility" util ? Why not wait for 2.0,
> to remove all compatibility aliases in one single shot ?
>
The current trend with contrib apps is to remove them if they'd benefit
from a more frequent release cycle - one not tied to that of core.
Howerver, I was a little surprised to see django.contrib.markup wasn't
moved to a django-maintained 3rd party app like some others were.  Perhaps
open a ticket for that?


>
> The one killing features of django is its app ecosystem - being able to
> plug blogs, authentication systems, webservice generators, and all other
> kinds of applications, into this common framework, and benefit from the
> common auto-admin. And since all these apps don't evolve at the same rythm,
> retrocompatibility is IMHO a NECESSITY for django, not a LUXURY. Or isn't
> it ?
>


>
> Please don't kill the ecosystem, please respect the promises of
> api-stability that were once made.
>
These promises have been kept.  There is a LOT of code that could be
dropped or rewritten immediately if it weren't for the 2-relese deprecation
cycle.

One of my PRs was rejected specifically because I hadn't implemented a
deprecation path.  It would likely speed up template rendering, which I
think everyone agrees is desirable.

--
Curtis

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

Re: integrating django-secure

2014-08-27 Thread Curtis Maloney

For what it's worth, I agree with Russ.

Having security as an optional extra [which is how it will look to
outsiders] is a bad look for Django, and certainly doesn't fit with the
"Secure by default" philosophy.

--
Curtis


On 28 August 2014 10:34, Russell Keith-Magee 
wrote:

> Hi Tim,
>
> On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham  wrote:
>
>> I've started tackling one of the ideas that's been on our GSoC ideas
>> page for a couple years now: integrating django-secure. I chatted with
>> Carl about the idea and he's onboard. There are a couple of design
>> decisions we'll need to make.
>>
>
> +1 to the idea. It was part of Chris' original proposal; we just didn't
> get around to it with the available time.
>
>
>> 1. How to integrate django-secure with the checks framework
>> django-secure essentially implements its own checks framework (which
>> predates the one in Django). The tricky part is that django-secure's
>> checks are not ones that generally should pass on a
>> development instance; they're checks that only make sense to run on a
>> production server (or at least against a production settings file).
>> I'm thinking to have some way to skip these new checks by default and
>> run them only when requested (e.g. manage.py check secure
>> --settings=prod_settings). Other options include an entirely separate
>> command like django-secure implements (curently called checksecure),
>> but perhaps could be called checkdeploy and eventually extended with
>> other checks that are relevant only in production. Idea/insight from
>> those more familiar with the checks framework (Chris, Russ), would be
>> welcome.
>>
>
> Generally, I'd be opposed to the idea of Yet Another Command to run checks
> - if you make it optional, it won't get run, and this is something we want
> to be forced in front of everyone.
>
> We use DEBUG as a proxy for "In Production" in other locations in the
> codebase - e.g., whether ALLOWED_HOSTS checks are run. If we were to
> supplement that with a --production=true/false flag to the checks command
> (to override the rare legitimate occasions where DEBUG=True in production,
> or DEBUG=False in development), wouldn't that meet all the needs here?
>
> 2. How to add settings for django-secure
>> As discussed in the thread below, I'm going to explore developing an
>> API for storing settings on an AppConfig to avoid adding more global
>> settings.
>> https://groups.google.com/d/topic/django-developers/qnnCLppwA3o/discussion
>>
>> I have imported django-secure into django.contrib.secure and started
>> work on integrating it with the built-in checks framework as well as
>> removing some bits of it that have since been added to Django
>> (frame-deny, SSL-proxy support).
>>
>
> Is it appropriate for this to be a contrib package? That implies it needs
> to be added to INSTALLED_APPS; I'm not convinced that this is a desirable
> approach.
>
> If django-secure is important enough to include as part of Django's
> codebase (and I fully agree it is), I'd consider security to be part of
> core, not something you can opt out of. Including it as
> django.core.checks.security (or similar) would make more sense to me.
>
> Russ %-)
>
>  --
> 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/CAJxq84_Tq1Fnm_pG4pMSy98DOLsnLtVp9jEgTo6X8%2BH%2BJYi1dQ%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/CAG_XiSCJyiu7Wqwuoe_DjqPJRonFE0-kZvQdQtsGKcbP2CipFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: getting django 1.7 out the door

2014-08-15 Thread Curtis Maloney

On 15 August 2014 13:13, Collin Anderson  wrote:

> You rock, Andrew.
>

+1



>
> On Thu, Aug 14, 2014 at 10:48 PM, Andrew Godwin 
> wrote:
> > Solved it now! For those interested, deconstruct() was not including
> > related_name, with the result that both a ForeignKey and a ManyToMany had
> > the same related_name, and it turns out that Django really doesn't like
> > this, and there's a reason model validation complains about it.
> >
> > Andrew
> >
> >
> > On Thu, Aug 14, 2014 at 6:57 PM, Collin Anderson 
> > wrote:
> >>
> >> Hi All,
> >>
> >> If anyone's looking for ways to help get 1.7 out the door, there's a
> >> strange but reproducible many-to-many ORM bug happening in migrations.
> We
> >> could use some help narrowing down the cause of it.
> >>
> >> https://code.djangoproject.com/ticket/23288
> >>
> >> Thanks,
> >> Collin
> >>
> >> --
> >> 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/f1007cbb-6242-4a36-8f79-c58c218b6f37%40googlegroups.com
> .
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Django developers" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/d/topic/django-developers/NDNAxlqg4Yk/unsubscribe
> .
> > To unsubscribe from this group and all its topics, 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/CAFwN1uojCuzzDzrgT8Qbztaa_zf%3DgvmNrMsM8TC3e_2%2BqPxHMA%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/CAFO84S5nWGtPmuKASGB8uq-DDqPPkxHz1Ge78sy_P5Nyrrtc2Q%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/CAG_XiSDJGwz2o0Dpezi9TJ-ZpbeZhBu0BOjp2uoDR_KtE%3Dpk%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

2014-08-10 Thread Curtis Maloney

I ran into that exact problem when djangopackages changed... case mis-match
meant it took months before I had access again.


On 10 August 2014 09:35, Luke Granger-Brown  wrote:

> My only concern with this is the thing with the usernames, whereby some
> people don't use the same username on Trac as on GitHub, and that accounts
> are automatically munged together if they have the same username.
>
> As a demonstration, I found someone with the core developer tag on Trac
> (lukeplant) who didn't have a corresponding GitHub account (his is
> spookylukey), and created a GitHub account with that username and tried
> logging in to Trac. As expected, it just logged me into their Trac account.
>
> I'm not sure if this is a concern at all, but thought it was probably
> worth bringing up, or at least having some method for resolving it (some
> sort of horrific map between GitHub and Trac accounts?) It's probably
> slightly more concerning if there are people like that with greater
> privileges on Trac, which I don't believe is the case.
>
> Luke
>
>
> On Sun, Aug 10, 2014 at 12:13 AM, Wim Feijen  wrote:
>
>> Nice :)
>>
>>
>> On Saturday, 9 August 2014 21:22:07 UTC+2, Aymeric Augustin wrote:
>>
>>
>>> > Uhmm... but I see you moved forward and already did it?
>>>
>>> Yes, I did.
>>>
>>> --
>>> Aymeric.
>>>
>>>  --
>> 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/0dae599b-afcf-4a41-8c2b-75fead33754b%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/CALE3ZjWgUyBYmN22__Qr0ikj-0M8wo2KjgmJzPVyrwYQJ6gpPQ%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/CAG_XiSBtT0hB%3DAsiP8jvWsSgb6FNPxbTgEeWSVDV25q7pRnMGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

2014-08-08 Thread Curtis Maloney

For what it's worth, I can understand the opposition to requiring a GH
login [ostensibly a "coders" account] in order to make comments on tickets.

However, if you're opinionated on a ticket you're either a coder, or feel
strongly enough to overcome such a [low] hurdle.

Still, options of more than just GH would dissipate this issue... those
without GH, BB and Twtitter accounts would be few, I'm sure, and tools like
python-oauth-toolkit give you many options easily.

Does this debate include removing the _existing_ auth?

--
C



On 8 August 2014 17:46, Aymeric Augustin  wrote:

> 2014-08-08 8:55 GMT+02:00 Ben Finney :
>
>> Aymeric Augustin
>> 
>> writes:
>>
>> > You're right. Then just remove "to submit pull requests" from my
>> > argument and it still holds, simply because the vast majority of the
>> > Django ecosystem is on GitHub, and you can't participate meaningfully
>> > without GitHub.
>>
>> You can, at present, participate in Django's bug tracker without a
>> GitHub account.
>>
>
> The "Django ecosystem" includes third-party apps, most of which
> use GitHub issues for bug tracking.
>
>
>> The bug tracker contributions don't count, then? You consider
>> participation in bug tracker discussions to be meaningless?
>
>
> Would you mind avoiding strawman arguments?
>
> --
> Aymeric.
>
> --
> 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/CANE-7mUMrhB1L7ej%3DN1hE70CFV_EiwBG16bV6FSVCUnU6ZOgkw%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/CAG_XiSAwYNpBSn0XH17og4Bd0YStCMcGrz5e0MLGfHoe%3Ds6O8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ORM Optimization for filtering by related existence

2014-08-08 Thread Curtis Maloney

Can you create a PR, with docs and tests?

If not, we'll need to find someone brave enough to delve into the ORM and
add this [quite valid, IMHO] optimisation.

--
C



On 8 August 2014 11:16, David Butler  wrote:

>
>
> On Thursday, August 7, 2014 6:48:22 PM UTC-5, Tim Graham wrote:
>>
>> Does .filter(somefield__isnull=False) not work for what you're trying to
>> do?
>>
>
> If I do .filter(somefield__isnull=False) it tries to do a LEFT OUTER JOIN
> on the table for somefield  instead of a WHERE EXISTS (...) and if that
> table is very large then it is pretty slow
>
> Perhaps the answer is just to modify what __isnull does instead of making
> a new lookup
>
>
>> On Thursday, August 7, 2014 7:43:07 PM UTC-4, David Butler wrote:
>>>
>>> It would be nice if there was some database level optimization for
>>> getting objects that have related objects that exist.
>>>
>>> This is a slow filter:
>>>
>>> qs = [obj for obj in qs if qs.somefield_set.exists()]
>>>
>>> Could be faster with something like this:
>>>
>>> qs = qs.filter(somefield__exists=True)
>>>
>>> Here is some (rough, probably grossly over simplified but working) code:
>>>
>>> Code is also available here if it gets garbled: http://dpaste.com/
>>> 0825PNP
>>>
>>>
>>> query_template = (
>>> '{not_part} EXISTS (SELECT 1 FROM "{table1}" WHERE '
>>> '"{table1}"."{table1_column}" = "{table2}"."{table2_column}")'
>>> )
>>> def filter_by_reverse_feriegn_key_existance(qs, **kw):
>>>
>>> for arg, value in kw.items():
>>>
>>> assert arg.endswith('__exists')
>>>
>>> if value is True:
>>> not_part = ''
>>> elif value is False:
>>> not_part = 'NOT'
>>>
>>> Model = qs.model
>>> for field in arg.rstrip('__exists').split('__'):
>>> field = Model._meta.get_field_by_name(field)[0]
>>>
>>> qs = qs.extra(where=[query_template.format(
>>> table1=field.model._meta.db_table,
>>> table1_column=field.field.db_column,
>>> table2=Model._meta.db_table,
>>> table2_column=Model._meta.pk.db_column,
>>> not_part = not_part
>>> )])
>>>
>>> Model = field.model
>>> return qs
>>>
>>>
>>> This works on postgres, and is ~100x faster
>>>
>>> I would be interested in any comments
>>>
>>  --
> 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/d4f2d1bc-326d-43d0-a53c-d2b1c25465cd%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/CAG_XiSAaSWExeOSFaf0L-_2Bs3dduM%3D2HDMPninvRH%3DcPm3s4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

2014-08-04 Thread Curtis Maloney

Stupid phone

The reason for that cipher over xor was to avoid non printable characters.

Any other solution is fine. Xoring the lower 4 bits reduced the entropy too
much in my view.
On Aug 5, 2014 6:11 AM, "Donald Stufft"  wrote:

> On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmail.com)
> wrote:
> > The patch I've written implements this mitigation, with one difference:
> > instead of using xor, it uses a Vigenère cipher (as suggested by
> FunkyBob),
> > as xor was creating non-printable characters which caused problems. I
> think
> > this should be OK as Vigenère is commonly used for one-time pads and does
> > more or less the same thing to characters that xor does to bits.
> >
> > This is pretty much what django-debreach does, except that *it* uses AES
> > instead of xor (i.e. the output is K + AES(K, S).). However, this adds
> > processing load to every request and a dependency on PyCrypto, and as far
> > as I can tell this doesn't actually add any benefit over xor/Vigenère.
> >
> > So, in summary, I think I'm doing nearly exactly what the paper says,
> and I
> > think it effectively makes the attack practically impossible, but I'd
> love
> > to hear from someone who has a better idea than I as to if I'm actually
> > correct on all of this.
>
> Thoughts:
>
> -1 on implementing our own Vigenère cipher.
>
> If I understand the patch correctly it doesn't use the pad as a nonce
> exactly,
> it will happily accept the same pad + CSRF token multiple times over and
> over.
> Anything that treats the CSRF token as an opaque sequence of characters
> (which
> is essentially what it is prior to this patch) should be backwards
> compatible
> if my understanding is correct. Further more it looks like the original
> unpadded CSRF token is still in the cookie so anything that pulls it's
> tokens
> out of the cookie directly should be completely unaffected.
>
> Is my understanding correct? If so then the only thing I can imagine this
> breaking is something that expected a certain length for the CSRF token and
> afaik the length of the token is not within our backwards compatibility
> promises.
>
> --
> 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.53dfe906.327b23c6.1280a%40Thor.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/CAG_XiSDDwnEScQ26DJduiYDTyYjCK5B8R0mBvHOr4HQGMBC7%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

2014-08-04 Thread Curtis Maloney

As mentioned the cipher choice was mine. It was, also as mentioned
On Aug 5, 2014 6:11 AM, "Donald Stufft"  wrote:

> On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmail.com)
> wrote:
> > The patch I've written implements this mitigation, with one difference:
> > instead of using xor, it uses a Vigenère cipher (as suggested by
> FunkyBob),
> > as xor was creating non-printable characters which caused problems. I
> think
> > this should be OK as Vigenère is commonly used for one-time pads and does
> > more or less the same thing to characters that xor does to bits.
> >
> > This is pretty much what django-debreach does, except that *it* uses AES
> > instead of xor (i.e. the output is K + AES(K, S).). However, this adds
> > processing load to every request and a dependency on PyCrypto, and as far
> > as I can tell this doesn't actually add any benefit over xor/Vigenère.
> >
> > So, in summary, I think I'm doing nearly exactly what the paper says,
> and I
> > think it effectively makes the attack practically impossible, but I'd
> love
> > to hear from someone who has a better idea than I as to if I'm actually
> > correct on all of this.
>
> Thoughts:
>
> -1 on implementing our own Vigenère cipher.
>
> If I understand the patch correctly it doesn't use the pad as a nonce
> exactly,
> it will happily accept the same pad + CSRF token multiple times over and
> over.
> Anything that treats the CSRF token as an opaque sequence of characters
> (which
> is essentially what it is prior to this patch) should be backwards
> compatible
> if my understanding is correct. Further more it looks like the original
> unpadded CSRF token is still in the cookie so anything that pulls it's
> tokens
> out of the cookie directly should be completely unaffected.
>
> Is my understanding correct? If so then the only thing I can imagine this
> breaking is something that expected a certain length for the CSRF token and
> afaik the length of the token is not within our backwards compatibility
> promises.
>
> --
> 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.53dfe906.327b23c6.1280a%40Thor.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/CAG_XiSCBTn88VhZFaVXdxmmSWm_sTvLSYw2aY%3DNeRqjEhUj93Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

< 1 2 3 >

101 - 200 of 280 matches

Mail list logo