Re: ANN: Django 1.3 released

[Mathieu Leduc-Hamel]

Congratulation !!!

Amazing, just in time for the spring

On Wed, Mar 23, 2011 at 4:52 AM, Idan Gazit <i...@gazit.me> wrote:
> Three cheers for the release team!
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
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-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.

ConFoo 2010 Call for speakers

[Mathieu Leduc-Hamel]

Greetings Django Developers,

We, Montréal-Python, are the coordinators of the Python track at
ConFoo 2011 and we are very proud to announce our call for speakers.

PHP-Québec, Montréal-Python, Montreal.rb, W3Qc, and OWASP Montréal are
organizing the first edition of the ConFoo conference, which will be
held in Montréal on March 9th through 11th at the Hilton Bonaventure
Hotel.  With over 500 expected attendees, ConFoo is one of the largest
Web development conference in North America.

ConFoo is about the Web, but it's also about showcasing the strengths
of different technologies.  Do you think that Python beats all the
other languages out there for Web development?  Do you think that
Django knocks PHP's socks off?  Come and tell us why!

Sessions are one hour long and you can present in French or in
English, which ever your prefer.  Submissions are due for November 26;
for more details, visit the ConFoo website:

  http://confoo.ca/en/call-for-papers

By the way, we are perfectly aware that there is a slight clash with
PyCon.  You should not worry about that since all Python talks will
happen before Friday, giving you plenty of time for the commute
towards Atlanta.

Share 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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Application, tempaltetags and namespace

[Mathieu Leduc-Hamel]

Cool, than from what i see it seems the namespacing will be more and
more implemented in Django in the future.

But as a good practice, it would be cool if it's finally happen to
force any templatetags to be used with namespace ? Cause if people can
use the old way to do things, we'll still have 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-Hamel <marra...@gmail.com> 
>> wrote:
>>> Hi all,
>>>
>>> I'm curious to know if it's planned in the future to force the use of
>>> the complete name of the applications and the templatestags. I'll
>>> explain myself.
>> There are two tickets related to this problem:
>>
>> #2539: Namespacing for template tags
>> #12772: Loading by fully qualified path name
>>
>> Template tag namespacing has been accepted as an idea; it's just
>> waiting on a trunk-ready patch.
>>
>> Loading by fully qualified path is currently marked DDN; On principle,
>> the idea seems sound to me, but it requires more thought in terms of
>> how the new loading scheme will interact with existing code.
>
> I've proposed a solution[1] some time ago, where I also gathered all
> the discussions on the topic I could find. Sadly I got no feedback.
>    Iván
>
> [1] 
> http://groups.google.com/group/django-developers/browse_thread/thread/da9ed3a3116c546a/88d0d780a5e9d09f?lnk=gst=namespaces#88d0d780a5e9d09f
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Application, tempaltetags and namespace

[Mathieu Leduc-Hamel]

Hi all,

I'm curious to know if it's planned in the future to force the use of
the complete name of the applications and the templatestags. I'll
explain myself.

Imagine you have an application called

hello.world

with the following structure:

hello.world/
  setup.py
  hello/
world/
 ...

If you have an application called common and a templatags named
featured_product, there's no way to it seems to force django to refer
only to the complete name like that:

hello.world.common

and

hello.world.common.featured_products

it caused sometime some problems related to conflicting names 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...@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.

Re: Model translation

[Mathieu Leduc-Hamel]

Oh no I think i didn't understand correctly your points.

You created a lookup table, then it means you'll to translate the differents
fields values in one specific section of the admin backend of django which
contain every translatable fields of your project ?

