Re: Bringing some popular must have django tools/packages under django org umbrella

[Matías Iturburu]

2016-03-16 12:39 GMT-03:00 James Pic :

> FTR, there's also Djangonauts which have been there for a while:
> https://github.com/djangonauts
>
>
This is exactly what I was asking for when I asked if there was an
organization to pick on unmaintained projects.
Thank you very much.


> Sorry, I tried not to look uncivil - and yet I fail to see where I
> was, but definitely re-reading and thinking about it (I'm not an
> english native speaker). Please anyone feel free to PM me and point me
> to where I was uncivil.
>
> Best ;)
>
> James
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALC3KadbC%2B5QcScijB1a0yRFwuS9%3DRgXBdk8HrHaNvBy1qdWRA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Matías Iturburu
http://www.linkedin.com/in/tutuca | http://ltmo.com.ar

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPy_ubZ2Vfn1CzHsS61x0uw%2BBTXDLqA5-2eS-yHAN7ApAnQ9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: FileField and ImageField

[Josh Smeaton]

It seems like you have a pretty good grasp on the problems and possible 
solutions. I'm not familiar enough with storage backends and FileFields to 
provide much guidance so hopefully someone else can comment. Regarding the 
linked line in the save method which forces forward slashes, it seems that 
the FileSystemStorage should be doing that, rather than the base Storage 
class. It looks like Storage tries to do too much, so pushing some 
behaviour back down to FileSystemStorage seems correct. Again though, we 
have to be wary of backwards compatibility. You could offer opt-in to more 
correct behaviour while deprecating the status quo. Something like a 
`normalize_slashes = True` that can be flipped to False for brand new code.

