Re: Security Advisory: BREACH and Django

> > I am doing something a little different with my CSRF tokens, and I believe it guards against BREACH. Instead of sending the token in the HTTP response, I am using javascript to read (and generate if needed) the CSRF token cookie. The javascript reads the token from the cookie and adds it

Proposal: ./manage check to look for models.BooleanField() without default= value.

The new ./manage check command is for helping people upgrade to a new version of django. https://docs.djangoproject.com/en/dev/ref/django-admin/#check django1.6 changes models.BooleanField() to not default to False any more. This has already bitten me a few times.

Re: Deprecate admindocs?

Looking at the code, we're only using docutils for parsing reST markup in docstrings. What if we made reST parsing (and docutils) optional? Seems to me admindocs would still be plenty helpful without it. > -- You received this message because you are subscribed to the Google Groups "Django

Re: #2507 LDAP Auth

> *The issue with where documentation should go -- I threw together a > patch for the auth doc in django/docs/, but the auth document is already > long. Does the documentation want to live somewhere else, or is it happy > there? How about a docs/auth_backends.txt? Collin

GSoC Proposal: Auto-generation of Models from Data

Hello, My name is Collin Anderson and I am interested in participating in Google Summer of Code for django. I am a junior at the University of Minnesota studying computer science. My idea is inspired by a suggestion on the 2006 Summer of Code ideas list: "add dabbledb (http://dabbledb.co

Re: GSoC Proposal: Auto-generation of Models from Data

Hi Jacob, > My main point of feedback is that you're dealing with a *HUGE* problem > -- dabbledb represents literally years of work, and trying to > reproduce that in a single summer is seriously unrealistic. Yes, I realize that the types of migrations that dabbledb does are currently not

newforms.fields.UploadedFile Undocumented Backwards Incompatible change

for the UploadedFile.data attribute, which was only in there for 45 revisions. It would be nice to also have a deprecation warning for UploadedFile.content. Thanks, Collin Anderson http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Uploadedfilechanges http://code.djangoproject.com

Re: [RFC] Python 3 and MySQL

While we're on the topic, I'd like to propose (also?) supporting the pure-python, MySQLdb-compatible pymysql, which INADA Naoki (methane) has also put a lot of work into. pymysql is pure-python, so it's really easy to get up-and running on Mac OS X and in other environments, because you don't

use semantic versioning after 2.0?

Hi All, I just saw #23015 come through (1.9 -> 2.0 not an earth-shattering release). I think it's a little ridiculous that decimal point doesn't really mean anything. I'm wondering if it would make sense, after 2.0, to follow Chrome, Firefox, and semantic versioning (http://semver.org/), and

Re: use semantic versioning after 2.0?

> MAJOR version when you make incompatible API changes,MINOR version when you add functionality in a backwards-compatible manner Although our changes are backwards compatible, they are only guaranteed to be backwards compatible for the previous two versions. Instead, semver says that code

Re: Pull django-registration into contrib?

It seems to me, in any case, the first step is to get django-registration actively maintained again. James Bennett is welcoming proposals of people to take over maintenance of the project. Get it working well with custom user models and with python 3. Once django-registration is a thriving app

Re: Updating the organization of the Django Project

> > Also there are like 120 Pull Requests which are over an year old > sometimes.Which scary's off a lot of people. We should do something against > it to have a "cleaner" queue. > In theory every pull request has a trac ticket and the queue is all handled by queries such as:

Re: Proposal new Django Admin css style

I think slowly making small changes over time towards an end goal is better than a quantum leap. I like that in 1.7 we changed admin messages to be green-ish and we started using css rounded corners. Slowly moving towards more mobile/touch friendly and a flat design (replacing gradients)

Re: [GSOC] Weekly update

if we do really need a list, could we gain some performance by caching tuples and converting them to lists instead of caching lists? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails

Re: Proposal: Use timestamp or hash to determine name when uploading duplicate filenames

