Re: Any interest in adding a short form for template comments?

[Alex Gaynor]

On Sat, May 14, 2011 at 11:16 PM, br  wrote:

> Pretty new to django. While {% comment %}  {% endcomment %}  isn't
> that cumbersome, its cumbersome enough compared to  that I
> find myself using html comments more often than I should (given that
> these comments will end up in my output), largely because i'm too lazy
> to type out the full django comment tags.  I'm sure I'm not the only
> one.
>
> I'm not familiar with the internals of the parser, but maybe something
> like {%-- Insert your comment here --%}, akin to jsp's <%-- --%>
> comments, or something similarly concise.
>
> Regards,
>
> Ben
>
> --
> 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.
>
>
What's wrong with {# comment goes here #}

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

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

Any interest in adding a short form for template comments?

[br]

Pretty new to django. While {% comment %}  {% endcomment %}  isn't
that cumbersome, its cumbersome enough compared to  that I
find myself using html comments more often than I should (given that
these comments will end up in my output), largely because i'm too lazy
to type out the full django comment tags.  I'm sure I'm not the only
one.

I'm not familiar with the internals of the parser, but maybe something
like {%-- Insert your comment here --%}, akin to jsp's <%-- --%>
comments, or something similarly concise.

Regards,

Ben

-- 
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: Fwd: Fwd: Feature request: log capture during testing

[Luke Plant]

This is a slightly confusing set of messages to be forwarded to
django-devs - please remember that django-devs has over 6000 subscribers
who probably don't want to have to put together fragments of a private
conversation!

But the original message from Jody was sent 2 weeks ago to django-devs,
and probably wasn't properly answered, so I'll do that here:

1) testfixtures and log_capture are things that we know nothing about,
as they are not part of Django, so bugs in them shouldn't be reported here.

2) if there is still a feature request that is valid, please file a
ticket on our tracker - http://code.djangoproject.com/newticket

Thanks,

Luke


On 14/05/11 18:04, Chris Withers wrote:
> Hey Jody/Django Devs,
> 
> A friend of mine saw this go by and forwarded on to me.
> 
> testfixtures is actively maintained and, while I don't use filters
> myself, I consider it a bug that this doesn't work as you expect!
> 
> Can you email me a sample unit test that doesn't work properly and I'll
> get this fixed?
> 
> cheers,
> 
> Chris
> 
>  Original Message 
> Subject: Feature request: log capture during testing
> Date: Fri, 29 Apr 2011 12:20:25 -0700 (PDT)
> From: Jody McIntyre 
> Reply-To: django-developers@googlegroups.com
> To: Django developers 
> 
> Now that Django has logging support using the Python logging module,
> it would be nice if the unit testing framework included the ability to
> capture logs, similarly to the mail.outbox functionality.
> 
> I am aware of the log_capture decorator in the testfixtures package,
> and we are using it for some tests.  Unfortunately, it doesn't
> correctly capture anything that's been changed by a filter, since it
> installs itself as a handler without preserving filters attached to
> existing handlers.  It would be great if Django could do better!
> 
> Cheers,
> Jody
> 


-- 
"Procrastination: Hard work often pays off after time, but laziness
always pays off now." (despair.com)

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

Fwd: Fwd: Feature request: log capture during testing

[Chris Withers]

Hey Jody/Django Devs,

A friend of mine saw this go by and forwarded on to me.

testfixtures is actively maintained and, while I don't use filters 
myself, I consider it a bug that this doesn't work as you expect!


Can you email me a sample unit test that doesn't work properly and I'll 
get this fixed?


cheers,

Chris

 Original Message 
Subject: Feature request: log capture during testing
Date: Fri, 29 Apr 2011 12:20:25 -0700 (PDT)
From: Jody McIntyre 
Reply-To: django-developers@googlegroups.com
To: Django developers 