On Thu, Aug 19, 2010 at 11:44 AM, 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 ! ;-)
>
> Does that mean that with your solution, these translated fields will be in
> the general .po file of your project and will be translated like any other
> static fields ?
>
> On Thu, Aug 19, 2010 at 11:20 AM, Jef Geskens <jef.gesk...@gmail.com>wrote:
>
>> > I haven't seen django-datatrans before. Does it play well with the
>> > Django ORM querying style? The other registration based apps don't.
>> >
>> > - hejsan
>>
>> It does nothing at the ORM layer, it only comes in action on the model
>> instances, when accessing their fields.
>>
>> django-datatrans was kept very simple: it mimics the behavior of the
>> gettext po-files, like the i18n app from django. It looks for
>> translatable strings, puts them in a lookup table, that can in turn be
>> easily translated. Instead of putting {% trans "" %} around all your
>> strings, you say "this model contains these translatable fields", and
>> datatrans scrapes the contents of those fields and make them
>> translatable. In fact, our first model translation solution was a
>> script that scraped the model content and put all translatable strings
>> in a .txt file with {% blocktrans %} around them.
>>
>> Creating this app proved more efficient to our company than
>> restructuring and possibly rewriting our apps as well as third party
>> apps. The only disadvantage is the extra lookup, but by using django's
>> caching mechanism we try to overcome that inefficiency. Django's i18n
>> app and gettext also have to lookup and cache translations. I don't
>> see the difference. Our ISP website, mobilevikings.com, is required to
>> be completely multilingual, in three languages. In the releasing
>> process of a new feature, we have a translators team that use the
>> included admin tool from datatrans intensively.
>>
>> I think that if you want to create a website with 30 or more
>> languages, the approach of one-instance-for-each-language is more
>> usable indeed. But if you have an huge, live system with a lot of apps
>> that work together, and only need to support a handful of languages,
>> django-datatrans might be a good option.
>>
>> I suggest you take a look at the source, especially here:
>>
>> http://github.com/citylive/django-datatrans/blob/master/datatrans/utils.py
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model translation

[Mathieu Leduc-Hamel]

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 .po file of your project and will be translated like any other
static fields ?

On Thu, Aug 19, 2010 at 11:20 AM, Jef Geskens  wrote:

> > I haven't seen django-datatrans before. Does it play well with the
> > Django ORM querying style? The other registration based apps don't.
> >
> > - hejsan
>
> It does nothing at the ORM layer, it only comes in action on the model
> instances, when accessing their fields.
>
> django-datatrans was kept very simple: it mimics the behavior of the
> gettext po-files, like the i18n app from django. It looks for
> translatable strings, puts them in a lookup table, that can in turn be
> easily translated. Instead of putting {% trans "" %} around all your
> strings, you say "this model contains these translatable fields", and
> datatrans scrapes the contents of those fields and make them
> translatable. In fact, our first model translation solution was a
> script that scraped the model content and put all translatable strings
> in a .txt file with {% blocktrans %} around them.
>
> Creating this app proved more efficient to our company than
> restructuring and possibly rewriting our apps as well as third party
> apps. The only disadvantage is the extra lookup, but by using django's
> caching mechanism we try to overcome that inefficiency. Django's i18n
> app and gettext also have to lookup and cache translations. I don't
> see the difference. Our ISP website, mobilevikings.com, is required to
> be completely multilingual, in three languages. In the releasing
> process of a new feature, we have a translators team that use the
> included admin tool from datatrans intensively.
>
> I think that if you want to create a website with 30 or more
> languages, the approach of one-instance-for-each-language is more
> usable indeed. But if you have an huge, live system with a lot of apps
> that work together, and only need to support a handful of languages,
> django-datatrans might be a good option.
>
> I suggest you take a look at the source, especially here:
>
> http://github.com/citylive/django-datatrans/blob/master/datatrans/utils.py
>
> --
> 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-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Logging in Django

[Mathieu Leduc-Hamel]

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 <marra...@gmail.com> wrote:
>> 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 implemented using the default python way.
>>
>> I don't exactly understand why it should be in the settings.py file ?
>>
>
> What's proposed to be in settings.py is the actual configuration, not
> the mechanism. The mechanism will be the new-in-Python-2.7-and-3.2
> configuration via dictionaries (rather than via Python code or the ini-
> style confguration files - see PEP 391 for more details of the
> rationale behind dict-based configuration).
>
> Existing projects (like Django) can use the standalone dictconfig
> project on BitBucket to get the functionality which will be in Python
> 2.7 and 3.2, for use with earlier versions of Python. So really,
> Django is using the same mechanisms as Python for logging. It's good
> practice to put a shallow interface between the Django and Python
> logging configuration layers, to allow Django to specify sensible
> defaults. (There's an example of that in my Launchpad branch - the
> Django layer adds a default key in the dictionary to specify that by
> default, existing loggers are not disabled when configuration
> happens.)
>
> Logging of third-party libraries and django-apps (which make use of
> logging) in a Django site will be customisable through the logging
> configuration mechanism being proposed. All of Django, your apps and
> their dependencies, third-party apps and their dependencies - if any
> of them already use logging in the conventional way, you will be able
> to modify their logging behaviour through this mechanism.
>
> Regards,
>
> Vinay Sajip
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Logging in Django

[Mathieu Leduc-Hamel]

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 implemented using the default python way.

