Re: I am interested in maintaining django-localflavor-us

[Trey Hunner]

I'm treyhunner on Github.  Thanks Jacob.

On Monday, May 20, 2013 3:14:59 PM UTC-7, Jacob Kaplan-Moss wrote:
>
> No objections from me. What's your GitHub username? I'll hook you up. 
>
> Jacob 
>
> On Mon, May 20, 2013 at 3:10 PM, Trey Hunner 
> > 
> wrote: 
> > The django-localflavor-us package currently lacks a responsive 
> > maintainer.  I would like to fix this problem by helping to maintain 
> > this project. 
> > 
> > My primary goals: 
> > 
> > * Make the tests easier to run 
> > * Merge good pull requests 
> > * Add instructions for contributing (namely how to run the tests) 
> > * Ensure the project stays up-to-date on PyPI 
> > 
> > I already uploaded the project to PyPI.  I can't help much more 
> > currently without commit access or someone with commit access to 
> > comment on and merge pull requests. 
> > 
> > -- 
> > Trey Hunner 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-develop...@googlegroups.com . 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > Visit this group at 
> http://groups.google.com/group/django-developers?hl=en. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: I am interested in maintaining django-localflavor-us

[Jacob Kaplan-Moss]

No objections from me. What's your GitHub username? I'll hook you up.

Jacob

On Mon, May 20, 2013 at 3:10 PM, Trey Hunner  wrote:
> The django-localflavor-us package currently lacks a responsive
> maintainer.  I would like to fix this problem by helping to maintain
> this project.
>
> My primary goals:
>
> * Make the tests easier to run
> * Merge good pull requests
> * Add instructions for contributing (namely how to run the tests)
> * Ensure the project stays up-to-date on PyPI
>
> I already uploaded the project to PyPI.  I can't help much more
> currently without commit access or someone with commit access to
> comment on and merge pull requests.
>
> --
> Trey Hunner
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

I am interested in maintaining django-localflavor-us

[Trey Hunner]

The django-localflavor-us package currently lacks a responsive
maintainer.  I would like to fix this problem by helping to maintain
this project.

My primary goals:

* Make the tests easier to run
* Merge good pull requests
* Add instructions for contributing (namely how to run the tests)
* Ensure the project stays up-to-date on PyPI

I already uploaded the project to PyPI.  I can't help much more
currently without commit access or someone with commit access to
comment on and merge pull requests.

--
Trey Hunner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Keep template tags grammar (for simple_tag, assignment_tag and inclusion_tag. Extend with block_tag). Ticket 20434 and 20435.

[Jonathan Slenders]

Hi all,

For being able to do AST manupulations on templates we need to keep the 
grammar of templatetags somewhere.
During the sprints, Russel told me to attach these as a property on the 
functions that go into Library.tags. (I would attach an instance of a class 
named TemplateTagMeta.)

For those who wonder what the applications are. They are mainly for 
template preprocessing, HTML validation, and code completion in editors, 
when writing Django templates.

For simple_tag, assignment_tag and inclusion tag. The grammar rules are 
easy.
For any other custom tag it's right now impossible to extract the grammar.

The reason is mainly that it is too complicated to define custom template 
tags which consist of an open/close tag.
It should certainly not be necessary to touch the (parser, token) tuple.

I propose that we introduce a new, more user-friendly way of defining these 
tags. I created register.block_tag, but I'm not sure about the API. This 
works, and it's is all we need for the built-in "if" template tag.


@register.block_tag('if elif* else? endif')
def do_if(parser, blocks):
conditions_nodelists = []
for name, bits, nodelist in blocks:
if name in ('if', 'elif'):
condition = TemplateIfParser(parser, bits).parse()
else:
condition = None
conditions_nodelists.append( (condition, nodelist) )

return IfNode(conditions_nodelists)


The advantage is that it's both much more easy to write custom template 
tags which have one or more "bodies", and that this declaration allows us 
to extract the grammar rules of templates. (Which can be used for 
preprocessing, or HTML validation.)

Note that we don't deprecate the old way of writing template tags. It's a 
public API. But we should discourage custom token/parser manupulation in 
custom template tags. 

- What do you think about the name "block_tag"? I'm not sure. 
tag_with_grammar is too long, and the tag function itself cannot be changed 
anymore.
- What do you think about the syntax of the grammar. The space-separated 
notation is more often used in the Python core.
- Is the "parser" parameter really necessary. At least we need it in 
TemplateIfParser. But Why?
- register.block_tag works as well if the templatetags don't have a body. 
In that case, there's only one iteration through blocks, where nodelist is 
an empty list. Would this imply we need another name for "block_tag" or 
not? Otherwise we need something else for -- for instance -- the csrf_token 
template tag.

