Ludvig Ericson wrote:
> On Sep 11, 2008, at 00:15, Jeff Anderson wrote.
>
> Honestly, not that my opinion matters in any way, but:
> Don't fix it if it ain't broken.
>
Improving on something doesn't always fall under this saying. While it
gives good advice in many cases, you don't see many
On Sun, Sep 14, 2008 at 6:35 AM, Martin Diers <[EMAIL PROTECTED]> wrote:
>
> The answer is community packaging guidelines. Somebody needs to write
> or adapt an existing doc on how to package django apps using existing
> Python tools (which are excellent already), how to name them, etc.
Somebody
Oh, yeah, by the way, for those who haven't looked at the ticket, my
implementation changes the 'connect' method, so that it can be used in
the old way ("signal.connect(receiver)"), or as a decorator
("@signal.connect" with "def receiver").
The old 'connect' method is still used (by the new
I think the "signal.decorate" form is nicer, but the name has to show
that there is some sort of connection going on; if you want to know
why I think this is, take a look at "The Zen of Python". Basically,
it's explicit (you know it refers to *that* signal), it's the obvious
way to do it (seeing
On Sep 14, 8:35 am, Martin Diers <[EMAIL PROTECTED]> wrote:
> The answer to the current package chaos is not a centralized
> repository. I do not like that idea one bit. It's too storm-
> trooperish. Who is going to decide whether a package is repository-
> worthy?
I would take the example of
On Sep 10, 2008, at 9:31 AM, mrts wrote:
>
> This is for Django 2.0.
>
> Rationale:
>
> a) useful (and less-useful) Django apps are proliferating on Google
> Code, djangoplugables.com and Django resources wiki page,
> b) apps need refactoring (#3591,
>
On Sep 12, 2008, at 13:01, zvoase wrote:
> I think the principle of least surprise applies here. It would be very
> easy just to implement __call__ as a decorator, but by the same token,
> the signal needs to be used from both ends, and the addition of a
> __call__ method may confuse some people.
On Sep 11, 2008, at 00:15, Jeff Anderson wrote.
Honestly, not that my opinion matters in any way, but:
Don't fix it if it ain't broken.
Good day to you
Ludvig "lericson" Ericson
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are
Yang mana download yg mudah tuk bro & sis semua??
Dari Ziddu or dari Depositfiles???
Regards,
Tommy Keren...
Hi,
First, apologies if this is already being looked after.
Since the refactoring of the docs and the old docs being shut down,
the model examples have gone. Also, some links are now outdated (4
occurrences in [1]).
I just see it's been reported again in #9007, and I think this will be
a trap
On Sat, Sep 13, 2008 at 8:10 AM, zvoase <[EMAIL PROTECTED]> wrote:
> Couldn't we move this discussion to the ticket on Django's Trac?
Preferably not; it's far easier to keep track of a threaded discussion
here on the mailing list, as opposed to trying to follow it in the
ticket.
--
Couldn't we move this discussion to the ticket on Django's Trac?
http://code.djangoproject.com/ticket/9015
On Sep 12, 1:01 pm, zvoase <[EMAIL PROTECTED]> wrote:
> I think the principle of least surprise applies here. It would be very
> easy just to implement __call__ as a decorator, but by the
I have a use case for compressed fixtures too.
> Jeremy Dunck wrote:
>> I'd like to add support for fixture load/dump to deal with compressed
>> (gzip) files transparently.
Jacob Kaplan-Moss wrote:
> I don't see a good reason *not* to do this, but I also don't see the
> space requirements as a
On Sat, Sep 13, 2008 at 1:35 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> I'd like to add support for fixture load/dump to deal with compressed
> (gzip) files transparently.
Something like #4924, perhaps? :-)
I'm not completely sold on the --compress option to dumpdata - there
are many
Hi,
> I think first before trying.
> what about DB connections?
> how a global ext works with multiple instances of typo3 that use different
> DBs?
A global extension will act as a local extension. This means that it is
context-aware. The only difference is that it can be "installed" for
each
On Sat, Sep 13, 2008 at 6:35 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I'd like to add support for fixture load/dump to deal with compressed
> (gzip) files transparently.
I don't see a good reason *not* to do this, but I also don't see the
space requirements as a big deal, either; disk space
> I know this probably isn't exactly what you are proposing, but have you
> looked at the LDAPBackend in ticket #2507[0]? We use it in production,
> and it works marvelously. After skimming your design spec, it seems like
> the one in ticket #2507 would fit your bill just fine. #2507 doesn't
>
17 matches
Mail list logo
