[no subject]
http://www.jhm3.lowcostpillsx.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-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.
Global name 'table' not defined
I'm on the latest trunk (updated this morning), and I'm getting a Python NameError in django.core.cache.backends.db . Line 127 (http:// code.djangoproject.com/browser/django/trunk/django/core/cache/backends/ db.py#L127) references a variable 'table', but it's not locally defined. All other methods in the CacheClass first do the following line before such use: table = connections[db].ops.quote_name(self._table) Has anybody else run into this problem in runtime? I was surprised that the error was legitimately happening in the core code. -- 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: a new template algorithm
> Pros of this solution:
> * The implementation is clear and short; 250 lines of code do the magic
> All the statements are exactly the python statements
Alex briefly mentioned the design decision of the template system, but
I think it'd be good to emphasize his point-- Django was designed to
have various layers, such as the urls, the views, the templates, etc.
If you think about it, different people within a large project could
actually be in charge of different layers, free to change certain
things without breaking the other layers. If the templates make
proper use of the {% url %} templatetag, a urls designer can make
small changes the URL structure without breaking the site at all.
The template system is built with non-Python programmers in mind. It
is assembled to introduce fundamental Python functionality (loops, if-
else logic, variables, methods) into HTML, such that an HTML designer
can use the system without needing to know Python.
There's no doubt that many of us independent site designers are in
fact well acquainted with Python, but that's not the larger vision.
Interesting idea, though. Your approach is much more like PHP, which
unarguably has its advantages. Django's template system is built such
that it could be used all by itself, without the rest of Django's
layers. There's certainly nothing to stop you from using your
template system or any other template system with Django!
--
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: Global name 'table' not defined
The only time i've seen this sort of thing happening was when i had an
app name that got in the way of something in the core/python namespace
('collections'). Do you have any apps that could be getting in the
way? Does the error occur with all your projects?
Stephen
On 30 Aug 2010, at 17:35, Tim wrote:
I'm on the latest trunk (updated this morning), and I'm getting a
Python NameError in django.core.cache.backends.db . Line 127 (http://
code.djangoproject.com/browser/django/trunk/django/core/cache/
backends/
db.py#L127) references a variable 'table', but it's not locally
defined. All other methods in the CacheClass first do the following
line before such use:
table = connections[db].ops.quote_name(self._table)
Has anybody else run into this problem in runtime? I was surprised
that the error was legitimately happening in the core code.
--
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
.
--
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: Global name 'table' not defined
I don't think that's the issue, although the answer to that question
is 'no'.
Back on commit r13473 several changes were made, which introduced this
inconsistency. the value was shifted from self._table to the local
variable named just 'table', which each method was responsible to
derive via that line I pasted above:
table = connections[db].ops.quote_name(self._table)
The problem is that the above line didn't make it into the _cull
method, but the NameError in question is only encountered through an
if-else construct, shielding it from some light testing. I've been
staring at those lines of code trying to find something subtle that
I'm missing, but there's no possible way for those lines to execute
without causing a NameError.
I guess I'll be filing the bug..
On Aug 30, 1:14 pm, Stephen Wolff wrote:
> The only time i've seen this sort of thing happening was when i had an
> app name that got in the way of something in the core/python namespace
> ('collections'). Do you have any apps that could be getting in the
> way? Does the error occur with all your projects?
>
> Stephen
>
> On 30 Aug 2010, at 17:35, Tim wrote:
>
>
>
>
>
>
>
> > I'm on the latest trunk (updated this morning), and I'm getting a
> > Python NameError in django.core.cache.backends.db . Line 127 (http://
> > code.djangoproject.com/browser/django/trunk/django/core/cache/
> > backends/
> > db.py#L127) references a variable 'table', but it's not locally
> > defined. All other methods in the CacheClass first do the following
> > line before such use:
>
> > table = connections[db].ops.quote_name(self._table)
>
> > Has anybody else run into this problem in runtime? I was surprised
> > that the error was legitimately happening in the core code.
>
> > --
> > 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
> > athttp://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: Global name 'table' not defined
http://code.djangoproject.com/ticket/14199
On Aug 30, 1:34 pm, Tim wrote:
> I don't think that's the issue, although the answer to that question
> is 'no'.
>
> Back on commit r13473 several changes were made, which introduced this
> inconsistency. the value was shifted from self._table to the local
> variable named just 'table', which each method was responsible to
> derive via that line I pasted above:
>
> table = connections[db].ops.quote_name(self._table)
>
> The problem is that the above line didn't make it into the _cull
> method, but the NameError in question is only encountered through an
> if-else construct, shielding it from some light testing. I've been
> staring at those lines of code trying to find something subtle that
> I'm missing, but there's no possible way for those lines to execute
> without causing a NameError.
>
> I guess I'll be filing the bug..
>
> On Aug 30, 1:14 pm, Stephen Wolff wrote:
>
>
>
>
>
>
>
> > The only time i've seen this sort of thing happening was when i had an
> > app name that got in the way of something in the core/python namespace
> > ('collections'). Do you have any apps that could be getting in the
> > way? Does the error occur with all your projects?
>
> > Stephen
>
> > On 30 Aug 2010, at 17:35, Tim wrote:
>
> > > I'm on the latest trunk (updated this morning), and I'm getting a
> > > Python NameError in django.core.cache.backends.db . Line 127 (http://
> > > code.djangoproject.com/browser/django/trunk/django/core/cache/
> > > backends/
> > > db.py#L127) references a variable 'table', but it's not locally
> > > defined. All other methods in the CacheClass first do the following
> > > line before such use:
>
> > > table = connections[db].ops.quote_name(self._table)
>
> > > Has anybody else run into this problem in runtime? I was surprised
> > > that the error was legitimately happening in the core code.
>
> > > --
> > > 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
> > > athttp://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: a new template algorithm
At first let me say that I really appreciate your reply! Thanks.
On Aug 30, 6:48 pm, Tim wrote:
> Alex briefly mentioned the design decision of the template system, but
> I think it'd be good to emphasize his point-- Django was designed to
> have various layers, such as the urls, the views, the templates, etc.
> If you think about it, different people within a large project could
> actually be in charge of different layers, free to change certain
> things without breaking the other layers. If the templates make
> proper use of the {% url %} templatetag, a urls designer can make
> small changes the URL structure without breaking the site at all.
Yes, I understand that. I've just sent you what I did just because I
think it's
interesting and if you had found it interesting too you could include
(the way
was completely in your hands) in the project. I thought issues related
to
backward compatibility and "python syntax for non python programmers"
could
be solved quite easily.
What I'm trying to say is that my sending you the template engine I
developed
was something like "Hey guys, I did this, are you interested?", in a
full open
source philosophy.
I'm using it currently in my sites and I think it's very easy,
powerful and
quick to develop, and no one of the template engines (Tornado, ...)
use this
algorithm, so I'll sure keep using my django patched version.
Thanks,
Gabriele
--
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: a new template algorithm
On Mon, Aug 30, 2010 at 7:31 PM, gabriele wrote:
> At first let me say that I really appreciate your reply! Thanks.
>
> On Aug 30, 6:48 pm, Tim wrote:
> > Alex briefly mentioned the design decision of the template system, but
> > I think it'd be good to emphasize his point-- Django was designed to
> > have various layers, such as the urls, the views, the templates, etc.
> > If you think about it, different people within a large project could
> > actually be in charge of different layers, free to change certain
> > things without breaking the other layers. If the templates make
> > proper use of the {% url %} templatetag, a urls designer can make
> > small changes the URL structure without breaking the site at all.
>
> Yes, I understand that. I've just sent you what I did just because I
> think it's
> interesting and if you had found it interesting too you could include
> (the way
> was completely in your hands) in the project. I thought issues related
> to
> backward compatibility and "python syntax for non python programmers"
> could
> be solved quite easily.
>
> What I'm trying to say is that my sending you the template engine I
> developed
> was something like "Hey guys, I did this, are you interested?", in a
> full open
> source philosophy.
> I'm using it currently in my sites and I think it's very easy,
> powerful and
> quick to develop, and no one of the template engines (Tornado, ...)
> use this
> algorithm, so I'll sure keep using my django patched version.
>
> Thanks,
> Gabriele
Gabriele;
Will you post your code on a site like BitBucket or GitHub? While it might
not be accepted into Django proper, another template engine is always a good
exercise for everyone to take a look at. It also sounds like you found some
possible Django bugs, which would be nice to get those filed for the
maintainers, either you can file tickets or if you post the code, the
community can.
Thanks,
Michael
--
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: a new template algorithm
On Sat, Aug 28, 2010 at 10:47 PM, Gabriele Fantini
wrote:
> Hi,
>
> I've just joined this group. The reason is that I've recently
> developed a new django template system (and I'm still working on it)
> and I'm currently using it for my new sites.
> I hope this is the right place to discuss of such things.
>
> This is the basic idea of my templates:
>
> * The Template class turned into a Python code generator
> * The compilation of a template string (Template.compile_string
> method) consists in the generation of python code that when will be
> evaluated will generate the html source.
>
> Basic steps of the algorithm are:
> * When a template rendering is required, a new Template instance is created.
> * The __init__ method generates a python code, compiles it using
> compiler.compile (python compiled module) and stores the result in a
> class attribute `__compiled` (the standard Template class instead
> generates and store the nodelist)
> * As the rendering is requested the previously compiled python
> code is evaluated using builtin function `eval`, passing context as
> "globals" environment ( eval(compiled, context) ).
>
> Pros of this solution:
> * The implementation is clear and short; 250 lines of code do the magic
> All the statements are exactly the python statements
>
> * Python code and HTML/CSS/Javascript can be mixed together
>
> * No more need to extend with tags and filters; you can use all that
> python provides and extend with modules.
> You can do things like:
> 1) for statement example:
> {% for i in [1, 2, 3] %} {{i}}{% end %}
>
> 2)
> {% for k, v in {'a': 1, 'b': 2} %}
> {{k}} {{v}}
> {% end %}
>
> 3) import a module and use it
> {% import datetime%}
> {{ datetime.datetime.utcnow().isoformat() }}
>
> 4) define functions (and classes) and use it
> {% def myfunction(arg) %}
> return arg.lower()
> {% end %}
> {{ myfunction("TEST STRING") }}
>
> * The only things that were missing were the django specific
> statements (extends, block, ...)
>
> * A new "block" type called "fblock" as been introduced; it is like a
> block that can have arguments.
>
> Well, this is in brief the idea, it can do much more.
> I hope I explained it clearly.
> You can find attached the patch from the latest version 1.2.1 and also
> a test site that shows the power of this solution.
>
> The patch also include:
> 1) A bug fix for the makemessages: code syntax for the xgettext was
> Perl instead of Python
> 2) A compiled template cache
> 3) A few lines changes in order to obtain the exception class in the
> 500 error handler (so that the 500 page message can be exception
> dependent)
>
> If you find this interesting we can work to include it in the django
> repository as an alternative from the current template system.
> Otherwise I'll keep it for my own use.
> The template syntax has a few changes but the backward compatibility
> can be improved.
> If someone wants to try it and have problems or questions I'll be glad
> to answer to any question.
> I can send an already patched version if someone want it.
>
> Hope to have feedback soon,
> Gabriele
Hi Gabriele,
Why you patched Django instead of making a connector so everyone would
be able to use your template engine without patching django?
Looking at your django patch, you also seems to have a typo in your
Http500 page rewrite:
-Request Method: {{ request.META.REQUEST_METHOD }}
-Request URL: {{ request.build_absolute_uri|escape }}
+Request Method: {{ request.META['RQUEST_METHOD'] }}
+Request URL: {{ escape(request.build_absolute_uri) }}
>From the engineering point of view, you did nothing important. In
fact, I think, you did a bad thing to Django:
By increasing the number of incompatible template engines for django,
you fraction the user base of each one, so you decrease the overall
quality of Django solutions, and Django plugins won't be that good (if
they provide any templates). I believe, new template engine should be
made only if it will be much better than old one (i.e, look at Razor
template engine from Microsoft ASP.NET team).
Your work also makes me think you haven't ever heard of Jinja2 and
Mako, both of which already do what you need (python programming in
templates), but have good documentation and have proper way to connect
to Django.
>From the teenager point of view, look, you created new cool template
engine! Wow! You rock!
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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-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.
