Re: I want a pony: Distributed RCS

[Jeff Anderson]

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 corporate
presentations that use an overhead projector anymore. They generally use
a projector driven by a computer. If it can be improved on, fine-- just
don't overdo it. I hardly think that making a switch to a modern RCS
would qualify on your over-used snarky catchphrase.



signature.asc
Description: OpenPGP digital signature

Re: I want a pony: Django Cheeseshop

[Russell Keith-Magee]

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 really is a great guy. He does a lot of great work for the
community, doesn't he :-)

If you think this document is required, why not write it? Don't wait
for permission - just write it!

Of course, if you actually sat down to write this document, you would
rapidly discover why it hasn't been written - the questions you need
to answer haven't got canonical answers yet. Are you familiar with the
Django Hotclub? This project started out to answer exactly these
questions, and they still don't have canonical answers. Pinax is an
attempt to discover best practices through empirical means, but they
don't have a complete set of answers.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Signal Connection Decorators

[zvoase]

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 method), only it's
been renamed to '_connect'. This fits with Django's way of having the
raw methods prefixed by an underscore, and the nicer, more general
methods as the name on its own.

This is only in the patch, by the way, it hasn't yet been merged :)
Don't worry, I'm not messing with stuff!

Regards,
Zack

On Sep 14, 1:51 am, zvoase <[EMAIL PROTECTED]> wrote:
> 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 as we can actually edit the "Signal" class's
> source code, adding this as a method), and it's substantially more
> beautiful and explicit. That's what I think, anyway.
>
> Plus, we don't write it as signal_connect(signal, receiver). We write
> it as signal.connect(receiver). It's more compact, explicit, beautiful
> and obvious.
>
> The thing is, can we actually change the 'connect' method, or are we
> going to give this a new name?
>
> Regards,
> Zack
>
> On Sep 14, 12:19 am, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
>
> > 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. As with most problems in
> > > programming, we just end up discussing the name :)
> > > IMHO, I think the removal of ambiguity is worth the extra 8
> > > characters. If we make a decision (by informal vote), then I'll just
> > > go ahead and implement it, and then we just need someone to commit to
> > > SVN.
>
> > Yes, so if we decide to go ahead and include decorator functionality, we
> > have two ways to go:
>
> >   [EMAIL PROTECTED]
> >    def f(...): ...
>
> > - or -
>
> >   [EMAIL PROTECTED](signal)
> >    def f(...): ...
>
> > I'm not sure which is more Pythonic or which I prefer, considering  
> > Python
> >   mixes and matches these two styles. (math.sqrt, str.encode, etc.)
>
> > Ludvig Ericson
> > [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Signal Connection Decorators

[zvoase]

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 as we can actually edit the "Signal" class's
source code, adding this as a method), and it's substantially more
beautiful and explicit. That's what I think, anyway.

Plus, we don't write it as signal_connect(signal, receiver). We write
it as signal.connect(receiver). It's more compact, explicit, beautiful
and obvious.

The thing is, can we actually change the 'connect' method, or are we
going to give this a new name?

Regards,
Zack