I don't exactly understand why it should be in the settings.py file ?

On Fri, May 28, 2010 at 11:48 AM, Russell Keith-Magee
 wrote:
> Hi all,
>
> Following some discussion at the DjangoCon.eu sprints, here's what
> we've got on the table regarding adding logging support to Django.
>
> The core of Vinay's work is essentially ready to go -- the logging
> configuration code is an implementation of what has been accepted as a
> PEP, so there's no reason for us to use anything else.
>
> As for landing this in trunk - the consensus is that this should be
> done in two parts:
>
> The first commit will be the the actual core logging infrastructure -
> the logging config parsing module, and the hooks to get a logging
> configuration parsed and installed.
>
> The second commit will be the addition of actual logging. The
> intention here is to be initially conservative; two immediate targets
> would be to replace calls to mail_admins() with logging calls, and
> replacing debug messages in management commands with their logging
> equivalent.
>
> At this point, it largely becomes a political problem -- we don't want
> Django's core to get bogged down in trivial logging calls, so we need
> to develop our policy on when we add a logging statement to trunk, and
> at what trace level, and so on. Of course, none of this prevents end
> users from putting whatever logging they want into their own code. It
> also doesn't prevent the core logging code and initial logging calls
> being added to trunk; we can develop the logging policy over time once
> the core is in place.
>
> On a technical level, the only issue that needs resolving is the issue
> of how to trigger configuration of logging in the first place. The
> current patch implements this using signals (a bootstrap plus pre/post
> model load signals). The consensus at the sprints is that we should
> take this opportunity to kill an old request -- 'startup' handling.
>
> Under this proposal, startup would look like this:
>
>  * Once settings have been successfully imported, logging is
> configured based on settings.LOGGING. This guarantees that logging
> will always be configured, rather than relying on users successfully
> invoking logging in their own settings file or similar. This will
> essentially replace the BOOTSTRAP_CALLBACK in Vinay's current patch.
>  * We then look for a 'startup.py' in each app included in
> INSTALLED_APPS, and import that module. This is the replacement for
> (PRE|POST)_MODEL_CALLBACKS in Vinay's current patch
>
> This provides a convenient entry point for configuration items such as
> signals. The only runtime guarantee for startup.py is that the
> settings have been imported. This means that you should be able to
> import models, register for signals, or anything else you may want to
> do on startup.
>
> There won't be a project-level startup file. We've been trying to
> discourage the use of projects for a long time, and almost everything
> that needs to be considered as "project level" can be implemented by
> using a "project app" -- either adding a 'project.core' app to the
> mix, or by adding the project directory itself to INSTALLED_APPS. If
> you have a need for a project level startup.py, then this is the
> approach that should be taken.
>
> So - comments? Suggestions?
>
> 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-develop...@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.
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [GSoC] Making django.db usable outside Django

[Mathieu Leduc-Hamel]

