Re: [Python-ideas] Deprecation utilities for the warnings module

2018-09-14 Thread Anders Hovmöller
> If correctly understood your concern, it's about usage of stdlib's *Warning > classes directly > that makes all warnings coming from different libraries indistinguishable. That was my concern yes. > I think that's not the case, since warnings.filterwarnings allows > to specify custom

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Chris Angelico
On Sat, Sep 15, 2018 at 6:09 AM, Davide Rizzo wrote: > One way out of the impasse is to draw upon the feeling behind the > adjective. We call "beautiful" something that appeals to us, makes us > comfortable, or inspires us awe. Ugly is something that makes us > uncomfortable, repels us,

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Davide Rizzo
Regardless of whether the original posting is a trolling attempt or not, the argument does have value that I want to corroborate with an anecdote. At one Python conference in Italy, participants were given an elegantly designed and well-crafted t-shirt with a writing in large characters that read

Re: [Python-ideas] Deprecation utilities for the warnings module

2018-09-14 Thread Ilya Kulakov
Hi Anders, If correctly understood your concern, it's about usage of stdlib's *Warning classes directly that makes all warnings coming from different libraries indistinguishable. I think that's not the case, since warnings.filterwarnings allows to specify custom filter using a regular

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Keats Kelleher
I don't think additional replies on this thread are really constructive. If you aren't contributing any new thoughts on the original message consider not replying at all. On Fri, Sep 14, 2018 at 12:24 PM Brett Cannon wrote: > > > On Thu, 13 Sep 2018 at 13:10 Koos Zevenhoven wrote: > >> >> If

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Brett Cannon
On Thu, 13 Sep 2018 at 13:10 Koos Zevenhoven wrote: > > If you can't tell inclusivity/diversity from political correctness, or > dirty words from dirty bytes or from unfriendliness and intolerance, you'd > better go fuck yourself. > That language and tone is entirely uncalled for and you have

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Greg Ewing
Guido van Rossum wrote: Facts to consider: (a) the OP's address is ...@yandex.com , a well-known Russian website (similar to Google); (b) there's a Canadian actress named Samantha Quan. Now I'm waiting for the Kremlin to deny rumours that the Canadian actress Samantha Quan

Re: [Python-ideas] Combine f-strings with i18n

2018-09-14 Thread Hans Polak
f-strings & pythonic  - Simple is better than complex.  - Flat is better than nested. (I think this applies)  - Readability counts.  - If the implementation is easy to explain, it may be a good idea. Just saying. Cheers, Hans On 14/09/18 11:33, Chris Angelico wrote: On Fri, Sep 14, 2018 at

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Oleg Broytman
On Fri, Sep 14, 2018 at 12:47:39AM -0700, Zaur Shibzukhov wrote: > I completely agree with the fact that this discussion should be stopped The discussion should be stopped before those 3 pull requests. Now they should be reverted. Or more discussion will be sparked and more PRs created.

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Antoine Pitrou
On Fri, 14 Sep 2018 10:47:07 +1200 Greg Ewing wrote: > M.-A. Lemburg wrote: > > For > > me, it refers to a general feeling of consistency, pureness and > > standing out on its own. It's abstract and doesn't have > > anything to do with humans. > > Yep. And the proposed replacement

Re: [Python-ideas] Combine f-strings with i18n

2018-09-14 Thread Chris Angelico
On Fri, Sep 14, 2018 at 7:02 PM, Hans Polak wrote: > I have recently updated my code to use the more pythonic f-string instead of > '{}'.format() Well there's your problem right there. Don't change your string formatting choice on that basis. F-strings aren't "more Pythonic" than either

[Python-ideas] Combine f-strings with i18n