Now that Django has logging support using the Python logging module,
it would be nice if the unit testing framework included the ability to
capture logs, similarly to the mail.outbox functionality.

I am aware of the log_capture decorator in the testfixtures package,
and we are using it for some tests.  Unfortunately, it doesn't
correctly capture anything that's been changed by a filter, since it
installs itself as a handler without preserving filters attached to
existing handlers.  It would be great if Django could do better!

Cheers,
Jody

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


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

--
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: RFC: Composite fields API

[Luke Plant]

On 12/05/11 12:41, Michal Petrucha wrote:

> 1) Leave out the ``unique`` option and live with ``unique_together``.
>This would pribably imply also leaving out ``db_index``, otherwise
>the API would be a complete mess.
> 
> 2) Allow ``CompositeField.unique`` but also keep ``unique_together``.
>The problem I see with this approach is that there would be two
>quite different ways to achieve the same effect.
> 
> 3) Make ``CompositeField.unique`` the way to go and deprecate
>``unique_together``.
>This way, specifying a unique constraint on a tuple of fields would
>work the same way it works on single fields which is IMO a
>significant benefit. There's, however, the issue of breaking
>backwards compatibility. Furthermore, one would have to add a new
>field, albeit virtual, just to create a simple constraint, which
>may seem weird to some.

I'd go with (2), we can easily live with these two different ways to do
something, because, from a given starting point, there is actually only
"one obvious way" to achieve what you want i.e. if you have a composite
field already, there is one obvious way to make it unique, and if you
have two separate fields, there is one obvious way to make them 'unique
together'.

> I'm also thinking about implementing an abstract class, VirtualField.
> This could be useful mainly as a base class for fields with no direct
> database column. That means, it would mainly handle things like
> add_to_class (adding itself to the list of virtual fields instead of
> local ones), specifying arbitrary lookup filters when asked for one
> etc. CompositeField could then be a descendant of this class.
> 
> However, I can't currently imagine any other use-case for this
> abstract class than CompositeField. The question is, then, is there
> any interest in having an abstract mechanism like this? Can anyone
> imagine a use-case? (The question is, should I implement this
> functionality directly inside CompositeField or factor it out into
> something more general?)

Feel free to make such a class if it makes development easier, but keep
it private/undocumented until we have at least 2 use cases.

Luke

-- 
"Procrastination: Hard work often pays off after time, but laziness
always pays off now." (despair.com)

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-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: RFC: Composite fields API

[Michal Petrucha]

> > 2) Allow ``CompositeField.unique`` but also keep ``unique_together``.
> >The problem I see with this approach is that there would be two
> >quite different ways to achieve the same effect.
> 
> I agree with Javier - I favor option 2. In my mind, although the final
> result at the database level may be the same (a unique index across
> multiple database columns), in conceptual terms at the ORM level it is
> really two different things. There are many cases where I want to
> specify that two fields should be unique together, but they really are
> two separate fields; I'm never going to want to access it as a single
> field or composite value. In this case, specifying a CompositeField
> would confuse the intent and be more verbose than unique_together. I
> think the conceptual distinction is clear, and it will actually be less
> confusing to users to have both options available than to have
> CompositeField become the only way to specify an index on multiple columns.

One point I forgot to mention in the original e-mail is that there
would be an inconsistency: creating a unique index will be possible
using either a unique CompositeField or unique_together where as a
non-unique index will be possible only with an explicit
CompositeField. At least as far as I know there is currently no option
to create a non-unique index over several columns.

> > One minor detail, should the field silently ignore invalid options or
> > should it issue warnings?
> 
> Explicit is better than implicit, and errors should never pass silently
> unless explicitly silenced. If the option is invalid, it should not just
> be a warning, it should be an outright failure (though if the check is
> expensive, it could possibly happen in model-validation rather than
> always at runtime).

Thanks for the pointer, model validation looks like the right place
for this.