I'd also like to add a new management command to Django which prints the 
AST for templates. But in a human readable way. I think this would help a 
lot for developers to understand how the template tags of third party 
libraries work. And further, it would make it easier for people to write 
autocompletion plug-ins for a lot of editors.
What do you think would be good as a format, maybe the following?


if elif* else? endif
for empty? endfor
...

...


Further, the following line does not say anything about the template tag 
parameters. 
@register.block_tag('if elif* else? endif')

Should we add some syntax to tell which template tags have or don't have 
any parameters, or leave that to the implementation of block_tag?


Cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: Support for HTTP PATCH method

[Andrey Antukh]

+1 Many times I had to add this method to the test client.


2013/5/20 Krzysztof Jurewicz 

> There is a RFC describing HTTP method named PATCH:
>
> http://tools.ietf.org/html/**rfc5789 
>
> Quoting that RFC:
> “  The difference between the PUT and PATCH requests is reflected in the
>way the server processes the enclosed entity to modify the resource
>identified by the Request-URI.  In a PUT request, the enclosed entity
>is considered to be a modified version of the resource stored on the
>origin server, and the client is requesting that the stored version
>be replaced.  With PATCH, however, the enclosed entity contains a set
>of instructions describing how a resource currently residing on the
>origin server should be modified to produce a new version.”
>
> Django currently has (seemingly shallow) support for PUT method. Based on
> that, I’ve grepped for places in code where it is implemented to see if
> support for PATCH could be easily added on a basis of symmetry. Those
> places are:
>
> In test client:
> There is a `put` method, but `patch` is also implemented:
> https://github.com/django/**django/commit/**293f7a21147ad94c92c7d5b3f33cba
> **b2f87b001b
>
> In View class:
> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d**
> 73b9d46476/django/views/**generic/base.py#L33
> `put` is listed in http_method_names
>
> In RedirectView:
> `put` is a fallback to .get():
> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d**
> 73b9d46476/django/views/**generic/base.py#L207
>
> In ProcessFormView:
> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d**
> 73b9d46476/django/views/**generic/edit.py#L164
> PUT is implemented as a fallback to POST and it seems to assume that
> request data is form encoded. While it is not generally true for PUT
> method, it looks like a reasonable assumption when processing a form.
> However since PATCH request doesn’t have to contain full form data, I think
> the best approach may be to not implement `patch` method here (unless we
> want to deal with editing only some of the form’s fields – for example this
> is the case in Rails, where PATCH will be the primary method for updates in
> 4.0 version: http://weblog.rubyonrails.org/**
> 2012/2/25/edge-rails-patch-is-**the-new-primary-http-method-**for-updates/).
>  The same stays true to `get_form_kwargs` method in FormMixin:
> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d**
> 73b9d46476/django/views/**generic/edit.py#L44
> In general, Django’s approach to whether PUT should be treated as a
> request containing form data seems to be inconsistent because we generate
> forms in the views, but we refuse to generate PUT QueryDict on a request
> object: https://groups.google.com/d/**msg/django-developers/**
> dxI4qVzrBY4/m_9IiNk_p7UJ.
>  So maybe it’s worth to consider removing PUT support in form processing
> just on the basis of consistency.
>
> In conclusion, it seems pretty easy to add basic PATCH support similar to
> PUT. So if it gets enough +1s, I’m willing to make a patch and hope it gets
> included in 1.6 alpha. Or maybe it is (from a technical point of view) so
> small a feature that it doesn‘t need to be merged before alpha release?
> --
> Krzysiek
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> django-developers+unsubscribe@**googlegroups.com
> .
> To post to this group, send email to 
> django-developers@**googlegroups.com
> .
> Visit this group at http://groups.google.com/**
> group/django-developers?hl=en
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>


-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" gro

Proposal: Support for HTTP PATCH method

[Krzysztof Jurewicz]

There is a RFC describing HTTP method named PATCH:

http://tools.ietf.org/html/rfc5789

Quoting that RFC:
“  The difference between the PUT and PATCH requests is reflected in the
   way the server processes the enclosed entity to modify the resource
   identified by the Request-URI.  In a PUT request, the enclosed entity
   is considered to be a modified version of the resource stored on the
   origin server, and the client is requesting that the stored version
   be replaced.  With PATCH, however, the enclosed entity contains a set
   of instructions describing how a resource currently residing on the
   origin server should be modified to produce a new version.”

Django currently has (seemingly shallow) support for PUT method. Based 
on that, I’ve grepped for places in code where it is implemented to see 
if support for PATCH could be easily added on a basis of symmetry. Those 
places are:


In test client:
There is a `put` method, but `patch` is also implemented:
https://github.com/django/django/commit/293f7a21147ad94c92c7d5b3f33cbab2f87b001b

In View class:
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L33
`put` is listed in http_method_names

In RedirectView:
`put` is a fallback to .get():
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L207

In ProcessFormView:
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L164
PUT is implemented as a fallback to POST and it seems to assume that 
request data is form encoded. While it is not generally true for PUT 
method, it looks like a reasonable assumption when processing a form. 
However since PATCH request doesn’t have to contain full form data, I 
think the best approach may be to not implement `patch` method here 
(unless we want to deal with editing only some of the form’s fields – 
for example this is the case in Rails, where PATCH will be the primary 
method for updates in 4.0 version: 
http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/ 
). The same stays true to `get_form_kwargs` method in FormMixin:

https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L44
In general, Django’s approach to whether PUT should be treated as a 
request containing form data seems to be inconsistent because we 
generate forms in the views, but we refuse to generate PUT QueryDict on 
a request object: 
https://groups.google.com/d/msg/django-developers/dxI4qVzrBY4/m_9IiNk_p7UJ 
. So maybe it’s worth to consider removing PUT support in form 
processing just on the basis of consistency.


In conclusion, it seems pretty easy to add basic PATCH support similar 
to PUT. So if it gets enough +1s, I’m willing to make a patch and hope 
it gets included in 1.6 alpha. Or maybe it is (from a technical point of 
view) so small a feature that it doesn‘t need to be merged before alpha 
release?

--
Krzysiek

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Andrew Godwin]

Of course, the long-term solution for this is probably migrations. The
post_syncdb signal already causes me problems - as there's no good
definition for it with migrations around (you basically have to send it
right at the end for every model you think you touched).

However, the patch Donald linked would be a lot easier to emulate, so I'm
not that against it.

Andrew


On Sat, May 18, 2013 at 7:15 PM, Donald Stufft  wrote:

> There's already a patch on the ticket tracker for a pre_syncdb signal, and
> yesterday I started updating it and modifying it a bit as I needed this
> signal.
>
> https://github.com/dstufft/django/compare/pre-syncdb-signal
>
> On May 18, 2013, at 1:06 PM, Karol Sikora  wrote:
>
> I can try to implement approach with pre_syncdb signal tomorrow. I think
> that is quite enough solution before deeper diggling into new migrations
> framework.
>
> Karol
> 18 maj 2013 19:03, "Anssi Kääriäinen" 
> napisał(a):
>
>> On 16 touko, 11:20, Danilo Bargen  wrote:
>> > As a sidenote, there was a discussion about this on this mailing list a
>> few
>> > months ago:
>> >
>> > https://groups.google.com/forum/#!searchin/django-developers/16550/dj.
>> ..
>>
>> I think a pre_sync signal is best approach. The signal should be
>> called either just after connecting to the (test) DB in syncdb
>> command, or maybe just after existing tables have been introspected so
>> that you know what tables are already there. Latter might be better as
>> syncdb can be ran multiple times, and you only need to CREATE
>> EXTENSION on initial sync. OTOH if you add one more model with
>> JSONField it seems you would need to run another CREATE EXTENSION, or
>> to investigate if some existing model has already ran CREATE
>> EXTENSION. So, defensive coding (that is, CREATE EXTENSION IF NOT
>> EXISTS) would be needed.
>>
>> Another problem is that post_syncdb is called from flush command, too.
>> This seems wrong. Could we just add post_flush signal and send that
>> instead? Another option is to add a "for_flush" kwarg to the signal
>> parameters, but it feels just so wrong to have post_syncdb signal with
>> an argument that tells syncdb didn't happen after all. The reason for
>> post_syncdb from flush is creation of ContentTypes and Permissions
>> after truncation of those tables.
>>
>> While the pre_syncdb signal approach has many shortcomings (how to
>> include the output in sqlall?), I think it is enough to solve this
>> problem for now. You can run CREATE EXTENSION IF NOT EXISTS and that
>> seems already a big step forward. Also, distinguishing post_flush from
>> post_syncdb seems like a good idea, but should be done in separate
>> ticket.
>>
>> Later on migrations framework could offer a much better solution to
>> this. But pre_syncdb signal seems small enough to include already in
>> 1.6. Maybe this could be done in the sprints?
>>
>>  - Anssi
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.