It seems to me a setting is not the way to go, but a custom storage would be better. I've made a custom storage the computes the md5 of the content and uses that as the directory of the file, though that generate a whole lot of directories. In a lot of ways, I think it would be great if django

Re: Proposal: Password Validity Layer

Could we handle it with model validation on a custom user model? Maybe add a validate_password() method on the user model? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it,

Re: [GSOC] Weekly update

> > Communication. > > From a purist theoretical perspective, there shouldn't be any argument - > the data we're talking about is a list. Lists have homogeneous elements; > Tuples have heterogeneous elements, but have *positional* homogeneity. A > "Point" is a tuple, because element 0 of the

Re: ORM Optimization for filtering by related existence

I personally use qs = qs.filter(somefield__gte=1) (works if the id field is an integer) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Requiring GitHub login for actions on Trac

I was looking at the wiki page myself a few weeks ago an noticed it was horribly out of date. I might be nice to keep that page minimal (maybe just a few links to other pages) because normal users aren't allowed to edit it. -- You received this message because you are subscribed to the Google

Re: [GSOC] Weekly update

Summarizing the conversation I just had with Daniel in IRC: What if we thought about just documenting the high-level api, like what ModelForms uses, and not necessarily document what the django low levels: ORM, migrations, etc would need to use. Could we get away with not documenting

Re: [GSOC] Weekly update

Also, I still believe that just because "class Meta:" stole the word "meta", doesn't mean we should take what it should really be called ("options") and put it on this. Can we call the two "meta options api" and "meta fields api"? or "meta schema api". -- You received this message because you

getting django 1.7 out the door

Hi All, If anyone's looking for ways to help get 1.7 out the door, there's a strange but reproducible many-to-many ORM bug happening in migrations. We could use some help narrowing down the cause of it. https://code.djangoproject.com/ticket/23288 Thanks, Collin -- You received this message

Re: getting django 1.7 out the door

out that Django really doesn't like > this, and there's a reason model validation complains about it. > > Andrew > > > On Thu, Aug 14, 2014 at 6:57 PM, Collin Anderson <cmawebs...@gmail.com> > wrote: >> >> Hi All, >> >> If anyone's looking for ways t

Wiki Home Page

Hi Russ, I like the new wiki home page. Would it make sense to have a link to Github? People who click "Code" in the top right might be looking for the source code. Thanks, Collin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: GSoC Meta refactor: Bikeshedding time!!

