Hi Bobby,
I'm not sure what you mean by "fields don't allow built-in defaults". While
it's true that Django's DateField (for example) doesn't have a built-in
default, here's[1] a custom field with a built-in default:
class MyDateField(models.DateField):
EPOCH = date(197
> On Jun 15, 2015, at 1:42 PM, Rick van Hattem (wolph)
> wrote:
>
> While I understand the rationale, it's not really possible due to the
> underlying Python object:
> >>> import datetime
> >>> datetime.date()
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: Required
Agree this is not an appropriate default, although I could see an argument
for supporting __all__ like in forms. This isn't very hard as a third party
solution though so I'm not super keen on that idea.
M
On 15 Jun 2015 22:03, "Shai Berger" wrote:
> (I received the message I'm replying to here w
The Google doc has been evolving:
https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
On Monday, June 15, 2015 at 3:37:16 PM UTC-4, Aymeric Augustin wrote:
>
> Le 15 juin 2015 à 15:54, Loïc Bistuer >
> a écrit :
> >
> > I'm -0 (borderline -1) on tha
(I received the message I'm replying to here with an empty subject, and
detached from the thread. Google Groups being funny?)
On Monday 15 June 2015 22:52:09 Rick van Hattem wrote:
> On 15 June 2015 at 21:34, Florian Apolloner wrote:
> > On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hat
On 15 June 2015 at 21:34, Florian Apolloner wrote:
>
>
> On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph)
> wrote:
>>
>> Would anyone oppose a pull request like this?
>>
>
> Yes, it is highly backwards incompatible for not much gain, I am also
> usually just fine with one/two
Le 15 juin 2015 à 15:54, Loïc Bistuer a écrit :
>
> I'm -0 (borderline -1) on that proposal. I don't think we should compromise
> on our historical commitment of deprecating over 2 releases
I'm in the same camp as Loïc on this specific point.
If we're approaching consensus, could a kind soul p
On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph) wrote:
>
> Would anyone oppose a pull request like this?
>
Yes, it is highly backwards incompatible for not much gain, I am also
usually just fine with one/two fields for list_display. You could just use
your own admin subcl
While I understand the rationale, it's not really possible due to the
underlying Python object:
>>> import datetime
>>> datetime.date()
Traceback (most recent call last):
File "", line 1, in
TypeError: Required argument 'year' (pos 1) not found
>>> datetime.datetime()
Traceback (most recent cal
While there are several solutions to this problem, I find myself
scaffolding the Django admin every time I create a new app/model. I even
created an app to do just that (harmless
plug: https://pypi.python.org/pypi/django-admin-generator/).
Anyhow... I've wondered for some time why Django doesn'
Personally I don't agree with implementing the Channel using in-memory mode
first. Writing code to communicate among sockets will become very
difficult for me(ordinary developer). If we see async in Django as a tool
instead of a coding style, I think Redis/NoSql/Database backend/ is good
enough as
Given the negative reaction to quick deprecation of LTS releases, I also now
most prefer Loïc's proposal. It's semver with a little extra to help folks out.
I'd also most prefer seeing 1.9 being changed to 2.0 if this proposal were
accepted, but that is not a strong opinion given that I am not f
I'm -0 (borderline -1) on that proposal. I don't think we should compromise on
our historical commitment of deprecating over 2 releases, especially since it's
aligned with the policy of Python itself and much of the ecosystem.
It should be as easy as possible for 3rd-party apps to straddle 2 LTS
Here are the cleanups for dropping Python 3.3:
https://github.com/django/django/pull/4861
To prevent users from getting stuck on a non-LTS version of Django with an
old version of Python (when they would have had longer support had they
stuck with an LTS), the policy I suggest we adopt is:
Typ
I really like Ryan's second proposal (quoting here again):
2.2 - 0 mos - (LTS) No features dropped
> *3.0 - 8 mos - All deprecations, including the LTS deprecations, are
> removed *
> 3.1 - 16 mos - No features dropped
> 3.2 - 24 mos - (LTS) No features dropped
> *4.0 - 32 mos - All deprecatio
Hello everyone,
I've been formulating a plan to decouple Django from the request-response
cycle for a couple of years now and after discussing it with some people at
DjangoCon Europe I thought it was high time that I actually wrote it up,
wrote some code, and solicited feedback.
So here it is. Th
16 matches
Mail list logo
