Re: #13781: select_related and multiple inheritance

[Tomas Ehrlich]

Works for me. I've just have to resolve two conflicts, new patch
submited, see https://code.djangoproject.com/ticket/13781#comment:16.

Cheers, 
 Tom

Dne Wed, 10 Oct 2012 01:47:38 -0700 (PDT)
Piotr Czachur  napsal(a):

> Hi!
> 
> Patch from ticket #13781 looks like a good candidate for review as it fixes 
> a few bugs in ORM.
> Could someone please take a look at it?
> 
> Cheers,
> Piotrek.
>

-- 
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: Update on localflavor move

[Tomas Ehrlich]

Salut Claude,

> I can work on this, however I'm wondering if it makes sense to re-add all 
> translations in all packages. Is adding Korean translation to Switzerland 
> localflavor useful?

I think it is. If someone translated Switzerland localflavor into
Korean language it means that he might need it (for whatever reason).


Anyway, thanks Adrian for this work. It's awesome.

Dne Sat, 13 Oct 2012 00:57:56 -0700 (PDT)
Claude Paroz  napsal(a):

> Le samedi 13 octobre 2012 00:21:16 UTC+2, Adrian Holovaty a écrit :
> >
> > Hi all, 
> >
> > We've been talking about moving django.contrib.localflavor into 
> > separate packages, outside of Django proper 
> > (
> > https://groups.google.com/d/topic/django-developers/OiyEGmXTifs/discussion).
> >  
> >
> > Today I did the work of creating the django-localflavor-* packages and 
> > copying code/tests/docs to them. 
> >
> > Now we have 44 django-localflavor-* projects on our Django GitHub 
> > account, and you can see them here: 
> >
> 
> Thanks Adrian for your work. 
> (...)
> 
> * If you have any existing Trac tickets for localflavor, please close 
> > them and open a pull request on the appropriate django-localflavor-* 
> > project. 
> >
> 
> You meant: open an issue?
>  
> 
> > Here are the outstanding to-dos with this effort: 
> >
> > * Move/copy translations into the django-localflavor-* packages. This 
> > is outside of my expertise, so does anybody want to take the lead on 
> > this?
> >
> 
> I can work on this, however I'm wondering if it makes sense to re-add all 
> translations in all packages. Is adding Korean translation to Switzerland 
> localflavor useful?
>  
> 
> >   * Add DeprecationWarning to django.contrib.localflavor in trunk, 
> > before Django 1.5. I will take care of this. 
> >
> 
> Did we decide on an accelerated deprecation here, or did you mean 
> PendingDeprecationWarning?
> 
> Claude
> 



S pozdravem
  Tomáš Ehrlich

Email:  tomas.ehrl...@gmail.com
Tel:+420 608 219 889
Jabber: elv...@jabber.cz

"Půjdu kamkoliv, pokud je to kupředu." - J. London

-- 
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: Adding a OneToMany Relationship to Django

[Tomas Ehrlich]

Hello Amir,
you've mentioned only definiton of model. Yes, it looks interesting and
definitely more readable. But definition of model is just the begining.

At database level, these models would be represented in the same way.
(No difference)

Working with models would be similar or even the same as it's now:
``member.group = band`` or ``band.members.add(member)``
Again, I don't see any difference.

There would be probably some constraint when you try delete member of
band which doesn't have any other members. Now, that could be
implemented using pre_delete/post_delete signals.


It looks for me that the only difference is in readability of
models.py. What am I missing?


Cheers,
  Tomas Ehrlich




Dne Sat, 15 Jun 2013 08:11:53 -0700 (PDT)
Amir Rachum  napsal(a):

> Hi there,
> 
> I'm not sure if this feature was discussed before (I've seen some mentions 
> of it when searching this group, but nothing definitive).
> I have written a blog post regarding the reasons (and the suggested syntax) 
> to use this relationship, and would love some feedback
> 
> http://blog.amir.rachum.com/post/53019452363/a-case-for-a-onetomany-relationship-in-django
> 
> Thanks,
> Amir Rachum
> 

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Merge policy for cleanup commits