The goal is to have "API methods that let you introspect the fields and relations that exist on a model", right? Why go though the trouble of finding the one specific type for each field (that we'll never be able to change later)? Why have a get_fields() method with an ever-growing number of

Re: GSoC Meta refactor: Bikeshedding time!!

Also, I think we should avoid discriminating between "virtual" and non-virtual (as with local vs parent). Why should it matter how a field is stored in the database? I think the distinction will make it harder to use non-relational databases. It maybe helpful to recognize if a field has a

Re: Proposal: Password Validity Layer

Wow. That's simple. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to

Re: GSoC Meta refactor: Bikeshedding time!!

I like the direction the API is heading. RE: composite fields: Would it help to have an attribute on the individual fields like: field.parent = TheCompositeField()? This might help determine which fields to pass into __init__(), and might help when serializing. RE: related objects: I'm

Re: Improvement to objects.get_or_create and objects.update_or_create

This is a bit magical. It means adding or removing a unique constraint could have additional unintended side effects. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send

Re: integrating django-secure

I still don't see the benefit to a dictionary. It's helpful for DATABASES and CACHES because there can be multiple of them. > It ensures that related settings remain grouped together. It seems to me a common SECURITY_ prefix should be good enough - It satisfies our craving for DRY A _tiny_ more

Re: Please don't kill the ecosystem

I agree that there have been a lot of backwards-incompatible changes over the last few years clean up the API. We've really been in "get stuff done" mode. I do however think it's a not good idea to break all compatibility in one single shot. Python 3 did this and 6 years later it's still

Re: Please don't kill the ecosystem

Considering we're trying to come out with more frequent releases, I wonder if it would sometimes make sense to sometimes have a 3-release deprecation for some features. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from

Re: proposing max line length of 119 + enforcing it with flake8

we say 119 because it's 120 minus one, just like PEP8 recommends 79 because it's 80 minus one. It allows for one character at the beginning of the line for a plus or minus sign in a diff. -- You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: Setting dictionaries (was Re: integrating django-secure)

yeah... I thought of circular imports... you would need to lazy-load most imports. not fun. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Proposal: enhance 1.7 migration docs re django.core.handlers.wsgi:WSGIHandler()

I ran into this problem myself upgrading to to django 1.7. The secret is that get_wsgi_application calls django.setup() which is now required to initialize django. I went through and switched all my code to use get_wsgi_application(). get_wsgi_application() has been in the default wsgi.py in

Re: Django views/templates vs. Javascript MVC Front-ends

I think many people are going the django-as-a-REST-server route. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [RFC] Python 3 and MySQL

I'm warming up to mysqlclient. I assume it has better performance or is more correct than pymysql? Is there any hope to getting the package included in debian/ubuntu? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from

Re: [RFC] Python 3 and MySQL

Ohh wow. I also just noticed CyMySQL, which is a fork of PyMySQL with optional C speedups. It seems like a good idea in theory, though it appears to have diverged from PyMySQL a bit. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: [RFC] Python 3 and MySQL

It's great to see us moving forward on this. Thanks to Naoki for all of the work on this! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [RFC] Python 3 and MySQL

I also don't need python 3.2 support (or even python 3.3 support for that matter) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Unifying locale time formats

If you did "git add .", you should be fine without the -a flag, just use git commit -m “Removed seconds from all locales.” -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it,

Re: HTTP/2 and WSGI

On Saturday, September 20, 2014 12:25:02 PM UTC-4, Ryan Hiebert wrote: > > Being the idealist I am, I hope we can find a way to rid ourselves of the > pain of cgi. I'd be more than willing to help, but my help would probably > be more of a hindrance because of the limited exposure I've had with

Re: Storage engine aliases?

> > In hindsight I regret not having pushed harder for integration of > staticfiles into core instead, lots of confusion could have been prevented, > IMO. > Is it too late to move to core? -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Django Admin - Front-End Improvements

I'm not a designer, but I agree the admin could use some tweaks to keep up with the times. (flat design, more mobile friendly, etc). Here are my personal thoughts, in general: - I like small, gradual changes, changing one thing at a time. Like Tim said, separate tickets. - If possible, try to

Re: Websockets... again

Hi Luis, There is some work on making a WSGI2 that would include support for http/2 and likely websockets too. That would likely need to happen first or at the same time. https://github.com/python-web-sig/wsgi-ng You could also check out a project called "hendrix" which supports using

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi All, On Monday, November 3, 2014 5:54:38 PM UTC-5, Carl Meyer wrote: > > I favor keeping OPTIONS. I don't think OPTIONS will be significantly > confusing to beginners (it may even provide a useful hedge between "the > basics" and "the advanced knobs"). > > Once you are doing anything beyond

Re: [RFC] Python 3 and MySQL

I started the ball rolling on getting mysqlclient packaged in Debian/Ubuntu. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768096 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from

Re: Multiple template engines for Django - week 4 - DEP ready for review!

On Tuesday, 4 November 2014 17:30:27 UTC-5, Aymeric Augustin wrote: > > In my opinion the request context processor should be enabled by default. > +1 > I suspect the only reason why it isn't is to avoid changing the default > settings (django.conf.global_settings). > Right. Can we uncomment

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Could we do a list of 2-tuples instead of OrderdDict? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Information on construction of object on form (philosophy)

Philosopy-wise, I agree it would be good (and more secure) to error if the form detects that a field was not present in the html, however it's not possible to properly detect it in every case. On Tuesday, November 18, 2014 12:39:03 PM UTC-5, Collin Anderson wrote: > > Hello, > > Th

Re: Adding hard dependencies to Django's test suite

I'm -0 for freezegun, +0 for unittest. I see unittest as a polyfill that we'll only need to keep around for about 3 years, and I like the "nudging people to use python3" Freezegun is a less popular, less established library, and I'd personally still rather see it be an optional dependency. I

Re: delegating our static file serving

Hi All, I think doing something here is really good idea. I'm happy with any of the solutions mentioned so far. My question is: what does static/dj-static do that our built-in code doesn't do? What makes it more secure? It seems to me we're only missing is wsgi.file_wrapper and maybe a few

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

I was just thinking about this. I agree that a GET causing logout is wrong, and we need to not break things and I agree we need to keep the original view untouched so we don't break anything. _maybe_ deprecate it. The admin could begin using the new view right away. On Wednesday, December 3,

Re: delegating our static file serving

tally thought through. I'm fine with waiting until 1.9 if needed. Collin On Saturday, November 29, 2014 6:07:05 PM UTC-5, Collin Anderson wrote: > > Hi All, > > I think doing something here is really good idea. I'm happy with any of > the solutions mentioned so far. > > My

Re: Settings: lists or tuples?

I agree lists are the way to go. I have heard that tuples are faster, but I don't think that outweighs comma issue and inconsistency. global_settings isn't completely undocumented, based on greping the docs. Seems to me we should at least make the docs and project_template consistent and use

Re: Bypassing 1.7+ migrations

Hi All, Totally a shot in the dark here, but would allow_migrate work in this case? https://docs.djangoproject.com/en/dev/topics/db/multi-db/#allow_migrate Collin On Friday, December 19, 2014 2:04:37 PM UTC-5, Carl Meyer wrote: > > On 12/19/2014 11:59 AM, Marcin Nowak wrote: > > > > > > On

Re: Delivering PR 3114 - The _meta refactor

Ditto. I'm ok with a tiny shim for GFK, and we should get the API right for RelatedObject going forward, (as long as it's at least _possible_ to detect which is which and write code that works on both 1.7 and 1.8). On Monday, December 22, 2014 9:29:15 AM UTC-5, Aymeric Augustin wrote: > > Hi

