Re: GDAPS

2019-06-16 Thread Curtis Maloney
[forgive me for typing as I think... but sometimes it's the best way to 
think ;) ]


On 6/17/19 5:19 AM, Christian González wrote:

Am 16.06.19 um 10:06 schrieb Adam Johnson:
* What do you think are the implications for Django core? Is there 
anything Django could do better to support this and all the other 
plugin systems you’ve looked at? Also I’m totally sure you can 
contribute, it’s not scary and there is a lot of information on 
getting started! See

https://docs.djangoproject.com/en/dev/internals/contributing/


Yes, I'll have a deeper look at the contributing guidelines.
The most parts where I had to struggle within Django were:

* The settings, to let each module provide it's own setting. There is no 
standardized way of having settings saved. I borrowed the 
graphene-django way - which had copied it from DRF ;-)


I've given some thought to this over the years, and what I think we've 
somehow missed in settings until now is ... Namespaces!


Whilst we have namespace-by-prefix (CACHE_*) and namespace-by-dict 
(DATABASES = {} ) when it comes to plugins having their own declared 
settings, we may want to move to something a little more formal.


Any plugin or app ought be able to declare its own settings and their 
defaults. And ISTM the "obvious" place to do this is in their AppConfig


Except, that may be too late, since we may want/need the settings before 
apps are loaded?


So the alternative is for a plugin to declare in its entry points a 
reference to its settings declaration. This way, all 3rd party settings 
can be gathered, vetted, and applied before having to scan the 
INSTALLED_APPS list.


Now what we'll need is a way to avoid namespace clashes, and a 
dev-friendly way to update these settings in settings.py


--
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/d8cc1a37-b8ae-3a0c-021b-92ec6f7e5701%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: How to deal with potential Django bugs you come accross

2019-05-13 Thread Curtis Maloney

Hi Erik,


On 5/13/19 8:22 PM, Erik Stein wrote:


Hello everyone --

 From time to time I come accross a potential bug in Django core, but 
because of a tight schedule don't have the time to dive into it and 
write a proper ticket. How would you suggest to deal with it?



my personal position would be to open a ticket with what information you 
_do_ have, so the discovery is not lost.


The "worst case" is one of the ever efficient Django Fellows comes by, 
tests it out, and closes it as "works as expected".


If you _don't_ log the issue, it _will_ be forgotten about, because 
we're all human. :)



Today e.g.

– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL

works in debug mode, but gives an internal server error without any 
backtrace in production mode.


This was caused by a buggy 404.html template, but probably buggy 404 
templates should give a backtrace, too, and i18n_patterns shouldn't be 
concerned by this anyway.


Certainly a solution worthy of discussion!

Are those notes something which should get into Trac to be investigated 
later?


Absolutely yes!


Thanks for you opinion and guidance,


--
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/f91ecd30-a077-956c-a5af-1027359c65f2%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-25 Thread Curtis Maloney

On 4/25/19 8:14 PM, James Bennett wrote:

I like Django's style guide.

I like the *idea* of an autoformatter.

I dislike the particular mostly-unconfigurable style Black enforces, and 
I find that several of its rules negatively impact code readability.


So I would be -1 on applying it to Django.



I think this very clearly sums up what I was going to say on this topic, 
if I hadn't already.


I see the benefits [lower barrier to entry, time saving for the Fellows, 
etc], but I don't believe Black is the answer.


Specifically because in my own experience with it (as well as 
demonstrated in this list) there are cases where its style makes code 
significantly harder to read.


And IMHO, the sole purpose of a consistent style (and thus a style 
guide) is to reduce the cognitive load of humans parsing code.


--
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/2e34fd6f-98c7-d34f-630c-b0945d621ec5%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: First ASGI pull request is ready for review

2019-04-24 Thread Curtis Maloney
I cannot find emoji enough to express how much I appreciate the work 
you've put into this :)


--
Curtis


On 4/25/19 6:50 AM, Andrew Godwin wrote:

Hi everyone,

Just wanted to drop a note and say that the first pull request in the 
series needed to enable async in Django is now ready for review: 
https://github.com/django/django/pull/11209


This is a very minimal amount of work to get Django async-safe and 
understanding ASGI as an application interface, but the idea is to land 
this so it's definitely in 3.0, and then work on getting async abilities 
down to views before the 3.0 feature freeze if we can.


Once those two things are down, we can then expand the effort out a lot 
more and have some work for new contributors to get their teeth into, as 
we can then start making all the other parts of Django async-capable as 
a parallel effort.


Reviews and comments on the PR are encouraged; I want to make sure this 
is not going to hurt existing sync Django when it lands, and that it's a 
useful stepping stone towards async in views.


Andrew


--
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/dcfe51af-8e6c-ca1e-cf12-6409b93720db%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Why does ModelForm do validation and not Model

2019-04-17 Thread Curtis Maloney

On 4/17/19 4:55 AM, Aymeric Augustin wrote:

Hello Will,

It's mostly for performance reasons, since validation can be expensive. 


Really? My memory was that it was (a) backward compatibility [model 
validation was added later], and (b) practicality [try catching 
everywhere in your code you save a model, and enforce catching 
validation exceptions there].


Models _support_ validation, but don't _enforce_ it.

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


Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

2019-04-14 Thread Curtis Maloney

On 4/13/19 10:22 PM, Markus Holtermann wrote:

Thanks for the proposal, Shai. I quite like it.

