When I began to create several tables of data for the globalization I
wanted to use a license of CC because GPL or BSD are more specific of
software. I repeat, a license for data.
http://satchmo.python-hosting.com/browser/trunk/satchmo/G11n/data/
http://creativecommons.org/licenses/by-sa/2.5/
Af
When I began to create several tables of data for the globalization I
wanted to use a license of CC because GPL or BSD are more specific of
software. I repeat, a license for data.
http://satchmo.python-hosting.com/browser/trunk/satchmo/G11n/data/
http://creativecommons.org/licenses/by-sa/2.5/
Af
When I began to create several tables of data for the globalization I
wanted to use a license of CC because GPL or BSD are more specific of
software. I repeat, a license for data.
http://satchmo.python-hosting.com/browser/trunk/satchmo/G11n/data/
http://creativecommons.org/licenses/by-sa/2.5/
Af
Sorry this message was sent 3 times by a google error.
--~--~-~--~~~---~--~~
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 unsubscrib
Chris Long wrote:
> Already had a few people point out some bugs and some features they
> want. Community involvement is key to get this moving ahead as quickly
> as possible.
I'm planning to move my development work to the pop/gen_auth branch
once they are merged. Hopefully I will be able to gi
On 9/6/06, Linicks <[EMAIL PROTECTED]> wrote:
>
> I'm planning to move my development work to the pop/gen_auth branch
> once they are merged. Hopefully I will be able to give some good
> feedback at that point. When the merge is complete, would it be
> possible to have you guys merge with trunk f
Hi, all.
Been playing with the serializer stuff a bit. What do people think
about the optional ability to limit which fields get serialized?
Something like:
serializers.serialize('json', foo.objects.all(), fields=('somefield',
'anotherfield'))
So that only 'somefield' and 'anotherfield' get se
On 06/09/2006, at 11:19 PM, GinTon wrote:
>
> it did not matter to me to use the New BSD license, although I would
> prefer to use the following one of CC who is compatible with BSD and
> not viric (it's different of avobe)
> http://creativecommons.org/licenses/by/2.5/
>
> But David Pratt demand
On 9/6/06, GinTon <[EMAIL PROTECTED]> wrote:
> 1) Has more preference the contributors of Google summer code that the
> one independents?
For the students who did SoC projects, they of course can choose any
license they want. But if they want their projects to be merged into
Django proper, they n
Same as Linicks. Alain (Dazzi) and I plan to use this new
merged pop/gen-auth branch for development, and also
would like relatively frequent (once a week sounds fine) merges
from trunk.
Would let you know how that goes. Let us know when the
new branch is ready to try out. (by replying here)
/Na
Ian Holsman wrote:
> the only 'viral' in my reading is '4b
> as long as chris (the owner of the ecommerce code) is happy with the
> type of CC license you put in there it should be fine.
>
The '4b' section simply leaves the author attribution very clear
http://creativecommons.org/licenses/by/2.5/
Freelance Work Exchange is a premier online community for freelance
professionals and companies looking to hire skilled freelance experts.
We have thousands of freelance and work-at-home jobs in the US and
worldwide.
http://www.shopzero.com/best_services/freelance-work-exchange-home-jobs-for-writ
I'm in the process of creating a FileBrowseField that inherits from the
CharField, but implements similar accessors to the File/ImageField. e.g.
get_%s_url
Additionally, in the admin, I want it to pop-up a filebrowser to allow
me to select the file I want.
I'm currently using a modified version
Any idea what,
--~--~-~--~~~---~--~~
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
Sometime over the next few days when I feel a bit more organized I'll
merge it to trunk. Moving into a new house so everything has been a bit
chaotic.
Chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django d
On Wed, 2006-09-06 at 17:36 -0500, Marc D.M. wrote:
> I'm in the process of creating a FileBrowseField that inherits from the
> CharField, but implements similar accessors to the File/ImageField. e.g.
> get_%s_url
>
> Additionally, in the admin, I want it to pop-up a filebrowser to allow
> me to
Just because I stubled on the code of curry (I had to find out what
this function really does).
It's not a big of a deal, but I think it would be better to change the
function from the current implementation:
def curry(*args, **kwargs):
def _curried(*moreargs, **morekwargs):
return a
When moving an app to a different project, I had to go through and fix
all the references to my project name in code. Is there a better way to
import my code? Currently I import like:
from projectname.appname.models import Model
It seems like this inhibits portability of apps somewhat. Perhaps t
On 9/6/06, Martin <[EMAIL PROTECTED]> wrote:
> def curry(fct, *args, **kwargs):
> def _curried(*moreargs, **morekwargs):
> return fct (* (args+moreargs), **dict(kwargs, ** morekwargs))
> return _curried
>
> It's just a performance issue (saving a few list operations) andbecause
> I
On Thu, 2006-09-07 at 03:41 +, SmileyChris wrote:
> When moving an app to a different project, I had to go through and fix
> all the references to my project name in code. Is there a better way to
> import my code? Currently I import like:
>
> from projectname.appname.models import Model
>
>
Adrian Holovaty wrote:
> On 9/6/06, Martin <[EMAIL PROTECTED]> wrote:
>> def curry(fct, *args, **kwargs):
>> def _curried(*moreargs, **morekwargs):
>> return fct (* (args+moreargs), **dict(kwargs, ** morekwargs))
>> return _curried
>>
>> It's just a performance issue (saving a few
Hello!
gabor wrote:
...
> this way works perfectly:
> - have EVERYTHING in utf8
...
Sadly not so :(
There are some places in Django that prohibit you from using utf8 (any
multibyte encoding in fact) - already mentioned admin's `last change`
list is one of those places.
For example, see contrib
> Well, as far as I know, python's import is relative. So if you're in the
> module /home/gray/white.py and you say
> import blue
> it will first try to find blue.py in /home/gray, so design your imports
> carefully.
Be careful ... in one of the next releases of python, support for
relativ
23 matches
Mail list logo