Re: Delivering PR 3114 - The _meta refactor

Odd. We should really save the "through" attribute on the m2m field itself. Maybe in 1.9... On Tuesday, December 23, 2014 8:33:58 AM UTC-6, Tom Christie wrote: > > Thanks Russ, appreciate your time. > > I've no great problem with keeping 'through' table API undocumented with > 1.8, probably

Re: intended security model for templates

I also think the "load your tag lib by default for your project" is a good idea. It's a tad magical, but very nice. On Sunday, December 28, 2014 5:26:46 PM UTC-6, Curtis Maloney wrote: > > I certainly like the idea of making public the API to load your tag lib by > default for your project.

simplifying the default template context_processors

Hi All, In talking to Aymeric and other developers, we're starting to think about the usefulness of global template context_processors. It seems to us that ideally you should only need the "request" context processor. You could even imagine removing context_processors all together and having

Re: simplifying the default template context_processors

%}. I agree creating custom template tags is not fun. Reusable apps can't assume specific context_processors are installed and may need to use alternatives anyway. Collin On Saturday, January 10, 2015 at 6:42:21 PM UTC-5, Russell Keith-Magee wrote: > > > On Sun, Jan 11, 2015 at 6:40 A

Re: simplifying the default template context_processors

Here's a PR for this change https://github.com/django/django/pull/3897 On Sunday, January 11, 2015 at 4:58:53 AM UTC-5, Aymeric Augustin wrote: > > On 11 janv. 2015, at 09:43, Russell Keith-Magee > wrote: > > > However, I'd still have some concerns about a project