On Thursday, 17 March 2016 14:30:43 UTC+11, Cristiano Coelho wrote:
>
> I agree with you, generate_filename should just call the field upload_to 
> and then delegate the whole name generation to the storage.
>
> There's another thing about file storage that is troubling me: 
> https://github.com/django/django/blob/master/django/core/files/storage.py#L57
>
> The docs state you are not suposed to override the save method and just 
> implement _save, however, doing a complete random rename at the send pretty 
> much forces you to always override save instead. That name replacement is 
> probably to save the file name in a way you can easily create the URL, but 
> again, that should be delegated to the storage.url method shouldn't it?
>
> There's one more thing I noticed (gonna open a ticket about this one) is 
> that the proxy class for FileField (FieldFile, what a name!) states in the 
> docs that in order to call its save method you need a django File object 
> rather than a simple file-like object, I can understand that's because the 
> save method uses the .size property (
> https://github.com/django/django/blob/master/django/db/models/fields/files.py#L92)
>  
> to save the file size into a _size variable. It doesn't seem anywhere in 
> the code the _size is being used as size is a property that gets the file 
> size either from the storage class or the actual file. So removing that 
> line, could also allow us to use normal files in the save method.
>
> El miércoles, 16 de marzo de 2016, 23:41:58 (UTC-3), Josh Smeaton escribió:
>>
>> It seems like FileField should delegate some of these methods to an 
>> underlying Storage backend, no? I don't know what the implications to 
>> back-compat would be, but the idea seems like a sensible one to start with. 
>> The storage backend API may need to grow some additional methods to 
>> verify/validate paths and filenames or it might already have the correct 
>> methods needed for FileField to work. Fields should do all of their 
>> path/storage IO via their storage object though.
>>
>>
>> On Thursday, 17 March 2016 12:16:00 UTC+11, Cristiano Coelho wrote:
>>>
>>> To add a bit more about this, it seems that FileField is really meant to 
>>> be working with an OS file system, making it harder to use a custom Storage 
>>> that sends data to somewhere like AWS S3 where basically everything is a 
>>> file (there are no real folders, just key prefixes)
>>>
>>> These 3 functions inside FileField are the culprits:
>>>
>>> def get_directory_name(self):
>>> return 
>>> os.path.normpath(force_text(datetime.datetime.now().strftime(force_str(self.upload_to
>>>
>>> def get_filename(self, filename):
>>> return 
>>> os.path.normpath(self.storage.get_valid_name(os.path.basename(filename)))
>>>
>>> def generate_filename(self, instance, filename):
>>> # If upload_to is a callable, make sure that the path it returns is
>>> # passed through get_valid_name() of the underlying storage.
>>> if callable(self.upload_to):
>>> directory_name, filename = 
>>> os.path.split(self.upload_to(instance, filename))
>>> filename = self.storage.get_valid_name(filename)
>>> return os.path.normpath(os.path.join(directory_name, filename))
>>>
>>> return os.path.join(self.get_directory_name(), 
>>> self.get_filename(filename))
>>>
>>>
>>>
>>> They basically destroy any file name you give to it even with upload_to. 
>>> This is not an issue on a storage that uses the underlying file system, but 
>>> it might be quite an issue on different systems, in particular if file 
>>> names are using slashes as prefixes.
>>>
>>> So what I did was to override it a bit:
>>>
>>> class S3FileField(FileField):
>>>  
>>> def generate_filename(self, instance, filename):
>>> # If upload_to is a callable, make sure that the path it returns is
>>> # passed through get_valid_name() of the underlying storage.
>>> if callable(self.upload_to):
>>> filename = self.upload_to(instance, filename)
>>> filename = self.storage.get_valid_name(filename)
>>> return filename
>>>
>>> return self.storage.get_valid_name(filename)
>>>
>>>
>>> 

Re: Proposal: change to the way list_editable form data is submitted in the admin

[Josh Smeaton]

I know this particular case has been discussed before. Here are two related 
tickets (I think there's a better canonical ticket but I can't find it just 
now): https://code.djangoproject.com/ticket/11652 
and https://code.djangoproject.com/ticket/16549

I haven't done the required reading recently, so I can't comment on whether 
or not your idea could be accepted. But hopefully those tickets should 
provide a bit more information for investigation puproses.



On Thursday, 17 March 2016 11:37:06 UTC+11, John C wrote:
>
> Hey,
>
> For the past five years, I've been using Django to manage a database of 
> online applications. I absolutely love it! Makes my job so much easier.
>
> In general, any problems I run into, there's usually an easy workaround. 
> But I wonder if that's even feasible in this case. Anyway, here's the 
> problem: in managing submissions we make a lot of use of the list_editable 
> attribute of ModelAdmin, particularly for status columns. It's extremely 
> handy to be able to load up a list, filter it, and then make status changes 
> to selected records all in one go.
>
> However, there are times when these status columns are also changing on 
> their own, due to what's happening on the front end. I have to be very 
> careful to ensure that this doesn't happen in between when I load an admin 
> list and when I click "Save." If so, then I may end up overwriting the 
> newly changed data, back to what it was when the list was loaded in my 
> browser. This is because all rows are always saved, based on the data in 
> the form inputs from the list.
>
> I propose that a copy of the list_editable values be sent along as a 
> hidden form element (or, alternatively, that Javascript be used to detect 
> values changed in response to user input). That way, in the admin form 
> handler, only rows that have been intended to be changed would be updated 
> to submitted values.
>
> It adds some complexity, sure, but are there any disadvantages I haven't 
> thought of? From my perspective, it would solve a rather frustrating 
> problem.
>
> Thanks,
> John Cronan
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7498742-a94c-4e22-b188-bcef624bf74b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[Tim Graham]

What I meant about increasing coupling is this question: do we want to go 
down the road of defining more and more form related things in models? Yes, 
there are already a few options that are primarily for model forms (e.g. 
editable and blank), but is it okay to add more or should we try to avoid 
that?

For example, there was also a similar proposal to allow specifying the form 
field when instantiating a model field [0].

selected = models.BooleanField(
...,
field=forms.ChoiceField(empty_label=None, widget=forms.RadioSelect())
)


If we accept the formfield_defaults proposal, then I don't see a clear 
place to draw the line to reject this other proposal.

[0] https://code.djangoproject.com/ticket/22609

On Thursday, March 17, 2016 at 9:46:30 AM UTC-4, is_null wrote:
>
> On Thu, Mar 17, 2016 at 2:17 PM, Tim Graham  > wrote: 
> > It seems useful, but I'm not sure if it increases the coupling between 
> model 
> > and forms in an undesirable way? 
>
> The coupling is already there because model fields sit right 
> in-between the db and form fields, so I don't know if it would 
> actually /increase/ the coupling. 
>
> Another way is to extract out all form related methods from model 
> fields (value_from_object(), save_form_data(), formfield()) into a new 
> class. 
>
> Then instead of this model: 
>
> dbfield -> model field <- formfield 
>
> You'd have: 
>
> form field 
> \ 
>modelformfield 
>   | 
>model field 
>/ 
> dbfield 
>
> modelformfield would have the formfield(), value_from_object(), and 
> save_form_data(). 
>
> Anyway, are you sure it's not another issue ? I mean, even if we 
> decide to move formfield(), shouldn't it have overridable defaults ? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/774f2f61-c749-4f82-b1e0-7dcc615f32d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

[Vincent]

Hey Andrew,

Thanks for looking through all that, and for the reply.

I like the simplicity of your updated examples. I started to make a 
counter-example to suggest that `include` be inside of a `route` 
(https://gist.github.com/orokusaki/c0c934013ee7911071ef).

But then, as I thought through this, I think I like your example almost* 
exactly like it is, but I'm afraid there might be a problem:

Given your example, any message how would a 'websocket.connect' message at 
the path `notifications/foo/` be routed, giving this example:

routing = [
route("websocket.connect", ChatConnect),
include(path="^notifications", "notification.routing.routing"),
]

Given that the chat route is the first match, wouldn't the notifications 
route never be used? Would path need to be required, so that the matching 
would be similar to `urlpatterns`? Otherwise, we're allowing routing based 
on channel name or path again? Maybe I'm misunderstanding.

On Friday, March 18, 2016 at 10:58:41 AM UTC-4, Andrew Godwin wrote:
>
> Hi Vincent,
>
> I think you make some good points - in particular, I think includes are 
> probably a necessity, as you say. However, I disagree we should let people 
> have either channel->url or url->channel; I'd like us not to try and give 
> people multiple ways to do things if we can help it, especially in an 
> ecosystem of third-party apps.
>
> You can't rename routing.py to channels.py, however, as then the import 
> names will clash with the `channels` third-party app if the user hasn't 
> turned on absolute imports.
>
> I'd build on your proposal and say the following:
>
> ---
>
> Routing should be a list of pattern matches rather than a dict, so you can 
> spread it across multiple includes sensibly. Each entry in the list will be 
> a route() match object that takes a channel name (it has to be a name, no 
> regular expressions here) as a required argument, and an optional `path` 
> argument that's a regular expression matched against the incoming message 
> `path`.
>
> In fact, the routing will be generic, so you can regex against any primary 
> message attribute you know will be present - for example, `method` for 
> HTTP, or in the SMS example, by country code. It'll work like URL routing 
> too and let you capture groups to be passed to the consumer (but only by 
> name, to avoid confusion when a user matches against multiple message 
> attributes and there's no defined ordering).
>
> The include() function will take any keyword argument and do prefixing 
> like it does now for URLs.
>
> Example:
>
> routing = [
> route("http.request", ViewConsumer),
> route("websocket.connect", path="^chat/(?P[^/]+)/$", 
> ChatConnect),
> route("sms.receive", sender="+44(?P[0-9]+)$", 
> UkSmsConsumer),
> include(path="^notifications", "notification.routing.routing"),
> ]
>
> It also means that the simple example case stays quite readable:
>
> routing = [
> route("websocket.connect", ws_connect),
> route("websocket.receive", ws_receive),
> route("websocket.disconnect", ws_disconnect),
> ]
>
> We can also have channels upconvert the old dict format into this 
> trivially to preserve all the existing code and examples, like Jacob's 
> article.
>
> Andrew
>
> On Fri, Mar 18, 2016 at 3:48 AM, Vincent  > wrote:
>
>> Jacob, Florian, Andrew,
>>
>> I've spent the last 200 minutes thinking this through and writing, and 
>> here's what I've come up with:
>>
>> https://gist.github.com/orokusaki/c67d46965a4ebeb3035a
>>
>> Below are the full contents of that Gist (but I recommend the Gist for 
>> formatting).
>>
>> I also created https://github.com/andrewgodwin/channels/issues/87 last 
>> weekend (re: your static files point above, Jacob).
>>
>> ### Problem
>>
>>   1. Channel / URL routing is 2-dimensional (compared with 1D URL 
>> handling in Django)
>>   2. This creates a chicken / egg problem between channel name and URL 
>> path
>>   2. That's illustrated by the discrepancy between Florian's URL -> 
>> channel and Andrew's channel -> URL
>>   3. Put a Channel on the Y axis and URL are on the X axis, and the 
>> intersection is where a Consumer comes into play
>>
>> ### Considerations
>>
>> Here are some design considerations for my API proposal:
>>
>>   1. Includes - because nobody wants to all of their channels / URLs in a 
>> project-level module
>>   2. URL generation for channels with URLs
>>   3. The following duplicate include functionality works perfectly in 
>> Django currently with URLs
>>   4. `urlpatterns` are kepts in `urls.py`
>>   5. So, I've renamed `routing.py` to `channels.py` - after all, we're 
>> defining `channelpatterns`
>>   6. Either channel name OR URL has to come first, so that we don't need 
>> a 2D graph in Python for routing consumers
>>
>> Project-level channels:
>>
>> # channels.py
>> channelpatterns = [
>> channel(r'^websocket\.', include('chat.channels', 
>> namespace='chat')),
>> channel(r'^websocket\.', 

Re: Revisiting multiline tags

[Collin Anderson]

Here's the actual code PR https://github.com/django/django/pull/2556

On Sun, Mar 13, 2016 at 1:26 AM, Martijn van Oosterhout 
wrote:

>
> On 12 March 2016 at 05:31, Curtis Maloney  wrote:
>
> I think this conversation needs to come to a conclusion, and that
>>> conclusion should be simple. Several people have asked a very simple
>>> question of the purists: what is the "correct" way of writing tags which
>>> by nature need to be very long, without line breaks and without them
>>> being 400 characters long. If no acceptable answer can be given, we need
>>> to just implement the line break mechanic and give the developers back
>>> their whitespace.
>>>
>>
>> As pointed out by Josh in another email, I wrote a patch to permit
>> multi-line tags.  I asked for feedback.  I got _none_.
>>
>> If people really wanted this feature, why didn't we hear more about it?
>> What can we do to get more people to know about it, and to give more
>> feedback?
>>
>> I would recommend you review the history of this discussion, collect the
>> pros and cons, formulate a DEP, and we can go from there.
>>
>> I'm quite sure the patch will still work fine.
>>
>>
> Presumably you're talking about this:
> https://github.com/django/deps/pull/3/files
>
> I'm not sure what feedback you're expecting, but if +1's are what's
> needed, then here you go: +1.
>
> The thing is, this feature is a nice to have but no show stopper. The
> first time a developer runs into this (by trying the obvious and finding it
> doesn't work), they'll check the documentation, shrug their shoulders at
> the weird Django developers and get on with their job.
>
> Perhaps 1% will go to the effort of seeing if it has been proposed, find
> it's been mentioned several times and think "someone is working on it" and
> get on with their job.
>
> Perhaps 1% of those will note it hasn't been done yet, dig deeper and find
> your proposal and the various bugs, note it's been blocked, figure it's a
> lost cause and get on with their job.
>
> If this change requires a horde of developers waking up and calling for
> it, then it's never going to happen. The current situation will however
> continue to cause wasted developer time until eternity. Simply because
> there is no obvious reason why it shouldn't work. It's not ambiguous, it's
> not going to confuse anyone, it's just one of those little things that
> makes computers just a little bit more user friendly.
>
> Have a nice day,
> --
> Martijn van Oosterhout  http://svana.org/kleptog/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADWG95v7eMb8u85PyS3MsigXMVoKs3a_H9zx8aGJBsetBaWyLQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S6iJt9DCuRM5LKDWX%3DB02BUq7zBgf8TDp3-%2BrC4xGHLRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

[Andrew Godwin]

On Fri, Mar 18, 2016 at 4:40 PM, Vincent  wrote:

> Hey Andrew,
>
> Thanks for looking through all that, and for the reply.
>
> I like the simplicity of your updated examples. I started to make a
> counter-example to suggest that `include` be inside of a `route` (
> https://gist.github.com/orokusaki/c0c934013ee7911071ef).
>
> But then, as I thought through this, I think I like your example almost*
> exactly like it is, but I'm afraid there might be a problem:
>
> Given your example, any message how would a 'websocket.connect' message at
> the path `notifications/foo/` be routed, giving this example:
>
> routing = [
> route("websocket.connect", ChatConnect),
> include(path="^notifications", "notification.routing.routing"),
> ]
>
> Given that the chat route is the first match, wouldn't the notifications
> route never be used? Would path need to be required, so that the matching
> would be similar to `urlpatterns`? Otherwise, we're allowing routing based
> on channel name or path again? Maybe I'm misunderstanding.
>
>
My idea there was that, like urlpatterns, it would go down the list in
order, so if you did it like this:

routing = [
include("notification.routing.routing", path="^notifications"),
route("websocket.connect", ChatConnect),
]

Then it would check the include first, before hitting the catchall. This is
what you have to do with catchall URLs now, so I don't think it will be too
unusual.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uqLayLOaFR7gE5jQLJMDJ%2BYcdA%2BF-wDSnitTzm24Fv%3DfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[Collin Anderson]

A few thoughts, just to see if we can solve the problem by documenting some
existing code:

Would making a subclass overriding formfield() work?

class RadioSelectBoolean(models.BooleanField):
def formfield(self, *args, **kwargs):
kwargs['widget'] = forms.RadioSelect
super(RadioSelectBoolean, self).formfield(*args, **kwargs)

Or would using fields_for_model help?
https://github.com/django/django/blob/master/django/forms/models.py#L111

On Thu, Mar 17, 2016 at 1:49 PM, James Pic  wrote:

> If we prefer to remove form related stuff from models, then we should
> be able to register new default model forms:
>
> models.py:
>
> class YourModel(models.Model):
> your_field = models.BooleanField()
>
> forms.py:
>
> class YourModelDefaultForm(django.?.ModelFormConfiguration):
> class Meta:
> help_texts = dict(your_field='your help text')
>
> # Set it as default
> django.?.register(YourModel, YourModelDefaultForm)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALC3KaeL2VefbA_GfkhaYf8jWJvr%3DsRLLjyP4FcHL9_q_EwfxA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S4R_oHPRot1uL6p2kCqTppQb4yL0-d0DPQtgyy7VbWnAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.