As discussed at the DCEU sprints I think I'd like to be able to omit the display form of an item and have it auto 
generated from an item's name, i.e. turning "FOO_BAR" into "Foo Bar" (`key.replace("_", 
" ").title()`)



For reference, this is what my project does ( labeled-enums: 
https://pypi.org/project/labeled-enum/ )



--
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/5a5956f5-84ba-1abf-9dbe-56ba1fbe84dc%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Add to QuerySet method `one` that acts as `first` but without ordering

2019-04-14 Thread Curtis Maloney

On 4/14/19 8:02 PM, Florian Apolloner wrote:

Hi,

while your arguments for adding `.one` are all good and well, I think 
adding yet another function will add quite some confusion and will make 
arguing harder imo. As a middleground I could imagine adding an 
`ordered=True/False` argument to first to turn off ordering as needed. 
This will also make it easier to argue about it in the docs I think. 
Would that work?




I was thinking the same for most of this thread... I would just 
bike-shed it as, for instance "ensure_ordering=False" or 
"stable_order=False" so you more clearly know what you're asking for.


--
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/ffc53023-83d5-b31d-c77e-96b403f69b5a%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-14 Thread Curtis Maloney

So to summarise the discussion so far:

1. automated code formatting will be a great boon - reduce work, lower 
barrier for new committers, reduce work for the fellows, etc.


2. there are issues with git history in doing "the great commit".

3. there are issues with black's formatting choices.


So to address 1:

I am entirely +1 for automated code formatting to take the work out of 
our hands.


Can such a tool be automated into, say, github in a way that doesn't 
create extra commit noise?


To address 2:

I side with those who favour a progressive solution, whereby new code 
only has the new tool applied.


That said, there might be cause to suggest a deadline [perhaps a N.0 
release?] where all remaining code is "cleaned".


And finally 3:

My perspective on the goal of any code formatting tool is this:

When we as developers approach a piece of code, our goal is the 
understand its intent and its implementation of that intent.


In the process of reaching that, we pass through the stages of (a) 
identifying the relevant code, (b) understanding the action of the code, 
and (c) understanding the intent of the code.


Good code formatting choices will remove or reduce the cognitive load in 
(b) and (c).


In my experience with using black [we use it at work], there are 
numerous choices (including those demonstrated in this list already) 
where it can significantly _increase_ the cognitive load in simply 
parsing the code.


As simple as black can make the job of code formatting, I feel I'd 
rather see a different tool that retained the benefits of "trivial code 
reformatting", but still allowed us to retain some of Django's existing 
code formatting rules.


(An interesting [and defensible] choice, we had a module with a lot of 
strings wrapped across lines. black opted to push them onto the same 
line, but NOT to merge them.  This is because in Python prior to 3.7, it 
would have altered the generated AST - one of the guides black uses)


--
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/56392596-0246-b62b-4725-628a2b0801ae%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: More standard template filters

2019-04-05 Thread Curtis Maloney

On 4/5/19 8:16 PM, Adam Johnson wrote:

FYI Jinja2 allows (most) python expressions, so this would Just Work(TM):

{{  myvar.startswith("x") }}

Django Template Language has a lot of legacy that prevents this from 
happening, afaiu it would not be possible to move to it.


For "legacy" read "philosophical choices" :)

--
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/496aa5dc-058c-4126-164a-e421cd20162a%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: More standard template filters

2019-04-05 Thread Curtis Maloney

On 4/5/19 3:06 AM, Collin Anderson wrote:

Hi All,

I use django templates a lot and I always wished there was a 
myvar|startswith:"teststring", myvar|endswith:"teststring" and a 
myvar|contains:"teststring" filter.


It's almost like we need a syntax for calling methods with an argument, 
just like we can with filters.


For example (bring on the sheds for bikes!)

{{ myvar.startswith<"teststring" }}

I instead do stuff like myvar|slice:":10" == "teststring" which is a 
total hack.


Is this something that could be simple and common enough to add to 
django as batteries-included built-in?


Alternatively, I recall some time in the past I may have written a 
"strings" template filter library simply to provide string methods as 
filters...


--
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/a2b323bc-9f60-f4c9-6074-4d103bd6f930%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC 2019 proposal - Easy Ethereum Blockchain integration

2019-03-14 Thread Curtis Maloney

On 3/15/19 6:42 AM, Diego Lima wrote:

*Introduction*

These days, every single living being has heard of Bitcoin. Some of 
those know that Bitcoin is a cryptocurrency (crypto for short) and, 
within those, a few know that it runs on top of a technology called 
Blockchain.


Be aware that outside of the ponzi-scheme laden world of 
cryptocurrencies, "crypto" is short for "cryptography" ; be careful to 
ensure your audience knows which you mean :)



*My proposal is...*


to develop a library to supplement or support the development of django 
applications with blockchain integration.


My success indicator is whether I have made it easy for anyone to store 
and retrieve information on the blockchain inside their Django code.


This sounds like an interesting and potentially very popular project.

However, AIUI Django's GSoC projects should involve development of 
Django itself.


Is there a reason why your project could not remain a 3rd party library?
This would allow it to develop and release at a pace independently of 
Django's release cadence.


--
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/0e744ce5-714c-d7c4-7677-45d410e2750d%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

2019-02-22 Thread Curtis Maloney

On 2/23/19 7:35 AM, Collin Anderson wrote:
I wouldn't mind just rolling back the security fix (or maybe making a 
straightforward way to enable/disable the behavior). We could instead 
encourage people to use  on any links (from the 
password rest page) to untrusted urls.


I don't think it would be controversial to add the rel="noreferrer" part 
to the docs no matter what choice we make about the other functionality.


--
Curtis


On Friday, February 22, 2019 at 5:03:01 AM UTC-5, Henrik Ossipoff Hansen 
wrote:


Just wanted to chime in and say we also experienced this issue. We
ended up having to revert the security fix that was added to the
view in Django just to avoid the flood of customers reporting they
couldn't reset their passwords on our apps anymore - so I'm assuming
this affects a lot of users out there.

torsdag den 21. februar 2019 kl. 14.48.45 UTC+1 skrev Mat Gadd:

You can see this in action yourself using Chrome's Dev Tools.
Open Dev Tools, then their Settings, and turn on "Auto-open
DevTools for popups". Then, click any link in the Gmail web app.
You'll see you go via google.com/url?q=original_url_here
. Since they're doing
this with JavaScript, the links look like they're going to open
the real URL, but they /don't./

On Thu, 21 Feb 2019 at 10:44, Mat Gadd  wrote:

Exactly that, yes. We've disabled all click tracking that we
can, but Gmail has its own redirect which causes Safari's
privacy features to kick in. (Some?) Gmail users are unable
to use the password reset emails.

On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:

Mat, are you saying you're seeing Safari still blocking,
even with click tracking turned off, because GMail
itself is inserting a redirect?

PJJ
http://philipjohnjames.com


On Wed, Feb 20, 2019 at 4:46 AM Mat Gadd
 wrote:

We're also now seeing Gmail users complain that the
password reset links don't work, even after we
disabled click tracking. It seems that Google are
inserting their own click tracking into users'
emails, which is… weird?

The markup of links is transformed to the following
(where … is our original URL):

https://www.google.com/url?q=
…">Link text here

Gmail is a *huge* provider of emails, and they make
up around 54% of our user base. Anyone using the
Gmail web app can no longer reset their password
simply by clicking the link in the email.

On Wednesday, 23 January 2019 12:51:22 UTC, Perry
Roper wrote:

It would appear that this affects a large number
of users. We're also experiencing this in the
following configurations.

- Mailgun click tracking enabled + Safari 12.0
on MacOS or any browser in iOS 12
- Clicking the link in the Gmail app or web app
(Mailgun click tracking disabled) + Safari 12.0
on MacOS or any browser in iOS 12.

All iOS 12 browsers and MacOS Safari users using
the Gmail app, or in any email client if the
site they are requesting a password from uses
link tracking.

On Thursday, 22 November 2018 20:43:15 UTC+7,
Mat Gadd wrote:

Hi all,

I raised a ticket
 
regarding
this and was directed here to discuss the
topic. The summary is that the combination
of using click-tracking redirects (which are
popular with a variety of email providers)
with the Django contrib.auth password reset
views does not work in Safari on macOS and
iOS as of the latest major versions.

It took me quite a long time to work out
what was happening, so I wanted to at least
raise a ticket where other people might find
it, but was also hoping to start a
discussion around how else the problem could
be mitigated. 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Curtis Maloney

On 2/5/19 1:09 PM, Cristiano Coelho wrote:
Pointing to Django Rest Framework should be more than enough. Anyone 
starting a project with Django and a SPA/JS architecture, will pretty 
much end up with DRF. Correct me if I'm wrong.


It's likely they'd end up with DRF, however there are alternatives.

However, by explicitly listing DRF, it might give the impression it's 
the "blessed" solution by Django...


--
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/77e1f7b8-d5c7-31a9-4e8d-55fc094cc968%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Curtis Maloney

On 2/5/19 11:52 AM, Maciek Olko wrote:

I didn't find this topic being discussed before.



I guess it wouldn't take much to say "Just like any other server-side 
framework that can parse and generate arbitrary content, Django can be 
used to support any Javascript or Mobile app that talks HTTP(S)."


Since Django doesn't care what the client is, so long as it talks HTTP...

--
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/bde91f87-1afe-2f15-4b0b-8e37fd5780dd%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: IRC Channel

2018-12-13 Thread Curtis Maloney

On 12/14/18 5:30 AM, Avi Garg wrote:

Does Django have an IRC channel? I am unable to join it if so...


There is #django on the Freenode network.

To join it you will need to create an account on their network - see 
https://freenode.net/ for more details.


--
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/acab5d07-87e2-6fdb-0593-00c7cef59c91%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: A faster paginator for django

2018-12-05 Thread Curtis Maloney

On 12/5/18 8:30 PM, Saleem Jaffer wrote:

Hi all,

The default paginator that comes with Django is inefficient when dealing 
with large tables. This is because the final query for fetching pages 
uses "OFFSET" which is basically a linear scan till the last index of 
the current page. Does it make sense to have a better paginator which 
does not use "OFFSET".


If this sounds like a good idea, I have some ideas on how to do it and 
with some help from you guys I can implement it.


There are a number of alternatives to this, as well as low-cost 
solutions to improve OFFSET / LIMIT pagination.


By adding an index to the sorting field(s), it can drastically improve 
the "simple" case.


Beyond that, you start getting into cases with more significant 
trade-offs.  I know Matthew Schinckel was recently working on a drop-in 
replacement paginator that used "keyset pagination" 
https://bitbucket.org/schinckel/django-keyset-pagination


There's a lot of published work on this topic, and I'd be very 
interested to see, at least, a library implementing some of these 
alternatives.


At the very least, we could want to ensure the documentation recommends 
indexing on the ORDERing fields, where possible.


--
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/f9c52aee-e28c-7ae0-306d-3ae2fbd828ee%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Consensus about visual diagrams in the docs.

2018-11-30 Thread Curtis Maloney

On 11/30/18 7:38 PM, guettli wrote:

I do not care for the strategy, I care for the goal.

How to find clear consensus now?


There is a time honored practice in open source of spurring more 
spirited discussion by presenting a solution, however sub-optimal it may be.


It may not be the accepted solution, but it's far more likely to get 
people to give input than asking for discussion.


[No, I'm not just wrapping up "patches welcome" - this is a general 
observation in life. It's just more openly recognised in OSS :) ]


--
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/88fbd91d-e4ee-89ac-5bae-1c54f7560698%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Question regarding a possible bug

2018-11-22 Thread Curtis Maloney

On 11/23/18 11:10 AM, bernie2004 wrote:

I am pretty but not 100% sure i found a bug in 2.1.2.

Would it be appropriate to post a description of what i think i found to 
this mailing-list before starting a ticket or is there a better place 
for posting things like that?


Opening a ticket directly is fine, so long as it's not a security 
related issue.


The Django Fellows do an excellent job of curating and addressing 
issues, and the Trac helps keep a coherent history of discussion of the bug.


Just go https://code.djangoproject.com/ and follow the instructions :)

--
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/fa97664e-443c-2caa-8a4a-19bbf1bda8b4%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: QuerySet.iterator together with prefetch_related because of chunk_size

2018-10-11 Thread Curtis Maloney

On 10/12/18 10:51 AM, charettes wrote:

Hello Tobias,

 From my understanding the introduction of chunk_size doest't help here.

The fundamental reason why iterator() cannot be used with 
prefetch_related() is that the latter requires a set of model instance 
to be materialized to work appropriately which chunk_size doesn't 
control at all.


In other words chunk_size only controls how many rows should be fetched 
from the database cursor and kept into memory at a time. Even when this 
parameter is used, iterator() will only materialize a single model 
instance per yield.


I inferred from the original post they were suggesting to do a set of 
prefetch_related "filling" queries _per_ _chunk_


It wouldn't be as efficient as the 1+P (where P is number of prefetched 
relations) of a normal prefetch_related, but at 1+(P x Chunks) it would 
_probably_ be more efficient than the 1+(P x N-rows) it would otherwise 
be [or worse!]


--
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/fad10ba6-783d-bfbe-6b78-2500e475983f%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Question (potential feature request) on dropping database column in migration

2018-10-01 Thread Curtis Maloney

On 10/02/2018 09:42 AM, martin_x wrote:

Hi there,

Thanks for making Django a great framework for starters :D

Recently my team have run into problems when trying to remove a database 
column from the model without stopping our Django server, below is the 
timeline:


There have been processes developed for addressing this, but they're 
quite involved.


You need to ensure any field the current running codebase knows about 
never disappears. So, the process of removing a field must be spread 
across multiple code deployments


The first setting it nullable [or with a "harmless" default] so when the 
new code inserts new rows the DBMS doesn't complain.


The next deploy can then drop the field, as Django no longer interacts 
with it.


Either way, you're still likely to encounter a full-table exclusive lock 
whilst the DBMS rewrites the table to no longer include that field.


Hope this helps some.

--
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/e8a32669-b566-17ee-132e-49e9dff33256%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: RFC732 (a.k.a. brotli) support

2018-09-14 Thread Curtis Maloney

On 09/14/2018 08:24 PM, Aymeric Augustin wrote:

Hello,

I would like to be sure that Brotli is actually faster. In my 
experience, while decompression is fast, compression can be extremely slow.


https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html

It's primarily tuned for fast decompression, making it especially good 
for offline compression (i.e. compression of static assets on deploy)


At lower levels it can get as good compression as gzip, but much faster, 
or similar speed for better results. IIRC the general "wisdom" is that 
brotli at level 4 is typically faster than gzip, and gives better results.


I like the general idea of an "extensible" or plugin driven 
Content-Encoding handler, though it would require at least some 
preferencing engine so you can influence which algorithm is chosen by 
(a) browser supported, (b) local preference, and (c) content type.


--
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/836eb496-a2bf-5362-695c-673ae9ccd948%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Not Creating test DBs with PG backend

2018-08-28 Thread Curtis Maloney

On 08/28/2018 08:33 PM, Tim Graham wrote:

Why is a new option needed? Why can't --keepdb be used for this use case?


Because that would be different behavior.

If you can convince me that using --keepdb is a solution, then I will 
use your argument to say that --keepdb should be on always.


What I'm looking to offer users is to create and clean up objects in the 
test DB, separate from create/drop test DB.


However, I want to do this in a way that doesn't weaken the existing 
protection for "Oops, we're trying to use a test DB that already 
exists... did you make a mistake?  We don't want to trounce real data."


--
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/a2f93f80-ff4d-9082-76c4-2f186a3b9a7a%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Not Creating test DBs with PG backend

2018-08-28 Thread Curtis Maloney

Greetings,

one problem that turns up more and more frequently, it seems, is that 
someone is trying to run tests but can't because of the following scenario:


1. The user they connect to the DB using a role that does NOT have 
permission to create a DB


2. Django's PG adapter, when keepdb is not set, will attempt to create 
the DB


3. If the create fails, and NOT with the error of "duplicate DB name", 
KABOOM.


The error they get is that the user does not have permission to create 
DBs, since permissions are checked before testing if the name exists.


Instead, I'm trying to leverage the existing _database_exists check used 
by keepdb.


My initial attempt checked if the DB exists and, if it does, issues a 
"DROP OWNED BY CURRENT_USER;" instead of calling _execute_create_test_db.


Of course, this failed the tests, and rightly so. This obliterates the 
protection of connecting to the wrong DB... and, in fact, makes that 
mistake far FAR more damaging.


So I'm looking for input on what might be the best direction moving forward:

1. wrangle a new option to say "use existing" ... to allow using an 
existing DB if it exists.


2. prompt the user to confirm they want to use the existing DB... and 
perhaps prompt a second time to confirm they want to DROP OWNED BY...


3. some other option?

The first option, at least, will possibly require more invasive changes, 
since higher levels of the code make assumptions about 
_execute_create_test_db and when it will succeed / raise exception.


--
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/3b1324e9-c3c1-6ae6-491b-3c9d9c5be47f%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: A Django Async Roadmap

2018-08-20 Thread Curtis Maloney
In general this sounds like a tremendously useful tool... I'm caused to 
wonder, however... what, if any, are the performance impacts?


--
Curtis



On 08/21/2018 08:10 AM, charettes wrote:

Regarding the lazy loading of deferred fields and foreign keys
I wanted to mention I've been working on a third-party application
that allows overriding the default behavior[0].

The project works by tainting objects retrieved from "sealed"
querysets and having fields descriptors lookup whether or not
the object is "sealed" on attribute access and warn the developer
about it if it's the case. Warnings can be elevated to errors
using `filterwarnings` when deemed appropriated (e.g. CI, staging).

It has been an useful tool to assist in figuring out where
`select_related()` and `prefetch_related()` should be used
to adjust complex projects database interactions.

I assume a similar pattern could be used to mark objects retrieved
from `QuerySet.__aiter__` to prevent non-async queries from being
performed on attribute accesses; on `Model._state.async = True`
field descriptors would error out.


Cheers,
Simon

P.-S.

While the project might look complex most of the code takes care
of the delicate tasks of replacing fields descriptors once models
are configured which could be significantly simplified if it was
part of Django core.

[0] https://github.com/charettes/django-seal
Le samedi 9 juin 2018 02:30:59 UTC-4, Josh Smeaton a écrit :

I think most of what you've laid out sounds great and that pursuing
async Django is in the projects best interests. The sync to async
and async to sync wrappers that have come out of channels give me
much more confidence that this project is doable in a reasonable
amount of time with backwards compatibility being preserved.

The only real concern I have at the moment is around your comments
regarding on demand foreign key traversal. If existing code running
synchronously is going to be impacted, that's going to be very
difficult for a lot of people. If it's only asynchronous traversal
that'll have issues, then I have no real concern, as on demand
foreign key fetching is usually a bug anyway.

Having a brief read through the psycopg asynchronous docs[0], it
looks like a number of features will be impossible or troublesome to
use, like transactions, executemany, and named cursors (.iterator()
with server side cursors). We'd also need to investigate how
pgbouncer would work in async mode, as most large sites using
postgres are also using pgbouncer. I would expect support can only
further improve, especially if there is a driver like django
pushing. Fallback would just be to run inside a thread pool though,
so it's not a blocker for the rest of the proposal.

Very exciting times ahead!

[0] http://initd.org/psycopg/docs/advanced.html#asynchronous-support


On Monday, 4 June 2018 23:18:23 UTC+10, Andrew Godwin wrote:

Hello everyone,

For a while now I have been working on potential plans for
making Django async-capable, and I finally have a plan I am
reasonably happy with and which I think we can actually do.

This proposed roadmap, in its great length, is here:

https://www.aeracode.org/2018/06/04/django-async-roadmap/


I'd like to invite discussion on this potential plan - including:

  - Do we think async is worth going after? Note that this is
just async HTTP capability, not WebSockets (that would remain in
Channels)

  - Can we do this in a reasonable timeframe? If not, is there a
way around that?

  - Are the proposed modifications to how Django runs sensible?

  - How should we fund this?

There's many more potential questions, and I really would love
feedback on this. I'm personally pretty convinced that we can
and should do this, but this is a decision we cannot take
lightly, and I would love to hear what you have to say.

Andrew

--
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/0b3b92b9-eee7-4909-82d6-c0138e8b5760%40googlegroups.com 

Re: HTML5 and XHTML5 documents

2018-08-17 Thread Curtis Maloney

On 08/17/2018 06:50 PM, Nils Fredrik Gjerull wrote:

think, however, that it is more clear if we give it a value. By the way,
the syntax is not new it is the old syntax from HTML4. I have spent
quite some time cleaning up ill-formed HTML4.


One of the more significant differences between the advent of XHTML and 
now, is that HTML5 introduced standard rules for how to deal with 
"invalid" markup, meaning its handling in browsers became consistent.


XHTML was a great move to allow a shift to browsers only accepting valid 
markup, but it never happened -- in part because IE just wouldn't play 
along.


So a softer solution was found - moving to HTML5 with defined failure 
modes and handling.


Currently, ISTM the only thing standing in the way of you using Django 
for generating valid XHTML is the form widgets, in which case I suspect 
writing your own widget templates would be far less work for everyone 
involved.


You could also provide them, quite trivially, as a 3rd party app for 
other people facing the same issues as you.


--
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/42092148-d7b2-2047-287b-3c2278f7944d%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Django and Cython

2018-08-03 Thread Curtis Maloney

On 08/02/2018 07:02 AM, Daniel Anechitoaie wrote:
I'm looking at frameworks like https://vibora.io/ that make use of 
Cython to greatly improve the performance and I'm just wondering if 
something like this would work with Django?
Was there any discussion (taken into consideration) about using Cython 
to boost the performance of certain aspects of the framework?

Would it help make it faster?

I really love Python and Django for me is the best web framework out 
there, but you have to notice how fast other frameworks from other 
programming languages are.

Would using Cython help boost the performance?


There was a discussion some time ago about perhaps cythonising some of 
the template engine and other select parts of Django.  Someone did some 
eexcellent independant work on this, and you should be able to find 
their results in the mailing list archives.


However, I think you'll find the common wisdom on speeding up Django is 
to reach for tools like PyPy, which can provide hot-spot JIT 
compilation, thus focusing performance work on the parts where your app 
needs it.


Further to that, my own experiences of optimising and scaling django 
have shown often the performance bottlenecks are not where you expect.


As anyone in the industry will tell you, beware of benchmarks not 
testing what you _actually_ do.


One time we got a dramatic improvement in site resource usage by moving 
a user setting (like preferred language] into a cookie instead of the 
user session. This allowed many requests to never access the session 
store at all, avoiding a round-trip.


Another time, a site trebled in throughput (on average) by simply 
upgrading Django.  As is often the case, a smarter algorithm (in this 
case, in how QuerySets made copies) will yield improvements orders of 
magnitude more than minor optimisations.


As has been mentioned in other posts, async IO is often viewed as a 
solution to performance problems.  This is a furphy; asyncio can help 
improve resource utilisation when you have an IO-bound workload.


It can allow fewer processes to scale more readily to consume more CPU 
by avoiding blocking on IO.  It's trues that the majority of web sites 
are IO bound [waiting for DB, disk, or even other web sites].


However, this doesn't necessarily make each individual request any 
faster - in many cases, it can actually be slower.


As is always the case with improving performance, measurement and 
careful analysis are requried.


--
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/d1fbf79c-6861-0ac4-d48e-f0316d0f3ca6%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: A Django Async Roadmap

2018-06-04 Thread Curtis Maloney

On 06/05/2018 07:54 AM, Tom Forbes wrote:

Are the proposed modifications to how Django runs sensible?


I had a few random thoughts while reading your proposal:

I think getting rid of the related field references could be a big issue 
here and cause a lot of headaches for existing applications. Could we do 
this in a backwards compatible way at all? I wonder if PEP 567 
 could help here, could we 
define some kind of ‘Django async context’ and do different things 
depending on if this is true or false?


One thought about the related field stuff... whilst having it makes it 
easy to get started, any site at scale will sensibly obviate their need 
in almost all cases by using select_related, for performance reasons.


--
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/4447805e-f035-8242-957e-ffb1e0c57d51%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Spaces between argument separator and argument in template filter generate error

2018-06-01 Thread Curtis Maloney

On 05/31/2018 06:39 PM, oli...@kidsnote.com wrote:

Are there any reasons that not allow spaces between separator and arg?


My first thought would be that it starts making the syntax looser, 
meaning more things that are currently error cases would be accepted as 
valid.


Which means mistakes will no longer raise errors.

--
Curtis


2018년 5월 31일 목요일 오전 11시 41분 22초 UTC+9, oli...@kidsnote.com 님 
의 말:


In the template filter system now,

spaces between augment separator and augments generate error.
For example, the following template code generates the following error.

{{ value | filter: "arg"}}

TemplateSyntaxError at /
Could not parse the remainder: ': "arg"' from 'value | filter: "arg"'

https://code.djangoproject.com/ticket/29457



What do you think of this ticket?

--
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/131b5095-c5b7-4492-92fa-e58912ac842a%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/ab2d6097-51e4-56a2-e096-3a8189cdc6eb%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: A more useful list of common passwords?

2018-03-30 Thread Curtis Maloney

On 03/30/2018 07:05 PM, Adam Johnson wrote:

This new file sounds good to me.

Whilst you're at it, what is the new file size?


I downloaded the gist, took only column 3 (the actual passwords) and 
gzipped it, it came to 81K over the existing 3.8K. Uncompressed that's 
163K over 7.1K.


Still a tiny drop compared to a running system... but something worth 
keeping an eye on.


A quick look at the code shows, of course, that you can specify your own 
file, so IFF this new file is rejected, it can at least be easily 
offered and used.


It would probably warrant a smarter checking algorithm over the current 
one, where the validator loads the whole file into memory on 
initialization (and doesn't share it between instances).


The current solution is storing the strings in a set, so membership of 
strings in a set _should_ be fairly efficient.


--
Curtis

OOI have you seen https://github.com/ubernostrum/pwned-passwords-django/ 
, which uses Troy Hunt's massive API for all leaked passwords ?


The joy of pluggable validators is... people can choose their level of 
strictness :)


--
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/aa76a554-41be-191f-3c8f-914aadf16af4%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: A more useful list of common passwords?

2018-03-29 Thread Curtis Maloney

By which I mean... hi Brenton! Great to see you being active again :)

It's great you've taken the time to do this, and the benefits are very 
clear [improved security], but what are the costs?


Whilst you're at it, what is the new file size?

--
Curtis



On 03/30/2018 04:26 PM, Curtis Maloney wrote:

What sort of performance impact is this having over the existing list?

What's the additional memory load, if any?

--
Curtis


On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and 
included a list of 1,000 passwords considered to be "common". That 
list was based on leaked passwords and came from xato.net[1].


I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 
20,000 of which are available in a gist from Royce Williams[3], 
including the frequency, md5 hash and plain text password.


Interestingly there's 27 passwords in the Django list that aren't in 
the HIBP list. I'd post them here but they're mostly short and not 
safe for work.


I've created a ticket for the increase in size[4] but wanted to check 
in and make sure this is something django-developers thinks is valuable.


Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25 


[2]: https://haveibeenpwned.com/Passwords
[3]: 
https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7

[4]: https://code.djangoproject.com/ticket/29274

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto: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/0a215878-9d3f-4446-a018-602694f54904%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/0a215878-9d3f-4446-a018-602694f54904%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2cb005ec-5f22-a77e-ddeb-791ab85ff03c%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: A more useful list of common passwords?

2018-03-29 Thread Curtis Maloney

What sort of performance impact is this having over the existing list?

What's the additional memory load, if any?

--
Curtis


On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and 
included a list of 1,000 passwords considered to be "common". That list 
was based on leaked passwords and came from xato.net[1].


I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 20,000 
of which are available in a gist from Royce Williams[3], including the 
frequency, md5 hash and plain text password.


Interestingly there's 27 passwords in the Django list that aren't in the 
HIBP list. I'd post them here but they're mostly short and not safe for 
work.


I've created a ticket for the increase in size[4] but wanted to check in 
and make sure this is something django-developers thinks is valuable.


Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25

[2]: https://haveibeenpwned.com/Passwords
[3]: https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7
[4]: https://code.djangoproject.com/ticket/29274

--
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/0a215878-9d3f-4446-a018-602694f54904%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/5565c4fd-5de3-dc52-c952-5ad4b555bac0%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

2018-03-29 Thread Curtis Maloney

On 03/30/2018 08:57 AM, Ryan Hiebert wrote:
It's a subtle difference between how a single filter works and two 
filters work together over to-many relationships. Here's a writeup that 
I found helpful: 
https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/


It's also addressed in the documentation:

https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relationships

--
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/f31f5413-59e8-eec2-7adb-e619bf5637cb%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC 2018

2018-03-17 Thread Curtis Maloney

On 03/17/2018 08:18 PM, Manasvi Saxena wrote:

Hello Sir,

On Saturday, March 17, 2018 at 2:23:45 PM UTC+5:30, Curtis Maloney wrote:

On 03/17/2018 07:37 PM, Dmitriy Sintsov wrote:
 > Hi!
 >
 > Template languages are my favorite topic in programming.

Having written a few template engines myself... I guess it's high on my
list too :)

 > If you implement html library yourself, it is much better to
define tags
 > not as functions but as classes with base Tag class which has
properties
 > for tag name, attributes and the nested list of tags. Such way
you will
 > re-implement DOM, although it is already available in lxml library.
 >
 > So maybe it's a better idea to figure out whether lxml can be
used as
 > template engine for Django, because it can load source html into
nested
 > structures via binary optimized code. It should be cleaner and
faster
 > than manual composition of html in Python code.

Now, I like this idea as a line of inquiry.

Despite the Django Template Language being explicitly designed to _not_
use HTML syntax [like so many before it did] so as (a) not create
torturous syntaxs, and (b) not restrict it to just HTML...

I think for the case of knowingly generating HTML, using lxml opens the
door to:
1. ensuring valid markup
2. faster processing [maybe?]
3. minifying on the fly -- readable templates, minimal output.

-- 
Curtis



I was trying to explain the exact pros you have stated above and those 
were the main reason behind how I come up with this idea.
Can you guide me how I should move forward with my idea in order to 
increase my chances of getting selected in spite of that fact that it's 
rejected by the members of Django core team?


Well, you should probably look at past examples of such things, like TAL 
for the server side, and ... just about every JS framework of today 
(svelte, Vue, Knockout, etc :)


lxml should make it easy to parse, iterate, walk, mutate the DOM tree... 
now you need to determine a syntax.


--
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/b708db98-2fe9-fcdf-cb1b-3978e5ee4eb2%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: GSoC 2018

2018-03-17 Thread Curtis Maloney

On 03/17/2018 07:37 PM, Dmitriy Sintsov wrote:

Hi!

Template languages are my favorite topic in programming.


Having written a few template engines myself... I guess it's high on my 
list too :)


If you implement html library yourself, it is much better to define tags 
not as functions but as classes with base Tag class which has properties 
for tag name, attributes and the nested list of tags. Such way you will 
re-implement DOM, although it is already available in lxml library.


So maybe it's a better idea to figure out whether lxml can be used as 
template engine for Django, because it can load source html into nested 
structures via binary optimized code. It should be cleaner and faster 
than manual composition of html in Python code.


Now, I like this idea as a line of inquiry.

Despite the Django Template Language being explicitly designed to _not_ 
use HTML syntax [like so many before it did] so as (a) not create 
torturous syntaxs, and (b) not restrict it to just HTML...


I think for the case of knowingly generating HTML, using lxml opens the 
door to:

1. ensuring valid markup
2. faster processing [maybe?]
3. minifying on the fly -- readable templates, minimal output.

--
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/f690efb3-7d6b-042b-68dc-76cfa8afec5c%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Cache backends and thread locals

2018-03-07 Thread Curtis Maloney
I believe I'm (at least partly) responsible for this change, and the short 
answer is basically "historically memcache client libs have been awful with 
threading".

This may have improved, but in order to avoid a whole slew of potential 
problems (with memcache and other backbends) I copied the pattern used by 
database connections.

That said, I like your idea of sharing the connection pool between threads. It 
would mean at worst we'd wind up where we are.

--
Curtis

On 8 March 2018 06:53:57 GMT+11:00, Nicolas Le Manchet  
wrote:
>Hello,
>
>Thanks to commit f02dbbe1ae[0], the Memcached cache backend using
>pylibmc can now keep connections open between requests. Establishing a
>new TCP connection is rather expensive and each saved round trips to
>the cache server allows to shave a few ms of response time.
>
>It appears that in a multithreaded environment we could improve the
>situation even more by letting threads share the same `PyLibMCCache`
>instance.
>
>Currently in Django, each thread asking for a cache backend gets its
>own personal Backend object[1], thus each thread also get its own
>connection pool to memcached. After a few requests the process ends up
>opening as many connections to memcached as there are threads.
>
>If instead we allowed the connection pool to be shared between threads,
>connections would only be opened when necessary (other threads using
>all the pooled connections).
>
>Now the important questions. Why do we have thread locals in the first
>place? Can we share Backend instances between threads?
>
>After looking at the code of all cache backends I feel that nothing
>prevents dropping threadlocal altogether. Did I miss something?
>
>[0]
>https://github.com/django/django/commit/f02dbbe1ae02c3258fced7b7a75d35d7745cc02a
>[1]
>https://github.com/django/django/blob/master/django/core/cache/__init__.py#L64
>-- 
>Nicolas Le Manchet
>
>-- 
>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/1520452437.1399418.1295099912.51D6677F%40webmail.messagingengine.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/7D6EADB0-F6D3-410F-905D-DECDAC8D975D%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: “Abusing BinaryField” warning about binary files in DB

2018-02-25 Thread Curtis Maloney

On 02/26/2018 08:30 AM, Antoine Pietri wrote:

Can I suggest replacing the warning by something like this?:


Although you might think about storing files in the database, consider that
it might be a bad design choice. This field is not a replacement for proper
static files handling.

That said, there might be cases where you do want the guarantees that the
database offers you for binary files. Be sure to be aware of the
trade-offs[1] before you decide to do so.
[1]: https://wiki.postgresql.org/wiki/BinaryFilesInDB 




As discussed on IRC, I think the wording here is a bit weak... "it might 
be" probably ought be "it is probably".



--
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/6c9df2e0-4d84-42a7-9290-fca11a33fb0a%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Thoughts on diff-based migrations with django?

2018-02-20 Thread Curtis Maloney

Hi,

I must say your idea intrigues me... and I'd certainly like to discuss 
it further.


The first thought that comes to mind is how would such a system handle 
data migrations?


Being able to leap from one schema state to another is great, buy 
typically in the life-cycle of a reusable app it's required to also 
migrate old data into new schema.


This also happens within project-specific apps.

--
Curtis


On 02/20/2018 05:05 PM, djrobstep wrote:

Hi all,

Some thoughts on schema migrations that may interest you. By way of 
background, I'm the author of migra 
(https://github.com/djrobstep/migra), a schema comparison/diff tool for 
Postgres.


I initially wrote this tool because I wanted to be able to generate 
migration scripts automatically, without needing historical migration files.


It means that you can do things like sync your database to your models 
mostly automatically, and also explicitly test for a matching schema. 
Instead of a chain of migration files you only ever need to keep track 
of one, containing any pending changes).


I've used this approach with success on a number of projects now, and it 
seems to work pretty well. I also talked about this approach to 
migrations at the most recent PostgresOpen 
(https://www.youtube.com/watch?v=xr498W8oMRo).


The downside of this approach is that it's slightly more operationally 
complex (you need have a temporary copy of your production schema 
available for comparison purposes, typically a --schema-only dump file) 
and also that it's postgres-only at this point. It's also conceptually 
quite different to the typical Django/Rails style of migrations which 
represents a barrier to entry.


In spite of this, I think doing migrations this way has some compelling 
advantages, that are relevant to users of Django.


I'm interested in your opinions on this topic as Django developers. What 
do you think? Is it something worth offering as an option for managing 
Django migrations? If your feelings are positive, I'm happy to take a 
look at extending the code accordingly.


--
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/5f84157b-071e-42c3-90dd-6f9e3df48ab3%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/4ef38de9-780c-e2f9-9ce2-5d9621d6bf64%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2018

2018-02-13 Thread Curtis Maloney

On 02/13/2018 09:23 PM, askpriya...@gmail.com wrote:

Hello !

What is the policy regarding NoSQL datastores being used as backends ? I think 
adding support for something like MongoDB might be good idea.


Could you elaborate on why you think it would be a good idea?

I believe every other time the discussion has come up the following 
points have been made.


1. "NoSQL" is not a DB category, it is an anti-category
2. Because of there there is no common data model, or query languages.
3. If you limit yourself to just document stores, there is still no 
common query language [but this can be hidden by code]
4. Document stores are a really really bad fit for the ORM, as it's 
designed for the relational model, not document model.
5. A better approach would be to develop an ODM, which is sufficiently 
compatible with the ORM you can provide similar tools like ModelForms 
and ModelAdmin, as well as GCBV.


If I missed anything, I'm sure someone else will remind me.

[Also... why is it always MongoDB, instead of something with a solid 
reputation of reliability and performance?]


--
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/d9e38eeb-eab1-e0db-8d50-54abe6fb1afd%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


RFC : Migration Adapters

2018-02-03 Thread Curtis Maloney

Hey,

I've recently written an app that implements a closure tree using 
views... and in order to make the migrations work as needed you must 
manually add an entry to the migrations.


Another friend of mine, a recent django convert, was wanting a way to 
add to the migration script generated when creating certain tables...


And today I realised I wanted quite involved control of how migration 
actions are written for the idea I was working on...


What I conceived was what I call a MigrationAdapter, which controls at 
least how create/modify/delete actions for a given object are generated.


I've started looking into the migrations code, and it appears the steps 
are very much hard-coded [and, it appears, with much painfully learned 
good reasons]...


Anyone with more familiarity with the migration machinery got input on 
if this is feasible?


--
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/12134aff-d37c-2b35-27a2-58d52f9358ff%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Don't assume that missing fields from POST data are equal to an empty string value.

2018-01-22 Thread Curtis Maloney

On 01/22/2018 06:03 PM, Anupam Jain wrote:
Wow - I just realised that we have been losing data for sometime on our 
web platform since there were some fields in the ModelForm that were 
hidden and not being sent. They were all being overwritten as blank 
values. Thank God, we use django-reversion to track changes. Will take 
us sometime to recover the data though.


Just something vaguely related that this post prompted in me ...

My general guide is... if you're using hidden fields, then you're 
probably doing it wrong.


There are very few valid cases for passing data in hidden fields. In 
most cases you really want to exclude the fields from the model. This 
has the added benefit of protecting from a malicious user who edits the 
values of the hidden fields.


A ModelForm will _only_ update fields on the model that it has fields 
for. No matter what the user - or your code [such as clean functions] - 
manages to get into the cleaned_data dict.


--
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/f06e134e-f596-3938-0bdf-daea0a56d505%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: GLOBAL_PERMS

2017-12-30 Thread Curtis Maloney


So, I've taken a different approach, following Markus' idea, and added 
"app_label" to Permission.


I probably still need to add a check to ensure you don't set app_label 
_and_ content_type, but that can wait for now.


You can now define new app-level permissions on the app's 
AppConfig.permissions [optional].


I've also implemented a "create_app_permissions" function which will ... 
do just that.  Call it whenever you like :)


Basic tests are working, as well as added ones.

No documentation or changelog as yet...

--
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/0314c0c1-0ebc-6d6b-a7ff-47a428e926b6%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: GLOBAL_PERMS

2017-12-30 Thread Curtis Maloney

On 12/31/2017 11:51 AM, Josh Smeaton wrote:


- I dislike the seetings approach of GLOBAL_PERMS and would rather see
   users writing explicit data migrations.


I don't favour either setting or migration based perms, but if you're 
going to go with migration based, then please also consider adding a 
first class permission type, to avoid the ceremony of creating 
forward/back functions, and having to remember the model layout for 
Permissions.


Something like:

migrations.CreatePermission(app_label, permission_name)


Certainly, if we go the data migration path I'd go this way...

--
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/0f67a5d7-dfa0-c31d-5f69-c9f0490dbf8f%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: GLOBAL_PERMS

2017-12-30 Thread Curtis Maloney

On 12/31/2017 12:50 AM, Markus Holtermann wrote:

Thanks Curtis,

I had a quick look. Some thoughts (in no particular order):

- IMO a nice idea. I've attached all model independent permissions to
  the user model in the past to work around the limitation.


Certainly a good one I'll remember to mention on #django next time it 
comes up :)



- How do you envision 3rd party apps handling their own permissions? If
  I install 2 independent apps and both use a permission can_do_foo, one
  can't distinguish between those two, right?


I had considered this, and yes would much rather some sort of per-app 
permissions.  For some years now the model-centric view many people take 
of their designs has bothered me.



- What do you think about adding an 'app_label' to the Permission model
  that can be used instead of a content type. That could solve the issue
  from the previous point? content_type and app_label would be
  exclusive?


Oh, absolutely!  A solid mechanism for per-app permissions would win me 
over in a second.


Would we keep the existing syntax of "{scope}.{codename}" and fallback 
scope from model to app label?  Or have a different syntax for app-level 
permissions, like "{app_label}:{codename}"?


And if so, how would that be handled in templates?

Also would we add get_app_permissions() to the auth API?


- I dislike the seetings approach of GLOBAL_PERMS and would rather see
  users writing explicit data migrations.


I was specifically aiming for something almost as simple as the 
per-model custom permissions.


Could we add it to AppConfig?  Feels like the right place to me.

--
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/6c4eaa19-6add-2841-be34-7da37ae6625d%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


GLOBAL_PERMS

2017-12-30 Thread Curtis Maloney


So, after a discussion with a new user on #django today I decided to 
make "permissions not bound to models" a first-class feature.


So I've written a simple patch that is in 
https://github.com/django/django/compare/master...funkybob:feature/cjm/global_perms?expand=1


Basically:

1. Allow Permission.content_type to be null

2. Adjust everything else to cope with that

3. Add new setting "GLOBAL_PERMS"

4. Teach create_permissions to honor that.

5. Write minimal test and documentation.

Would welcome further input.

--
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/1a028faa-beb1-7e67-69a7-a9c1028a4e17%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: about ticket 28588- has_perm hide non-existent permissions

2017-09-26 Thread Curtis Maloney

On 09/25/2017 08:56 PM, Dan Watson wrote:
Seems like maybe it would be more helpful if has_perm logged a note 
about the permission not existing (probably only in debug), rather than 
just returning False. In fact, I'd argue it should still return True -- 
if the permission did exist, the superuser would have it. And there's a 
backwards-compatibility argument. Think of superusers more as 
"permissions don't apply to me" than "I have all permissions".


I agree with the logging... however, I think has_perm should always 
return False for non-existent permissions.  This will mean any 
half-decent level of testing will uncover a typo in a permission name, 
since you will never trigger the True state.


This would also be an argument for is_superuser to equate to "has all 
the perms" instead of "has_perm always says true".


--
Curtis




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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ee6d4c13-97c8-09b5-49dd-b92bbab15616%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Automatic prefetching in querysets

2017-08-15 Thread Curtis Maloney

The 2 goals of a famework:
- protect you from the tedious things
- protect you from the dangerous things

N+1 queries would be in the 'dangerous' category, IMHO, and 'detecting 
causes of N+1 queries' is in the 'tedious'.


If we can at least add some DEBUG flagged machinery to detect and warn 
of potential prefetch/select candidates, it would be a big win.


--
C

On 16/08/17 09:26, Josh Smeaton wrote:
I believe we should be optimising for the **common** use case, not 
expecting everyone to be experts with the ORM.


 > If I can come up with a single example where it would significantly 
decrease performance (either memory usage or speed) compared to the 
default (and I'm sure I can), then I would be strongly opposed to it 
ever being default behaviour.


The status quo is already one where thousands of users and sites are 
doing the non-optimal thing because we're choosing to be conservative 
and have users opt-in to the optimal behaviour. A massive complaint 
against Django is how easy it is for users to build in 1+N behaviour. 
Django is supposed to abstract the database away (so much so that we 
avoid SQL related terms in our queryset methods), yet one of the more 
fundamental concepts such as joins we expect users to know about and 
optimise for.


I'd be more in favour of throwing an error on 
non-select-related-foreign-key-access than what we're currently doing 
which is a query for each access.


The only options users currently have of monitoring poor behaviour is:

1. Add logging to django.db.models
2. Add django-debug-toolbar
3. Investigate page slow downs

Here's a bunch of ways that previously tuned queries can "go bad":

1. A models `__str__` method is updated to include a related field
2. A template uses a previously unused related field
3. A report uses a previously unused related field
4. A ModelAdmin adds a previously unused related field

I think a better question to ask is:

- How many people have had their day/site ruined because we think 
auto-prefetching is too magical?
- How many people would have their day/site ruined because we think 
auto-prefetching is the better default?


If we were introducing a new ORM, I think the above answer would be 
obvious given what we know of Django use today.


What I'd propose:

1. (optional) A global setting to disable autoprefetching
2. An opt out per queryset
3. (optional) An opt out per Meta?
4. Logging any autoprefetches - perhaps as a warning?

More experienced Django users that do not want this behaviour are going 
to know about a global setting and can opt in to the old behaviour 
rather easily. Newer users that do not know about 
select/prefetch_related or these settings will fall into the new 
behaviour by default.


It's unreasonable to expect every user of django learn the ins and outs 
of all queryset methods. I'm probably considered a django orm expert, 
and I still sometimes write queries that are non-optimal or *become* 
non-optimal after changes in unrelated areas. At an absolute minimum we 
should be screaming and shouting when this happens. But we can also fix 
the issue while complaining, and help guide users into correct behaviour.



On Wednesday, 16 August 2017 08:41:31 UTC+10, Anthony King wrote:

Automatically prefetching is something I feel should be avoided.

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

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

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



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

I agree with Marc here that the proposed optimizations are
'magical'. I think when it comes to optimizations like these you
simply cannot know in advance whether doing extra queries is
going to a be an optimization or a pessimization. If I can come
up with a single example where it would significantly decrease
performance (either memory usage or speed) compared to the
default (and I'm sure I can), then I would be strongly opposed
to it ever being default behaviour.

Concerning implementing it as an additional  QuerySet method
like `auto_prefetch()` - I'm not sure what I think, I feel like
it could get icky (i.e. increase our technical debt), due to the
way it couples things together. I can't imagine ever wanting to
use it, though, I would always prefer the manual option.

Luke



On 15/08/17 21:02, 

Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-08-08 Thread Curtis Maloney
Is there any list of things we gain from dropping / adding any particular 
version?

The older discussion mentions a tracking ticket, but it is empty.

--
C

On 8 August 2017 9:45:54 AM AEST, Tim Graham  wrote:
>With a little more than a month to go until the Django 2.0 alpha
>(targeted 
>for September 18), I'd like to make a final decision about whether or
>not 
>to keep Python 3.4 support for Django 2.0. Jenkins is currently running
>the 
>tests on pull requests with Python 3.4 and 3.6. I've seen a few times
>where 
>contributors first used Python 3.5+ syntax and then had to make
>adjustments 
>for 3.4 compatibility so while it's not a large burden, it's not a 
>non-trivial one.
>
>Has anyone changed their thinking in the last few months? If not, I
>guess 
>we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.
>
>On Friday, February 17, 2017 at 9:32:20 PM UTC-5, Tim Graham wrote:
>>
>> Ok, I created a ticket to track cleanups and new Python features we
>can 
>> use when Python 3.4 support is removed: 
>> https://code.djangoproject.com/ticket/27857
>>
>> We can evaluate that a bit later in the Django 2.0 release cycle and 
>> decide whether or not to keep Python 3.4 support for 1.11.
>>
>> On Wednesday, January 18, 2017 at 12:20:13 PM UTC-5, Rotund wrote:
>>>
>>> I agree that allowing more people to be able to do development
>against 
>>> Django 2.0 is important. That stated, please be very explicit in the
>
>>> release notes and documentation that "Versions below Python 3.6 are 
>>> expected to be dropped before the next Django LTS will be released,
>so 
>>> please keep that in your project planning." (Language too informal,
>but I 
>>> think the idea is correct.)
>>>
>>>
>>>
>>> On Wed, Jan 18, 2017 at 2:28 AM, Claude Paroz 
>wrote:
>>>
 Le mardi 17 janvier 2017 15:48:46 UTC+1, Tim Graham a écrit :
>
> I propose to tentatively target Python 3.5+ for Django 2.0 but not
>to 
> remove the current workarounds for Python 3.4 at this time.
>Shortly before 
> the alpha for Django 2.0, an interested person can look into how
>much work 
> is required to fix any test failures on Python 3.4 and we'll make
>a 
> decision then.
>

 I'm strongly advocating for keeping 3.4 support for now, as I would
>have 
 difficulty to continue contributing to Django.
 My main system is still using 3.4 and will be for some months. Even
>if I 
 could rather easily installing manually a more recent Python, I
>very much 
 like relying on my stable distro packages. Sorry for my dumbness!

 Claude

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

>https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com
>

>
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Joe Tennies
>>> ten...@gmail.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 https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/356d7e07-0be0-4200-a5da-0d092dd2e761%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/6160B82D-223A-401F-BB3C-B87965C83823%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Trimming in the settings file (Was: Re: Follow-up to #28307: Possible app_template improvements)

2017-06-26 Thread Curtis Maloney



On 26/06/17 20:21, Melvyn Sopacua wrote:

On Thursday 15 June 2017 08:14:02 Aymeric Augustin wrote:

I see the point for the number of useless files. But in every release,
settings.py has been trimmed more and more to the point that it's next
to useless. I'm wondering about the upside of that. Cause I'm seeing
plenty of downsides for both new and veteran users.


Can't say I agree it's useless... I find I need very little to modify 
the start project template to get under way... especially now that admin 
is in by default.



Not to mention the choice of what to remove. To keep STATIC_URL (which I
rarely change) but remove STATIC_ROOT (which is different per project
and sometimes even per install) is beyond me.


Because STATIC_URL is useful always, whereas STATIC_ROOT typically only 
makes sense when you deploy...



--
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/c46370db-c437-5b18-e5ab-bce8bec8a4e2%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Follow-up to #28307: Possible app_template improvements

2017-06-15 Thread Curtis Maloney



On 15/06/17 16:14, Aymeric Augustin wrote:

Hello,

The more files get generated to startapp, the more empty useless files
accrue in many projets, because devs don't take the time to delete those
they don't use.


Beat me to the punch... I agree the default template should be as light 
as possible.



Encouraging people to improve the structure of their Django code is
worthwhile but I don't believe the startapp template is the right medium
for that.


There's no reason we can't provide an "advanced" template in core, surely?

IMHO project/app templates are one of the least utilised features of 
Django, sadly.


It deserves more marketing :)

--
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/9167ee89-f406-196b-28ec-5ba63ea1b049%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Admin browser support policy

2017-06-14 Thread Curtis Maloney
This topic seems to appear frequently over the years, but I've yet to 
see a clear decision.


Without a clear Browser Support Policy for admin, it can be very unclear 
what cleanups, optimisations, and improvements can be made.


Collin Anderson suggested supporting IE11+ ("as that's the latest on 
Windows 7 and there's not much 9-10 usage"), and I'd suggest also 
considering the general Google approach:


Basically, it's "Current and Previous version", and considering IE as 
separate from Edge (so IE 10/11, Edge current and previous).


Does this sound fair and reasonable?
Do we care about mobile browsers?
Does Safari deserve/require special casing?

Once we can resolve this, I want to start working on revising all the 
JS. But I won't start that until I know what dross I have to still drag 
along.


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


Re: Default to BigAutoField

2017-06-10 Thread Curtis Maloney



On 10/06/17 22:21, Claude Paroz wrote:

Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit :

Right, hence my point of having a global setting to say "the default
auto-field is ..."



I see, but this conforms to the pattern "use the same id field type for
all models of my project". I'm not sure we should encourage that.


Yeah... naming would be key with "DEFAULT_AUTO_FIELD_TYPE" or whatever...


Another idea would be to offer variants of models.Model which models
could inherit from, like models.BigIntModel or models.UUIDModel.


Ah, well... now you're talking.  But then, you can do this already as an 
abstract base with TYPE as id...


class BigIntModel(models.Model):
id = BigAutoField(primary_key=True)
class Meta:
abstract = True


--
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/a7da67fb-349a-c77c-8324-32dc16bd0ada%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Default to BigAutoField

2017-06-10 Thread Curtis Maloney

f) let MySQL users opt for PositiveBigAutoField if they want...


On 10/06/17 19:40, Curtis Maloney wrote:

Right, hence my point of having a global setting to say "the default
auto-field is ..."

This would:
a) let people continue to use AutoField
b) let people opt for BigAutoField
c) let 3rd party projects be agnostic
d) let people use UUIDField(default=uuid.uuid4)
e) possibly make it feasible to change mid-stream from AutoField to
BigAutoField...

--
C

On 10/06/17 19:33, Claude Paroz wrote:

I think we should first discuss if it makes sense to set a BigAutoField
by default for all tables. I'm not convinced of that yet. I looked at my
projects with this perspective and found for example a case where I have
many small lookup tables (containing between 2-20 entries) for which I
know I would never use BigAutoField if I'd design the schema on paper.

For me, it's a bit like the `on_delete` parameter for foreign keys. A no
"one size fits all" situation.
For example, a quick analysis of contrib models (sorry for bad
formatting):

Model BigAutoField appropriate
===
admin.LogEntry yes
auth.Userno
auth.Group  no
auth.Permission no
contenttype.ContentType no
flatpage.FlatPage  no
redirect.Redirectno
sessions.Session  yes
sites.Site no

Shouldn't we treat that issue by better documentation instead?
Another idea is to leverage the system check framework (--deploy part)
to warn when the max id is over 50% of available range.
We are perfectionists, aren't we :-)

Claude

--
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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
<mailto: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/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%40googlegroups.com

<https://groups.google.com/d/msgid/django-developers/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ec59bb2e-bce9-924f-1509-60709a07c5dc%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Default to BigAutoField

2017-06-10 Thread Curtis Maloney
Right, hence my point of having a global setting to say "the default 
auto-field is ..."


This would:
a) let people continue to use AutoField
b) let people opt for BigAutoField
c) let 3rd party projects be agnostic
d) let people use UUIDField(default=uuid.uuid4)
e) possibly make it feasible to change mid-stream from AutoField to 
BigAutoField...


--
C

On 10/06/17 19:33, Claude Paroz wrote:

I think we should first discuss if it makes sense to set a BigAutoField
by default for all tables. I'm not convinced of that yet. I looked at my
projects with this perspective and found for example a case where I have
many small lookup tables (containing between 2-20 entries) for which I
know I would never use BigAutoField if I'd design the schema on paper.

For me, it's a bit like the `on_delete` parameter for foreign keys. A no
"one size fits all" situation.
For example, a quick analysis of contrib models (sorry for bad formatting):

Model BigAutoField appropriate
===
admin.LogEntry yes
auth.Userno
auth.Group  no
auth.Permission no
contenttype.ContentType no
flatpage.FlatPage  no
redirect.Redirectno
sessions.Session  yes
sites.Site no

Shouldn't we treat that issue by better documentation instead?
Another idea is to leverage the system check framework (--deploy part)
to warn when the max id is over 50% of available range.
We are perfectionists, aren't we :-)

Claude

--
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/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%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/43c2a63f-87de-fda1-87c3-412574c13804%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Default to BigAutoField

2017-06-09 Thread Curtis Maloney
I don't see it helping once you hit the problem, but like custom user its a 
recommendable setting for pre planning

--
C


On 10 June 2017 11:37:04 AM AEST, Tim Graham <timogra...@gmail.com> wrote:
>I'm not sure how this could work with migrations. In a sense, it would 
>involve making the auto-generated primary key "swappable", including 
>foreign keys that point to it. This sounds like a headache.
>
>I haven't thought of a possible solution since Kenneth floated this
>idea in 
>#django-dev yesterday.
>
>On Friday, June 9, 2017 at 7:11:05 PM UTC-4, Curtis Maloney wrote:
>>
>> I know people hate settings, but what about one for auto id field
>type?
>>
>> It would let you handle backwards compatibility, uuid, and bigint...
>>
>> --
>> C
>>
>>
>> On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss
><ja...@jacobian.org 
>> > wrote:
>>>
>>> I think this would be a good improvement, and I'd like to see it.
>I've 
>>> been bitten by integers overflowing at least twice I can remember in
>my 
>>> career, which is two times too many.
>>>
>>> However, a major thing we'd have to work out is the upgrade path
>Consider 
>>> a simple model:
>>>
>>> class Person(Model):
>>> name = CharField()
>>>
>>> In Django 1.11, this actually generates a model with an integer `id`
>
>>> field. But in we change it, in Django vNext, that `id` field would
>"turn 
>>> into" a bigint magically without the underlying table changes.
>That'd be 
>>> confusing: you'd expect the model to be "fixed" by pugrading to
>vNext, but 
>>> it wouldn't be. I think the migrations engine would detect this as a
>
>>> migration (?), so perhaps that's the path forward, but it could
>still be 
>>> super-confusing. We've never shipped a release of Django that
>required a 
>>> migration to _all_ your models.
>>>
>>> Have you thought about what the upgrade path should look like,
>Kenneth?
>>>
>>> Jacob
>>>
>>> On Fri, Jun 9, 2017 at 11:24 AM, Kenneth Reitz <ken...@heroku.com 
>>> > wrote:
>>>
>>>> Dear Django Dev,
>>>>
>>>>  
>>>>
>>>> At Heroku, we have the privilege of seeing an extremely broad range
>of 
>>>> customers utilizing tools like Django to build their applications
>and 
>>>> companies. One of the things that we’ve seen customers hit, time
>and time 
>>>> again when using tools like Django, is integer overflows for
>primary keys. 
>>>> Their application starts behaving unpredictably once they reach the
>
>>>> overflow, not even knowing such a constraint exists, and they often
>think 
>>>> the problem is with their database provider, rather than with their
>schema. 
>>>> Once they realize what is wrong, it’s a relatively trivial fix, but
>a 
>>>> migration can take several hours to complete, which results in
>unacceptable 
>>>> amounts of downtime.
>>>>
>>>>  
>>>>
>>>> Because of this, Heroku, as a company, would like to encourage
>bigints 
>>>> as a sane reasonable default for primary keys for application
>models. If 
>>>> the Django project agrees with this idea, that would mean that
>Django would 
>>>> provide BigAutoField as the default for ‘id’ instead of AutoField. 
>>>>
>>>>  
>>>>
>>>> Rails made this change recently 
>>>> <http://www.mccartie.com/2016/12/05/rails-5.1.html>, and has seen 
>>>> success in doing so. 
>>>>
>>>>  
>>>>
>>>> I’m happy to provide the code to do this, but I wanted to discuss
>it 
>>>> here before doing so, to hear what the general consensus was to the
>
>>>> proposal of such a change. 
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>> Pros:
>>>>
>>>>- 
>>>>
>>>>Users of Django, following the docs, won’t accidentally hit the
>int 
>>>>overflow barrier. 
>>>>- 
>>>>
>>>>Encourages best-practices from the beginning. 
>>>>- 
>>>>
>>>>Bigints don’t take up much more storage than ints when using 
>>>>Postgres. 
>>>>- 
>>>>
>>>>In-line with other frameworks movi

Re: Default to BigAutoField

2017-06-09 Thread Curtis Maloney
I know people hate settings, but what about one for auto id field type?

It would let you handle backwards compatibility, uuid, and bigint...

--
C


On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss  wrote:
>I think this would be a good improvement, and I'd like to see it. I've
>been
>bitten by integers overflowing at least twice I can remember in my
>career,
>which is two times too many.
>
>However, a major thing we'd have to work out is the upgrade path
>Consider a
>simple model:
>
>class Person(Model):
>name = CharField()
>
>In Django 1.11, this actually generates a model with an integer `id`
>field.
>But in we change it, in Django vNext, that `id` field would "turn into"
>a
>bigint magically without the underlying table changes. That'd be
>confusing:
>you'd expect the model to be "fixed" by pugrading to vNext, but it
>wouldn't
>be. I think the migrations engine would detect this as a migration (?),
>so
>perhaps that's the path forward, but it could still be super-confusing.
>We've never shipped a release of Django that required a migration to
>_all_
>your models.
>
>Have you thought about what the upgrade path should look like, Kenneth?
>
>Jacob
>
>On Fri, Jun 9, 2017 at 11:24 AM, Kenneth Reitz 
>wrote:
>
>> Dear Django Dev,
>>
>>
>>
>> At Heroku, we have the privilege of seeing an extremely broad range
>of
>> customers utilizing tools like Django to build their applications and
>> companies. One of the things that we’ve seen customers hit, time and
>time
>> again when using tools like Django, is integer overflows for primary
>keys.
>> Their application starts behaving unpredictably once they reach the
>> overflow, not even knowing such a constraint exists, and they often
>think
>> the problem is with their database provider, rather than with their
>schema.
>> Once they realize what is wrong, it’s a relatively trivial fix, but a
>> migration can take several hours to complete, which results in
>unacceptable
>> amounts of downtime.
>>
>>
>>
>> Because of this, Heroku, as a company, would like to encourage
>bigints as
>> a sane reasonable default for primary keys for application models. If
>the
>> Django project agrees with this idea, that would mean that Django
>would
>> provide BigAutoField as the default for ‘id’ instead of AutoField.
>>
>>
>>
>> Rails made this change recently
>> , and has seen
>success
>> in doing so.
>>
>>
>>
>> I’m happy to provide the code to do this, but I wanted to discuss it
>here
>> before doing so, to hear what the general consensus was to the
>proposal of
>> such a change.
>>
>>
>>
>>
>>
>> Pros:
>>
>>-
>>
>>Users of Django, following the docs, won’t accidentally hit the
>int
>>overflow barrier.
>>-
>>
>>Encourages best-practices from the beginning.
>>-
>>
>>Bigints don’t take up much more storage than ints when using
>Postgres.
>>-
>>
>>In-line with other frameworks moving forward on this issue, like
>Rails
>>.
>>
>>
>>
>> Cons:
>>
>>-
>>
>>Backwards compatibility would need to be considered.
>>
>>
>> Why not UUID?
>>
>>
>>
>> I agree! I love using UUID for my primary keys, and I think a patch
>to
>> Django which provides an AutoUUIDField would be wonderful. However,
>there
>> are a few major drawbacks to making this the new default:
>>
>>
>>
>>1.
>>
>>It’s confusing to new users, would make onboarding process more
>>difficult.
>>2.
>>
>>UUID is difficult to implement in MySQL.
>>3.
>>
>>UUID has larger storage requirements.
>>4.
>>
>>Incrementing IDs are actually useful.
>>
>>
>>
>>
>> So, my proposal is to simply lift the int barrier to a bigint barrier
>for
>> new Django applications, and I think it will save a lot of developers
>a lot
>> of pain in the long run.
>>
>>
>>
>> Many thanks,
>>
>>
>>
>> Kenneth Reitz
>>
>> Heroku Python
>>
>> --
>> 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/6fe3401c-4404-4bd8-9d22-
>> 58df95cd1348%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 

Re: Exceptions in model._meta._property_names with some 3rd-pty libraries

2017-06-02 Thread Curtis Maloney

What about using inspect.getmembers ?

https://docs.python.org/3/library/inspect.html#inspect.getmembers

In other code I've also used inspect.classify_class_attrs but it seems 
to be undocumented :/


If nothing else, it could be used as a guide on how to do this.

--
Curtis


On 03/06/17 08:52, Adam Johnson wrote:

This is my bad, I did the refactoring :) You're right, the original
version

did in fact use a try..except AttributeError and that should be
preserved for cases like this.

I've made a ticket here https://code.djangoproject.com/ticket/28269 . If
you want to make the PR copying in your fix and adding a test that would
be neat, you've done 90% of the work already! :)


On 2 June 2017 at 22:02, Zack Voase >
wrote:

Hi all,

I'm encountering exceptions in a number of popular third-party
Django libraries when upgrading from 1.8 to 1.11. The code path is
typically `MyModel.objects.get_or_create(...)`, which causes
`model._meta._property_names` to be checked (to make sure we're not
querying/setting a property). The problem is, `_property_names` is
implemented as follows:

|
# in django/db/models/options.py:
def_property_names(self):
returnfrozenset({
   attr forattr in
   dir(self.model)ifisinstance(getattr(self.model,attr),property)
})
|

The problem is when a custom field installs a field descriptor on
the model class (during `contribute_to_class()`), with a `__get__()`
method like this:

|
classSomeFieldDescriptor(object):
# ...
def__get__(self,instance,type=None):
ifinstance isNone:
raiseAttributeError("Can only be accessed via an instance.")
# ...
|

Libraries which install such descriptors include

[django-fsm](https://github.com/kmmbvnr/django-fsm/blob/2d2eaee/django_fsm/__init__.py#L225

)
and

[django-jsonfield](https://github.com/dmkoch/django-jsonfield/blob/2.0.1/jsonfield/subclassing.py#L35

).
I think the problem is that we can't assume that all results of
`dir(model_class)` can be accessed via `getattr(model_class, attr)`
without exception; indeed, the Python docs state (c.f.
https://docs.python.org/2/library/functions.html#dir
):

> Because dir() is supplied primarily as a convenience for use at an
interactive prompt, it tries to supply an interesting set of names
more than it tries to supply a rigorously or consistently defined
set of names, and its detailed behavior may change across releases.

A potential fix would be to adjust the definition of
`_property_names` like so:

|
def_property_names(self):
attrs =[]
forattr indir(self.model):
try:
ifisinstance(getattr(self.model,attr),property):
attrs.append(attr)
exceptAttributeError:
pass
returnfrozenset(attrs)
|

Does this seem like a good solution, or even a problem worth solving?

Thanks!
-- Zack

--
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/ec0e2506-4c4b-441f-b005-5623d6521ae3%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout
.




--
Adam

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

Re: Cython usage within Django

2017-05-21 Thread Curtis Maloney

On 22/05/17 09:30, Tom Forbes wrote:

Hey Karl and Russell,
Thank you for your quick replies!

Russell:

You are of course right about the speed of the Python code itself being
a bottleneck and the usual suspects like the database are more important
to optimize. However I don't think it's necessarily always a waste of
time to explore optimizing some Python/django functions, if that only
means simply moving them to a separate file and running Cython on them
to get a speed boost.


Of course, I'm sure Russel won't object to be shown to be wrong, if you 
feel like giving it a go anyway :)


--
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/50d4b757-ca93-66b6-c518-7ab0793e7646%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-05-12 Thread Curtis Maloney
Dogfooding is a fairly strong argument, IMHO.

Especially when there's a volunteer to do the work.

--
C

On 7 May 2017 6:53:13 PM AEST, Paolo Melchiorre  wrote:
>On Sun, May 7, 2017 at 9:16 AM, Florian Apolloner
> wrote:
>> On Sunday, May 7, 2017 at 12:50:02 AM UTC+2, Paolo Melchiorre wrote:
>>>
>>> Hello,
>>>
>>> in the djangoproject.com the search is powered by elasticsearch.
>>>
>>> Since the site uses postgresql as database backend I want propose to
>use
>>> the Full-Text Search function provided by
>django.contrib.postgres.search
>>> module.
>>>
>>> I presented a talk "Full-Text Search in Django with PostgreSQL" at
>the
>>> last PyConIT 2017 Conference in Florence
>>> https://twitter.com/pauloxnet/status/850766131338117120
>>> and I proposed a similar talk for the next EuroPython 2017
>>> https://ep2017.europython.eu/conference/voting/#ord128
>>>
>>> If you're interested in this proposal it will be nice to organize a
>>> related sprints at the next EuroPython 2017
>>> https://ep2017.europython.eu/en/events/sprints
>>
>> What would be the benefit of using django.contrib.postgresql aside
>from much
>> work?
>
>The benefit would be to have a djangoproject.com made with
>technologies the site talks about and to demonstrate what you can
>build using only officially documented Django module.
>
>For the work to do this I can candidate myself to work on it!
>
>-- 
>Paolo
>
>-- 
>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/CAKFO%2Bx59T7ykkk9WT%3DoAyvG9xX-vxp4gSN0gLRAmSmz%2Byo1bqQ%40mail.gmail.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/907C8BE2-970B-452C-9F91-AEBAE8F8B952%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Admin and CSS Custom Properties

2017-04-28 Thread Curtis Maloney
I recently discovered that the stated "policy" on browser support in 
Admin is... well... not clear at all.


https://docs.djangoproject.com/en/1.11/faq/admin/#what-browsers-are-supported-for-using-the-admin

It claims to support full function for "YUI's A-Grade" browsers, but the 
link it provides does nothing to explain the supported versions, and a 
further "target environments matrix" link still lists IE6.


So perhaps it's time to update the FAQ, and have a discussion on what 
Admin's browser support policy needs to be updated to.


--
Curtis

On 28/04/17 19:14, Patrick Guido wrote:

On 27 April 2017 at 23:18, Adam Johnson > wrote:

Thanks for introducing me to a new CSS feature! I clearly don't keep
up with front end stuff enough.

Re: your issues:

1. From the support grid at the bottom of the Smashing Magazine
article you linked, it looks like it's only IE 11 and Edge 14 that
are major browsers that don't support it. However I feel like if
Django is going to announce a feature like "you can override the
Admin colours", it should work in all browsers. I'm not sure if we
have a written policy for this though.

I guess it also depends on use cases, usually (where I work) we tend to
support only latest browsers when it comes to admin, since
it will be used by only a few people :) But I see your point.

A friend of mine was suggesting configuring colours in python, but this
means that the css would be rendered via python, which is
not ideal.
Another solution would be to add a JS polyfill to make it work on older
browsers, but I'm against it :)
Let's also keep in mind that this (if approved) will be included in
django 2.0 or later, so the browser support will be even better :)


2. I'm not a huge fan of an additional HTTP request for every admin
page load, for every admin site in existence whether or not the
colours have been overridden. HTTP/2 isn't very widely deployed
still so requests still ain't cheap.

Uhm, I think we can easily skip one request if the colours have not been
overridden. We can put the vars in base.css.
Then we can add the variables by changing the template (but that's more
cumbersome) either by adding an external css link
or by adding a style tag with the variables.


3. This can be overcome with a test to ensure the two files are in
sync, I guess?

Uhm, true!


And one more question: how much less painful is this to override the
colours compared to the variable-less way, where you just clone the
colour definitions of every rule in the original file in a second
override file?

I haven't checked all the rules, but I think it will require quite a bit
of work. Maybe we can create a "template" file
that can be used to override quite easily the colours, but that doesn't
scale too well I think.


--
Patrick Guido Arminio

--
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/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%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/db7742bc-769b-85fe-af87-c398fa99215d%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Django versioning and breaking changes policy

2017-04-04 Thread Curtis Maloney
See? This is exactly what I told you you could expect ... to be shown 
the new release process details :)


[For those playing at home, Bernhard raised this concern on IRC first, 
and I recommended bringing it here.  He expressed concern about being 
roasted, and I predicted someone would introduce him to the details of 
the new release process :)]


--
C

On 05/04/17 08:29, Bernhard Posselt wrote:

Oh wow, haven't seen that yet, thank you :)

Just make sure to follow the semver spec closely if you transition to
semver, because it can cause issues for parsers. Also the spec is more
restrictive than you'd think with regards to syntax (source: working
with semver in my current Django project)


On 04/04/2017 11:11 PM, Aymeric Augustin wrote:

Hello,

As far as I can tell, recent modifications to the release process means it will 
meet your expectations going forwards.

Take a look at https://docs.djangoproject.com/en/dev/internals/release-process/ 
 for details.

Best 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-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/bd9bbe2b-79db-a765-9b4a-7f4afd9901a4%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-04 Thread Curtis Maloney



On 05/01/17 10:09, Adam Johnson wrote:

Whitespace control in templates is an exercise in frustration. In my
experience more flexible tools such as {%-, {%+, -%}, and +%} in
Jinja2 increase the frustration.


I really enjoy the {%- etc. operators in Jinja 2 in the context of
Ansible, there are often cases when templating obscure configuration
files that they come in useful.


I believe SmileyChris had a patch to add this to DTL...

--
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/3c0f36e6-74ea-2bf5-6fa5-fe616440e560%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: No 'Content-Type' header in response

2016-12-26 Thread Curtis Maloney
>From what I can see in the rfc, it is permitted but not required.

Only a body in a 204 response is proscribed.

Any metadata (I.e. headers) are about the resource just accessed... So a 
Content-Type would, IMHO, be acceptable but not essential.



On 26 December 2016 9:47:02 PM AEDT, roboslone  wrote:
>Thanks, that was an old setting in Mail.app =/
>
>I've made a pull-request to DRF:
>https://github.com/tomchristie/django-rest-framework/pull/4768
>
>But it seems to me that fixing it in Django would be more appropriate.
>
>On the subject of Content-Type header with no response body, seems
>there's no convention about it, I've found different opinions on the
>web. The only thing I'm sure about is that putting None in that header
>is a bad idea.
>
>> On 26 Dec 2016, at 13:24, Adam Johnson  wrote:
>> 
>> Hi GMail! (you might want to fix your name used on google groups, I
>had the same problem ;) )
>> 
>> This seems to be a legitimate bug in the __repr__ to me - SO informs
>me that DRF is correct in not defining a Content-Type for a 204 as it
>has no body:
>https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use
>
>> 
>> I created a ticket: https://code.djangoproject.com/ticket/27640
> . If you want to try fix
>it there's a great contribution guide at
>https://docs.djangoproject.com/en/dev/internals/contributing/
> . I
>think using str.format would be acceptable, but the dict subclass
>sounds more complicated than just doing self.get('Content-Type', '') :)
>> 
>> On 26 December 2016 at 05:57, GMail > wrote:
>> Hi! I'm using Django 1.10.2 and Django-Rest-Framework 3.5.3.
>> I noticed, that HttpRequest.__repr__ method relies on 'Content-Type'
>header:
>> 
>> 
>> > class HttpResponse(HttpResponseBase):
>> > ...
>> >
>> > def __repr__(self):
>> > return '<%(cls)s status_code=%(status_code)d,
>"%(content_type)s">' % {
>> > 'cls': self.__class__.__name__,
>> > 'status_code': self.status_code,
>> > 'content_type': self['Content-Type'],
>> > }
>> 
>> 
>> And after deleting an object in DRF sends empty response with HTTP204
>and no 'Content-Type' header. I was trying to log outgoing response and
>got KeyError here.
>> 
>> So I have two questions:
>> 1. Is this intentional? Do all responses in Django have
>'Content-Type' header and should DRF be aware of it?
>> 2. Why not use `str.format` here? To avoid errors like this, `dict`
>subclass with `__missing__` method could be used.
>> 
>> --
>> 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/39F85D40-019C-411A-BCA7-402E338EA527%40gmail.com
>.
>> For more options, visit https://groups.google.com/d/optout
>.
>> 
>> 
>> 
>> -- 
>> Adam
>> 
>> -- 
>> 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/CAMyDDM39qZj7fV-MvPX%2BtXvSNL9%2B80283Aa5P47uBh3D46Q8BQ%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 

Re: Feature idea

2016-11-17 Thread Curtis Maloney
My solution to the "initial password problem" is to send a password 
reset token first...


And Django has this built in, handily :)

http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/

It would be very easy to use the same approach for an "invite" 
registration pattern.


--
C


On 17/11/16 19:38, Aymeric Augustin wrote:

Hello,


On 16 Nov 2016, at 21:22, Anthony King > wrote:

Sending a link to set a password isn't much better.


The cardinal rule of passwords is “you must be the only person who knows
your password”. This means never writing it down anywhere, except in a
proper password manager, and never telling it to anyone, *even* your IT
staff — to fight social engineering attacks.

Sending a password in clear over email means the IT staff is okay with
knowing the user's password. Disregarding their own guidelines sets a
poor example and reduces their credibility about password management in
general.

Of course, on most Django websites, someone who can create a staff user
can also change the user’s password — it’s rare to give the “create
user” but not the “change user” permission. I’m not making a technical
argument here, I’m thinking of IT literacy and educating users.


Perhaps a way to force a password change on login would be better,
which has more use elsewhere, such as being able to periodically force
password changes


Forcing a password change on login is another interesting idea to solve
this problem. That’s what ActiveDirectory has to do, because OSes don’t
have the same password reset possibilities that web applications have.

However I think that would mean solving the general problem of password
rotation. Django solved password validation recently; it could solve
password rotation next. (Note that password rotation is controversial
because it forces users to choose weak passwords with a basic rotation
scheme like putting month number at the end, instead of storing strong
random password in a password manager. Trade-offs.)

I still think a simple solution hooking into the current password reset
mechanism, just with a different email template, could be a quick
security win for a lot of Django sites. I’d encourage people to use it
if it existed.

Best regards,

--
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/76AE3F1E-6C00-4E4E-86A7-4E1374FF20AF%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/694f60cb-bcd8-cc32-fd8b-c060c7a54415%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: drop compatibility with Python < 2.7.8?

2016-11-14 Thread Curtis Maloney
Well, I certainly agree with the intent... especially, as you say, for 
LTS users who effectively cement themselves to a version for the long haul.


Might as well remind them there are security updates in things other 
than OpenSSL, Java, and Django :)


--
C


On 15/11/16 09:49, Tim Graham wrote:

Hi,

I was wondering if Django could or should nudge Python 2 users toward
the latest stable release of 2.7.x? For example, we could require at
least 2.7.8 by removing the fallback pbkdf2() implementation in
django.utils.crypto [0]. I guess part of my feeling is that if you're
running 1.11 LTS for at least another three years, you should really try
to use the latest Python 2 as it has security improvements and fixes
compared to the older 2.7.x releases.

As a data point, Ubuntu 14.04 ships with Python 2.7.6 and 16.04 ships
with Python 2.7.12.

[0] https://github.com/django/django/pull/7556

Thanks for your input.

--
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/16cafa10-d727-4b42-be26-4e5458520546%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/c1ca7a85-32bf-ca4a-7a9b-fc05ffd246ba%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Report - October 15, 2016

2016-10-15 Thread Curtis Maloney

Ummm...

On 16/10/16 11:45, Tim Graham wrote:

https://code.djangoproject.com/ticket/27334- File uploads could rename
temporary files rather than copying them (duplicate)

https://code.djangoproject.com/ticket/27334- File uploads could rename
temporary files rather than copying them (accepted)


Is it a duplicate of itself? :P

--
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/de7874ea-b263-9cfe-bd99-1b139fc9487c%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Please put monitor.py as default in next django version

2016-10-14 Thread Curtis Maloney



On 15/10/16 08:16, Ricardo Prado wrote:

Thanks "Folks" in special Aymeric

Let's go, let me explain about this "monitor.py".

When users deploy django app in production, the changes in any python
script need be "reloaded" for apply changes, in this you have two
options to do this:

1 - restart apache or nginx server


Well, no... if you're using apache/mod_wsgi (and have configured it 
correctly) you merely need to "touch" the wsgi script.


If you're using nginx, it doesn't run django, so you should be starting 
whichever uwsgi service you are using (e.g. uwsgi, gunicorn, waitress, etc)



Anyway this is a problem, this file can be included in django core for
apply changes in python script and don't need be reload server. When you
start a django app

typing: "python manage.py runserver".

An internal montior is initialized for apply changes runtime. Would be
good have this option in production too.


Most deploy processes and managers would scream at you if you decided to 
restart the service every time a file changed.


Typically in production you want to update the whole codebase and have a 
controlled reload (is touch really so difficult?)


What sort of situations are you seeing that you want a restart 
frequently and more simple than "touch wsgi.py" ?


--
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/672f21be-7524-9c22-173b-2ddefe93444e%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Should the Django session-id be hashed?

2016-09-22 Thread Curtis Maloney



On 22/09/16 18:52, Rigel wrote:

Hello!

The Django session framework stores session-ids in the database as
plain-text. Unless I'm missing something, these ids could be
vulnerable to SQL injection attacks, if any are discovered or if
developers misuse features like extra().


Firstly, extra() is on is way out... being replaced by expressions, 
transforms, and so on...


That said, yes, extra() does potentially open you to SQL attacks, but 
only if you use it incorrectly.  If used as documented -- same goes for 
raw() -- you should remain immune to SQL injection.


The only time you're likely to become vulnerable to SQLi is when you do 
something as stupid as putting values into SQL commands yourself.



This vulnerability could be
mitigated if the session-ids were hashed with a secure cryptographic
hash function, like SHA-256, before storing them or querying for them
in the database.


They're just a random string, I don't see how turning them into another 
random string will help?  Or do you mean to set the original string in 
the cookie only, and hash them for the key, and hash them _every_ _time_ 
you look up the session?



This concern has recently been raised for Joomla! on the Full
Disclosure mailing list:
http://seclists.org/fulldisclosure/2016/Sep/50

What is your opinion on this matter? It could be fairly trivial to
implement, with the only side effect of being computationally
expensive. Still, security is more desirable than efficiency or
performance.


You are right there, security is more important.

However, it's a small overhead for everyone... for a small win for 
almost nobody.


Until you can demonstrate how there's any SQLi vulnerability, I'm -1 on 
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/16ef8ea5-cc5c-ad81-bdf8-f2d6f438bb61%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Challenge teaching Django to beginners: urls.py

2016-09-16 Thread Curtis Maloney

On 15/09/16 16:37, Curtis Maloney wrote:

Somewhere I have code to provide a "parse" based URL router.

Will dig it up now 1.10 has has shipped


Ah, found it...

So, here is a gist of a sample of using parse 
(https://pypi.org/project/parse/) instead of regex.


https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b

Since you can register extra type names, and those types can cast also, 
it covers a lot of things some people expect [but don't get] from regex.



--
C




On 14 September 2016 6:38:20 PM AEST, Florian Apolloner
<f.apollo...@gmail.com> wrote:

Hi Emil,

On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström
wrote:

and more experienced users are expected to switch over to using
regexes directly to get the exact behavior they want.


How so? Personally I would use this quite quickly since a few
builtin types would cover 99%. While I can write regex in sleep
nowadays, I still find it kinda tedious to redefine what "slug"
means in every URL I wanna match something… I am sure others think
the same.


Beginners likely won't look at all the different options and
choose one based on it's merits, they'll pick whatever their
teacher suggests they use. Also installing an extra package when
setting up django feels a bit strange.


I think the eco system is far enough to support that, after all
south lived long and well as external package. Either way, DEP or
not, having an implementation out there would definitely help.

Cheers,
Florian


--
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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
<mailto: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/B35D1655-D658-41FC-9EB5-83311B6C892C%40tinbrain.net
<https://groups.google.com/d/msgid/django-developers/B35D1655-D658-41FC-9EB5-83311B6C892C%40tinbrain.net?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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9ab6342b-f969-4a3b-1263-aabd27cc0eb9%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Challenge teaching Django to beginners: urls.py

2016-09-15 Thread Curtis Maloney
Somewhere I have code to provide a "parse" based URL router.

Will dig it up now 1.10 has has shipped

On 14 September 2016 6:38:20 PM AEST, Florian Apolloner  
wrote:
>Hi Emil,
>
>On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström
>wrote:
>>
>> and more experienced users are expected to switch over to using
>regexes 
>> directly to get the exact behavior they want. 
>>
>
>How so? Personally I would use this quite quickly since a few builtin
>types 
>would cover 99%. While I can write regex in sleep nowadays, I still
>find it 
>kinda tedious to redefine what "slug" means in every URL I wanna match 
>something… I am sure others think the same.
> 
>
>> Beginners likely won't look at all the different options and choose
>one 
>> based on it's merits, they'll pick whatever their teacher suggests
>they 
>> use. Also installing an extra package when setting up django feels a
>bit 
>> strange.
>>
>
>I think the eco system is far enough to support that, after all south
>lived 
>long and well as external package. Either way, DEP or not, having an 
>implementation out there would definitely help.
>
>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 https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/6ea6cd5d-8870-4596-852d-e3b59110af8c%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/B35D1655-D658-41FC-9EB5-83311B6C892C%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


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

+1

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?


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

https://groups.google.com/d/msgid/django-developers/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
* 

  1   2   3   >