Re: Replace decimal prefix(kB) with binary prefix (KiB) for bytes

I'd be fine changing MB -> MiB in just docs wherever needed, and then not using KB or MB at all because of their ambiguity. I've seen "KiB" and "MiB" around before, but I've never seen "Mebi" before today. On Monday, January 12, 2015 at 6:53:37 PM UTC-5, Markus Holtermann wrote: > > Hey folks,

Re: Settings: lists or tuples?

Hi All, Should change tuples to lists in more places in the docs? https://github.com/django/django/pull/3929 Collin On Thursday, December 18, 2014 at 7:56:47 AM UTC-5, Carl Meyer wrote: > > On 12/17/2014 11:49 PM, Russell Keith-Magee wrote: > > On Thu, Dec 18, 2014 at 7:48 AM, Carl Meyer

Re: Settings: lists or tuples?

Hi Andreas, I agree that tuples do slightly help enforce that settings are supposed to be immutable, and I agree that if someone were to try to modify the settings the way you showed it would be very hard to debug. However, I think it's a pretty rare case. I think a much more common case is

Re: automated import sorting and better pull request checks

I personally prefer multi_line_output = 4 (closing parentheses on the same line), but no big deal either way. On Thursday, January 29, 2015 at 10:56:03 AM UTC-5, Tim Graham wrote: > > Here's the current iteration of the config (it's stored in setup.cfg). > > [isort] > combine_as_imports = true >

Re: Feature proposal: Conditional block tags

Sounds like a spot where we might be able to improve the documentation. On Sunday, February 1, 2015 at 10:33:09 AM UTC-5, Markus Amalthea Magnuson wrote: > > Which is, I guess, why it is the block tag's behavior that would need to > change rather than the if tag's, if support for blocks inside

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

Hi frantisek, I've also ran into a number of problems with extra whitespace in forms. Pretty annoying. I also find settings pretty annoying. :) We were just talking on another thread [1] about the possibility of packaging packaging django.forms as a standalone package, but global settings are

Re: CSRF REASON_NO_REFERER with meta referrer tags

If we add Origin checking, could we then allow a missing referrer and token? (check referrer and token if no origin header) On Tuesday, February 3, 2015 at 5:15:08 PM UTC-5, Paul McMillan wrote: > > The referer check is primarily there to help make users who choose not > to use HSTS safer. > >

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

Hi All, I'd be ok with a well thought-out strip-by-default. - I think most of my problems have been with trailing whitespace on CharFields. - I once have seen a minor unintentional leading whitespace. I think I also may have once used a leading whitespace for sorting purposes, but I'd be ok

User.username max_length 254

Hi All, I was reminded by: Allow shadowing of abstract fields https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ and https://code.djangoproject.com/ticket/24288 (Custom User Models for small tweaks). Could we reopen https://code.djangoproject.com/ticket/20846 and

Re: Bytecode in Migrations

Hah. Check out this ticket :) https://code.djangoproject.com/ticket/23406 On Wed, Feb 11, 2015 at 4:04 PM, abhillman wrote: > I have gotten bitten by lingering bytecode in migrations on several > occasions. Steps to reproduce are a little bit complex, but here is an >

Re: Relations to non-trivial fields

Long term, eventually we want the FK to use a real models.UUIDField under the hood, right? On Sat, Feb 14, 2015 at 1:17 PM, Shai Berger wrote: > Hi all, > > This comes from trying to fix #24343[1] -- a problem where a UUIDField is > used > as a PK (legitimate and common

Re: Psycopg2 version support

Right, I think the situation would be if you don't have admin/sudo and the -dev / -devel header files are not present. Seems to me 2.4.5 would be a safe minimum today, but supporting it until 2018 seems a bit excessive. On Sun, Feb 15, 2015 at 7:18 PM, Christophe Pettus