> I mentioned this in an earlier thread, but I'd really like to see the
> API allow me to specify my own class as the value class, as long as it
> satisfies some basic API requirements. In my mind the long-term goal
> here is that GFKs should be reasonably implementable as a CompositeField
> or a CompositeField subclass without exploiting undocumented internal APIs.
> 
> If there are implementation complexities that push this feature out of
> scope for GSoC, that's fine - but I want to make sure we don't make that
> future expansion difficult by design choices we make now.

I'll make it possible to insert custom hooks into the
assignment/retrieval routines which should be sufficient for the
purposes of GFKs.

> [...]
> > I'm also thinking about implementing an abstract class, VirtualField.
> > This could be useful mainly as a base class for fields with no direct
> > database column. That means, it would mainly handle things like
> > add_to_class (adding itself to the list of virtual fields instead of
> > local ones), specifying arbitrary lookup filters when asked for one
> > etc. CompositeField could then be a descendant of this class.
> > 
> > However, I can't currently imagine any other use-case for this
> > abstract class than CompositeField. The question is, then, is there
> > any interest in having an abstract mechanism like this? Can anyone
> > imagine a use-case? (The question is, should I implement this
> > functionality directly inside CompositeField or factor it out into
> > something more general?)
> 
> I wouldn't spend time on something we don't have any use case in mind
> for (unless making this split makes the code easier to read and
> understand). This is something that most likely could easily be done
> later, if we find we need it.

Fair enough, unless it turns out to be a better approach anyway. (-:

Michal


signature.asc
Description: Digital signature

Re: Test optimizations (2-5x as fast)

[Jonas H.]

On 05/14/2011 04:26 PM, Jonas H. wrote:

I believe there's no generalized way of creating databases in Django
now, so that would have to be added.


s/creating/copying/

--
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: Test optimizations (2-5x as fast)

[Jonas H.]

How about caching the test databases? The database state could be cached 
after model setup (which takes some time if you've got lots of them) + 
initial data fixture setup, and after the setup for each test case 
(fixtures + setUp() method).


So, in the best case, no database setup is required at all to run tests 
-- which encourages test driven development :-)


I believe there's no generalized way of creating databases in Django 
now, so that would have to be added.


I'd love to hack on that :-)

Jonas

--
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: RFC: Composite fields API

[Michal Petrucha]

On Fri, May 13, 2011 at 09:01:19AM -0700, onelson wrote:
> I'm not that familiar with GFK's and how they work in django, but I just 
> wanted to check... 
> Will we have (non-generic) FK support for this, or is that another 
> can-o-worms that won't get touched for some time?

Adding support for composite PK targets into related fields (i. e.
ForeignKey, OneToOne and ManyToMany) is something I intend to devote
the whole second half of the program to. That means, if all goes well,
this should be all right by the end of this summer.

Michal


signature.asc
Description: Digital signature

Re: Re : [GSoC form rendering] Weekly check-in -1.0

[Gregor Müllegger]

Thanks Mathieu,

I already knew this library, however I wanted to have a quick implementation
that doesn't use classytags or any other thirdclass library. But thanks to
your link I looked in the documentation of sekizai again and saw the
restrictions page [1]. And after having a look at the my sample
implemenation... I think we obviously experiencing the same.

I need to investigate a bit more here and see how we can deal especially
with the limitation that the {% media %} tag might not be usable inside a
block tag.
Maybe we can also trick the parser here a bit, but this would result in a
pretty hacky solution that also will likely break anyway when Armin exchanges
the parser with a new implementation.

[1] http://django-sekizai.readthedocs.org/en/latest/restrictions.html

--
Servus,
Gregor


2011/5/14 Mathieu AGOPIAN :
> Hello Gregor,
>
> just FYI, one of the guy from django-cms created django-sekizai, which is
> used just for that (injecting stuff in template blocks) :
> https://github.com/ojii/django-sekizai
>
> Mathieu
>
> --
> 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-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.