Re: contrib.admindocs need some love.
On Thu, Aug 27, 2009 at 5:03 PM, Alex Gaynor wrote: > > On Thu, Aug 27, 2009 at 4:03 PM, Justin Lilly > wrote: > > Hey guys. > > > > I started writing some docs for another developer today and hit a few > > issues with admindocs that I plan on sprinting on for DjangoCon. I'm > > hoping anyone else with complaints / ideas will voice up, though my main > > impetus for the post is to announce that I'm going to do it so I > > can't back out. ;) > > > > Things I plan to address: > > > > 1. No tests. > > 2. No docs. > > 3. You can't seem to cross-link to views without the link being > > app.package.func . I'd like to see it at least configurable. > > I've actually got a patch that fixes this on my github django repo in > the "admindocs" branch. > > > 4. ManyToManyFields don't show up. > > > > I don't see this problem, for example User/Group show the relationship > in both directions correctly, since you clearly don't see it there's > probably some more debugging work needed here to figure it all out. Yea, James committed this before 1.1 went out. http://code.djangoproject.com/changeset/11128 http://code.djangoproject.com/changeset/11127 Cheers, Eric --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django.template refactoring (again) #7806
The proposal and motivation are essentially the same as in the last
thread [1] and the ticket description [2]. I put it on the 1.2 feature
list.
I tried to split my patch into smaller, more readable commits here:
http://github.com/emulbreh/django/tree/master
I haven't converted defaulttags, loadertags and django.templatetags.*
yet to show that it's (mostly) backwards compatible (see below). It
would be useful to decide on some questions in the "API Design .."
section below first.
I'll summarize the core ideas again as well as problems and pending
design decisions.
Concepts: Expressions and TokenStream
=
Variable and FilterExpression will be deprecated as they require the
caller to know the length of the expression in advance. This makes
whitespace handling cumbersome and some syntactical constructs really
hard to parse (e.g., the {% url ... %} parser is broken by design).
Instead there would be a tokenizer (currently named TokenStream) that
lets you read expressions from a stream of tokens - this would replace
Token.split_contents().
>>> bits = TokenStream(p, 'url views.client_action
id=client.id,action="update",num=3').tokens; bits
[('name', 'url'), ('name', 'views.client_action'), ('name', 'id'),
('char', '='), ('name', 'client.id'), ('char', ','), ('name',
'action'), ('char', '='), ('string_literal', '"update"'), ('char',
','), ('name', 'num'), ('char', '='), ('numeric_literal', '3')]
Now, instead of explicitly constructing a FilterExpression object you
would simply call `bits.parse_expression()` and would get back an
object with a `.resolve(context)` method (a subclass of
django.template.expressions.Expression) that represents a Literal,
Variable (called Lookup), or FilterExpression. For compatibility
issues see "Variable vs FilterExpression" below.
A TokenStream can be read via the following api (the current stream
position is called `offset`).
Low level API
---
``def pop(self)``
Returns a pair (tokentype, lexeme) and offset+=1; tokentype is one of
"string_literal", "numeric_literal", "char", "name".
``def pop_lexem(self, match)``
Returns True and offset+=1 if the next token's lexeme equals `match`.
Returns False otherwise.
``def pop_name(self)``
Returns the next token's lexeme and offset+=1 if its tokentype is
"name". Returns None otherwise.
``def pushback(self)``
offset-=1
High level API
These methods raise TokenSyntaxError and leave offset untouched if
the expected result cannot be parsed.
Each accepts a boolean required=False kwarg which turns
TokenSyntaxErrors into TemplateSyntaxErrors if True.
``def parse_string(self, bare=False)``
Returns the value of the following string literal. If bare=True,
unquoted strings will be accepted.
``def parse_int(self)``
Returns the value of the following numeric literal, if it is an int.
``def parse_value(self)``
Returns an Expression that evaluates the following literal, variable
or translated value.
``def parse_expression(self)``
Returns an Expression that evaluates the following value or
filterexpression.
``def parse_expression_list(self, minimum=0, maximum=None, count=None)``
Returns a list `e` of expressions; minimum <= len(e) <= maximum.
count=n is a shortcut for minimum=maximum=n.
Variable vs FilterExpression
==
I could only find documentation for Variable. If the internally used
Parser.compile_filter() is indeed undocumented there is no official
way to use FilterExpression in custom tags. If that means that
FilterExpression.resolve() behaviour doesn't have to be backwards
compatible, that would help a lot ..
1.) Currently `Variable("unresolvable")` and
`FilterExpression("unresolvable", p)` resolve differently: Variable
raises VariableDoesNotExist and FilterExpression returns
TEMPLATE_STRING_IF_INVALID. Except when `ignore_failures=True` is
given. But `FilterExpression("foo|cut:unresolvable", p)` will again
raise VariableDoesNotExist - regardless of `ignore_failures=True`.
My Expression implementation unifies these behaviours: If any part of
an expression is unresolvable a LookupError will be raised.
`ignore_failures` will be deprecated but there's a resolve_safe()
method on the Expression base class that reads:
def resolve_safe(self, context, default=None):
try:
return self.resolve(context)
except LookupError:
return default
This would be a small backwards incompatible change. I have one
failing test (exception02) because the ExtendsNode implementation
depends on the current FilterExpression behaviour.
2.) Currently `Variable("a._hidden")` works - but
`FilterExpression("a._hidden", p)` raises a TemplateSyntaxError. This
would be unified: lookup parts may not start with an underscore. If
it's not acceptable to break bc here leading underscores might simply
be allowed.
3.) Numeric literals ending with "." are currently treate
Re: Feature proposal: Test client form value extraction
On Fri, Aug 28, 2009 at 4:11 PM, Joshua Russo wrote: > On Thu, Aug 27, 2009 at 10:39 PM, Forest Bond > wrote: > >> Hi, >> >> On Thu, Aug 27, 2009 at 07:42:24PM -0100, Joshua Russo wrote: >> > On Thu, Aug 27, 2009 at 6:22 PM, Forest Bond < >> for...@alittletooquiet.net> >> > wrote: >> > >> > Hi, >> > >> > On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote: >> > > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo < >> josh.r.ru...@gmail.com> >> > wrote: >> > > Ok, so I found that the way I was 'casting' the response object >> didn't >> > work. Is >> > > there no way to cast an instance of a base class to a child class >> in >> > Python? >> > > >> > > What I did was to create a class method on my child class that >> takes the >> > > current response instance and creates a copy of it using my new >> response >> > > object. >> > > >> > > http://dpaste.com/hold/86193/ >> > > >> > > Does this look appropriate, or is there a better way to do this? >> > >> > This should work: >> > >> > response.__class__ = TestHttpResponse >> > >> > >> > Nope, it resets the status_code. That's what I tried at first. >> >> Okay, you'd have to copy the class attributes, too. Or, you could just >> define a >> sub-class on-the-fly: >> >> class _TestHttpResponse(TestHttpResponse, response.__class__): >> pass >> >> response.__class__ = _TestHttpResponse >> >> I haven't tested this. > > > That might just work. I would need to to change the base class of > TestHttpResponse to Object, but then my class wouldn't (shouldn't) override > the status_code in the response class. Good idea. Though I may have to wait > until Monday to test it out. > > Thanks > Yup that works! Thanks! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Time frame for GSoC projects integration
Hi all, I'm sorry, probably everyone's busy with DjangoCon stuff, other projects, and spending their vacation times, but could anyone please tell me what's planned time frame for GSoC projects integration into Django if there's any. -- 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-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 -~--~~~~--~~--~--~---
Re: Time frame for GSoC projects integration
On Fri, Aug 28, 2009 at 10:09 AM, Yuri Baburov wrote: > but could anyone please tell me what's planned time frame for GSoC > projects integration into Django if there's any. There is no timeline I'm aware of. And, personally, I don't think there's a need for any sort of special process: these are pieces of work which can be proposed for inclusion in Django just like anything else. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Feature proposal: Test client form value extraction
On Thu, Aug 27, 2009 at 10:39 PM, Forest Bond wrote: > Hi, > > On Thu, Aug 27, 2009 at 07:42:24PM -0100, Joshua Russo wrote: > > On Thu, Aug 27, 2009 at 6:22 PM, Forest Bond > > > wrote: > > > > Hi, > > > > On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote: > > > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo < > josh.r.ru...@gmail.com> > > wrote: > > > Ok, so I found that the way I was 'casting' the response object > didn't > > work. Is > > > there no way to cast an instance of a base class to a child class > in > > Python? > > > > > > What I did was to create a class method on my child class that > takes the > > > current response instance and creates a copy of it using my new > response > > > object. > > > > > > http://dpaste.com/hold/86193/ > > > > > > Does this look appropriate, or is there a better way to do this? > > > > This should work: > > > > response.__class__ = TestHttpResponse > > > > > > Nope, it resets the status_code. That's what I tried at first. > > Okay, you'd have to copy the class attributes, too. Or, you could just > define a > sub-class on-the-fly: > > class _TestHttpResponse(TestHttpResponse, response.__class__): > pass > > response.__class__ = _TestHttpResponse > > I haven't tested this. That might just work. I would need to to change the base class of TestHttpResponse to Object, but then my class wouldn't (shouldn't) override the status_code in the response class. Good idea. Though I may have to wait until Monday to test it out. Thanks --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Time frame for GSoC projects integration
On Sat, Aug 29, 2009 at 2:35 AM, James Bennett wrote: > > On Fri, Aug 28, 2009 at 10:09 AM, Yuri Baburov wrote: >> but could anyone please tell me what's planned time frame for GSoC >> projects integration into Django if there's any. > > There is no timeline I'm aware of. And, personally, I don't think > there's a need for any sort of special process: these are pieces of > work which can be proposed for inclusion in Django just like anything > else. But who will propose these pieces and when? Are they ready for inclusion? Can I propose them for inclusion? I just don't understand who should do what right now, and if people do understand their, ehm, responsibilities and the whole process :) Just it seems I'm one of the persons interested in their soonest successful inclusion. -- 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-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 -~--~~~~--~~--~--~---
Re: Time frame for GSoC projects integration
On Fri, Aug 28, 2009 at 6:17 PM, Yuri Baburov wrote: > > On Sat, Aug 29, 2009 at 2:35 AM, James Bennett wrote: >> >> On Fri, Aug 28, 2009 at 10:09 AM, Yuri Baburov wrote: >>> but could anyone please tell me what's planned time frame for GSoC >>> projects integration into Django if there's any. >> >> There is no timeline I'm aware of. And, personally, I don't think >> there's a need for any sort of special process: these are pieces of >> work which can be proposed for inclusion in Django just like anything >> else. > > But who will propose these pieces and when? > Are they ready for inclusion? > Can I propose them for inclusion? > > I just don't understand who should do what right now, and if people do > understand their, ehm, responsibilities and the whole process :) > > Just it seems I'm one of the persons interested in their soonest > successful inclusion. > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com > > > > I imagine the projects will be proposed by the student and mentor responsible for them. Even for the projects that were very successful and got most (or all) of their work done there's probably stuff to be done to make it Django core ready. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: App Engine support
Hey hey, If we're gunna start talking about a more generic DB API then count me in! For what it's worth, I really think that a basic API that only supports a few simple operations (get, set, and delete, primarily) is the way to go. There's not enough commonality between datastores at a higher level than that. While you could "fake" some operations in code, I think that will end up causing problems. Trying to "fake" an order-by with a limit in a key-value store, for example, just seems like a bad idea. Also, if you're trying to make SimpleDB work with Django you might want to check out the python-simpledb client I wrote (http://github.com/sixapart/python-simpledb/tree/). Conceptually it's very similar to the Django ORM. We (Six Apart) also just released a package called remoteobjects that gives REST APIs a Django-ORM like interface. Might want to check that out too. http://github.com/sixapart/remoteobjects/tree/master Mike --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Time frame for GSoC projects integration
On Fri, Aug 28, 2009 at 2:35 PM, James Bennett wrote: > There is no timeline I'm aware of. And, personally, I don't think > there's a need for any sort of special process: these are pieces of > work which can be proposed for inclusion in Django just like anything > else. That's generally my feeling as well, but I'd like to in the near term get a feel for how close the SoC projects are to merging. In particular, I'd like to make 1.2 include all the mergeworthy SoC code, but I don't have a feel yet for how realistic that's going to be. There's going to be some (possibly complex) timing issues w/r/t merge conflicts between different branches, so doing things in the right order might become important. I'm going to be emailing students/mentors in the next couple-three days and trying to work out a loose gameplan here. However, James is completely right that there's not a big difference between this work and other stuff. IOW, the best way to make sure that SoC code gets back into Django is same as it ever was: use it, file bugs, patches, and when it's done tell us. Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