Re: Drop the TEMPLATE_DEBUG setting

Hi, Is there a reason to not always store the debug information? Performance? Why have two behaviors? Thanks, Collin On Sun, Feb 15, 2015 at 9:15 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > During the multiple template engines refactor, I didn’t touch >

Re: Psycopg2 version support

On Mon, Feb 16, 2015 at 1:41 PM, Thomas Stephenson wrote: > And now I'll shut up, because I'm not entitled to an opinion here yet :D > By the way, Thomas, your opinion is welcome. :) Collin -- You received this message because you are subscribed to the Google Groups

Re: User.username max_length 254

ing-a-custom-user-model). >> >> So, for anyone without a custom user model, who is already running on >> Django 1.7 in production, who would like to have usernames longer than 30 >> characters, there is no way to make that happen. >> >> >> On Friday

Re: Django Admin new look

Re theming layer: In theory (if you use collectstatic :) it should be possible to include an "app" that overrides the css files. I believe it the custom app would need to be placed above django.contrib.admin in INSTALLED_APPS. Or you can even override the files by putting them in a

Re: Changes to django.db.models.fields.Field API

Hi, If it's not too much work, creating pull requests could help give some context and show a bit more of the impact of your proposed changes. Some days I think I'm better at reading Python than English :) value_from_object maybe should be value_from_instance or get_instance_value, as in,

Re: User.username max_length 254

Hi All, I made a pull request. https://github.com/django/django/pull/4250/files I wish I would have thought of this two months ago, but I think it's too big of a change to get into 1.8 this late. I personally don't want to potentially have the release delayed because of possible issues with

Re: Password validation in Django revisited

Hi Erik, This nice, though I'd like it even more if it didn't introduce another setting. :) Having it on the backend would solve that problem for me I think. Also, this may be obvious, but more specific error messages would be nice, like "password is too simliar to username". Collin On

Re: Django Admin New Look

That looks beautiful! I can see all of the improvement from last time too! I'd personally prefer slightly less vertical padding, but otherwise I think it's awesome! Thanks! Collin On Wednesday, March 11, 2015 at 4:20:31 PM UTC-4, elky wrote: > > Hi everyone, > > I reworked my previous attempt

inspectdb database defaults

