group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
&g
the word!
--
Mathieu Leduc-Hamel
--
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 email to
django-developer
the same problem
related to conflicting names no?
On Mon, Sep 27, 2010 at 10:56 AM, Iván Raskovsky <raskov...@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 3:14 AM, Russell Keith-Magee
> <russ...@keith-magee.com> wrote:
>> On Mon, Sep 27, 2010 at 1:43 PM, Mathieu Leduc-H
and more
than that, it means we are not completely explicit but magic.
What do you think ?
--
Mathieu Leduc-Hamel
--
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...@google
, Mathieu Leduc-Hamel <marra...@gmail.com>wrote:
> Hi jef,
>
> I really the approach you took with your datatrans application. Do you have
> an example application of your solution. I would like to implement in our
> solution but i need to convince my colleagues ! ;-)
>
> Do
Hi jef,
I really the approach you took with your datatrans application. Do you have
an example application of your solution. I would like to implement in our
solution but i need to convince my colleagues ! ;-)
Does that mean that with your solution, these translated fields will be in
the general
Oh cool! next time I'll check in the PEP list before...
But I don't understand how it'll work with older python version, like
the current 2.6 branch ?
On Fri, May 28, 2010 at 4:33 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>
> On May 28, 9:16 pm, Mathieu Leduc-Hamel <mar
I would say, why not use the default python way to config logging,
handler and loggers ? it work fine and many projects are using it.
That way, we'll be able to use the same logging configuration for our
django projects and the different python library that we may use and
we the logging is
: I don't think splitting up everything is going to happen anytime
> soon. The proposal is just to rip out the ORM so it can be used outside -
> not to make it easy to use other ORMs in Django with the same amount of
> integration.
>
> On Sat, Mar 13, 2010 at 12:05 AM, Mathieu Leduc-H
It would be very very cool to have the orm separated from everything
else ! And by the way, there could be some other cool possibilities
as:
- Bug fix of separated component and not all the framework unnecessary
- You just install what you need, by example, I've just on a project
without any
By the way, did you the effort of porting reported on the python website:
http://wiki.python.org/moin/PortingDjangoTo3k
Seems to the good way to achieve it some times...
On Tue, Feb 2, 2010 at 5:37 PM, Dave wrote:
> Ok everyone, a bit of a status update.
>
> We finished our
Using djangorecipe and zc.buildout offer your exactly that kind of mechanism.
You write the name of settings of choice in your buildout:
[django]
recipe = djangorecipe
version = 1.1
settings = development
eggs = ${eggs:eggs}
wsgi = true
project = project
And after that you can have by example
12 matches
Mail list logo