On Sep 14, 12:19 am, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
> 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. As with most problems in
> > programming, we just end up discussing the name :)
> > IMHO, I think the removal of ambiguity is worth the extra 8
> > characters. If we make a decision (by informal vote), then I'll just
> > go ahead and implement it, and then we just need someone to commit to
> > SVN.
>
> Yes, so if we decide to go ahead and include decorator functionality, we
> have two ways to go:
>
>   [EMAIL PROTECTED]
>    def f(...): ...
>
> - or -
>
>   [EMAIL PROTECTED](signal)
>    def f(...): ...
>
> I'm not sure which is more Pythonic or which I prefer, considering  
> Python
>   mixes and matches these two styles. (math.sqrt, str.encode, etc.)
>
> Ludvig Ericson
> [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: I want a pony: Django Cheeseshop

[Julien Phalip]

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 jQuery. They have a single repository at
google code to store pretty much every plugin [1], the good the bad
and the ugly. So, no discrimination, anyone can have their plugin
hosted there. I think the jQuery team have a deal with Google to
handle such big volumes of data, for free.

There is also a centralized interface [2] for all the community
activities related to plugin development: discussion boards, voting,
bug tracking, etc.

I think that is a very sensible and useful approach. Everything is in
one place, and it is much easier to compare plugins and find the best
ones. It both keeps the jQuery community focused and makes users' life
a lot easier.

I would argue that this system was part of jQuery's success, and I
would love to see a similar thing with Django.

> 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.  
> That doc could then be incorporated into djangoproject.com. The usual  
> community-driven caveats apply: let it be discussed, debated, etc. If  
> the major Django contributors begin using it for their own package  
> submissions, and the guidelines make sense, the community as a whole  
> will follow suit.

I agree and I like this idea. While I think packaging an app should
remain the responsibility of each app's developer, some documentation
with best practices (from a Django's perspective) would be welcome.

[1] http://code.google.com/p/jqueryjs/source/browse/#svn/trunk/plugins
[2] http://plugins.jquery.com/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: I want a pony: Django Cheeseshop

[Martin Diers]

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,
> http://code.djangoproject.com/wiki/VersionOneFeatures#INSTALLED_APPSrefactoring
> )
> c) reusable apps are immensely useful and may be one of Djangos great
> selling points once they are easy to deploy and some order is enforced
> upon the current chaos.
>

I do not believe that this has anything to do with Django 2.0 or any  
version of Django.

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?

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.  
That doc could then be incorporated into djangoproject.com. The usual  
community-driven caveats apply: let it be discussed, debated, etc. If  
the major Django contributors begin using it for their own package  
submissions, and the guidelines make sense, the community as a whole  
will follow suit.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Signal Connection Decorators

[Ludvig Ericson]

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. As with most problems in
> programming, we just end up discussing the name :)
> IMHO, I think the removal of ambiguity is worth the extra 8
> characters. If we make a decision (by informal vote), then I'll just
> go ahead and implement it, and then we just need someone to commit to
> SVN.

Yes, so if we decide to go ahead and include decorator functionality, we
have two ways to go:

   @signal.decorate
   def f(...): ...

- or -

   @signal_decorator(signal)
   def f(...): ...

I'm not sure which is more Pythonic or which I prefer, considering  
Python
  mixes and matches these two styles. (math.sqrt, str.encode, etc.)

Ludvig Ericson
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: I want a pony: Distributed RCS

[Ludvig Ericson]

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 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

[nonamanis] Polling, menurut temen2 Storage yg mudah diakses yg mana? (ZIddu, Depositfiles)?

[Tommy]

Yang mana download yg mudah tuk bro & sis semua??
Dari Ziddu or dari Depositfiles???

Regards,

Tommy Keren...



 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 <<.jpg>><<1112.gif>><>

Model examples missing in refactored doc

[Julien Phalip]

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 especially for all the new users looking for documentation on
models.

These models examples seemed to be auto-generated from the actual
model tests. Are they easy to restore in the new docs? I believe the
1.0 docs will be frozen soon so it'd be good to fix it before then.

Thanks,

Julien ;)

[1] http://docs.djangoproject.com/en/dev/topics/db/models/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Signal Connection Decorators

[James Bennett]

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.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Signal Connection Decorators