Hi All, We recently added database introspection of defaults for purposes of testing migrations. https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc I would find it useful to have inspectdb attempt to use those defaults when generating models. (My use case is

Re: GSOC-2015, Newbie, Want to contribute to Django development and also try my hand in GSOC

Hi, Welcome! If you haven't yet, check out the contributing docs. https://docs.djangoproject.com/en/dev/internals/contributing/ I also recommend hanging around the #django-dev irc channel. Collin On Thursday, March 12, 2015 at 7:23:42 AM UTC-4, Saurabh Jain wrote: > > Hello, > My

Re: Pre-DEP: community support of unmaintained versions of Django

Hi All, I am free of 2.6 websites myself (and nearly free of 2.x completely), but I think this makes sense and I'm certainly in favor of community-maintained longer support periods of django versions, assuming people want to do it :) Two thoughts: - This doesn't _need_ to happen through

Re: improving debug logging in development

Hi All, A little off topic, but here's what I do to generate "yellow" html tracebacks in production behind the scenes: from django.views import debug html = debug.ExceptionReporter(request, is_email=False, *sys.exc_info()). get_traceback_html() Though, I do that within the

Re: django-admin.py shebang

Hi Stan, In the source, it's looks like it's been using #!/usr/bin/env python for almost 10 years: https://github.com/django/django/blame/master/django/bin/django-admin.py My quick guess is that gets modified when installing. Did you use the newer version of python to install django? Collin

Re: django-admin.py shebang

/local/bin/django-admin.py > #!/usr/bin/python > from django.core import management > > if __name__ == "__main__": > management.execute_from_command_line() > > > > >> As Collin already wrote, Django uses "/usr/bin/env python" for years. >> >&

Re: Fate of sql* management commands

And the auto-generated in-memory migrations should work for tests too, right? On Friday, April 3, 2015 at 2:34:23 PM UTC-4, Andrew Godwin wrote: > > > >> > An alternative would be to ignore migrations files, regenerate a fresh >> > set of migrations, and dump the corresponding SQL. >> >> I think

Re: ModelManager behaviour for Proxy Models

Hi Mahmud, I personally really like the technique of having a "type" column in the base model. It allows you to query across all types but still get the correct subclass. However, I think the manager is a good place to handle this. You could have a manager that looks something like: objects

Re: Django Admin New Look

There's a ticket about icons here: https://code.djangoproject.com/ticket/20597 On Tuesday, April 7, 2015 at 11:16:42 AM UTC-4, elky wrote: > > Hi everyone. As you can see there is less activity now in this thread. > With the latest 0.9.3 release I just think CSS work is over until anyone >

Re: 1.9 release planning

On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote: > > How about > > a 8 month release cycle and having a LTS in every two years and supporting > the old LTS atleast 3 years from the release date? there will be 3 version > between two LTS. > Interesting. I like the idea of

Re: django site framework bug, site name swaps back and forth each request

Ahh, yes, that sounds like the warning box here: https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/modwsgi/#basic-configuration On Sunday, 19 April 2015 03:03:44 UTC-4, Florian Apolloner wrote: > > Hi, > > this is certainly a bug in your code or deployment via mod_wsgi (eg the > two

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

Though it could still ajax-in the token from a page that does have it, right? On Sunday, April 19, 2015 at 3:42:14 AM UTC-4, Marc Tamlyn wrote: > > I'm not a security expert, but one thing I could suggest is that this > setting does mean that only javascript on a page with a POST form can >

Re: django site framework bug, site name swaps back and forth each request

Try it without setdefault or use daemon mode :) The "standard" configuration has this exact problem, which there's a warning in the docs and why daemon mode is recommended. On Sunday, April 19, 2015, Joe wrote: > @Florian What do you mean the projects are in the same python

Re: django site framework bug, site name swaps back and forth each request

(Multiple config files doesn't mean multiple processes. Daemon mode is the only way to get a separate process per site.) On Sunday, April 19, 2015, Joe wrote: > @Florian What do you mean the projects are in the same python process? > > This is a standard implementation of

Re: User.username max_length 254

that needed this change the most, hence the loss of motivation on this one. :) Thanks, Collin On Friday, March 6, 2015 at 7:05:28 PM UTC-5, Collin Anderson wrote: > > Hi All, > > I made a pull request. https://github.com/django/django/pull/4250/files > <https://www.google.com

Re: Rename *SSL* settings to *TLS*

I don't think it's really worth changing, but if anything, I'd recommend HTTPS rather than TLS, as that doesn't care about the underlying protocol which may change again in the future. Or maybe go with PROXY_SCHEME_HEADER or something. On Friday, May 1, 2015 at 12:23:32 PM UTC-4, Hugo Osvaldo

Re: Redirect loop detection in test client is incorrect

If it helps, I believe Chrome and Firefox have a limit of 20, and Internet Explorer have a limit of 10. On Friday, May 1, 2015 at 2:27:57 PM UTC-4, Mounir Messelmeni wrote: > > We've already the max total redirects counts it's 20 > > if len(redirect_chain) > 20: > # Such a lengthy chain

Re: Proposal: Manually login without authenticate

One advantage of authenticate() is that it isn't coupled to a request and is roughly stateless. Maybe an authenticate_and_login() would be nice. :) On Friday, May 22, 2015 at 12:21:15 PM UTC-4, James Brewer wrote: > > Hey Paulo, > > As you mentioned, the raw password should still be present in

  1   2   3   >