[Tomas Ehrlich]

Relevant discussion
https://groups.google.com/forum/#!msg/django-developers/tcNVvbAv4-M/bs0zPNLqv48J


Cheers,
  Tom

Dne Mon, 8 Jul 2013 09:59:49 -0700 (PDT)
Danilo Bargen  napsal(a):

> Hi there
> 
> (I tried to find previous threads concerning the same topic, but could not 
> find any. If this is already the n-th discussion about the topic, sorry 
> about it.)
> 
> I don't quite agree with the cleanup commit policy stated in the docs:
> 
> Systematically remove all trailing whitespaces from your code as those add 
> > unnecessary bytes, add visual clutter to the patches and can also 
> > occasionally cause unnecessary merge conflicts. Some IDE’s can be 
> > configured to automatically remove them and most VCS tools can be set to 
> > highlight them in diff outputs. Note, however, that patches which only 
> > remove whitespace (or only make changes for nominal PEP 
> > 8conformance) are likely to be 
> > rejected, since they only introduce noise 
> > rather than code improvement. Tidy up when you’re next changing code in the 
> > area.
> 
> 
> I did such a PR today (without knowing that policy): 
> https://github.com/django/django/pull/1345
> 
> While I agree that small PRs which fix issues like whitespace should not 
> necessarily clutter up the commit history, I disagree for larger cleanup 
> commits. In some places the code has serious formatting issues (e.g. lines 
> that are indented 3 instead of 4 characters and that only work thanks to 
> the lax Python indentation parsing). Also, I disagree that 1 commit which 
> cleans up a file would "clutter" its commit history.
> 
> While I support fixing coding standard issues on-the-go, I think that it 
> clutters up the commit history in a worse way than a cleanup commit would, 
> because the commits are not strictly focused on the feature or bug they 
> concern.
> 
> In addition to the PEP8 changes there were also a few pyflakes changes that 
> go beyond simple whitespace formatting. For example in the core module 
> there were a few places where "variable == None" was used, even though 
> "variable is none" should be used preferredly. Another issue would be 
> "type(c) == Typeclass" instead of "isinstance(c, Typeclass)".
> 
> Anyways, if you don't want to accept such commits that's OK, but I think 
> adherence to coding standards is pretty bad in many Django modules and it 
> should be fixed. And for sure I won't be the last person to send you such a 
> pull request.
> 
> Danilo
> 


signature.asc
Description: PGP signature

collectstatic - override default ignore list

[Tomas Ehrlich]

Hi,
ticket #20189 proposes to override default ignore patterns for
collectstatic management command in project's settings.

Patch has been submitted about a year ago, but right now it's waiting
for 'design decision' whether add a new setting or not.

What is your opinion?

Cheers,
   Tom

https://code.djangoproject.com/ticket/20189
https://github.com/django/django/pull/2854

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20140701144933.4023d4c0%40bodhi.
For more options, visit https://groups.google.com/d/optout.

Re: collectstatic - override default ignore list

[Tomas Ehrlich]

Hi,
thank you for review.

I'm just a bit confused with final decision.

As Jannis commented on ticket: "This is simple, don't add a global setting 
but a parameter to the staticfiles app config. That's where such things 
belong now."

But according to Aymeric, app config isn't ready for custom settings yet -- 
"Maybe the answer is just a 'get_setting' function analogous to 'get_model'")


So the final conlusion is: New settings won't be added anywhere until this 
feature
will be implemented in AppConfig, right?


Thanks in advance

Cheers,
   Tom


Dne Wed, 2 Jul 2014 08:17:52 +0200
Aymeric Augustin  napsal(a):