Yes I understood it was not necessarily the plan to split everything,
but for me I thought it could be a good start. Is there anything that
could block us to do it (Yes i know it's not a priority) ?


On Fri, Mar 12, 2010 at 4:15 PM, Yuvi Panda <yuvipa...@gmail.com> wrote:
> @Mathieu: 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-Hamel <marra...@gmail.com>
> wrote:
>>
>> 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 database, just the templates and the controller things.
>> We've choose Pylons cause it was lighter for our needs. But having the
>> possibility to install only the needed component, maybe we've choose
>> django !
>>
>> I hope you'll be able to work on that and maybe we'll have time to
>> contribute !
>>
>> And the other major point, some people who are using other framework
>> will be able to use and contribute to the django orm code !
>>
>> math
>>
>> On Fri, Mar 12, 2010 at 1:13 PM, Yuvi Panda <yuvipa...@gmail.com> wrote:
>> > Besides the smaller dependency, it can be more easily integrated into
>> > other
>> > frameworks. No manage.py, settings.py, etc, so you can integrate
>> > settings,
>> > management, etc with the rest of the target framework. It would be
>> > cleaner.
>> >
>> > On Fri, Mar 12, 2010 at 7:06 PM, Dougal Matthews <douga...@gmail.com>
>> > wrote:
>> >>
>> >> On 12 March 2010 12:51, Yuvi Panda <yuvipa...@gmail.com> wrote:
>> >>>
>> >>> I'm a CS student from India and am planning to apply for this year's
>> >>> GSoC
>> >>> to work on Django.
>> >>>
>> >>> My project idea is to rip out the Django ORM so it could be used
>> >>> outside
>> >>> django. django.db will be isolated (ie. dependencies on other parts of
>> >>> django will be cut or folded back into django.db), and packaged with a
>> >>> different name (perhaps djangoorm, to avoid conflict with django) so
>> >>> it can
>> >>> be used in other web frameworks, application servers, desktop apps,
>> >>> etc.
>> >>> I've already done some prelim work[1] cutting dependencies, and all
>> >>> the
>> >>> django.db related tests run successfully. This will make atleast one
>> >>> part of
>> >>> Django usable by a lot more people.
>> >>>
>> >>> I'm writing up a full proposal, but thought it would be a good idea to
>> >>> check with the developers.
>> >>>
>> >>> Thoughts?
>> >>
>> >> I've used the Django ORM in a few projects that don't use anything else
>> >> (some where not even websites). I just included Django and left much of
>> >> it
>> >> unused - it worked very well and was very easy to setup.
>> >> What advantage does your approach have over that? besides having a
>> >> slightly smaller dependency.
>> >> Dougal
>> >>
>> >> --
>> >> 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-developers+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/django-developers?hl=en.
>> >
>> >
>> >
>> > --
>> > Yuvi Panda T
>> > http://yuvi.in/blog
>> >
>> > --
>> > 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-developers+unsubscr...@googlegroups.com.
>> > For more options, visit thi

Re: [GSoC] Making django.db usable outside Django

[Mathieu Leduc-Hamel]

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 database, just the templates and the controller things.
We've choose Pylons cause it was lighter for our needs. But having the
possibility to install only the needed component, maybe we've choose
django !

I hope you'll be able to work on that and maybe we'll have time to contribute !

And the other major point, some people who are using other framework
will be able to use and contribute to the django orm code !

math

On Fri, Mar 12, 2010 at 1:13 PM, Yuvi Panda  wrote:
> Besides the smaller dependency, it can be more easily integrated into other
> frameworks. No manage.py, settings.py, etc, so you can integrate settings,
> management, etc with the rest of the target framework. It would be cleaner.
>
> On Fri, Mar 12, 2010 at 7:06 PM, Dougal Matthews  wrote:
>>
>> On 12 March 2010 12:51, Yuvi Panda  wrote:
>>>
>>> I'm a CS student from India and am planning to apply for this year's GSoC
>>> to work on Django.
>>>
>>> My project idea is to rip out the Django ORM so it could be used outside
>>> django. django.db will be isolated (ie. dependencies on other parts of
>>> django will be cut or folded back into django.db), and packaged with a
>>> different name (perhaps djangoorm, to avoid conflict with django) so it can
>>> be used in other web frameworks, application servers, desktop apps, etc.
>>> I've already done some prelim work[1] cutting dependencies, and all the
>>> django.db related tests run successfully. This will make atleast one part of
>>> Django usable by a lot more people.
>>>
>>> I'm writing up a full proposal, but thought it would be a good idea to
>>> check with the developers.
>>>
>>> Thoughts?
>>
>> I've used the Django ORM in a few projects that don't use anything else
>> (some where not even websites). I just included Django and left much of it
>> unused - it worked very well and was very easy to setup.
>> What advantage does your approach have over that? besides having a
>> slightly smaller dependency.
>> Dougal
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>
>
>
> --
> Yuvi Panda T
> http://yuvi.in/blog
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Porting Django to Python 3

[Mathieu Leduc-Hamel]

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 preliminary exercise in learning Django - we created
> an architecture, performance and call profile, as well as a screencast
> instructing how to install Django in Linux and a few simple use cases.
> We'll try to make these publicly available so you the community can
> use them if you wish. Right now they're in our school's repository so
> we'll try to export them soon.
>
> Right now we're trying to decide how our work should be evaluated at
> the end of our term, April 1. What we would like to hear back from you
> is, how much do you think we should finish by that point in time?
> All / 75% / 50%, or whatever is appropriate. We're also debating how
> it should be evaluated. What made the most sense to us was to pick a
> number (if not all) of the test cases in the test suite, and try to
> have them passed by the end of term, as well as being able to perform
> some use cases. How many test cases do you think the Django / Python 3
> port should be able to pass by April 1? What use cases should a Django
> user be able to do when using the port? We were also thinking of
> making a screencast to showcase these use cases.
>
> Finally, a small aside but Martin, we tried to email you at your
> Google Group address - we were interested in talking to you about the
> work you're doing or have done on the port. Is there a way we could
> contact you in case we had some questions or needed some guidance?
>
> On Jan 15, 6:50 pm, Luke Plant  wrote:
>> On Friday 15 January 2010 18:54:51 Martin v. Löwis wrote:
>>
>> > > That sounds like a not-unreasonable distribution of work.  One of
>> > > the big architecture questions is that in Django currently
>> > > anywhere you can pass a string Django will accept either a utf-8
>> > > encoded string or unicode, in Py3k given the clear
>> > > differentiation in purpose between str and bytes is that still
>> > > reasonable behavior?
>>
>> > What APIs does this refer to? There are certainly places in Django
>> > where there is no choice of providing byte strings (i.e. where you
>> > must pass Unicode strings).
>>
>> Some examples:
>>
>> >>> Template(u"{{ foo }}").render(Context({"foo":"bar"}))
>> u'bar'
>> >>> Template("{{ foo }}").render(Context({u"foo":"bar"}))
>> u'bar'
>> >>> Template("{{ foo }}").render(Context({"foo":u"bar"}))
>>
>> u'bar'
>>
>> >>> MyModel.objects.filter(my_attr="foo")
>> >>> MyModel.objects.filter(my_attr=u"foo")
>> >>> mymodel_instance.my_attr = "foo"
>> >>> mymodel_instance.my_attr = u"foo"
>>
>> In addition to these things, there may be problems where dictionary
>> keys and various other values have used byte strings up until now,
>> with no problems, but based on assumptions that no longer hold.  For
>> example, declarative classes (e.g. Models) are an interesting one - in
>> Python 2.x, the keys of MyClass.__dict__ are byte strings, but in 3.0,
>> they are unicode strings.  Since non-ascii names for identifiers are
>> valid in Python 3.0 (thanks in part, I believe, to your good self :-),
>> and also in at least some databases, this is not an academic issue.
>>
>> Also, in Python 3.0, you can have models with non-ascii names, which
>> challenges some assumptions about things like the INSTALLED_APPS
>> setting.
>>
>> I imagine that some of these things will 'come out in the wash', so to
>> speak, and the lack of automatic conversion will help identify
>> problems, but some things might come back to bite us if we don't get
>> them right.
>>
>> Luke
>>
>> --
>> "Outside of a dog, a book is a man's best friend... inside of a
>> dog, it's too dark to read."
>>
>> Luke Plant ||http://lukeplant.me.uk/
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: What The Enterprise wants from Django

[Mathieu Leduc-Hamel]

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 another production's
configuration file like "prod.cfg" overloading your django part and
using another settings name.

In your project dir, you'll have a file named development.py and
another one named prod.py. In these files you can override any
configuration you want.

For deployement, zc.buildout is working pretty fine with django:

http://pypi.python.org/pypi/djangorecipe


On Wed, Jan 20, 2010 at 1:46 AM, mrts  wrote:
> On Jan 20, 5:59 am, David Cramer  wrote:
>> The first three have been huges ones with us. We're just now running
>> into the settings issue, but would love to see what people can come up
>> with for solutions (we dont have a good one).
>
> The override_settings() idea that Eric Florenzano describes at
> http://djangodose.com/articles/2009/09/handling-development-staging-and-production-enviro/
> with some improvements and fixes as described in the following
> http://djangodose.com/articles/2009/09/handling-development-staging-and-production-enviro/#comment-16302200
> have made my life considerably easier.
>
> Hope the following helps others as well.
>
> # 1.
> # settings is a directory, containing host-specific overrides
> # and the generic override logic
>
> $ ls settings/
> __init__.py   override.py   host1.py   host2.py
>
> # 2.
> # __init__.py has the same contents that settings.py
> # usually has, except it automatically imports host-specific
> # settings in the end
>
> $ tail -2 settings/__init__.py
> override.override_settings('projectname', platform.node().split('.')
> [0],
>        sys.modules[__name__])
>
> # 3.
> # The generic override logic is as follows
>
> $ cat settings/override.py
> from django.utils.importlib import import_module
> import warnings
>
> def override_settings(package, name, settings_module):
>    rel_path = 'settings.' + name
>    try:
>        override_module = import_module(rel_path, package=package)
>    except ImportError:
>        warnings.warn("Failed to import settings from '%s.%s'" %
>                (package, rel_path))
>    else:
>        for key in dir(override_module):
>            if key.isupper() and not key.startswith('__'):
>                setattr(settings_module, key, getattr(override_module,
> key))
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.