> If optional fields are
> left off the HTML form deliberately, without change the Form class or
> the view code, this is exactly when data loss will currently occur.
> I think you are confusing optional as in "may not be specified by the
> user" with optional as in "may not be processed by the
I think Ian demonstrated exactly why this should not go in and that is not
all forms are ModelForms. Imagine writing a REST API which allows for an
optional format parameter for GET requests which is validated by a Django
form. With the inclusion of this proposal all clients would be forced to
Hi,
I am one such author and I wanted to share my experience. I have ported my
code and test suites for 3 applications to run on Django 1.3-1.5dev and
Python 2.6, 2.7 and 3.2 (1.5dev only).
Those are https://github.com/mlavin/django-responsive,
https://github.com/mlavin/django-ad-code and
I've been thinking about external app compatibility as well and it seems like:
from django.conf import settings
AUTH_USER_MODEL = getattr(settings, 'AUTH_USER_MODEL', 'auth.User')
class SomeModel(models.Model):
author = models.ForeignKey(AUTH_USER_MODEL)
is the easiest solution to
When I was working on a similar issue for django-selectable I created an
issue to address this problem with a simple proof of concept patch
https://code.djangoproject.com/ticket/15760. However I never followed
through with the ticket to try to get something like this added. In the
meantime
This was changed as part of https://code.djangoproject.com/ticket/17899
Best,
Mark
On Wednesday, December 19, 2012 4:23:24 PM UTC-5, Skylar Saveland wrote:
>
> I checked out 1.5 branch today and found a change that I can't find the
> debate/announcement for: e-mail to email in
>
>
Last weekend I set out to fix https://code.djangoproject.com/ticket/21856
which was a 1.7 release blocker and holding up additional 1.7 testing for a
project
I'm currently working on. Upon diving in I saw that the checks for
un-applied migrations
were tied to the runserver command. I thought to
ght place for now.
>
> If we could get some context for the checks - things like "this check is
> only for interactive runserver sessions" - then it would fit there. Perhaps
> we do, I've not looked into checks too much.
>
> Andrew
>
>
> On Wed, Feb 12, 2014 at 10:28
This was already changed in https://code.djangoproject.com/ticket/19866
which is part of 1.6. It's noted under the minor
features https://docs.djangoproject.com/en/1.6/releases/1.6/#minor-features
SuspiciousOperation has been differentiated into a number of subclasses,
and each will log to a
Welcome to the pain that third party app maintainers have already been
dealing with for the past year. I ran into this problem as well when I
added custom user support to one of the apps I maintain. As you noted you
can't simply change the AUTH_USER_MODEL setting because once the test DB is
Andrew,
Can you clarify exactly what is deprecated in this work-around? I don't see
anything in the deprecation timeline to remove MIGRATION_MODULES nor any
pending deprecations related to its usage. It seems like could probably be
replaced by something that uses the app-loading/app-configs
I don't see any meaningful notes about apps being required to ship
migrations beginning with 1.9. I do see deprecation notes about the syncdb
signals changing and the syncdb command itself is clearly deprecated. This
legacy behavior is handled by sync_apps in the migrate command but there
In my experience using the Media class is really only helpful in one place:
the admin. If you have a third-party widget which requires CSS or JS is a
pain to include it without the use of Media. Users want to just include the
widget in the form class and have it "just work". A majority of the
I'll be the first one to bite and submit
one https://github.com/django/deps/pull/1 It needs a lot of work as noted
in the PR but I'm happy to be a guinea pig for the process.
Best,
Mark
On Monday, April 14, 2014 8:41:07 PM UTC-4, Russell Keith-Magee wrote:
>
> On Tue, Apr 15, 2014 at 2:17 AM,
Hello,
I noticed some changes over the past few days to the migrations and I was
concerned about how this could impact reusable applications planning to
support 1.7.
In particular there is a note in
https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies
Be aware, however, that
the app starts shipping its own migrations
> will go.
>
> On Tuesday, June 17, 2014 9:18:57 AM UTC-4, Mark Lavin wrote:
>>
>> Hello,
>>
>> I noticed some changes over the past few days to the migrations and I was
>> concerned about how this could im
Support of south_migrations directory in South goes a long way to
addressing this problem from my perspective so that's very good news to me.
On Tuesday, June 17, 2014 1:34:02 PM UTC-4, Trey Hunner wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/17/2014 10:05 AM, Andrew
Hi,
Tom has done a great job describing why this has stalled recently. I plan
to pick back up on this now that the book has been released. I agree that
defining the public API is the best first step and the current DEP is not
sufficient in this regard. Before making any internal changes we
I have concerns about "built-in feature" means for existing applications
(and future applications really). Under "Preserving Simplicty" you note
that you should be able to run Django as simply as you do now. Is there a
consideration to run "classic" WSGI applications without channels?
This
Anssi criticisms are fair and I feel that some of these responses are
glossing over the details. You've claimed this is the same or equivalent to
a forked worker model but it isn't because there is no process
management/link between the interface and worker and because you've chosen
to make this
I'm not trying to be
needlessly critical of your work.
On Fri, Dec 18, 2015 at 10:07 AM, Andrew Godwin <and...@aeracode.org> wrote:
>
>
> On Fri, Dec 18, 2015 at 2:00 PM, Mark Lavin <markdla...@gmail.com> wrote:
>
>> Anssi criticisms are fair and I feel that some of the
I had assumed this was still a work in progress because there are missing
tests and some documentation. The build is passing but the unittest
coverage for the new modules seems low or at least not up to the standards
I expect for Django contributions. The same for the daphne and asgiref
en't required to run. If these we're in the install_requires
then I would withdraw the objections about them with regard to this change
in Django.
-Mark
On Wednesday, May 4, 2016 at 10:26:22 AM UTC-4, Andrew Godwin wrote:
>
> On Wed, May 4, 2016 at 6:15 AM, Mark Lavin <markd...@gmail.com
On Wednesday, May 4, 2016 at 12:39:02 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Wed, May 4, 2016 at 8:26 AM, Mark Lavin <markd...@gmail.com
> > wrote:
>
>> As noted in the PR there is at least one new setting,
>> CHANNEL_SESSION_ENGINE, which is lacking doc
I like Markus' suggestion and I think that's in line with how Django
handles other optional dependencies such as the db bindings
(psycopg2, MySQLdb, etc). Those raise an ImproperlyConfigured exception
when there is an import error. The memcache cache backend on the other hand
raises an import
it continues to mature.
Best,
Mark
On Wednesday, May 4, 2016 at 3:18:03 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Wed, May 4, 2016 at 11:52 AM, Mark Lavin <markd...@gmail.com
> > wrote:
>
>>
>>
>> Given that there is no guarantee of message de
Major features have never been perfect, no, but they have in the past
typically gone through two paths to prove out their design/API/usefulness.
One is as an established and mature third-party app such as messages,
staticfiles, and django-secure. More recently the other has been through
the
erformance
or say that isn't a requirement to even measure, regardless of outcome,
before its inclusion?
- Mark
On Wednesday, May 4, 2016 at 10:00:15 PM UTC-4, Russell Keith-Magee wrote:
>
> Hi Mark,
>
> On Thu, May 5, 2016 at 8:41 AM, Mark Lavin <markd...@gmail.com
> > wrote:
process and I will admit that has
jaded many of my interactions with the core team. Building consensus is
hard and I’m posting this to help work towards the goal of community
consensus. Thanks for taking the time to read this all the way through and
I welcome any feedback.
Best,
Mark Lavin
On Thursday, May 5, 2016 at 4:20:06 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Thu, May 5, 2016 at 12:34 PM, Mark Lavin <markd...@gmail.com
> > wrote:
>
>> After somewhat hijacking another thread
>> https://groups.google.com/d/msg/django-developers/t_zuh9ucSP4/eJ
Thank you for your comments and I have some brief replies.
On Thursday, May 5, 2016 at 4:20:06 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Thu, May 5, 2016 at 12:34 PM, Mark Lavin <markd...@gmail.com
> > wrote:
>
> The main gains are (in my opinion):
> - The same
wrote:
>
>
>
> On Thu, May 5, 2016 at 2:19 PM, Mark Lavin <markd...@gmail.com
> > wrote:
>
>> Thank you for your comments and I have some brief replies.
>>
>>
>> If I'm understanding it correctly, groups are an emulated broadcast. I'm
>>
at 8:52:17 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Thu, May 5, 2016 at 5:13 PM, Mark Lavin <markd...@gmail.com
> > wrote:
>
>> Yes I agree with the value of a standardized way of communicating between
>> these processes and I listed that as a highlight of Cha
, Mark, for starting this discussion. I, too, found myself simply
> accepting that channels was the right way to go, despite having the same
> questions you do. I realize this shouldn't be, so I've chimed in on some of
> your comments.
>
> > On May 5, 2016, at 2:34 PM, Mark Lavin <ma
Yes thank you Andrew for your continued work to move this conversation
forward. I hope that Channels can continue to grow as an external package
under the Django umbrella and bring on more contributors and improvements.
Best,
Mark
On Tuesday, May 10, 2016 at 12:44:21 PM UTC-4, Ryan Hiebert
35 matches
Mail list logo