> I've carefully deferred this topic until now...
> 
> Maybe the answer is just a "get_setting" function analogous to "get_model" :
> 
> apps.get_setting('myapp', 'MYSETTING')
> app_config.get_setting('MYSETTING')
> 
> It could simply defer to class level variables by default.
> 
> The first only works once the app registry is ready, while you may need 
> access to settings at import time. Technically we could make it work as soon 
> as the app import phase is done. Then I t would be available during the 
> module import phase. But I don't like basing an API on implementation 
> constraints.
> 
> The second one suffers from the same issue because one will obtain the 
> app_config through get_app_config which requires the app registry to be ready.
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20140702172151.5bd03288%40bodhi.
For more options, visit https://groups.google.com/d/optout.

Re: collectstatic - override default ignore list

[Tomas Ehrlich]

Dne Wed, 2 Jul 2014 21:17:52 +0200
Aymeric Augustin  napsal(a):

> 2014-07-02 17:21 GMT+02:00 Tomas Ehrlich :
> 
> > I'm just a bit confused with final decision.
> >
> 
> I don't think we have a decision yet ;-)

Tim Graham made comment on PR:
"Closing for now as the consensus seems to be adding a setting on the
AppConfig is the correct approach."

> 
> 
> > As Jannis commented on ticket: "This is simple, don't add a global setting
> > but a parameter to the staticfiles app config. That's where such things
> > belong now."
> >
> 
> That comment must have been written while I was working on app-loading and
> its final scope wasn't known yet.
> 
> I think a global setting isn't very different from a setting stored on the
> app config. The app config provides a bit of namespacing, but a prefix such
> as STATICFILES_ works just as well.
> 
> At this time, we don't handle settings for contrib apps in their app config
> classes. So if we want to handle this with a setting, it should be a global
> setting. If we don't, my explanations are irrelevant.
>

I would really like to see app configs with app-specific settings.
Personally, I don't like flat settings where namespaces are created
with prefixes (eg. STATICFILES_ ).

The idea of overriding class attributes in AppConfig seems promising.


Cheers,
   Tom

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20140702221427.66f0bb8a%40bodhi.
For more options, visit https://groups.google.com/d/optout.

Re: deprecate contrib.webdesign? (#22789)

[Tomas Ehrlich]

I would vote for:
Remove it from Django and provide no replacement

I almost never use original latin lorem-ipsum because
language specific dummy-text provides much better and reliable look. 

I feel that removing the package from django.contrib and keeping it as
third-party package (maintained either by community or django core dev)
would be easier for maintenance and pull-requests.


Cheers,
  Tom

Dne Fri, 11 Jul 2014 08:06:24 -0700 (PDT)
Tim Graham  napsal(a):

> 
> 
> It provides the lorem template tag. The functionality has not changed in 7 
> years and it has 20 commits in its history which are mostly maintenance 
> oriented (pep8, adding app loading compatibility).
> 
> Options:
> 
> * Move it into the main template tag library and deprecate the hook in 
> contrib.
> 
> * Remove it from Django and provide no replacement (let the community 
> maintain it somewhere).
> 
> * Remove it from Django and maintain it as a separate project under 
> (django/django).
> 
> * Your idea here
> 
> 
> thoughts on deprecating it from ​2011 mailing list thread 
> 
> :
> 
> Carl: +1
> 
> Paul M: +0 on webdesign, since it's functionality that's probably in 
> transient use by the more invisible members of our community.
> 
> Markus G: I'd miss it even though it's just a tiny piece of code and 
> trivial, it's quite useful when you mock up a site and thus need some text 
> to get a feeling for its layout when there's lots of text involved. I am 
> sure, as you say, there are quite a few people out there who would miss it 
> too.
> 
> Gabriel: As for webdesign, why not roll the one piece in it (the 
> marginally-useful lorem tag) into the main library and deprecate the hook 
> in contrib?
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20140711173205.2a28e008%40bodhi.
For more options, visit https://groups.google.com/d/optout.