byteflow: overriding 'compat' modules
Ben Jackson
to support hooks for [[local]] links*). I can see how I'd modify apps/render
to wrap it and add my byteflow-centric hooks, but I am not sure what the
Right way is to avoid using compat/wikimarkup. I'm wondering if byteflow
should use an explicit list of compat modules in a settings file. I'm
not sure how that would work with python's 'import'.
[*] http://github.com/bjj/py-wikimarkup
import settings
from pytils.translit import slugify
from blog.models import Post
def byteflowLinkHook(parser_env, namespace, body):
(article, pipe, text) = body.partition('|')
slug = slugify(article.strip())
text = (text or article).strip()
try:
post = Post.objects.get(slug=slug)
href = post.get_absolute_url()
except Post.DoesNotExist:
href = '#'
return '<a href="%s">%s</a>' % (href, text)
registerInternalLinkHook(None, byteflowLinkHook)
--
Ben Jackson AD7GD
<b...@ben.com>
http://www.ben.com/
Alexander Solovyov
> I'd like to use a newer py-wikimarkup (mainly because I've extended it
> to support hooks for [[local]] links*). I can see how I'd modify apps/render
> to wrap it and add my byteflow-centric hooks, but I am not sure what the
> Right way is to avoid using compat/wikimarkup. I'm wondering if byteflow
> should use an explicit list of compat modules in a settings file. I'm
> not sure how that would work with python's 'import'.
Surely render application is not very extensible, I'll think about
this. But... is there any downsides in usage of new py-wikimarkup? Maybe
we just need to replace old with this one?
--
Alexander
Ben Jackson
> On 2010-01-01, Ben Jackson wrote:
>
> > I'd like to use a newer py-wikimarkup (mainly because I've extended it
> > to support hooks for [[local]] links*).
>
> this. But... is there any downsides in usage of new py-wikimarkup? Maybe
> we just need to replace old with this one?
Maybe I should. At the moment I've just moved 'compat' to the end of
the python path so it acts as a backup for missing packages rather than
an override. If 'compat' is intended to be like the Rails 'vendor'
directory that is the wrong idea.
Alexander Solovyov
>> Surely render application is not very extensible, I'll think about
>> this. But... is there any downsides in usage of new py-wikimarkup? Maybe
>> we just need to replace old with this one?
> Maybe I should. At the moment I've just moved 'compat' to the end of
> the python path so it acts as a backup for missing packages rather than
> an override. If 'compat' is intended to be like the Rails 'vendor'
> directory that is the wrong idea.
Hm, probably. There was an idea that 'compat' contains modules which are
known to work, but I'm not in favor of it right now.
--
Alexander
Alexander Solovyov
> Maybe I should. At the moment I've just moved 'compat' to the end of
> the python path so it acts as a backup for missing packages rather than
> an override. If 'compat' is intended to be like the Rails 'vendor'
> directory that is the wrong idea.
Hmm... probably. Then it should be .append'ed to a sys.path instead of
.insert'ion. I'll change that.
--
Alexander
Ben Jackson
Since settings.py gets executed multiple times (the DEBUG print in
settings_local makes that obvious) I actually did this:
def addpath(where, path):
if not os.path.isabs(path):
path = os.path.join(PROJECT_ROOT, path)
if path not in sys.path:
sys.path.insert(where, path)
addpath(0, 'apps')
addpath(-1, 'compat')
and after local is loaded, a new hook:
try:
for path in ADDITIONAL_PATHS:
addpath(0, path)
except NameError:
pass
Alexander Solovyov
>>> Maybe I should. At the moment I've just moved 'compat' to the end of
>>> the python path so it acts as a backup for missing packages rather than
>>> an override. If 'compat' is intended to be like the Rails 'vendor'
>>> directory that is the wrong idea.
>> Hmm... probably. Then it should be .append'ed to a sys.path instead of
>> .insert'ion. I'll change that.
> Since settings.py gets executed multiple times (the DEBUG print in
> settings_local makes that obvious) I actually did this:
Huh, really? That's news for me. :-( Anyway, I'll wait with this change
to thought about and play with yml's developments.
--
Alexander
Ben Jackson
>
> > Since settings.py gets executed multiple times (the DEBUG print in
> > settings_local makes that obvious) I actually did this:
>
> Huh, really? That's news for me. :-( Anyway, I'll wait with this change
> to thought about and play with yml's developments.
I think it has to do with the way django.conf works. Something like
manage.py imports settings directly (via implicit . in path) and then
the DJANGO_SETTINGS_MODULE env is used in django.conf. It doesn't
matter if you only set constants but it becomes and issue if your
setttings.py has side effects. I don't know where the 4x issue comes
from, but I've seen the DEBUG print come out 4 times.
Alexander Solovyov
>>> Since settings.py gets executed multiple times (the DEBUG print in
>>> settings_local makes that obvious) I actually did this:
>> Huh, really? That's news for me. :-(
> I think it has to do with the way django.conf works. Something like
> manage.py imports settings directly (via implicit . in path) and then
> the DJANGO_SETTINGS_MODULE env is used in django.conf. It doesn't
> matter if you only set constants but it becomes and issue if your
> setttings.py has side effects. I don't know where the 4x issue comes
> from, but I've seen the DEBUG print come out 4 times.
Hah, magic, welcome to our lives. :\ Ok, thanks, I'll remember that.
--
Alexander
Yuri Baburov
All's simple:
if python manage.py runserver is called, settings.py is executed 4 times,
in production or any other command, settings.py is executed 2 times.
First double is because of "auto-reload" feature.
Second is because of "import settings" once & "import myblog.settings"
once if your django project is called "myblog".
I raised this issue few times at django-dev, it seems no one cares.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com