27;Connor wrote:
>
> >>>> > I have absolutely no pull in decision making, but maybe my message
> >>>> > will count towards a "community voice".
>
> >>>> > I think that including an image thumbnail package that integrates into
> >&
I got a printout of a stack trace on a white screen: I don't know how
I can help you guys find the bug since I have zero context with this
stack trace, but hopefully it helps.
Traceback (most recent call last):
File "C:\Python26\Lib\site-packages\django-trunk\django\core\servers
\basehttp.py",
Django version: 13858
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
Fo
I think I've found a bug in auth.login.
user = User.objects.get(username=request.POST.get('username', ''))
if user.check_password(request.POST.get('password', '')):
login(request, user)
This raises the following exception:
Exception: 'User' object has no attribute 'backend'
Locatio
ion[BACKEND_SESSION_KEY] = user.backend
Exception Type: AttributeError at /backend/login/
Exception Value: 'User' object has no attribute 'backend'
On Sep 23, 12:53 pm, Jacob Kaplan-Moss wrote:
> Hi --
>
> On Thu, Sep 23, 2010 at 1:38 PM, Yo-Yo Ma wrote:
> > I
It should also be noted that I don't have installed "contrib.admin" as
I don't need it. I hope that doesn't matter regarding a separate app,
but I thought I'd mention it.
On Sep 23, 12:53 pm, Jacob Kaplan-Moss wrote:
> Hi --
>
> On Thu, Sep 23, 2010 at 1:3
I'm simply proposing the idea of having the development server
explicitly set something to indicate a "in development" status, so
that if that does not exist you can make the assumption that the
project is live. I don't like having to check for specific things
like to see if I'm in live or develop
tually a problem with django and not
> the way you are using it, it'd be better addressed on django-users
> first.
>
> David
>
> On Fri, Sep 24, 2010 at 5:41 AM, Jacob Kaplan-Moss wrote:
> > On Thu, Sep 23, 2010 at 2:18 PM, Yo-Yo Ma wrote:
> >> Hey Jacob, unders
Btw, yes I am aware of the paragraph below explaining the confusing
dilemma. That's how I fixed my issue. Thank you Santiago.
On Sep 23, 5:02 pm, Yo-Yo Ma wrote:
> It is a problem with Django. I thought it was a problem with the code
> but it isn't. It's a problem with
different configs:
>
> manage.py runserver --settings=settings_test
>
> etc..
>
> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss wrote:
> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma wrote:
> >> I'm simply proposing the idea of having the development server
3, 3:25 pm, Jacob Kaplan-Moss wrote:
> On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma wrote:
> > I'm simply proposing the idea of having the development server
> > explicitly set something to indicate a "in development" status, so
> > that if that does not exist you c
with and it
> > doesn't get in the way of deployment/development. Thus this fails to
> > meet one of the critical requirements for consideration for inclusion
> > into core.
>
> > D
>
> > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma wrote:
> >> Thanks David,
ater during the login process.
> > """
>
> > The only time I could see this being a documentation issue is when
> > someone is implementing their own authenticate function but this
> > breaks the django convention if simply implementing a backend and
> &g
ev_settings
else:
# is live
just example. I'm not suggesting "project" as a global. It's just to
show the type of setting I want.
That's much cleaner, and far more explicit than "import os, socket,
etc".
On Sep 23, 7:41 pm, Yo-Yo Ma wrote:
> Thanks for the
ass
>
> 2)
> if DEBUG:
> from dev_settings import *
>
> Because to have "project.is_dev" you'll have to write it somewhere already!
>
> It's bootstrapping problem.
>
>
>
>
>
> On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma wrote:
> >
e options:
> > - check the absolute path of the settings file on the filesystem if you can
> > ensure this path is different on the production server
> > - import socket; and check socket.gethostname()
> > - check for "runserver" in sys.argv
> > - etc.
>
>
ddress. So the in active user can login and start using
> the basic features right away.
>
> On Sep 24, 6:58 am, Yo-Yo Ma wrote:
>
>
>
> > Thanks for the replies David. I didn't mean to sound brash with the
> > Joel stuff. It's just that the API didn&#
hen the dev server is run (by default) that allows you to set
settings.debug to true.
On Sep 24, 8:04 pm, Russell Keith-Magee
wrote:
> On Sat, Sep 25, 2010 at 8:59 AM, Yo-Yo Ma wrote:
> > Chuck - Thanks. Perhaps there isn't such room for improvement on the
> > topic.
>
ere's your solution, simple as that..." without
even basically understanding my question, or reading it for that
matter. Again, I apologize for the now 22 post long digression.
On Sep 26, 1:52 am, Russell Keith-Magee
wrote:
> On Sunday, September 26, 2010, Yo-Yo Ma wrote:
> > I apol
You don't require health profiling information, but if they enter any,
they must enter it all.
Currently, the pattern is something like:
def clean(self):
if any((self.weight, self.height))
if not all((self.weight, self.height))
raise ValidationError("Uh oh!")
My proposal
This is a feature request. I'm not asking how to do it. If you read,
I've shown the current method of doing this in clean(). I'm proposing
the addition of an additional Meta option to allow for automatically
adding this behavior.
On Sep 27, 1:18 am, Florian Apolloner wrote:
> Please post usage qu
Thanks, David. I've read some about the "Custom validation error on
unique_together" ticket. I imagine that if people want customization
there, required_together would need the same. The only idea I have
that seems to work for both situations is:
required_together = (('weight', 'height', 'You must
Django's aggregation is a great tool. That said; if I'm a new user who
knows it exists but not how it works, I'll likely pull up the page
about Aggregation (http://docs.djangoproject.com/en/dev/topics/db/
aggregation/). This page gives an excellent overview, but leaves me
feeling like there is some
Form wizard docs mention that MD5 hashes are made using
settings.SECRET_KEY -
http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#django.contrib.formtools.wizard.FormWizard.security_hash
If you give me a value, I give you a hash back, and you're aware that
I'm using Django (thi
Positive integer fields are useful all the time, and BigIntegerField
is no exception to that.
On a side note, there doesn't appear to be any built-in model-field
level protection from putting gigantic numbers into an IntegerField.
When using IntegerField in dev (sqllite3) it allows me to put
somet
I realize this is a bit late and not even the "right" discussion, bit
I just stumbled across this and the wiki, and I feel a bit sick to my
stomach.
1) self.request?
Whatever gains come from this will be offset by loss in design. A
method is called by a request. That is simple common sense. A met
bring about new Git Hub forks with possibly better
implementations and alternative APIs for class-based views. Something
much better will come and it'll be too late.
,
On Oct 15, 12:11 am, Russell Keith-Magee
wrote:
> On Fri, Oct 15, 2010 at 1:59 PM, Yo-Yo Ma wrote:
> > I realiz
me), and the other 10% is spent typing as fast as I can.
On Oct 15, 2:10 pm, Łukasz Rekucki wrote:
> On 15 October 2010 21:40, Yo-Yo Ma wrote:
>
> > My strong suggestion (again prima facie to this discussion) is:
>
> > Do not include something as controversial into the
Gabriel
You don't have to go to thesaurus.com with the intention of generating
a more formidable argument. I was merely offering my opinion. Playing
devil's advocate should be regarded as counter constructive. If I see
a man about to throw an egg at an otherwise clean wall, I don't need
to offer h
Typo (on iPhone): should read, "...devil's advocate shouldn't be..."
On Oct 16, 2:24 pm, Yo-Yo Ma wrote:
> Gabriel
>
> You don't have to go to thesaurus.com with the intention of generating
> a more formidable argument. I was merely offering my opinion.
I was trying some things out, and I noticed that it isn't actually
possible (without using a char-code and converting it) to put
something like ° (degree symbol) into a "message".
Example:
this code:
messages.info(request, request.GET.get('symbol'))
with this URL:
http://127.0.0.1:8080/?symbol=%
Thanks, I'll do that in the morning with a traceback, and steps to
reproduce it.
On Oct 20, 6:15 pm, Russell Keith-Magee
wrote:
> On Thu, Oct 21, 2010 at 12:50 AM, Yo-Yo Ma wrote:
> > I was trying some things out, and I noticed that it isn't actually
> > possible (with
OK, I finally created a ticket: http://code.djangoproject.com/ticket/14525
On Oct 20, 10:28 pm, Yo-Yo Ma wrote:
> Thanks, I'll do that in the morning with a traceback, and steps to
> reproduce it.
>
> On Oct 20, 6:15 pm, Russell Keith-Magee
> wrote:
>
> > On Thu, Oc
Case closed (by Tobias Luetke). I appears that the exception occurred
somewhere between my keyboard and my chair... as usual :)
On Oct 21, 1:36 pm, Yo-Yo Ma wrote:
> OK, I finally created a ticket:http://code.djangoproject.com/ticket/14525
>
> On Oct 20, 10:28 pm, Yo-Yo Ma wrote:
>
I have a large application that doesn't user contrib.auth, and when I
run `manage.py test` I get a slough of 35 errors, all of which are
DatabaseError: no such table: auth_user (differing Tracebacks for
each). I don't have any actual tests yet, just the SimpleTest that
comes free in tests.py. INSTA
> to fix this; skipping the user_messages tests unless contrib.auth is
> available.
>
> Yours,
> Russ Magee %-)
>
>
>
> > On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma wrote:
> >> I have a large application that doesn't user contrib.auth, and when I
> >> ru
spect we'll need to crack out some of the new unittest2 features
> to fix this; skipping the user_messages tests unless contrib.auth is
> available.
>
> Yours,
> Russ Magee %-)
>
>
>
> > On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma wrote:
> >> I hav
In the related_name docs (
http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name
) you read about how you must specify a related_name for any foreign
key in an abstract base class. This doesn't seem to be true in
practice (I'm using trunk from a week ago,
Ok, thanks. I'm using CookieStorage for messages, so the issue may not
reside only with legacy storage. Should I create a ticket for this?
On Nov 3, 6:11 am, Russell Keith-Magee
wrote:
> On Wed, Nov 3, 2010 at 1:43 PM, Yo-Yo Ma wrote:
> > I've been using CookieStorage (for
Ok, I finally created a ticket for this:
http://code.djangoproject.com/ticket/14632
On Nov 3, 5:26 pm, Russell Keith-Magee
wrote:
> On Thu, Nov 4, 2010 at 3:58 AM, Yo-Yo Ma wrote:
> > Ok, thanks. I'm using CookieStorage for messages, so the issue may not
> > reside only
I was reading about the low level cache API, and I noticed that you
could cache None (implied by the recommendation not to do so). It made
me wonder if I could cache other Python-specific objects, like
dictionaries, lists, ORM Model instances, etc. Are there differences
between a normal model insta
Ok!
On Nov 25, 8:28 pm, Jacob Kaplan-Moss wrote:
> On Thu, Nov 25, 2010 at 6:05 PM, Yo-Yo Ma wrote:
> > I was reading about the low level cache API, and I noticed that you
> > could cache None (implied by the recommendation not to do so). It made
> > me wonder if I cou
I recently worked with BuiltWith to provide a list of methods for
detecting whether a site was using Django, and their team implemented
them. You can now check stats for Django usage at
http://trends.builtwith.com/framework/Django (sparse for now), and if
you get the Firefox plug-in, you can check
ites, etc.
On Dec 17, 3:26 pm, Yo-Yo Ma wrote:
> I recently worked with BuiltWith to provide a list of methods for
> detecting whether a site was using Django, and their team implemented
> them. You can now check stats for Django usage
> athttp://trends.builtwith.com/framework/Djan
I understand that accessing ``request`` inside of a form's clean
method, or in a model's save method is a bit of a "leaky abstraction",
but it can be very useful in a number of cases. I've seen solutions
which use ``threading.local`` in middleware to accomplish this, but
the consensus seems to be,
MyForm(request=request)
> # use the form instance
>
> Problem solved, no threadlocals required. You can call this a
> "workaround" if you like; I'd prefer to call it "good software
> engineering practice".
>
> Yours,
> Russ Magee %-)
>
&g
I apologize ahead of time, if this bug is rather a user error.
If you have a model:
class Foo(Model):
spam= CharField(max_length=30)
xyz= CharField(max_length=30)
def __unicode__(self):
return self.xyz
and you use it in the shell like this:
>>> Foo.objects.create(xyz="Hello
, you have to specify
blank=True. I would suggest that to maintain integrity between your
applications logic and the database, Django should raise an
IntegrityError, if blank=False.
On Jan 2, 6:53 pm, Russell Keith-Magee
wrote:
> On Mon, Jan 3, 2011 at 7:46 AM, Yo-Yo Ma wrote:
> > I apol
I would head over the the django-users list (this one's for
development on Django itself): http://groups.google.com/group/django-users/
Also, you might try Stack Overflow. It's a great place to get quick
answers.
On Jan 3, 6:07 am, Ondřej Mirtes wrote:
> Hello,
> I am new to Python/Django/App Eng
> duplicate key, etc." [1] Since the creation of a model instance
> doesn't affect the database, it should definitely not raise an
This isn't correct. Model instantiation doesn't affect the database.
Model creation (ie, the use of ``Model.create()`` does. I'm not
arguing that instantiation should
>> ...*before* writing to the db. Therefore, don't use
>> Person.objects.create()
>> ...it does strike me as being a little odd that there is no way to validate
>> your data...
Let me get this straight:
I just shouldn't "use Person.objects.create()", if I ever want to
to take advantage
Waylan:
> Therefore, don't use Person.objects.create()
Marty:
> Developer mistakes can ruin your data. Full stop.
> Unfortunately, this is one of the many issues where "X doesn't work
> the way I think it should" gets confused with "X doesn't work the way
> it should" or even "X doesn't work.
On Jan 4, 4:43 pm, Jacob Kaplan-Moss wrote:
> On Tue, Jan 4, 2011 at 3:37 PM, Yo-Yo Ma wrote:
> > What's with all the hostility here? I've heard about this from others.
>
> Let's just stop this, right now. There's no hostility in Marty's tone
> -- if y
Problem:
When using the test client, it's simple to check for a 200 response
code, but not quite as simple to quickly determine, why a 500 was
encountered, in the case of a test failure.
Proposed Solution:
A new test method which expects a status code of X, and when a 500 is
encountered instead,
+1
I spent this Saturday morning implementing ad hoc table sorting in a
ListView's get_queryset. It felt very wrong, to say the least. An
abstracted sorting and filtering framework, along with a few of the
admin-ish features that are already in core (inline model formsets, et
al) provide some very
cient, but this should surely be in core.
On Oct 10, 12:22 am, Yo-Yo Ma wrote:
> +1
>
> I spent this Saturday morning implementing ad hoc table sorting in a
> ListView's get_queryset. It felt very wrong, to say the least. An
> abstracted sorting and filtering framework, along
What would be the value in replacing the admin with a new version with
abstracted, reusable tools... that still resides in the new admin?
IMO, duplicating the admin's features would be better than that
(assuming you can't simply change the admin's guts in-place, which is
probably the case).
On Oc
If you're posting to this list by logging in to https://groups.google.com/
rather than via email, I'd like to propose that you write your reply above
the quoted message to which you're replying. If you do this, the digest
emails that most subscribers get will be easily previewable from their
em
o to reiterate, in email digests the latter format results in the reply
not even being included in the email. Since this is a mailing list, it's
sometimes useful to be able to actually read a digest of it it in your
email.
Cheers
Yo-Yo
On Tuesday, June 4, 2013 1:28:47 PM UTC-4, Javier Gu
There doesn't appear to be a way to load fixtures from JSON (using Postgres
- works fine in sqlite3) for the following models:
class Collection(models.Model):
main_thing = models.OneToOneField(
'things.Thing',
null=True,
on_delete=models.SET_NULL
)
class Thing(mo
his any further. As it
> stands, I'm not aware of any problems loading fixtures into PostgreSQL. If
> you are able to construct and provide a set of models (which you have done)
> and simple fixture (which you haven't) that fails reliably, we have a new
> bug on our han
Pardon one typo: I meant `python manage.py loaddata test_data` in my
previous post.
On Friday, June 21, 2013 4:32:33 PM UTC-4, Yo-Yo Ma wrote:
>
> Hi Russel,
>
> Thanks for taking the time to explain that. I tried that same day to
> reproduce the issue in a testing env with
start.
On Friday, June 21, 2013 4:34:14 PM UTC-4, Yo-Yo Ma wrote:
>
> Pardon one typo: I meant `python manage.py loaddata test_data` in my
> previous post.
>
> On Friday, June 21, 2013 4:32:33 PM UTC-4, Yo-Yo Ma wrote:
>>
>> Hi Russel,
>>
>> Thanks for takin
:24:40 PM UTC-4, Yo-Yo Ma wrote:
>
> Hi again Russell,
>
> I did a little digging. I'm not sure, but I may have uncovered the
> problem. A transaction block (using `commit_on_success_unless_managed`) is
> entered and exited during each fixture object loaded, due to the calls t
I should actually note, this bug affects all versions of Postgres, and
presumably all other supported RDBMSs as well.
On Sunday, June 23, 2013 7:35:45 PM UTC-4, Yo-Yo Ma wrote:
>
> Minor correction: I placed Atomic.__exit__ to verify - the transaction is
> commited every time *startin
o 1.5? If it doesn't,
> it's a regression introduced by the new transaction management in Django
> 1.6, and it's a release blocker.
>
> --
> Aymeric.
>
>
>
> On 25 juin 2013, at 22:30, Yo-Yo Ma >
> wrote:
>
> I should actually note, this b
a bug, but I'm not sure why it happens. Could you file a ticket in
> the tracker, so we don't forget about it?
>
> Thank you,
>
> --
> Aymeric.
>
> On 26 juin 2013, at 02:43, Yo-Yo Ma >
> wrote:
>
> > It does happen in 1.5, but the error is someh
gt;
> Thank you,
>
> --
> Aymeric.
>
> On 26 juin 2013, at 02:43, Yo-Yo Ma >
> wrote:
>
> > It does happen in 1.5, but the error is somehow slightly different (no
> traceback in 1.5 to find the root cause). I have 2 fields on the order
> model poi
I'm excited about Django Vanilla Views. I think the GCBV implementation in
Django is pretty good (I use GCBV got everything - leads to better
extensibility), but a simpler version of the same functionality would be great.
I'm NEVER certain of whether I'm using the right mixins and base class com
It's so easy to build an Account or Tenant or Site model of your own, do a
little leg work, and you've got a multitenant app with all the custom
functionality you need. Getting caught up in trying to use contrib apps and
hacking things together turned out to be more work once you pass the basics
+1 on basically adding the functionality of checksecure to the default
validation.
-1 to adding the middleware.
--
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 emai
If this is a known bug, I apologize, otherwise I'll create a ticket in Trac
for it.
Details:
INSTALLED_APPS is
(
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfile
(continued)
I'm using Django 1.7c3, and the above is the first time running migrate
(sqlite3 database deleted prior to running).
--
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
was a deliberate change, I think it was discussed on the list but
> maybe just IRC. The tutorial was changed to reflect it, if any
> documentation still says otherwise it is a documentation bug.
>
> On 31 באוגוסט 2014 18:23:58 GMT+03:00, Yo-Yo Ma > wrote:
>>
>> (contin
With as many new frameworks as there are out there, with the gains in
popularity seen in Go and Node, my thinking is, move quickly, break (some very
small) things, or die slowly. As was said, if your favorite lib doesn't work
with 1.6 or 1.7, either use a prior version, or spend some time contri
Epic, thanks so much!
--
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 d
Along with the subject, I'd also propose abstracting the purposes that
contrib.sites.requests.RequestSite serves out of the sites app, since the
purpose it serves is more of a general one whose usefulness spans admin and
auth, as well as third-party apps. The use of code from sites when sites is
Please read this in full - you will not be disappointed by the end.
We often talk about "multiple-inheritance" when referring to multiple
levels of {% extends ... %} and defining {% block ... %} many layers up in
base templates.
But, something that comes up as a useful idea in my mind on a regu
r current
> example.
>
>
>
> *orders/list.html*
>
>
>
> {% extends 'generic-list.html' %}
>
>
>
> {% block list-item %}
>
> Order # {{ order.id }} (total: {{ order.total }})
>
> {% endblock %}
>
>
>
>
>
> *From:* django
concept is that
> multiple template inheritance is unnecessary.
>
>
>
> *From:* django-d...@googlegroups.com [mailto:
> django-d...@googlegroups.com ] *On Behalf Of *Yo-Yo Ma
> *Sent:* Tuesday, February 18, 2020 2:25 PM
> *To:* Django developers (Contributions to Django itse
sary in asynchronous communication.
On Tuesday, February 18, 2020 at 3:59:09 PM UTC-5, Aymeric Augustin wrote:
>
> Hello Yo-Yo Ma,
>
> Please assume good faith. You've been around for 11 years, so you know the
> way you address Matthew isn't how we behave on this mailing-list.
;products/base.html" in the products app.
>
> I often use this pattern exactly for the case when some app needs to add
> its own submenu.
>
> Best,
> Matthias
>
>
>
> On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma > wrote:
>
>> Please help us all understan
:
>
> I need help with this project, I can't configure the template pages to
> display the information
> https://github.com/shadowruge/benim_pro.git
>
> Em ter., 18 de fev. de 2020 às 18:39, Yo-Yo Ma > escreveu:
>
>> Hi Matthias,
>>
>> Thanks for the repl
Request exceptions have always been easy to manage, because you can use
middleware, and there is the built-in signal:
https://docs.djangoproject.com/en/3.0/ref/signals/#got-request-exception
Problem:
However, if you want to send data to e.g., Sentry or perform some other
action (logging, etc.)
The nice thing about leaving the warning as stern as it is is that anybody who
is absolutely sure that they need to store files this way isn’t going to stop
because of the warning to begin with; while weaking the warning will most
assuredly lead to “Django is Slow” posts by newcomers that didn’t
A model with a custom permission:
class *Spam*(Model):
class *Meta*:
permissions = (('spam', 'Can eat spam'),)
...
$ manage.py makemigrations
$ manage.py migrate
Now we have a custom permission in the User admin:
foods | spam | Can eat spam
Then update the permission's
FWIF, I wrote a custom data migration to update the Permission model.
My OP is attempting to suggest that migrations should handle this
automatically.
On Friday, March 30, 2018 at 5:43:39 PM UTC-4, Yo-Yo Ma wrote:
>
> A model with a custom permission:
>
> class *Spam*(Model):
>
I have yet to ever come across a situation where the default field
is more useful than the raw ID field, pertaining foreign key fields in the
admin.
I have, however, personally witnessed a major publishing company bring
their production app servers to a halt (out of memory) due to Django
att
One last note: M2M could also benefit from this, and could continue to look
for `filter_horizontal` and not use a raw IDs field in those cases.
On Wednesday, October 17, 2018 at 11:59:43 AM UTC-4, Yo-Yo Ma wrote:
>
> I have yet to ever come across a situation where the default
> fiel
To hopefully add to this conversation:
I'll start by saying I've enjoyed the contributions by Andrew over the years
and believe he is a most excellent developer.
A couple months ago, around the same time that JKM started Andrew's repo (which
is what got my attention) I decided to give Channels
Correction:
*JKM starred (not started) - stupid, stupid iPhone.
--
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-de
@Tom
> I'd be surprised if they didn't end up with the model default. Personally
I'd treat that as a regression, and revert to the older behavior.
I think Tim is saying the opposite, that Django 1.10 accidentally
introduced "fields missing from POST are set to model defaults" behavior.
@Tim
>
I'm not a fan of adding more complexity, for a couple reasons:
1) you have the ['*'] option for local / office development
2) you can just add a record to /etc/hosts to point to the server and then use
a name like e.g., local-office - just update the record to point to whatever IP
you're using s
> I found it much more difficult to follow to the point where I didn't feel it
> was an improvement.
I think that patch was just an example of bad abstraction. For instance,
_log_and_response was strange and confusingly named, and seemed to be there
mostly for vanity, to mask the imperative nat
101 - 194 of 194 matches
Mail list logo
