Hi Aymeric,
Thanks for all of your work on this. Am I too late to discuss the settings?
I don't see much advantage to the OPTIONS dict. It is consistent with
DATABASES, and it separates the engine specific settings from the common
settings. However, it doesn't seem like that helpful of a distin
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
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 thi
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 it
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 django-developers+un
Hello,
The way works in html forms, there's no distinction
between "unchecked" and "form field not present". The browser won't even
send an empty key for the the checkbox at all if it's not checked.
Therefore, if the django form has a BooleanField and doesn't see a key in
the data for it, the
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,
>
&g
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
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 mor
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, 20
t's not totally 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 menti
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 li
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 F
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 Rus
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 doe
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. It'
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
s nav %}. 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
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 template that took
> out all t
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,
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 > wro
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 th
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
>
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 i
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
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.
>
>
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
wi
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 increas
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
> rough example:
>
> Local Bo
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 practice), and we wish to
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 wrote:
>
> On Feb 15, 20
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
> TEMPL
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
"Django developers (Cont
n/1.7/topics/auth/customizing/#substituting-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 happ
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
STATICFILES_
Could be as simple as: {% csrf_token %}{{ form }}
On Tuesday, March 3, 2015 at 9:32:48 AM UTC-5, Ilya Kazakevich wrote:
>
> I agree: adding template from example is good idea! And I believe it will
> be used at least by newbies who just study Django auth system and by people
> who just need prot
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, pick
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 thi
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 Monda
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
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 runni
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 nam
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 Django
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 got_request_exception
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
O
'console_scripts',
> 'django-admin')()
> )
> $ cat /usr/local/bin/django-admin.py
> #!/usr/bin/python
> from django.core import management
>
> if __name__ == "__main__":
> management.execute_from_command_line()
>
>
>
>
>> As Co
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
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 =
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
> repo
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 havi
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 p
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
> acc
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 process?
>
> This is
(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 the sites framework abo
er responsible for the project 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/fil
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 B
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 likel
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 th
Hi Emil,
I also like "server sent events" (EventSource). They get through proxies
much more reliably than WebSockets. :)
"You would start the process separately, add a script tag to your page, and
all clients that connected to the page would be connected to the process.
Now Django could push m
8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and hav
cantly longer than this proposal. See Carl's post in the
> thread where we discussed the deprecation cycle changes:
> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>
> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>&g
Hi Dom,
Yeah, it looks like the admin_static is simply uses the staticfiles tag if
staticfiles is installed, otherwise falls back to the core static? The only
reason why it admin_static exists is because the admin can't rely on
staticfiles being installed, right? Maybe pulling the the staticfil
Hi All,
Here are some thoughts in reply to some of the comments in the
django-compat thread. I don't stick to the LTSs myself, but I've helped
maintain apps that have 1.4 compatibility.
On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>
> 1.8 (LTS): No features dropped.
> 1.9:
ot;supporting" the APIs for more than 5 years after deprecation.
But to be clear, most of that time it's only security support for those
APIs, and the APIs are long gone from master. Right?
Thanks,
Collin
On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>
>
> I believe.
>
> For "maintenance costs" I am not worried about supported deprecated APIs
> in old releases, only how long they stay around in master as that could be
> a barrier to innovation.
>
> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrot
marked as
deprecated in the previous LTS).
Collin
On Thursday, June 11, 2015 at 9:31:08 PM UTC-4, Matt Austin wrote:
>
> On 11 June 2015 at 01:37, Collin Anderson > wrote:
> >
> > I'd propose something slightly different, that's very close to our
> current
Some more data points (to support removing 3.3 support):
I believe old versions of RHEL were the reason people needed 2.6 support.
Unlike 2.6, I believe RHEL has never supported Python 3 except through
"Software Collections", and the Python33 software collection EOL is Oct
2016 (before 1.8 supp
I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2
LTS, 4.0, etc.) LTS is the final of a major version number, and we
sacrifice a little bit of strict semver, but it give some nice meaning to
the version numbers.
On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer
so +1 on the proposal as it stands, and neutral on when the
> semver
> >> versioning should begin.
> >> >
> >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> >> > I'm +1 on the Google doc proposal and like Markus, I suppor
I think XMLField was removed because the security of xml parsing and
validating is hard to get right.
On Sunday, June 28, 2015 at 7:51:22 PM UTC-4, Russell Keith-Magee wrote:
>
>
> On Mon, Jun 29, 2015 at 7:32 AM, Josh Smeaton > wrote:
>
>> I'm not quite up to date on XML in databases (I've neve
Hi,
This is the best reason I could find:
http://security.stackexchange.com/questions/62769/must-login-and-logout-action-have-csrf-protection
One thing that's going on here is that the csrftoken changes every time
someone logs in, so the old login page now has a stale token. The changing
csrf t
Hi All,
It seems to me this is just how class inheritance works in Python. Nothing
special in Django here, it just might not be intuitive.
I do think deepcopy has too much overhead to warrant a deepcopy by default
in Django for everyone, but it may help you to use it in your code.
Collin
On T
Sounds good to me, though I think we should wait until there's actually
native JSON support in one of the other databases. MariaDB has "dynamic
columns" which I think is more similar to Postgres's hstore.
On Wednesday, July 8, 2015 at 4:38:42 AM UTC-4, Григорий Крамаренко wrote:
>
> +1
> I'm wai
;
>>> objects = UserManager()
>>>
>>> class Meta:
>>> db_table = 'auth_user'
>>>
>>>
>>>
>>> Does anyone think this method could be worth adding to the Django
>>> documentation? I'd
We definitely should make sure postgresql_psycopg2 still works as expected.
As a data point, Heroku uses "postgres" instead of "postgresql" in their
DATABASE_URL scheme. Maybe we could support all three? :)
On Wednesday, July 15, 2015 at 9:17:30 AM UTC-4, Baptiste Mispelon wrote:
>
> Hi everyone
For choices, I've sometimes had my migrations import the correct choices
from the live model in order to avoid needing to create extra migrations
every time they change.
On Wednesday, July 15, 2015 at 7:10:39 PM UTC-4, Andrew Godwin wrote:
>
> Hi Marcin,
>
> Django persists every single field at
Ahh, yes, that's a good example of what I was thinking of:
https://github.com/pennersr/django-allauth/blob/fb2851fe333f303faab28e9633b6cf1b0ddbbe98/allauth/socialaccount/migrations/0001_initial.py#L39
On Wednesday, July 15, 2015 at 8:17:33 PM UTC-4, Marcin Nowak wrote:
>
> Please also review that
The documentation could give better backwards compatibility guarantees.
On Friday, July 24, 2015, Tim Graham wrote:
> There is at least one ticket about adding more blocks to the admin
> templates: https://code.djangoproject.com/ticket/14810
>
> You can browse the "contrib.admin" component in Tr
I like the behavior of showing the login screen if they don't have
permission. It's simple and pretty friendly. The new hint is helpful too.
On Tuesday, July 28, 2015 at 4:16:58 PM UTC-4, Carl Meyer wrote:
>
> On 07/28/2015 12:36 PM, Tim Graham wrote:
> > We received a ticket [1] noting that whe
I wonder if there's a way in the docs we can deprecate it as in "we don't
recommend you use it", but not actually schedule it for removal.
On Friday, July 31, 2015 at 2:01:20 PM UTC-4, Marc Tamlyn wrote:
>
> I don't know about unmaintained, but I think there's a consensus that
> .extra() has a h
That looks right to me.
On Sun, Aug 2, 2015 at 11:51 AM, Andy Baker wrote:
> I'll file a ticket but I wanted a quick sanity check first.
>
> In db.models.fields.Field there is a method called get_flatchoices (as
> well as _get_flatchoices which is turned into a property).
>
> I've searched the s
Hi All,
I really like the "don't use this on new code, but there's no rush in
replacing it" category. I think that's really important to have that in a
project that's this old. I think it would be great to minimize the amount
required changes that need to be done.
Thanks,
Collin
--
You recei
This all makes sense to me, but it would be nice if it worked out of the
box, especially for the purposes of the tutorial. :)
On Saturday, August 8, 2015 at 5:53:32 PM UTC-4, Aymeric Augustin wrote:
>
> Hello,
>
> While writing some horrific code [1] related to the development server’s
> auto-re
Just a quick thought: I could imagine some newbies could get confused by
the python-like syntax and try to do:
Equal(P.user.get_full_name(), 'Bob Someone')
I don't think it's not a huge deal, but worth noting.
On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
>
> Hi all,
To be clear: jQuery 1.x and 2.x are the exact same except for IE < 9
compatibility. jQuery v1.11.3 and v2.1.4, released simultaneously, _are_
the latest version of jQuery. It's not like "1.11.x" is an "old" release
series. 1.x and 2.x have the exact same features and API and are 100%
compatible
Hi Jun,
I think this might do what you want:
{% block js %}{{ block.super }} {% endblock %}
But, like the original poster said, please use django-users list for things
like this.
Thanks,
Collin
On Mon, Aug 24, 2015 at 2:25 AM, Amin Jun
wrote:
> I liked his suggestion, I don't know if I'm u
I propose adding a check on UserCreationForm (used by the admin). The
current implementation relies on the model fields unique=True check which
is case-sensitive (except on mysql).
Whenever I've made a login form, I've always used or made a copy of or at
least studied UserCreationForm. I think if
That looks right to me. More specifically (from the attic/magic-removal
branch):
Added css and some of those html classes:
https://github.com/django/django/commit/84b7590ba6e566186bba975e57b0686dd53927ca
Removed html classes, but not css:
https://github.com/django/django/commit/738d9af1e8e38b0289b7
Is there an external library for Python < 2.7.8? I know we don't officially
support the system version of python in RHEL/CentOS and Ubuntu, but I bet
we could get away with requiring a dependency for those old versions of
Python in new versions of Django.
On Mon, Sep 21, 2015 at 10:30 AM, Tim Grah
If anyone's curious, the mysql situation is as crazy as you might expect. :)
The max is only determined only by the total row size (65,535 bytes) and
the index size (767 bytes default).
Mysql defaults to only allowing 3-byte (no emoji) unicode characters, so
65,535/3=21,845 max across the entire
Could we have permanent backward-compatible (no deprecation timeline)
shims? I'm -0 if not because it's yet-another thing that everyone needs to
change when upgrading.
On Tue, Sep 22, 2015 at 11:23 AM, Marc Tamlyn wrote:
> The idea has been discussed before and was rejected as needless code chur
Yeah, I bet we could get rid of the entire "Installing an official
release manually" section, as I assume we don't actually want to
recommend that. Also, the "Installing the development version" section
outlines a more manual way already.
It makes sense to me to tell people to "install virtualenv"
Hi John,
I think we need to wait until we drop Python 2.x support to be able to do
this, as 2.x won't accept this syntax. Does that sound right?
Thanks,
Collin
On Sunday, October 11, 2015 at 9:22:17 AM UTC-4, John Michael Lafayette
wrote:
>
> Python now has static type checking. All you do is
If it helps, I have a similar need in the template. My case requires
adding, removing, or replacing one of the arguments on the fly:
In templates, I often need to change _one_ key of a GET request on the fly.
My use case is a "filter by" sidebar on the same page as a "sort by" and
"number per p
I also agree. And to be clear, we're talking about UserCreationForm, right?
Or where specifically would we implement this? (What part of Django do you
use that doesn't check this?)
On Monday, October 26, 2015 at 2:04:24 PM UTC-4, bliy...@rentlytics.com
wrote:
>
> > -1 on changing the check of u
Ooooh. I think I like it. The syntax could be a bit confusing, but I think
I like it. :)
On Saturday, November 7, 2015 at 12:16:05 PM UTC+1, Aymeric Augustin wrote:
>
> Hello,
>
> Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings
> contain a dotted Python path to the storage cl
I wouldn't mind having these in the project template. They're already the
example values in the docs. It could make it slightly easier for beginners.
STATICFILES_DIRS = [os.path.join(BASE_DIR, 'static')]
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
I would use this feature. It would be nice for calling a simple function.
Though if we didn't add the feature it would be nice to document the text
piping option.
The one downside of the piping is you get a little bit of garbage in the
output, especially when iPython is installed.
On Tuesday,
Also, doing this from the backend seems like sub-par way to do it. I would
recommend implementing this in javascript, so it can auto-update over time
if you leave the window open.
On Tuesday, 10 November 2015 14:57:57 UTC-5, jamie wrote:
>
> On Tue, 2015-11-10 at 18:50 +, Marc Tamlyn wrote:
Hi,
"It would also make it theoretically possible for the latest stable version
to support the
last LTS version from the same code tree".
Have you seen the latest changes to the deprecation policy? We hope we've
done exactly that (having the latest version of Django support code that
was writ
1 - 100 of 264 matches
Mail list logo