2018-09-14 Thread Hans Polak
I have recently updated my code to use the more pythonic f-string instead of '{}'.format() Now, I want to start on the road to multilingual internationalization, and I run into two problems. The first problem is that f-strings do not combine with i18n. I have to revert to the '{}'.format()

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Anders Hovmöller
> I don't think it's off-topic. The ugliness of the line you're talking about > stems in large part from that it's in a heavily indented complex section. The > distinction between positional and keyword args in this case is superficial. Indenting 4 levels (32 spaces) is a problem, but adding

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Greg Ewing
Tim Delaney wrote: And I can't think of an elegant replacement for "ugly" to pair with "elegant". There's "inelegant", but it doesn't have the same punch as "ugly". And I think Tim deliberately chose a very punchy word for that line, to reflect that we care a *lot* about aesthetics in Python.

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Michael Selik
On Fri, Sep 14, 2018 at 12:30 AM Anders Hovmöller wrote: > Since neither version fits well on one line or even three, I'd have > written each of those on a separate line, indented nicely to emphasize the > repetition. Seems fine to me. > > Sure. As would I. Doesn't change anything[.] > Our

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Zaur Shibzukhov
пятница, 14 сентября 2018 г., 1:56:58 UTC+3 пользователь Guido van Rossum написал: > > Everyone who still wants to reply to this thread: please decide for > yourself whether the OP, "Samantha Quan" who started it could be a Russian > troll. Facts to consider: (a) the OP's address is

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Anders Hovmöller
> On 14 Sep 2018, at 09:26, Michael Selik wrote: > > > > On Fri, Sep 14, 2018, 12:17 AM Anders Hovmöller > wrote: > > That's a bit of a dodge. There is a huge difference in verbosity between > > handler.new_file(field_name, file_name, content_type,

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Anders Hovmöller
> Maybe our difference of opinion stems from tooling and the way others > refactor the code we work on. Maybe. Or the code we have to refactor that others have written. Or both. > I enjoy using keywords to explain the values I'm passing. If I already have a > well-named variable, I'm less

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Michael Selik
On Fri, Sep 14, 2018, 12:17 AM Anders Hovmöller wrote: > > That's a bit of a dodge. There is a huge difference in verbosity between > > handler.new_file(field_name, file_name, content_type, content_length, > charset, content_type_extra) > > and > > handler.new_file(field_name=field_name,

Re: [Python-ideas] Deprecation utilities for the warnings module

2018-09-14 Thread Jacco van Dorp
Op vr 14 sep. 2018 om 08:07 schreef Anders Hovmöller : > > > I'd like to propose an extension for the warnings module > > to address this problem. > > I like all of that. The only issue I have with it is that the warnings > module is designed to namespace depredations so you can turn them on per

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Michael Selik
On Thu, Sep 13, 2018, 11:58 PM Anders Hovmöller wrote: > In that case, you should be able to link to a compelling example. If you >> go to the trouble of finding one, I'll take time to try to refactor it. >> >> >> https://github.com/django/django/blob/master/django/db/models/sql/compiler.py#L707

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Anders Hovmöller
> it reads fine precisely because the variables names match with the signature > of new_file(). But if new_file() is changed they won't match up anymore and > it will still read fine and look ok, but now the parameters don't line up and > it's broken in potentially very subtle ways. For

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

2018-09-14 Thread Jacco van Dorp
My mom is the only one who ever called me any shade of beautiful. I think we all know what that means. However, if merely the word ugly being on a page can be "harmful", what you really need is professional help, not a change to Python. Because there's obviously been some things in your past you

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Michael Selik
On Thu, Sep 13, 2018, 11:48 PM Anders Hovmöller wrote: > > It's a bit too large for me to make sense of it quickly. My apologies for > not offering a holistic refactor. > > > My tool will print plenty of other examples. You can pick anyone really... > > > That’s positional because keyword is

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Anders Hovmöller
>> In that case, you should be able to link to a compelling example. If you go >> to the trouble of finding one, I'll take time to try to refactor it. > > https://github.com/django/django/blob/master/django/db/models/sql/compiler.py#L707 > >

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

2018-09-14 Thread Anders Hovmöller
> It's a bit too large for me to make sense of it quickly. My apologies for not > offering a holistic refactor. My tool will print plenty of other examples. You can pick anyone really... > > That’s positional because keyword is more painful. > > Why would keyword arguments be more painful

Re: [Python-ideas] Deprecation utilities for the warnings module

2018-09-14 Thread Anders Hovmöller
> I'd like to propose an extension for the warnings module > to address this problem. I like all of that. The only issue I have with it is that the warnings module is designed to namespace depredations so you can turn them on per library and this code doesn’t seem to handle that. We really