I think that seems like a good thing to be able to configure.
On Thursday, June 23, 2022 at 7:54:56 AM UTC-7 Fab wrote:
> Hey,
>
> With JsonResponse instead of the encoder defaulting to DjangoJSONEncoder I
> was thinking it would be nice to have a setting like DEFAULT_JSON_ENCODER
> so I can se
It is a common idiom to use `.filter(<...>).first()` as a
replacement for `.get(<...>)` when `None` is wanted instead of an exception
when no match is found. That works, but wouldn't the intention be more
clear if that could be written as something like
.checked(False).get(<...>)
--
You recei
doesn't hope to address that comprehensively, I do think that some
interesting options come into play when we stop authoring FilterSpecs to
chain filters() and instead return Q-like objects which are then applied by
the ModelAdmin or AdminSite.
-Steve
--
You received this message because yo
erRunner to make
https://pypi.python.org/pypi/django-juno-testrunner
It's not the best code, but it works well for us. Maybe something in this
pattern (ie, a flag to generate and consume a rerun log) might be another
way?
Steve
> So the command would always be the same for testA, t
m wrote:
>
> Yes, the proposal isn't new. Here is some related discussion:
> * https://code.djangoproject.com/ticket/21801
> * https://github.com/django/django/pull/2260
> * https://github.com/django/django/pull/4595
> * https://github.com/django/django/pull/4526
>
&g
In the `SingleObjectMixin` generic view mixin, the `get_context_data`
method checks if the object is set by using: `if self.object`
I often include this mixin just for the `get_object` functionality and
error handing it brings. I end up having to set `object = foo` or `object =
None` to suppres
niu piątek, 22 maja 2015 10:49:11 UTC+2 użytkownik Steve Jalim napisał:
>>
>> Amen to 3 and 3a - that's been proving one of the fiddliest aspects when
>> there are lots of migrations to squash - trial-end-error checking of how
>> many you can get away with squashing in
Amen to 3 and 3a - that's been proving one of the fiddliest aspects when
there are lots of migrations to squash - trial-end-error checking of how
many you can get away with squashing in one go while avoiding dependency
issues from other apps
On Thursday, May 21, 2015 at 11:08:42 AM UTC+1, Piotr
Awesome, thank you very much for the detailed answer.
-Steve
On Tue, May 19, 2015 at 4:16 PM, Shai Berger wrote:
> Hi Steve,
>
> On Wednesday 20 May 2015 01:50:15 steve byerly wrote:
> >
> > I'm also unclear what the argument against storing in the migrations
>
ch the existing schema. If Django is
>>> > auto-faking migrations that don't match the existing one that would be
>>> a
>>> > bug, but it's almost too conservative in that aspect.
>>> >
>>> > Are you manually faking these migrat
was faked vs migration 0003 in another app that was
applied.
Adding a NullBooleanField to the model would solve the issue, but I'm not
positive if this is good practice.
Thanks for the input in advance.
-Steve
--
You received this message because you are subscribed to the Google
Naive / over-obvious suggestion: if there's a genuine stalemate, bundling
the changes into a third-party app that supplants core runserver (similar
to how django-devserver does it) would avoid the need for individuals to
monkey-patch while also making it possible to release versions with more
s
e 'questionable' join above, but even
removing that entirely creates the same problem.
I'll be glad to file a ticket, if the issue is something other than my
ignorance.
-Steve
--
You received this message because you are subscribed to the Google Groups
"Django developers"
this, but if there is, I do not know it. I find
it unreasonable in all but the simplest (AKA tutorial) project. In a 50~ app
suite which 12~ projects pool, I'm really not sure how best to make certain
models is loaded before forms in every case. Could I perhaps get some
further
I totally agree that returning an object is the way to go. I know a lot of
other folks are busy getting the next release out, but after that, I am happy
to submit a proposed patch. I think it should be straightforward to preserve
the current api while still adding new functionality.
On Apr
> From: Ulrich Petri
>
> Am 16.04.2009 um 21:12 schrieb Steve Howell:
> > http://www.djangosnippets.org/snippets/1444/
> >
> > In writing this code, it occurs to me that other
> advanced users might
> > want more control over URL resolution, and it seems
But I decided to post
here, since I think a lot of what I'm interested in learning about are
the internals and dev philosophy behind the current limitation.
Cheers,
Steve
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
n to arise, and check for one
last hurrah among PseudoFields for results, and then returning them.
That's the best I got so far. Thoughts?
-Steve
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django dev
ve a better API on top that
> third-party tags can use -- as long as internal tags don't break.
>
Heretical suggestion: {: :}, {! !}, {$ $} or {[ ]} with a different
processor (falling back to the original if necessary), and therefore no
need for a fully backwards-compatible approach?
Malcolm Tredinnick wrote:
[...]
> Hopefully, MySQL will fix their bug one day. That's the way to resolve
> this.
>
Just so long as nobody holds their breath waiting ...
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www
address the
django-users list.
Thank you.
regards
Steve
Shao wrote:
> Dear ALL,
>
> I am very much interested in using a HTML to fire off a data
> processing script to run over the internet.
>
> I will be very grateful if you can advise me on passing parameters
> from an HTML form
x27;s gotta be some
> more pythonic (battery-included, there's only 1 obvious way) way of
> dealing with this.
>
>
Well, you've certainly expanded on your frustration. To say that the
required changes could be made in less than 24 hours is a breathtaking
oversimplification, how
Julian wrote:
> [...] I think some people want to use snippets like that [...]
Wouldn't you agree that's a pretty feeble use case for something as
potentially disruptive as multi-threaded serving? Particularly when the
CherryPy alternative is so readily available.
regards
St
Malcolm Tredinnick wrote:
> On Thu, 2008-11-13 at 23:47 -0500, Steve Holden wrote:
> [...]
>
>>> Maybe be you mean transparently. If so, I think this is a requirement,
>>> too, but it's not a problem. We know when the ForeignKey field is
>>> spec
ect number
> of database columns at table creation time. We have perfect information
> when we create the table, which is where this differs from any generic
> relations.
> [...]
Does that apply even to recursive (reflexive) relationships, when the
related model must be specified by
, but you could consider applying. Keep
your eye on us.pycon.org.
>
>> As far as Django's concerned I'm pretty much a
>> user not a developer, but they do have a very knowledgeable and helpful
>> community on both sides of the line.
>
> OK, Steve, consequences? I have
running. (Of course, I have some work copy)
>
>
With a positive attitude like that I *really* hope you will be at the
PyCon sprints next year! As far as Django's concerned I'm pretty much a
user not a developer, but they do have a very knowledgeable and helpful
community on both si
er than 1.0, and 1.0.1 released in the very near future with n-x
> bugs fixed is better than 1.0.1 released at some unknown future data
> with those those additional x bugs fixed.
>
Well right, that'll be 1.0.2 if it's needed. Though with 1.1 on the way
it seems less than likely.
Jacob Kaplan-Moss wrote:
> I'm with Steve::
>
> {% for %} ... {% default %} .. {% endfor %}
>
> ... seems best.
>
>
Agreement is great, but my suggestion was actually
{% for %} ... {% empty %} ... {% endfor %}
I feel this says more than "default"
king assumptions then simply isn't good for anyone involved.
>
> +1 for a default, -1 for calling it else
>
+1 to both the +1 and the -1. It *will* confuse Python programmers who
also happen to write templates, and personally I think {% empty %}
expresses the meaning much more clearly
ads
{% for sec in lNavSecs %}
{% for p in sec.pages %}
{% ifequal path p.pagpath %}
{{ p.pagdoctitle }}
{% else %}
{{ p.pagdoctitle }}
{% endifequal %}
{% endfor %}
{% endfor %}
It's usually eas
used by openid consumer, from the point of view of scaling.
>
While I can see the generic desirability of GET requests not making
database writes there are always going to be exceptions. Let's not
pursue this as a purist goal, but rather for the sound pragmatic reasons
that have already
t; and whilst we have some similar code for other backwards compatibility
> reasons, the existing cases are requirements. This one is optional, so
> I'd much rather avoid it for now.
>
+1
Trendy might be superficially appealing, but I personally felt 2.6 would
have been just as use
tside
the scope of the denormalization, and hence no need to recompute the
denormalized values.
regards
Steve
Andrew Godwin wrote:
> David Cramer wrote:
>
>> If you're not doing denormalization in your database, most likely
>> you're doing something wrong. I reall
Steve Holden wrote:
> Jacob Kaplan-Moss wrote:
>> On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>>
>>> The question is: is it worth continuing this web-scraping and analysis
>>> and potentially extending it to other reference
Jacob Kaplan-Moss wrote:
> On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>> The question is: is it worth continuing this web-scraping and analysis
>> and potentially extending it to other reference mechanisms I am unaware
>> of? I
Jacob Kaplan-Moss wrote:
> On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>> The question is: is it worth continuing this web-scraping and analysis
>> and potentially extending it to other reference mechanisms I am unaware
>> of? I
anisms I am unaware
of? I don't know whether the current redirection will eventually cause
the web search engines to throw away the old references, but it would be
nice to be able to move them forward if possible.
regards
Steve
--~--~-~--~~~---~--~~
You r
equired interpreter as a component of your application or framework.
There is no reason why your Python program and mine need have any
components in common, and increasingly less reason to enforce this
requirement to save disk space.
Having s
ks at the timestamp
> when deciding whether to recompile a PY file, so if your PYC files for
> 0.96.x were created later than the corresponding 1.0 file, Python will
> pick up the wrong file).
>
> is the installer you're referring to here "setup.py", or something e
Steve Holden wrote:
[...]
> I've just done an install of 1.0 on my Python 2.6 alpha2 distribution
> and I see, for example, that .../django/views/static.py is dated
> 12/17/2007. In this case there wasn't a previous installation, so I
> can't verify that the comp
subdirectories) did *not*
change the creation time of the .py file.
So the answer is to put another step in the build process that touches
all files before bundling them up for distribution. Obviously this is
best done outside the version control system.
regards
Steve
--~--~-~--~~---
ers have a need to change the code
(though I am not sure why they would) that too would be possible.
The only proviso to that is that the existing web APIs used by distutils
and setuptools need to be retained. If they weren't, of course, it would
kind of nullify the point of using PyPi in the
Jacob Kaplan-Moss wrote:
[...]
>
> So, again, sorry about being a dick!
>
Well at least you're a dick with a proper sense of proportion and the
ability to apologize when necessary. Thanks for setting a good example.
regards
Steve
--
Steve Holden+1 571 484 6266 +
. Very Scary. Close your eyes. Little girls
> are screaming.
>
Well, speaking as an old fart, and something of a stick-in-the-mud, I am
interested in using the best possible version control system, but even
more interested in something that's easy to use.
When you consider attract
of fragmenting the infrastructure. That's what
it's there for - supporting Python users.
regards
Steve
[PSF chairman]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
Please forgive me if this feature exists and I have overlooked it.
Does anyone else think it would be desirable and useful to allow for
overriding the default app-labels in NFA? By this I mean the headers which
the ModelAdmin's fall under.
I've got a situation where I have a 'core' project which
/sb/queensland/qut/
>
Chris:
Any project that was involved with the Google Summer of Code might well
be interested in mentoring student projects.
You might also want to ask on the django-users list (if you haven't
already), as there may be applications of Django that meet your
requirements.
Well, since I can't make the conference I hope that everyone who *does*
get there has a great time!
regards
Steve
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To pos
fault behavior for every other web framework I've used. Interaction of
any kind with the server should be taken as an indication that the
session user wants the session to remain alive.
At least it's documented, though ...
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494
Johannes Dollinger wrote:
[...]
> Of course that's subjective, everything is.
>
Really? That's a bit sweeping.
"The atomic number of hydrogen is 1" (IMHO?).
regards
Steve
Who just felt like picking this particular nit. Sorry.
--
Steve Holden+1 571 484 626
ry for each row in the outer query, which can get a little
expensive.
Then later said:
> The problem is that the filter you specified was not returning the
> correct answer in 0.96. You're asking that Django returns an incorrect
> result to make your code faster. It's possibl
ields and widgets but we cannot declare them separately.
>
>
> ## Proposal
>
> To fix this I was thinking along the lines of:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
>
Eric wrote:
> Well, you can teach someone to fish without telling them to "get an
> f'n fishing pole".
>
>
"Give a man a fish and he will eat for a day. Teach him how to fish and
for the rest of his life he will bore you with stories about the one
here, like I did myself initially.
... and why not have it say "Your post *will* be rejected as spam unless
you are registered and logged in"? At the moment it sounds like you
*might* get away with an unregistered posting.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 8
for a more capable
community in the end, and is better from a learning point of view.
Besides which, sometimes it's amusing to watch the conversations. We are
a long way from the c.l.perl flaming of newbies. People are definitely
getting the answers they need, and Magus is a prime
to lack of authentication, presumably this is
supposed to mislead spammers?
Why not begin the message with:
"Did you register an account and log in before submitting your issue?
Non-registration is the most common cause of this error. Please click
here to register an account before submitt
were disabled, so automated checks could
be limited to those?
Otherwise I'd guess you end up saying "Tough, MySQL is currently
broken/less capable". Maybe we could talk to Ted Leung about that?
regards
Steve
--~--~-~--~~~---~--~~
You received
On Jun 15, 2:08 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Sun, Jun 15, 2008 at 2:43 PM, Steve Potter <[EMAIL PROTECTED]> wrote:
>
> > I recently ran across a bug in Django and was pointed to ticket #7199
> > that described the sa
elf due to another bug. I don't know any other way of re-
producing it.
Do I open a ticket and submit a patch (for which I have no idea how to
make a test case)?
or
Do I just leave it alone as if everything else is working properly, it
may never reveal itself again?
case you would be better off leaving it unclaimed until you are
ready to work on it. Moset people look for unassigned tickets when they
have bug fixing time, to avoid repetition of work.
regards
Steve
--~--~-~--~~~---~--~~
You received this message because you
I missing?
>
Well, the first thing you are missing is that the django-dev list is to
discuss development *of* Django rather than development *with* Django.
You want django-users, just down the corridor :-)
regards
Steve
--
Steve Holden+
Rahein:
Please also note that you are supposed to adjust your path so svn is
runnable from anywhere, not run svn in its bin subdirectory. Google for
"set path" followed by your operating system name if you don't know how
to do this.
regards
Steve
Dan Watson wrote:
> Q
Hi, we're just getting started using Django unit tests, and it looks
like the documentation says you can only have unit tests in two files:
models.py and tests.py. We would prefer to put our unit tests in many
different files, with, say, each main-line .py file having a
corresponding unit-test fi
In fact this question would be better addressed to a more general list,
such as the comp.lang.python newsgroup (also available as
[EMAIL PROTECTED]). See
http://mail.python.org/mailman/listinfo/python-list
for further information.
regards
Steve
[EMAIL PROTECTED] wrote:
> dja
Don Spaulding II wrote:
>
>
> Collin Grady wrote:
>> Steve Holden said the following:
>>
>>> If you want considered opinions you would do well to wait longer than 51
>>> minutes!
>>>
>>
>> You should check the date as well a
Jean-François wrote:
> Any comment, especially on the transaction model?
If you want considered opinions you would do well to wait longer than 51
minutes!
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.
ing code has to change initially. If you want to support the
> must insert vs. must update difference, you can add a parameter (or two,
> depending on which approach we take) and it's still backwards
> compatible.
>
How do these parameters get set for the above "
yway simply call a modified save with
alternative values of the flag (whose names are a little smelly, by the
way) is reasonable, I suppose.
But it does seem to me that create() and update() are more explicit than
save(must_create=True) and/or save(must_update=True). The separate
method solu
Kenneth Gonsalves wrote:
> On 20-Apr-08, at 12:47 AM, Steve Holden wrote:
>
>>> I wouldn't even call the current svn head a beta-quality product
>>>
>>>
>> Which is probably why it isn't yet a beta release?
>>
>
> what
So would you prefer to have a beta-quality product whose developers
>> lie and call it 1.0?
>>
>
> I wouldn't even call the current svn head a beta-quality product
>
>
Which is probably why it isn't yet a beta release?
regards
Steve
--
Steve Holden
t;> consistent format, and one which is easy to turn into a human-readable
>> string like "Django 3.2", "Django 1.4-beta3" or "Django
>> 2.18-svn28183".
>>
>> The only question is whether it meets (1). Thoug
Without wishing to turn this int
Trying to get admin on my system to load values based on related
tables on db. I have set the FK on the papers table to tie with the
PK of each look-up table and set models like so:
class LuPaperContentEra(models.Model):
paper_content_era = models.CharField(blank=True, maxlength=150)
de
Sorry I am new to this - what do you mean?
Steve Brumwell
Sales Director
www.iperium-consulting.com
(P) +44(0)1564 793701
(M) +44(0)7810 801130
(F) +44(0)1564 795916
Skype id : steve.brumwell
with an
attractive salary.
Steve Brumwell
Sales Director
www.iperium-consulting.com
(P) +44(0)1564 793701
(M) +44(0)7810 801130
(F) +44(0)1564 795916
Skype id : steve.brumwell
__
<http://www.iperium-consulting.
On Jul 5, 12:48 pm, anna <[EMAIL PROTECTED]> wrote:
> Just in case anyone knows, is it the same with the other frameworks
> for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on
> your answers here, but just wondering.
>
As someone coming to Django from TurboGears, I can say tha
lose the damned laptop
>>> and go to bed...); please feel free to poke me again if I forget!
>>> Jacob
Steve
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group
to know Python to create templates in Django.
> But they would if they want to manipulate forms or form error feedback.
> This should be consistent.
I think this point also has significant merit.
Steve
[1] http://en.wikipedia.org/wiki/Single_responsibility_principle
--~--~-~--~~-
sily collaborate.
http://groups-beta.google.com/group/django-users/browse_thread/thread/bd1417a08e37774a/67af32e775dae595
Steve
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&quo
nches/schema-evolution
Thanks,
Steve
--~--~-~--~~~---~--~~
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 t
Hi, guys.
This is a problem that troubled me for months, but maybe it is very
easy to you.
I guess it is an problem that has something relation with mod-python or
cookie, but I am not sure. Since many corresponding softwares I use,
between our production and develope server, are the same except
L
81 matches
Mail list logo