[zvoase]

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 same token,
> the signal needs to be used from both ends, and the addition of a
> __call__ method may confuse some people. As with most problems in
> programming, we just end up discussing the name :)
> IMHO, I think the removal of ambiguity is worth the extra 8
> characters. If we make a decision (by informal vote), then I'll just
> go ahead and implement it, and then we just need someone to commit to
> SVN.
>
> Regards,
> Zack
>
> On Sep 11, 10:44 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
>
> > On Sep 11, 2008, at 21:19, Justin Fagnani wrote:
>
> > > I just got a chance to look at this, and I like it, but have one
> > > suggestion. From a usage standpoint, wouldn't it be simpler to have
> > > the decorator just be the signal name, like @pre_save? I can't see any
> > > situation where you'd use a decorator for anything but connecting, so
> > > the ".connect" part just seems unnecessary.
>
> > I just sat using the dispatcher from Django in a project of mine, and  
> > was stunned at
> > __call__ not being *send*. So no, no __call__ decorator.
>
> > -- Ludvig
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: compressed fixture support

[Nicola Larosa (tekNico)]

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 big deal, either; disk space is very cheap.

Well, if fixtures are changed often, and the VCS does not employ
binary diffs, the occupied storage space may actually be greater when
compressing files.

Subversion does binary diffs, Mercurial does not. I don't know about
git and Bazaar.


> How big are your fixtures, anyway?

I have a number of files ranging up to 30MB. When storing them
uncompressed in the repo, used storage increases much less, as if
Mercurial stores them compressed anyway. However, commands are then
slowed down significantly, as if Mercurial had to decompress the files
in memory each time.

We ended up storing the fixtures in explictly compressed form, to
regain acceptable operating speed.

--
Nicola Larosa - http://www.tekNico.net/

Like any other entrenched, complex, and often closeted industry,
things in IT don't really work the way many people think they do. I'm
guessing the Vatican is a bit like that, too.
 - Robert X. Cringely, May 2008

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: compressed fixture support

[Russell Keith-Magee]

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 options for compression other than gz, and you can use shell
pipes to compress the output of dumpdata using whatever scheme you
desire.

However, loading compressed fixtures is a reasonable suggestion
(although, like Jacob, I don't have much need for them myself).

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: [TYPO3] crawler as Global ext

[Xavier Perseguers]

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 and single TYPO3 instance without to physically copy it to each of 
them. This allows to update it once for all. But the extension still is 
used and "associated" to each of your TYPO3 instance where it was installed.

HTH

-- 
Xavier Perseguers
http://xavier.perseguers.ch/en
___
TYPO3-english mailing list
TYPO3-english@lists.netfielders.de
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-english

Re: compressed fixture support

[Jacob Kaplan-Moss]

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 is very cheap.
How big are your fixtures, anyway?

> If there's pushback on this, do others keep their fixtures in source
> control?  If so, doesn't it bloat your repo?

Of course, keeping compressed fixtures in source control means you
lose the ability to intelligently diff them...

Really, though, seems like a fine feature, and one that'd be pretty
easy to add. No objections here.

Jacob

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: LDAP Backend for django.contrib.auth

[jd.strickler]

> 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
> inherit from ModelBackend-- it still uses the User model and stores it
> in the contrib.auth table. A drawback is that when a change is made in
> LDAP, it isn't reflected on the Django side of things until that user
> logs in through the website after the update has been made.
>
> There are several other Django+ldap solutions out there, and the Django
> devs usually don't want to put features in that the community can or
> does already provide. I imagine that if a solution emerges as an obvious
> choice in the Django community, that it may get put into Django. From
> what I've seen, ldap support has a low chance of getting into trunk in
> the near future, but I wouldn't be surprised if it did make it in at
> some point.
>
> Hopefully this is helpful and reflects the thinking behind the inclusion
> of this feature.
>
> Let me know if you end up using the one from #2507!
>
> Jeff Anderson
>
> [0]http://code.djangoproject.com/ticket/2507

I hadn't seen #2507 in my first two passes (searching "ldap" on
code.djangoproject.com brings up translations of authentication.txt
before #2507, so I never looked past the first page of results).

My needs are dead simple, so I'd rather just use it and move on.  The
only reason I posted something new in the first place was because I
didn't realize other people were already working on the problem.

Sorry for the unnecessary traffic!

Joe Strickler
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---