Hi Alex,
On 04/18/2011 02:44 AM, robim42 wrote:
> thank you for your answer. I also thought that owner_partner should
> work ... but when you try you get this:
Sorry, not owner__partner - since partner is only a field on Buyer, not
on Base, you'd need owner__buyer__partner.
In any case, I don't
Hi Ivan,
On 04/17/2011 10:38 PM, Ivan Sagalaev wrote:
> On 04/15/2011 02:20 AM, akaariai wrote:
>> I have been using setup_environ in my projects, and the lazy
>> initialization in can cause some weird problems, for example if you do
>> manual timing using:
>> start = datetime.now()
>> access sett
Hi Viktor,
On 04/18/2011 09:14 AM, Viktor Kojouharov wrote:
> I think I might have stumbled upon a small bug. According to its docs,
> the 'verbose_name_raw' property is supposed to return an untranslated
> version of the 'verbose_name' property. However, if LANGUAGE_CODE is
> set, then 'verbose_n
Hi all,
Our documentation on "automatic managers" [1] and related managers [2]
is quite clear that automatically-created managers for related-objects
access will be plain-vanilla Manager instances, unless you set
"use_for_related_fields = True" on the custom Manager subclass that you
use as a defa
On 04/15/2011 04:20 AM, akaariai wrote:
> I have been using setup_environ in my projects, and the lazy
> initialization in can cause some weird problems, for example if you do
> manual timing using:
> start = datetime.now()
> access settings
> print 'Used %s' % (datetime.now() - start)
>
> You mig
Hi Alex,
On 04/15/2011 07:51 AM, robim42 wrote:
> --- models.py code --- snip ---
> from django.db import models
>
> class Base(models.Model):
> name = models.CharField(max_length=20)
>
> def __unicode__(self):
> return self.name
>
> class Seller(Base):
> childa = models.Cha
Hi Michal,
On 04/01/2011 09:22 PM, Michal Petrucha wrote:
> I propose to implement a CompositeField with the following properties:
>
> - will be represented as a namedtuple containing the values of the
> actual fields it encapsulates
>
> - will support retrieval and assignment (assignment sets
Hi Mikhail,
On 04/01/2011 05:09 PM, Mikhail Korobov wrote:
> Hi Carl and Gregor,
>
> On 2 апр, 01:17, Carl Meyer wrote:
>>
>>> 3. The designers I worked with are often interested on adding custom css
>>> class
>>>or an attribute to a form fie
Hi Gregor,
As you've probably seen in past threads, this is an area where I'm quite
motivated to see some improvement. I think you've got quite a strong
proposal here in general, and you've clearly done your homework, so my
comments below dive directly into the details:
On 04/01/2011 11:57 AM, Gr
On 03/30/2011 07:43 PM, Russell Keith-Magee wrote:
> ... and this is the exact model that has been proposed, and rejected
> in #3011 (albeit with a more complex dance around default values). It
I just re-read #3011, and it is far from clear from reading through the
ticket that that approach was
On 03/29/2011 02:46 PM, Shawn Milochik wrote:
> I'm not proposing a change to Django itself or suggesting that this
> should be a standard practice. I do think that this is a fairly clean
> solution for an individual to use to solve this problem if they have
> it.
>
> They can create a custom ma
Hi Shawn,
On 03/29/2011 01:28 PM, Shawn Milochik wrote:
> Hopefully someone on the core dev team can let me know if this is
> possible in Django. If so, it will solve this problem.
> I am not familiar with custom metaclass stuff done within models.Model.
>
> 1. Create a custom metaclass as descri
On 03/29/2011 12:40 PM, Jeremy Dunck wrote:
> What about keeping abstract inheritance in this case, but allowing
> Document.objects.* to work by returning instances of the subclasses.
> Filtering, etc. would only work based on the Document base class.
>
> It would mean doing some unions, but would
Hi Jordan,
On 03/29/2011 11:40 AM, Jordan MacDonald wrote:
> I have three models, structured like so:
>
> Document
> -Presentation
> -Spreadsheet
>
> Document is never instantiated on its own; a prime candidate for an
> abstract base class. However, there are times where I want to list/
> search
I think it would be helpful here to clearly distinguish three distinct
varieties of "using HTML5," two of which are clear wins and one which I
don't see any reason to do:
1. Switching to the HTML5 doctype in those few places where Django
actually renders a full page with doctype (the admin, databr
Hi Alex,
On 03/29/2011 01:36 AM, Alex Kamedov wrote:
> I think, cron jobs is an overhead in many simple cases where old
> behaviour was useful and more simpler.
> Why you don't want include DeletingFileField[1] in django?
>
> [1] https://gist.github.com/889692
Because, as mentioned above, it is
Hi Luke,
On 03/28/2011 12:38 PM, Luke Plant wrote:
> Overall, I think the advantages outweigh the disadvantages, that we have
> to make the move sometime, and now is about the right time, or perhaps
> slightly late.
100% agreed, for all the reasons you outlined. We've been using the
HTML5 doctype
On 03/28/2011 02:33 AM, Russell Keith-Magee wrote:
> As with the other thread on Trac changes -- I agree this is worth
> doing, but would like to hear some other core dev voices before making
> any changes.
These changes look to me like a gain in sanity on every front. +1
Carl
--
You received
On 03/27/2011 06:42 AM, -RAX- wrote:
> I am referring to this:
> http://docs.djangoproject.com/en/dev/releases/1.3/#filefield-no-longer-deletes-files
> Instead of preventing the data loss from happening a very usefull
> feature has been removed.
Well, it does also prevent the data loss from happe
On Mar 16, 12:11 am, Tai Lee wrote:
> Assuming that any authenticated user might be an attacker who has
> brute forced a password and presenting obscure error messages to
> authenticated users is not helping anybody.
I agree with this, and with the many people in this thread who have
come to the
Hi Bruno,
On 03/23/2011 08:56 AM, Bruno Renié wrote:
> I'm not sure, however, how django's backwards-compatibility applies in
> this case. The widgets API has never been publicly documented but the
> official documentation encourages people to look at the code and
> create their own widgets based
On 03/22/2011 07:05 PM, Ian Kelly wrote:
> On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
> wrote:
>> Why not just do an import for your custom settings?
>>
>> try:
>>from site_settings import *
>> except ImportError:
>>pass
>
> No particularly compelling reason that I know of,
On 03/21/2011 09:14 AM, daonb wrote:
> On Mar 20, 4:49 am, Carl Meyer wrote:
>> Those last five characters in "get_context_data" actually serve quite a
>> useful purpose, IMO. They clarify that the return value is just the data
>> that will go into building a contex
Hi Benny,
On 03/19/2011 05:41 PM, daonb wrote:
> Migration to the beta was quite smooth except for two names that broke
> my code: `pk` & `get_context_data`. The first comes from `models` and
> is now used instead of `object_id` in urls and views. It also broke
> compatibility with django-backlink
On 03/18/2011 08:09 AM, Alexander Schepanovski wrote:
> I think using subclass of User model for your fields has the same
> flexibility as separate profile model (since you can have only one).
You can have multiple subclasses of the User model (not that I recommend
subclassing).
> contrib.auth
On 03/17/2011 05:36 AM, Tom Evans wrote:
> I strongly disagree here. Django shouldn't be doing magic with my
> PYTHONPATH, if I want stuff in my PYTHONPATH, I'll darn well put it
> there.
Hear, hear! I'm only a weak +0 on the entire idea of documenting a
"standard" project layout, as I think it'
Hi Marco,
On 03/17/2011 10:44 AM, Marco Louro wrote:
> I don't really know how to approach this issue the best way, so I'm
> just going to be direct, I'd love to see Django provide support for
> django.core.urlresolvers.reverse (at least) on the client (in
> JavaScript).
I think this is really in
On Mar 16, 11:43 am, Christophe Pettus wrote:
> On Mar 16, 2011, at 2:24 AM, Johannes Dollinger wrote:
>
> > I would be nice if support for composite primary keys would be implemented
> > as a special case of general composite fields.
>
> It's appealing, but the reality is that no existing back-e
Hi Alexander,
On 03/15/2011 03:30 AM, Alexander Schepanovski wrote:
> It would be nice to have a QuerySet subclass based on namedtuple().
> namedtuples takes less memory than dicts (from ValuesQuerySet), much
> more convenient and induce more readable code than tuples
> (ValuesListQuerySet).
>
>
Hi Bruno,
On 03/14/2011 06:33 PM, Bruno Renié wrote:
> Although Django 1.3 is not released yet I'd like to take advantage of
> the pycon sprints to discuss a proposal for 1.4: render form widgets
> using Django templates instead of python code.
>
> This approach is implemented in django-floppyfor
Hi Alex,
On 03/14/2011 08:49 PM, Alexander Schepanovski wrote:
> Personally, I would like all querysets mutate not clone by default.
> And when one need a clone just make it explicitly.
This is not an option. It will break quite a lot of existing code, and
often in highly confusing ways. You'll n
Hi Simon,
On Mar 4, 3:27 am, Simon Meers wrote:
> +1 for better polymorphic support in Django core; it is a very common
> problem which could do with an efficient and elegant solution.
> Regarding efficiency, if you can keep track of your subclasses
> effectively (potentially using a registry if
Hi Craig,
On Mar 4, 1:03 am, Craig de Stigter wrote:
> It looks like django_polymorphic does what I want. I'm not yet sure why it
> says it takes one query per type of model in a queryset. Unless it is
> talking about multi-table inheritance, in which each type would require a
> different join. B
On Mar 4, 5:55 am, Rahul wrote:
> When i ran test cases of multiple_databases model of regressiontests
> then "test_generic_key_deletion" test case gave Error at the point
> where it was trying to create Review object using "other" db,
> but when i ran "test_generic_key_deletion" test case only
Hi Rahul,
On Feb 21, 12:56 am, Rahul wrote:
> When i ran the test cases ( "modeltests/delete/
> test_inheritance_cascade_up" ) which were doing cascade up for
> inherited models, it failed for DB2 cause of the fact that DB2 doesn't
> support initial deferred constraint checks like behavior, hence
Hi Russell et al,
I don't agree with the wontfix resolution of #15330. I think the OP
there is right - we should be consistent in providing release notes
for all releases, even if they would be as short as "No significant
changes" (and I don't actually think that's true even for 1.2.1 or
1.2.3 --
Hi Hidde-Jan,
On Feb 18, 10:20 am, Hidde-Jan Jongsma wrote:
> Lately, I've been working a lot with Django's modelformsets in
> combination with javascript. The BaseFormSet implements a handy method
> _get_empty_form, accessible through the empty_form property. This
> method checks whether formset
Hi Paul,
On Feb 14, 1:37 am, poswald wrote:
> * Django ships with SHA2-256, SHA2-512 or PBKDF2 by default. SHA2 is
> python 2.5 compatible (due to hashlib being added in python 2.5) and
> PBKDF2 is short enough that it could be included into the project.
> This satisfies NIST/US Gov requirements.
Hi Mike,
On Feb 3, 4:36 pm, Mike Lindsey wrote:
> I'm doing something with bidirectional ManyToManyFields, in a project
> I'm working on, that is resulting in duplicate attempts to create the
> intermediate tables. I'm perfectly open to suggestions of "You're
> doing it wrong" if they come with
On Feb 4, 3:41 am, Rahul wrote:
> When i set this flag in DatabaseFeatures then for full test suit also
> both test cases of "contenttypes" app works fine.
>
> But i am not able to figure out why this test case was failing when we
> were not sets supports_transaction flag.
It may be worth invest
Only reason I didn't add it to the import is that it's not used in any
of the commented sample lines. But the better solution is to import it
and demonstrate using it.
Done in http://code.djangoproject.com/changeset/15415
Thanks for the suggestion.
Carl
--
You received this message because you
Hi Vivek,
On Feb 3, 1:03 am, Vivek Narayanan wrote:
> I am new to the Django community and I would like to implement a patch
> for the ticket #8809 - "Better error message when can't import url
> callback".
Welcome, and thanks for contributing!
> I was looking into the _get_callback function of
Hi Rahul,
On Feb 2, 4:03 am, Rahul wrote:
> When i run the entire inbuilt test suit of django, first test case it
> hits is of contenttypes app of contrib apps and first test
> case(intest_lookup_cache) works fine. But when it hits the 2nd test
> case (test_shortcut_view) it first flushes out al
On Jan 31, 1:49 am, Xavier Ordoquy wrote:
> The thread is pretty long because there are also 2 threads in one:
> - one for simply changing the site_id per request
> - one for changing the all setting per request
Exactly!
For the record, as far as I'm concerned #15089 is limited in scope to
the
On Jan 24, 3:51 am, Rahul wrote:
> Can you let me know how i can specify that this test case should not
> be run, when i run the inbuilt unit test-cases. Currently i just run
> them like this 'python runtests.py --setting=settings'
You should not avoid running test_do_nothing. It is written such
This seems right to me. Does anyone with more history on BooleanField
know of any reason why the "wontfix" resolution on #2855 was incorrect
and the current default-to-False behavior is correct?
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers
Hi Gabriel,
On Jan 19, 5:55 pm, Gabriel Hurley wrote:
> > In my mind, the introduction of a multitenancy hook (in the 1.4
> > timeframe) could then look something like this:
>
> Also agreed on the 1.4 timeframe. While there is a valid concern for making
> sure that get_current_site() (introduced
Thanks legutierr for all your work on this ticket and patch, and
everyone for the comments. I just took some time to review the patch
on #15089 and had a long conversation on IRC with legutierr, and
here's what I'm thinking:
It does appear that there is some code (CurrentSiteManager, for
instance)
On Dec 17, 9:21 am, Carl Meyer wrote:
> Instance._state.adding is new in 1.2 (in 1.2 it was instance._adding
> and only ever monkeypatched onto a model instance by ModelForm; I
> changed it to instance._state.adding and encapsulated it inside the
> ORM just a few weeks ago in r14612
Hi Luke,
On Dec 16, 9:47 am, Luke Plant wrote:
> For the latter, I think we should use instance._state.adding to reliably
> detect whether a PK has been set or not. This could cause some
[snip]
> While I was there, I fixed _get_next_or_previous_by_FIELD to use
> self._state.adding, rather than
Hi,
On Dec 12, 4:40 pm, Pakal wrote:
> Why, then, isn't it specified that all models.py files should be
> loaded by each starting worker ? That would solve the whole problem
> and hidden errors around startup code like signals and startup checks.
This is a real issue for me as well; not necessar
Hi all,
I've recently been exploring simple multitenancy options in Django
using contrib.sites, and have some thoughts on how core could make it
easier.
First, let me make a quick distinction between static and dynamic
multitenancy. In the static case, you have a limited set of sites
running on t
Hi all,
The special-cased handling of contrib.admin static assets in Django
core is a long-time wart. Fortunately, the new static assets standard
introduced by contrib.staticfiles and the STATIC_URL and STATIC_ROOT
settings finally allows us to begin a migration path to remove this
wart. AdminMedi
On Nov 17, 9:16 am, Tai Lee wrote:
> I believe that only the reporter, owner, and CCs are notified when an
> update is made, not anyone who added a comment.
I am quite sure this hasn't been my experience. I often receive email
notifications from Trac about changes to tickets that I have commented
This is committed as r14507: http://code.djangoproject.com/changeset/14507
Carl
--
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 e
Last call for any concerns with the patch; planning to land it in the
next 24 hours.
Carl
--
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
Hi Peter,
On Nov 7, 9:41 pm, Peter Herndon wrote:
> I just ran into a minor issue and thought I'd bring it to light. In adding
> django.contrib.comments to a site I'm building, I found that when using
> moderation and setting email_notification to True, that there is no default
> template for
On Nov 5, 6:51 pm, Gabriel Hurley wrote:
> 1. Add the versionadded directive to "docs/topics/db/queries.txt", and
> "docs/ref/contrib/contenttypes.txt". For reference, you can make it
> very clear what was changed/added by using the following syntax (note
> the *single* line break between the ve
On Nov 5, 11:17 am, Russell Keith-Magee
wrote:
> Giving credit where it's due, I think Michael Glassford also deserves
> a shoutout here. He was the original driving force behind this ticket,
> as was actively involved during the 1.2 development cycle.
Indeed! My mistake. I'd made a mental note a
Hi all,
The patch for #7539 [1] (support for on_delete behaviors other than
cascading deletes) has reached a state where I consider it a candidate
for committing; I invite review and comments. The current patch is
available as a github branch; the compare view [2] presents it nicely
as a diff with
Hi Tom,
On Nov 2, 12:58 pm, "Tom X. Tobin" wrote:
> Do the Git-using core developers have a preference for merge vs.
> rebase for updating an upstream-tracking branch? I prefer to rebase
> to keep the changes in question at the branch HEAD, especially if the
> branch hasn't been pushed publicly
On Oct 29, 2:04 pm, Ivan Sagalaev wrote:
> Aha, I see the point now. On a second thought I think we can avoid this
> problem altogether by not passing actual response object into
> middleware. Instead we could pass just those bits that a middleware
> should care about: a template name and a contex
Hi Waldemar,
On Oct 29, 3:05 am, Waldemar Kornewald wrote:
> Just to clarify: We are in fact talking about two questions here:
> 1. Do we need a standard for URL handling?
>
> This is the most important question and my answer is "yes" (I'll
> explain this in the rest of this mail).
I don't think
On Oct 28, 9:45 pm, SmileyChris wrote:
> My suggestion is that StaticFilesHandler only does its magic if
> 'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that
> sound acceptable?
That seems like a very reasonable opt-in approach that solves the
backwards-compatibility problem. +1
Hi Waldemar,
Thanks for putting so much thought into this issue, and outlining
these options in detail. However, I am not convinced that this
something Django core should be concerned with. I think we need to
maintain a clearer conceptual separation between the various layers of
functionality here
Hi Waldemar,
On Oct 20, 4:04 pm, Waldemar Kornewald wrote:
> In what way does staticfiles make writing reusable apps easier? It
> merely collects apps' "static" folders. The same thing could be
> achieved by defining a simple standard:
> "Put media files in the 'media' folder."
> and then making
Hi Waldemar,
On Oct 20, 1:40 pm, Waldemar Kornewald wrote:
[snip]
> However, what staticfiles does has almost nothing to do with "bigger
> project" asset management. Just look at the features grid on
> djangopackages (disclaimer: I'm the author of django-mediagenerator
> and I maintain that grid)
On Oct 2, 4:34 am, Russell Keith-Magee
wrote:
> I can't argue with the fact that setting variables in __init__() is a
> common idiom in Python generally, and this is certainly a weakness of
> copy on call that will fail in non-thread safe ways.
>
> My counterclaim is that the move to class-based
On Oct 1, 10:00 pm, Russell Keith-Magee
wrote:
> Now, I'm sure the counterargument is going to be that copy() will be
> just as error prone and FAQ inducing. My argument to this is:
Yes.
> * when it fails, it will fail during development, not just in production
>
> * the cases where it wil
On Sep 25, 1:50 pm, Alex Gaynor wrote:
> ISTM this would solve the "auth.User" issue, but doesn't help reusable
> apps at large: one can trivially imagine a project that wants voting
> (or tagging ;), or commenting, or ...) on more than one model.
Of course! This isn't a silver bullet for every s
Hi all,
I've seen some level of interest in the idea of a lazy foreign key
(one whose target table is determined by project configuration in some
way, not hardcoded by the app/model in which it lives). The idea was
most recently brought up again in Eric Florenzano's keynote at
DjangoCon. I have so
Hi Jim,
On Sep 19, 1:19 am, "Jim D." wrote:
> I found some time this evening to work this out, and have included a
> revised patch for this proposal at the end of this message.
Thanks for your work on this! The usual Django workflow doesn't
include patches to the mailing list: rather you can go
On Sep 11, 2:25 pm, Dana Spiegel wrote:
> When will the releases be available as tags in subversion?
> Specifically, both 1.2.2 and 1.2.3 have not been tagged in
> thehttp://code.djangoproject.com/svn/django/tags/releases/SVN directory.
I believe this has now been corrected.
Carl
--
You recei
On Jul 26, 10:02 am, Tobias McNulty wrote:
> If such reusable code needs to cache things forever, which sounds perfectly
> reasonable to me, I'd still rather not co-opt "0" to mean "forever" in all
> cases. Each backend that supports caching with no timeout could easily
> offer a class attribut
On Jul 23, 12:45 pm, Jacob Kaplan-Moss wrote:
> On Fri, Jul 23, 2010 at 8:17 AM, Tobias McNulty
> wrote:
> > The only concern in that ticket seems to be that 0 means different things
> > for different cache backends.
> > There may have been some effort towards making them all behave the same w
On Jul 14, 4:15 pm, SmileyChris wrote:
> We also need d) Media hooks for a single widget - whether this can be
> done in only the template layer is a tricky problem...
>
> I'm still struggling with how you'd be able to render all the media at
> the top of your template for the form. I guess you'd
Hi Tai,
On Jul 13, 8:42 pm, Tai Lee wrote:
> I wouldn't like to see widget libraries being packaged up with
> templates including conditional templates based on doctype. This seems
> messy, not friendly to override in your own templates, and effectively
> combining what should be multiple separat
Hi Russ,
On Jul 13, 12:11 pm, Russell Keith-Magee
wrote:
> I have exactly 0 mad skillz as a front end guy, but I know that rich,
> pretty ajax widgets et al are necessary for a good user experience. My
> goal, as a backend guy with limited frontend skills, was to find a way
> to get the people wh
Hi Russ,
First of all, thanks very much for this proposal! Form rendering has
been a major pain point for us (thus the existence of
django-form-utils), and improving it is tops on my 1.3 wishlist. I
will also be at DjangoCon and eager to sprint in this area.
Django has a really good template syst
Hi Russ,
On Jul 10, 8:24 am, Russell Keith-Magee
wrote:
> On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer wrote:
> > Wouldn't it be most sensible to treat the URL mount point similarly to
> > hostname, since they are really just two pieces of the same data: the
> >
On Jul 7, 7:11 pm, Graham Dumpleton
wrote:
[snip]
> web application, to be a well behaved WSGI citizen, should honour
> SCRIPT_NAME setting as supplied by the server, and ensure that ways
> are provided such that everything in the users code, including
> configuration, urls or settings files, can
On Jun 3, 5:48 pm, "petr.marhoun" wrote:
> - It seems that it is not possible to say if form has fieldsets
> (fieldsets method even construct fieldsets if meta attribute is not
> set) - I think it is useful to know it in templates.
I spoke too quickly here: this is a relevant API question. In for
Hi Petr,
On Jun 3, 5:48 pm, "petr.marhoun" wrote:
> I have some notes to forms-utils:
> - The code says: "if legend is None: legend = name". I dislike it - I
> want to have possibility not to set legend. I think that if legend is
> not set it should be "None" in fieldset.
Yes, this is one of the
On Jun 3, 8:57 am, Russell Keith-Magee
wrote:
> 5. Parameters "template" and "attrs" for forms, formsets, fieldsets,
> forms, (bound) fields and widgets
> 6. Support for (X)HTML5 and legacy HTML
>
> I strongly suspect that these two may be covered by something I
> discussed with Jacob at DjangoCon
Hey Petr,
On Jun 3, 11:32 am, "petr.marhoun" wrote:
> OK, more details: If fieldsets would be defined, fields would be
> concatenation of fields from individual fieldsets. So methods
> as_table, as_ul and as_li and "for field in form" would work as now.
> But if you want to really use fieldsets,
On Jun 2, 6:20 pm, Ben Firshman wrote:
> Yeah, this idea came up at the sprints, but it's a little too magic for my
> tastes.
I dunno... is __new__ really more magic than having a __call__ method
that magically copies the instance you call it on? That certainly
breaks my expectations.
Django do
Hi Ryan,
Moving discussion here off the Trac ticket.
On Apr 25, 5:44 pm, Ryan wrote:
> A decent workaround is for my post_delete hook to pass
> force_update=True and catch DatabaseError when saving the article, in
> case it has already been deleted. But I think it would be nice if
> django just
On Apr 17, 2:58 am, Paul McMillan wrote:
> For the particular test case in modeltests/fixtures/models.py, we
> might be able to improve test time by tearing the fixtures down after
> verifying them, rather than doing a full flush. This will be easier to
> do after converting from a doctest to a un
On Mar 1, 9:40 am, stuff4ash wrote:
> I am not necesary advocating magic. But the need for a more robust (or
> lets say, any) configuration management exists for many.
"Configuration management" is a fuzzy phrase that can mean many things
to many people. I think it'd be more helpful to focus on s
On Feb 27, 1:53 pm, stuff4ash wrote:
> b) easy way to register, override, configurations for apps.
> a settings.py in an app folder that is "magically" loaded the same way
> other things are would suffice, but there has to be a way to:
I've never understood the desire for more magical behavior
On Jan 26, 7:24 pm, Russell Keith-Magee
wrote:
> I'll put it on my list. It will probably still be a 'post 1.2-beta'
> activity, but I'll try to look at it at the start of the bugfixing
> phase.
Great, thanks. Looking forward your feedback.
Carl
--
You received this message because you are sub
Hey all,
During the Chicago sprint a few weeks ago I put together a patch for
#6191: the admin's "the following related objects will be deleted"
list in some cases omits items that actually are deleted (oops!). The
admin has its own routine for collecting related objects for
notification, separate
Anyone have thoughts on this? It would be really nice to get this
fixed so admin.py errors don't break the runserver, and I think the
updated patch on #11957 accomplishes this without any breakage.
Carl
On Sep 28, 4:56 pm, Carl Meyer wrote:
> Today I filed #11957 [1], and becau
Hi all,
Today I filed #11957 [1], and because it is questioning an earlier
bugfix, I was asked to bring up the issue for discussion here.
Under the dev server, if an error occurs while importing an app's
admin.py, the error will show up on the first request, and then
disappear. On all subsequent
On Sep 18, 6:48 pm, Alex Gaynor wrote:
> If you press the original format button you will see that the patch is
> still there, trac just can't display all diffs (it's a very special
> piece of software).
Specifically, if you're obsessive about avoiding minor breakages, you
can try to avoid the "
On Aug 23, 9:14 pm, Andrea Zilio wrote:
> So the answer to the question "Can I get the right instances with one
> single and only DB query" seems to be:
> "No, you cannot do so without touching the Django orm code".
>
> Am I right?
Actually, I think the ORM's extensibility mechanisms are suffi
Hi Chris,
On Apr 24, 7:47 pm, ccahoon wrote:
> Tickets #6527, #7581, and #2504 deal with issues in HttpResponse. They
> all have code but decisions need to be made about how to keep
> middleware from interfering with or breaking HttpResponses in certain
> instances, and about sending out content
On Apr 11, 1:15 pm, Marc Fargas wrote:
> That's a but in TRAC's svn-commit-hook script, there's a ticket about it in
> TRAC's TRAC with workarounds and so onhttp://trac.edgewall.org/ticket/3508.
Thanks. Actually reading through that ticket, it appears there is no
bug in recent versions of Trac
Is it possible to set up the svn commit hook that marks a Trac issue
fixed so it also emails the CC list for that issue? Since "being
fixed" is a fairly significant event in the life of an issue (relative
to, say, random comments or status changes which Trac emails out), it
seems like this would
On Jan 6, 11:20 am, "Jacob Kaplan-Moss"
wrote:
> I'd like to see this moved into an external app so that we can
> de-couple it from the 1.1 release. If it proves to be popular and
> stable, we could then consider it for 1.2.
I extracted 4604 into an external app[1] some months ago. It's quite
s
601 - 700 of 705 matches
Mail list logo
