ecreed by the core team a long time back
(https://code.djangoproject.com/ticket/6041#comment:6), and I can't find
any indication of that decision being reversed. Was this change intentional?
Cheers,
- Matt
--
You received this message because you are subscribed to the Google Groups
"
Adam Johnson wrote:
> Stephen - you're right that a constraint is the best way to enforce
> consistency in the DB. That doesn't fit every use case for sessions though
> - people use Django's built-ins with many different kinds of data stores
> that don't support l
The "post_comment" example of sessions appears to be incorrect:
https://docs.djangoproject.com/en/3.1/topics/http/sessions/#examples
Imagine two HTTP requests coming in at the same time, both seeing that
"has_commented" is False, and then both create a comment and set the
session variable to Tr
s works well, and managing the exclusions through settings is not a big
deal. Having said that, I do like the idea of putting it inside the Auth
middleware as well.
+1 from me to put this into core functionality, I include django-stronghold
in basically all my projects already.
Cheers,
Matt
O
EDIT:
Actually, after some further digging it turns out it's worse than I
thought. Unless I'm missing something it looks like there currently isn't
any non-hacky way at all to set a table's schema in django. There are
workarounds that involve SQL escaping hacks such as setting a model's
db_na
Hi,
So currently django seems to take the name of your models (either inferring
it from the model class name or, if provided, it takes it from the model
Meta options), and prepends the name of the app the model belongs to with
an underscore to avoid table name conflicts. It then creates that t
ango where
such field name strings are expected and wrapping the input in this
function.
Is there any chance something like this could be considered as a new
feature?
Thanks in advance,
Matt
--
You received this message because you are subscribed to the Google Groups
"Django developers (C
Perhaps we ought to just keep the current behavior when DEBUG is True (it
seems so obvious now, I can't believe it wasn't the first thing I
suggested)? Django does lots of helpful things in DEBUG mode at the expense
of performance. I think this would be an innocuous change for most people.
It
T ...
FROM HugeTable ORDER BY NonIndexedColumn LIMIT 21 (locking it up)
8. Bonus: Trigger all of the above on all your wsgi processes
In short, just call repr(BigTable.objects.all()) (where BigTable has an
ordering on an non-indexed column and lots of rows)
On Thursday, October
like such a minor thing. And I don't know of any precedent for changing the
behavior of Django in an interactive shell (and you can tell I'm not a fan
of inconsistent behaviors).
I'm going to re-open the ticket and hope other Django devs chime in.
On Thursday, October 10,
repr(some_queryset) will execute the query and display some results from
the query. This is done because it's (somewhat) helpful for debugging.
https://github.com/django/django/blob/2a6f45e08e8cb8c7e5157915c378b453109424d2/django/db/models/query.py#L248
This has caused at least two people to sc
properly.
-Matt
On Fri, Sep 14, 2018 at 11:29 AM, Tim Graham wrote:
> Sorry, I still don't understand what "whitelisting the health check path"
> looks like.
>
> Here's the snippet for anyone reading the thread after the pastebin expires.
>
> ALLOWED_H
se in
production to support AWS health checks that may help give some more
context: http://dpaste.com/2BS0C5M
-Matt
On Fri, Sep 14, 2018 at 10:44 AM, Tim Graham wrote:
> What would be the value of that setting for your use case?
>
> On Friday, September 14, 2018 at 11:52:46 AM UTC-4, Jonas H w
ut shortly. Other than that
(major) gap, I'd love to hear if I've missed anything important. The build
script is here <https://github.com/vtbassmatt/django/blob/ci/.vsts-ci.yml>.
On Thu, Jul 12, 2018 at 10:36 AM Matt Cooper wrote:
> Thanks! I'll keep in on list as long as no
ing/issues/168> with
the xmlrunner folks to make the same change. I'm also going to see if I can
track down the right person to be more liberal in what the uploader accepts.
On Thu, Jul 12, 2018 at 9:40 AM Carlton Gibson
wrote:
> Hi Matt,
>
> The settings files from the django-box p
Thanks Josh, I'll take a look at that.
Also, I got past the pylibmc problem (I wasn't running `apt-get update`
before attempting to install libmemcached-dev).
On Thu, Jul 12, 2018 at 8:58 AM Josh Smeaton wrote:
> Hi Matt,
>
> The django-box project[0] uses very close
r several years, but greatly improved it over the last year. From an open
source perspective, the worst problem the "black box" nature -- the
community couldn't see built results, test failures, etc since VSTS
projects were always private. Now with public projects, we're hoping
our CI system is as good a home for Python (and PHP,
and Ruby, and ...) projects as any system out there. One of the research
activities I'm doing is trying to get a CI pipeline set up for well-known
Python projects. Then I can see where we have gaps, where we have better
features, et
an just our translation management not being up to
scratch, and B) whether there's been any previous work on addressing this?
Cheers,
- Matt
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
>
>
> On Thursday, March 24, 2016 at 12:07:14 AM UTC+1, Matt wrote:
>>
>> > the ModelBackend uses the Permission model, so why would that ever
>> work without beeing in INSTALLED_APPS?
>>
>> ModelBackend.authenticate() doesn't use the permissions mod
Apolloner wrote:
>
>
>
> On Wednesday, March 23, 2016 at 8:36:39 PM UTC+1, Matt wrote:
>>
>> I created https://code.djangoproject.com/ticket/26401
>> <https://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F26401&sa=D&sntz=1&usg=AFQjCNG7tek6
r any
> model imports. Since the usage of any of the backends requires models, the
> import there seems fine -- I'd import RemoteUserBackend in
> RemoteUserMiddleware.__init__ -- A patch would be very welcome.
>
> Cheers,
> Florian
>
> On Wednesday, March 23, 2016
I like to use the authentication machinery in Django, without explicitly
putting 'django.contrib.auth' in INSTALLED_APPS. This prevents a bunch of
unused tables from being creating in the database.
This was possible in earlier version of Django. In 1.8, a spurious warning
was generated, but tha
Currently, the TEST database settings like USER and PASSWORD are only used
by the Oracle backend.
See:
https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TEST_USER
I just hit a case where it would be nice to use a different database user
during testing -- and I don't use Oracle.
With a more structured release plan, and LTS releases, would it be
worth considering LTS releases as 'major' version numbers, with
regular releases and 'minor' version releases? It would be easier to
identify LTS releases at a glance, and might provide more meaning to
the v
If I have some models like so:
from django.db import models
class X(models.Model):
y = models.ForeignKey(Y)
... other fields ...
class Y(models.Model):
... some fields ...
... and I do a query like so:
X.objects.all().values('y')
... I get back a list of dictionaries that contai
>
>
>
> On Saturday, April 25, 2015 at 8:46:58 AM UTC+2, Matt Hooks wrote:
>>
>> I'm not really familiar with the design ideals of the Django devs or the
>> WSGI spec. From what I can tell, the spec doesn't specify whether the url
>> should be unquoted befor
o. The
gevent ones dont play nice with my python3 install.)
On Friday, April 24, 2015 at 5:07:59 PM UTC-4, Florian Apolloner wrote:
>
>
>
> On Friday, April 24, 2015 at 10:51:12 PM UTC+2, Matt Hooks wrote:
>>
>> (The behavior of the development server is similar to the test
Hi all,
As I was fixing an issue in our API related to url encodings, I noticed a
problem should have been caught by a test that was somehow passing.
(Remember, make sure your test can fail!)
If you had some path /some/path/Spam%20Ham, and a URL pattern to capture
/some/path/(?P.+)$, it's not
Ticket and patch have been submitted regarding this:
https://code.djangoproject.com/ticket/24496
https://github.com/django/django/pull/4337
Since this is related to CSRF and technically weakening the strictness of
the Referer check, Tim Graham suggested soliciting feedback here to get
more eyeb
Here is the commit for adding HTTP range support. I tested it in late
versions of Chrome, Firefox, Opera and IE.
https://github.com/satchamo/django/commit/2ce75c5c4bee2a858c0214d136bfcd351fcde11d
The RangedFileReader class may be superfluous but I'm not aware of anything
in Django or the Python
And DEP20 for Django philosophy :}
https://docs.djangoproject.com/en/dev/misc/design-philosophies/
--
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-d
#x27; does appear to return the
correct results.
Thanks for investigating.
--
Matt
--
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+
s the correct approach.
Should an empty list be the desired behaviour, should an exception be
raised, or should the old behaviour (which doesn't honour timezones) be
maintained when tzinfo is not available?
--
Matt
m...@mattaustin.me.uk
http://mattaustin.me.uk/
--
You received this message b
On Thursday, August 1, 2013 3:50:33 AM UTC-4, Florian Apolloner wrote:
> For Python >= 2.7 it should be CPython; for everything below the separate
> unittest2 repository.
>
Thanks.
Just closing the loop. Now there's a conversation[1] on python-dev which
led to an existing ticket[2] that's alm
report your findings to the upstream maintainers.
>
> That way if it's actually confirmed as an issue, the solution will benefit
> much more people than people doing testing in Django.
>
Thanks for the lead, Ramiro.
Is the ultimate upstream the CPython repository now? Or a
t_result.test_method))
+_XMLTestResult._test_method_name(test_result.test_id))
testcase.setAttribute('time', '%.3f' % test_result.elapsed_time)
if (test_result.outcome != _TestInfo.SUCCESS):
With these two changes, I can see memory fluctuate, increasin
I
describe as "untidy" rather than as a bug as I'm not clear whether the
documentation on validation is suggesting fields should have a "to_python"
method and/or whether it's reasonable to expect "to_python" methods (if
they exist) on form fields should work.
Hi,
Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5
alpha tagged on the github repository? The tagging seems to have
fallen behind with these releases.
Thanks,
--
Matt
--
You received this message because you are subscribed to the Google Groups
"Django developers&q
Thanks, Russell. That's similar to the approach we were thinking of
implementing. Hopefully we'll have a straw man to share shortly.
Matt
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on
t, an approach that the community would
like to include in Django?
[1]: http://nedbatchelder.com/blog/201008/global_django_requests.html
--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
--
You received this message because you are subscri
Sorry all, disregard my previous email, I misread one thing and
completely missed Wim's original message.
On Thu, Mar 8, 2012 at 11:07 PM, Matt Pegler wrote:
> For the project I am working on, we solved this by making a custom
> auth backend that checks the username against the e
For the project I am working on, we solved this by making a custom
auth backend that checks the username against the email column. We've
found it to be a nice clean solution to wanting to use email addresses
instead of usernames.
On Thu, Mar 8, 2012 at 9:54 PM, Clay McClure wrote:
> "Django is a
On Fri, Jun 17, 2011 at 6:45 PM, Vinay Sajip wrote:
> Matt Bennett writes:
>
>>
>> > This is a case for a custom Filter object [1]. The filter object
>> > implementation would only be a few lines, to reject logging when DEBUG
>> > is True, and can be att
> code paths, and the admin email handler itself can remain
> general-purpose, but the backwards-compatible behavior can be maintained.
>
> Matt, if you'd be willing to open a ticket for this, that'd be helpful.
> If you feel like putting together a patch using the Fil
On Mon, Jun 13, 2011 at 9:53 PM, Vinay Sajip wrote:
> On Jun 10, 2:05 pm, Matt Bennett wrote:
>
>> Is there a reason the call to logger.error can't come before we return
>> the technical_500_response when DEBUG=True? It seems to me that the
>> debug level should
rror is passed to the logger at all.
Regards,
Matt.
[1]
http://stackoverflow.com/questions/6305132/django-1-3-logging-500-errors-are-not-logged
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send em
g off - a call has to be made to the
object.__getattribute__ - so self.db and self.cursor would need to be
fished out using that.
I wasn't sure about reopening #15289 or raising a new ticket, so
thought I'd post here to ask about the best course of action (assuming
I'm spot on i
On Apr 7, 10:47 am, Julien Phalip wrote:
> Hi Matt,
>
> Do you think this could be related
> tohttp://code.djangoproject.com/ticket/11448
> ?
>
> If so, do the patches attached to that ticket help resolve your issue?
>
> Thanks,
>
> Julien
Hi Julien,
Tha
han the public API.
Want me to log it as a bug and include the test that'll pass and some
notes explaining what's gone on? (I can, and have, run the same test
against Django 1.2.5 to prove the test fails where the problem hasn't
been masked by the change to the call to add_fields).
se of a reverse OneToOne
then something along the lines of "if not allow_many and (m2m or (not
direct and not isinstance(getattr(field,'field',None),OneToOneField))"
instead could work to allow OneToOne reverses through in setup_joins
when allow_many is False.
Regards,
Matt
--
nfluence on our potential
revenue sees pages like lynx does.
If not support html5 features now before the 1.4 release, then mark
support for ie6 like the XMLField, obsolete and on an accelerated
deprecation schedule.
I rest my case ;}
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
Yo
/
I think we should join this movement, and provide modernizr, for
example in conditional css tag
It works for me, hence all should benefit from it.
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
You received this message because you are subscribed to the Google Groups
"D
Ahh, I missed that from your original post.
I like that. :)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-deve
It could just be a combo of both. There'd be one file for the
urlresolver.js, and a patterns.js. Interesting.
Now, could the patterns in Python be translated to Javascript properly? I'll
do some playing around today and see if I can come up with some basics. Even
if this doesn't land in Django
I think the biggest problem with translating the reverse() lookup is the
lack of kwargs and named capture groups in Javascript regex. So a pattern
such as: /page/(?P\d+)/ would not translate whatsoever. Then on the
Javascript side, we wouldn't be able to use: reverse('goto_page', [],
{page_id:
There also proposes the problem of selecting which urls are "published" in
this file and which aren't. Any ideas for that? I'm sure lots of people
wouldn't want their entire sitemap exposed to the public in one large js
file.
--
You received this message because you are subscribed to the Googl
So you're basically proposing to write a Javascript library that is a
translation of URLResolver, and essentially have a dynamic "Javascript" file
that could be included that would contain your URL patterns? Just trying to
make sure we're on the same page.
--
You received this message because
How could this even begin to be solved without incurring another http
request to resolve the url pattern?
The only way I can imagine it is if we had a generic /resolve/ path that
took some get parameters to return a full URL, or even it translate to a 301
redirect, but that'll get messy with PO
I give you an example:
BTW switch name from media to "useruploaded" or "uploaded", which IMHO
is self explaining, hence MEDIA is not.
STATICFILES = {
'uploaded' : { # old name MEDIA
'PREFIX' : '',
'ROOT': '',
'URL': '',
},
'admin': {
'PREFIX' : '',
'ROOT': '',
s a nice little pattern that gets us by,
but yes, things like this do show that there needs to be one overall
"recommended" method for maintaining separate settings on a per
server/environment basis.
On Mar 22, 2011, at 7:05 PM, Ian Kelly wrote:
> On Tue, Mar 22, 2011 at 4:49 PM, Ma
Why not just do an import for your custom settings?
try:
from site_settings import *
except ImportError:
pass
On Mar 22, 2011, at 5:51 PM, Ian Kelly wrote:
> On Tue, Mar 22, 2011 at 6:44 AM, Kristaps Kūlis
> wrote:
>> I personally would greatly appreciate update in docs to sho
Thats right,
there should be a secret_settings.py file with db credentials and
secret_key
also a warning that it should not be added to version control
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
On Mar 21, 5:07 pm, Kristaps Kūlis wrote:
> "real" config should not be in ve
What we use is a settings.cfg, which is an ini file for global
configurations. Database settings, etc. We need to share these settings
across different languages and parts of our application.
You can set up your ini file as such:
[secret]
key=abcdefghijklmnopqrstuvwxyz0123456789
ini files are
What do you think?
IMHO both this ways are good
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubsc
/__init__.py imports all models. It works like a
charm.
I think it should be by default :}
I created skel/django/project and skel/django/app folders, where I
have this file structure
when I start project I simply copy folder, rename it, and adjust
--
Matt Harasymczuk
www.matt.harasymczuk.pl
--
You
e per view
--
Matt Harasymczuk
www.matt.harasymczuk.pl
On Mar 21, 8:44 am, Russell Keith-Magee
wrote:
> On Mon, Mar 21, 2011 at 9:09 AM, haras.pl wrote:
> > It would be nice to have possibility to distinguish a HTTP method in
> > urls.py. IMHO it would be clearer and more
the case of a reverse OneToOne
then something along the lines of "if not allow_many and (m2m or (not
direct and not isinstance(getattr(field,'field',None),OneToOneField))"
instead could work to allow OneToOne reverses through in setup_joins
when allow_many is False.
Regards,
Ma
On Fri, Jul 30, 2010 at 2:57 PM, Jerome Leclanche wrote:
> [2] People who do have ideas and do write code, but still get rejected
> because their ideas don't conform to whatever the core devs need in
> their websites.
I don't think that's a fair criticism at all.
> ...
> Nice job scaring that po
is set to True doesn't mean that False now is not of the
correct data type for BooleanField) so to_python shouldn't be doing
this check. I think it's probably an oversight as the code that's now
in "to_python" on BooleanField in 1.2 is what was in "clean" in 1.
the default and thus the default value would be valid so the user
could just hit submit without interacting with the field, whereas if
the selection list includes "Unknown" and defaults to that, the user
has to interact with the field and change it to "Yes" or "No" to pa
For the reasons I gave in my explanation above - which bit isn't
clear?
> If you require a "Yes" or "No" choice, why do you use a
> NullBooleanField in the first place and not a BooleanField ?
>
> George
--
You received this message because you are subscribed to the Google Groups
"Django develo
change would be in to_python
in the latter to check in the case where it would return None if
self.required is true and raise the validation error if that's the
case (i.e. similar to what BooleanField.to_python does for values of
False).
Matt
--
You received this message because you are subscr
> If we'd thought of it, dropping 7.4 support in 1.2 would have been the
> right thing to do. However, retroactively doing so now would be abuse
> of the time machine privileges and I'd like to avoid being grounded.
> #1's not worth the effort, so that just leaves #2, which sounds about
> right to
out it being a known issue just because the change in m2m saves
means that users (like me) who have a combination of a longish model
name and a longish m2m field name will find things break on upgrading
from 1.1 to 1.2 so you'd want to warn them off doing so!
Matt
--
You received thi
it - I was just wanting to make sure my
updated patch was on someone's radar to get looked at eventually so
it's great to hear you've picked it up (it's not urgent at all for me
- just thought I'd check before it slipped my mind :). Hope you're
having some luck getti
get the ticket
moved along (and whether my tests are sufficient and in a good enough
place in the test suite).
Regards,
Matt
On May 25, 12:00 pm, Matt Hoskins wrote:
> I think (from squinting at the code) that in Django 1.2 m2m field
> updates now use the object save code to add relati
've noted on the issue, although maybe I
should flag it thus).
Regards,
Matt
--
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 gro
On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner wrote:
>
> On Mar 10, 2010, at 7:16 AM, Joan Miller wrote:
>
>> It's a disaster from the maintenance view point. If it were not so,
>> then people would not be proposing to refactor the settings as has
>> been made in Pinax, or from multiple posts so m
> on this field not being null?
>
What isn't clear is that this value must be after 1900: I had used a
value of datetime(1,1,1,0,0) as "never logged in", but this fails with
password reset.
Matt.
--
You received this message because you are subscribed to the Google Groups
&q
en logs in. This could occur if a
person creates
password reset requests for a user that is not themself.
Matt.
--
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
On Nov 27, 10:07 pm, noel wrote:
> I really love this application Reinteract. Its an enhancement to
> Python Interactive Shell. And it would be lovely if I can use
> Reinteract with manage.py shell.
Have a look at bpython. I have a command set up where I can run
./manage.py bshell
And I get a
On Oct 5, 1:44 pm, Simon Willison wrote:
> Other than dates being a bit more annoying to pass around, I really
> don't think that telling people they can only dumps/loads JSON-
> encodable data would be a huge burden.
You could use YAML instead if you want date support... although JSON
does seem
On Sep 24, 10:18 am, Simon Willison wrote:
> This offers two APIs: sign/unsign and dumps/loads. sign and unsign
> generate and append signatures to bytestrings and confirm that they
> have not been tampered with. dumps and loads can be used to create
> signed pickles of arbitrary Python objects.
I'm very interested in the idea of expanding the database level
constraints that can be supplied to a database schema, and also
automatically apply the same constraints to the model/view in django.
The various backends that support them, I believe already apply such
constraints for PositiveIntege
, which I have just started using
for migrations. It doesn't have anything in there that is that
useful, other than raw SQL. Which can do those type of things, but it
is nicer to move into the declaration.
Matt.
--~--~-~--~~~---~--~~
You received this me
On Sat, May 16, 2009 at 1:42 PM, Richard Davies
wrote:
>
> My question is effectively the same as asking if the test suite passed
> on Oracle between [8314] in August 2008 and [10022] in March 2009.
>
> I assume that it must have passed during those six months (Django 1.0
> was [8961] in Septembe
On May 6, 2009, at 8:50 PM, Karen Tracey wrote:
> On Wed, May 6, 2009 at 10:34 PM, Leo Soto M.
> wrote:
>
> While testing the django-jython oracle backend I get an ugly failure
> on model_forms_regress,
Yes, I saw this too. I'll check in a fix tomorrow a.m. if no one
beats me to it.
>
Done.
http://code.djangoproject.com/ticket/10433
On Sun, Mar 8, 2009 at 3:20 PM, Matt Doran wrote:
> Thanks Malcom.
>
> Will do. I saw the patch contribution guidelines, but wasn't sure if a
> ticket was required for such a trivial patch.
>
> Matt
>
>
> On Sun,
Thanks Malcom.
Will do. I saw the patch contribution guidelines, but wasn't sure if a
ticket was required for such a trivial patch.
Matt
On Sun, Mar 8, 2009 at 2:54 PM, Malcolm Tredinnick wrote:
>
> On Sun, 2009-03-08 at 14:19 +1100, Matt Doran wrote:
> > Hi all,
>
Hi all,
Attached is a trivial patch for a typo in the testing documentation.
Regards,
Matt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
On Jan 22, 2009, at 9:23 PM, catsclaw wrote:
>
> On Jan 22, 12:12 am, Jacob Kaplan-Moss
> wrote:
>> Why don't we start over here: what is the problem? What did you try
>> do
>> do? What did you expect to happen? What actually happened?
>
> Here's another problem I'm stuck at. I'm trying
ce in helping Ian
Kelly and I to keep the Oracle backend in shape.
Matt
On Jan 16, 8:17 am, "Karen Tracey" wrote:
> On Fri, Jan 16, 2009 at 9:43 AM, Alex Gaynor wrote:
> > PgSQL is indeed PostgreSQL. Yes, I do still get the failures pre-fast
> > tests, I guess I
n is, what should the
configuration option look like? Here are two options:
1: SQLITE_MODULE_NAME = 'pysqlite2'
2: DATABASE_OPTIONS = {'module': 'pysqlite2'}
3: USE_PYSQLITE2 = True
4: # Other
Preferences? My current vote is option 2, because it does not
introd
I have a bit of confusion about how possibly "non-trivial" patches are
supposed to be handled.
Common practice here seems to be that if someone wants to propose a
change and has a patch ready, they open a ticket first and then a
discussion here. The docs indicate that if the patch is non-trivial
Is there any documentation as to why Django is not threadsafe? It just
seems to me that with the Global Interpreter Lock and all, it would be
threadsafe. I don't intend to start a flame, I am just curious about
learning why this might be. I am favor of the mutlitprocess approach layed
out by Lud
used by ChangePasswordTest, to ensure that the
correct templates are used during the test.
- Matt Brown
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
I would like to see this, it seems to be an idiom that most people use. I
know i have to implementent that exact same thing for every project I have
ever done with django.
On Thu, Oct 30, 2008 at 1:34 PM, Ole Laursen <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> There are a couple of things in settings
On Aug 25, 10:51 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> I just noticed that the MySQL backend also fails on this get_or_create
> test. It is returning an OperationalError instead of an IntegrityError.
> Looks like MySQL returns errno 1364 (ER_NO_DEFAULT_FOR_FIELD) in this case
> but this
side the oracle backend. Let me know if
you think that's acceptable.
On Aug 23, 10:47 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2008-08-23 at 08:07 -0700, Matt Boersma wrote:
>
> [...]
>
> > However, I grep'ed the Django source and found t
1 - 100 of 158 matches
Mail list logo
