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

[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 filter using a regular expression to match module names.

And what does that match against? The module name of the exception type right?

> Therefore it's not redundant to subclass *Warning for namespacing alone.

Not redundant? You mean you must subclass? In that case my concern stands. 

/ Anders
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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, disconcerts us. "Let awe and disconcert
> drive you"? "Attraction and repulsion are important"?

Oooh. This is a good one! Let's start using more electromagnets in our
source code.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 "Beautiful is better than ugly" in reference to
the Zen of Python. Back home, a close person who is not a Python
programmer nor familiar with PEP 20 saw the t-shirt. They were
horrified by the out-of-context sentence for reasons similar to what
has been already stated in support of this argument. It prompted them
of lookism and judgmentality, and found the message to be disturbing
in its suggestion to compare by some standard of beauty and to
discriminate. Let me add some context: this person is socially and
politically active (maybe what someone would call a "SJW"; definitely
not what anyone would call "politically correct"), and is specially
sensitive to issues of discrimination and sexism. This was enough,
though, for me to wonder what kind of message I would be projecting by
wearing that writing on me. I've been since then discouraged to ever
wear the t-shirt in any public context.

This story might have limited value because it's one anecdote, and
because the central point is the impact of the clause when taken out
of its original context. I don't want to construct this as an argument
in favor of removal of the clause, but I want to mention this as
evidence that it does carry emotionally (negatively) charged content.
If this content can be avoided without compromising the purpose and
function of the message, than by all means I would welcome and support
the change. It's meaningful, as a community, to show willingness to
respond to discomfort of any kind.

In this case, I even see the potential to convey the original message
in a more powerful way than the current formulation does. I'm not a
good candidate for this, as the chosen language for this community is
English, which is not my native language nor a language I feel very
good at. I appreciate the poetic style of the original, and I think
that Tim Peters has done an outstanding job at capturing these ideas
into easy and humor-rich language. The opportunity would be to express
the idea of aesthetic appeal of code in some way beyond the simplistic
judgmental labelling of "beautiful" vs "ugly". To be fair, in my
experience this has been a source of confusion to many Python
newcomers, as the notion of "beauty", as with any other value
judgment, is highly relative to the subject evaluating it. I've seen
people think of the Python community as conceited because they would
think they possess some absolute metric of beauty.

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, disconcerts us. "Let awe and disconcert
drive you"? "Attraction and repulsion are important"? "If it disturbs
you, it's probably wrong"? I know these are terrible and will all fail
the spirit and the style of the original, but I'm dropping suggestions
with the hope to stimulate some constructive thought on the matter.
I'm fine with PEP 20 being unchanged; and my goal is not to find a
replacement or urge for a change, but rather to be willing to think
about it.

Cheers,
Davide
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 expression to match module names.
Therefore it's not redundant to subclass *Warning for namespacing alone.

> On Sep 13, 2018, at 11:07 PM, Anders Hovmöller  wrote:
> 
> 
>> 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 want to avoid libraries 
> using these convenience functions instead of creating their own warning that 
> can be properly filtered. 
> 
> I’m not sure what the solution to this would be. Maybe just accessing 
> .DeprecationWarning dynamically? Seems a bit magical though. 
> 
> / Anders

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 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 been
> participating here long enough to know that it isn't.
>
> Due to the severity of the language and the fact that I have received
> previous reports of negative interactions I am implementing a 2 month ban
> for you, Koos. After two months you can submit a request to have your
> posting abilities restored.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Andrew K Kelleher
Brooklyn, NY
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 been
participating here long enough to know that it isn't.

Due to the severity of the language and the fact that I have received
previous reports of negative interactions I am implementing a 2 month ban
for you, Koos. After two months you can submit a request to have your
posting abilities restored.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 is a russian spy...

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 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 .format() or percent-formatting; all three of them are
supported for good reasons.

For i18n, I think .format() is probably your best bet. Trying to mess
with f-strings to give them methods is a path of great hairiness, as
they are not actually objects (they're expressions).

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 "clean/dirty" doesn't even
> mean the same thing. It's entirely possible for a thing to
> be spotlessly clean without being beautiful or elegant.

Well, not to mention that if you care about discrimination of people
(assuming one doesn't understand what polysemy is :-)), then I'm not
sure that clean/dirty is much better than beautiful/ugly (see e.g.
Norbert Elias "The Civilizing Process" about how cleanliness norms
historically developed - at least in the Western world - in the upper
classes of pacified European kingdoms), while elegant/inelegant may
even be worse.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 .format() or percent-formatting; all three of them are
supported for good reasons.

For i18n, I think .format() is probably your best bet. Trying to mess
with f-strings to give them methods is a path of great hairiness, as
they are not actually objects (they're expressions).

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Combine f-strings with i18n

[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() style.


The second problem is that I need to translate strings on the fly. I 
propose to add a f''.language() method to the f-string format.



Example:

user = 'Pedro'

f'Hi {user}' would be translated to 'Hola Pedro' if the locale were set 
to Spanish.


f'Hi {user}'.language('es_ES') would be translated in the same way.


To extract translatable strings from the source code, the source code 
could contain a 'HAS_LOCALES' flag (or something similar) at the top of 
the code. This way, the pygettext.py program would know that 
translatable f-strings are within the code.



Rationale:

More pythonic. At this moment, _('').format() is the way to go, so I 
would need to wrap another call around that: T(_(''), args, 'es_ES') 
<===This is an ugly hack.


# Set the _() function to return the same string

_ = lambda s: s

es = gettext.translation('myapplication', languages=['es_ES'])

def T(translatable_string, args_dictionary = None, language = None)

    if 'es_ES' == language:

        # Return translated, formatted string

        return es.gettext(translatable_string).format(args)


    # Default, return formatted string

    return translatable_string.format(args)


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 an extra 77 non-space 
characters is superficial? Is this your position?

> Remembering your comments about string interpolation, it sounds like you 
> write a lot of templating code and craft large JSON blobs for REST APIs. I 
> agree that keyword arguments are critical in those situations for avoiding 
> tedious and error-prone positional matching.

Well no they are not. You wouldn't have positional arguments because you'd 
create a dict and pass it.

> When I have similar situations I tend to avoid the `f(a=a)` annoyance by 
> creating kwds dicts and passing them around with ** unpacking.

Which everyone does. But how would you create that dict? 

> It avoids creating extra lists, which might make it more efficient. It also 
> emphasizes the recursion, which wasn't obvious to me when I first glanced at 
> the code.

Sure. All good improvements. No argument from me.

> No, I didn't bother switching to keyword arguments, because I didn't feel it 
> helped. My screen was big enough to verify the order as I wrote the arguments.

This makes me very frustrated. You could rely on the machine to verify the 
arguments, but you spend extra time to avoid it. You're explicitly avoiding to 
send a machine to do a machines job. Why? I'm arguing you're doing it *because 
it produces shorter code*. This is exactly my point. We should send a machine 
to do a machines job, and if the language pushes people to send a man to do a 
machines job then this is bad.


> If you feel like you're repeating yourself, the easiest way to avoid 
> frustration is to simply stop. Don't fall for the sunk cost fallacy, despite 
> the effort you've put into this proposal.

Well ok, you should have started with that. I'll just send what I've written so 
far :)

/ Anders
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

--
Greg

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 aesthetics are different. Some people like Rothko, others don't. Since
that pattern is rare for me, I don't wish for a better way.

The real problem with this code section wasn't the positional arguments,
> but that it was so heavily indented. Whenever I have code so nested, I put
> in a great deal of effort to refactor so that I can avoid the nesting of
> many try/except, for, and if/else statements.
>
> Most code has many problems. Bringing up random other problems instead of
> sticking to the topic doesn't seem very helpful. Or did you want to change
> the topic to generally be about how to clean up code? If so I'd like to
> know so I can stop responding, because that's not what I am trying to
> discuss.
>

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.


On Fri, Sep 14, 2018 at 12:27 AM Anders Hovmöller 
wrote:

> > I enjoy using keywords to explain the values I'm passing. If I already
> have a well-named variable, I'm less keen on using a keyword.
>
> Here lies the crux for me. You're describing telling the next reader what
> the arguments are. But without keyword arguments you aren't telling the
> computer what the arguments are, not really. The position and the names
> become disconnected when they should be connected.
>
> It's very similar to how in C you use {} for the computer but indent for
> the human, and no one checks that they are the same (not true anymore
> strictly because I believe clang has an option you can turn off to validate
> this but it's default off). In python you tell the computer and the human
> the same thing with the same language. This is robust and clear. I think
> this situation is the same.
>

It may be similar in theme, but in my experience it's different in practice
-- how often the problem arises and how difficult it is to detect and fix.

Remembering your comments about string interpolation, it sounds like you
write a lot of templating code and craft large JSON blobs for REST APIs. I
agree that keyword arguments are critical in those situations for avoiding
tedious and error-prone positional matching. When I have similar situations
I tend to avoid the `f(a=a)` annoyance by creating kwds dicts and passing
them around with ** unpacking.

> Here's a possible refactor. I didn't bother with keyword arguments,
> because the variable names are easy to match up with arguments
> positionally. My screen was large enough that I could read the signature at
> the same time as I wrote the call.
> >
> > def recurse(name):
> > return self.find_ordering_name(name, opts, alias, order,
> already_seen)
> > return itertools.chain.from_iterable(map(recurse, opts.ordering))
>
> I don't see how that changed anything. That just changes it to a
> functional style, but otherwise it's identical.


It avoids creating extra lists, which might make it more efficient. It also
emphasizes the recursion, which wasn't obvious to me when I first glanced
at the code. No, I didn't bother switching to keyword arguments, because I
didn't feel it helped. My screen was big enough to verify the order as I
wrote the arguments.


On Thu, Sep 13, 2018 at 11:35 AM Anders Hovmöller 
wrote:

> I’ll repeat myself [...]
>

If you feel like you're repeating yourself, the easiest way to avoid
frustration is to simply stop. Don't fall for the sunk cost fallacy,
despite the effort you've put into this proposal.

Have a good evening.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 ...@yandex.com, a 
> well-known Russian website (similar to Google); (b) there's a Canadian 
> actress named Samantha Quan.
>

I completely agree with the fact that this discussion should be stopped 
without starting it. I just want to note that anyone (with this it does not 
have to be Russian at all) can create an account on Yandex. I would not 
want this trolling to be considered in the spirit of forging a negative 
attitude towards the Russians. 
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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, content_length, 
> charset, content_type_extra)
> 
> and 
> 
> handler.new_file(field_name=field_name, file_name=file_name, 
> content_type=content_type, content_length=content_length, charset=charset, 
> content_type_extra=content_type_extra)
> 
> 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:

handler.new_file(
field_name=field_name, 
file_name=file_name, 
content_type=content_type, 
content_length=content_length, 
charset=charset, 
content_type_extra=content_type_extra,
)

> The real problem with this code section wasn't the positional arguments, but 
> that it was so heavily indented. Whenever I have code so nested, I put in a 
> great deal of effort to refactor so that I can avoid the nesting of many 
> try/except, for, and if/else statements.

Most code has many problems. Bringing up random other problems instead of 
sticking to the topic doesn't seem very helpful. Or did you want to change the 
topic to generally be about how to clean up code? If so I'd like to know so I 
can stop responding, because that's not what I am trying to discuss.

/ Anders___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 keen on using a keyword.

Here lies the crux for me. You're describing telling the next reader what the 
arguments are. But without keyword arguments you aren't telling the computer 
what the arguments are, not really. The position and the names become 
disconnected when they should be connected. 

It's very similar to how in C you use {} for the computer but indent for the 
human, and no one checks that they are the same (not true anymore strictly 
because I believe clang has an option you can turn off to validate this but 
it's default off). In python you tell the computer and the human the same thing 
with the same language. This is robust and clear. I think this situation is the 
same. 

> 
> Here's a possible refactor. I didn't bother with keyword arguments, because 
> the variable names are easy to match up with arguments positionally. My 
> screen was large enough that I could read the signature at the same time as I 
> wrote the call.
> 
> def recurse(name):
> return self.find_ordering_name(name, opts, alias, order, already_seen)
> return itertools.chain.from_iterable(map(recurse, opts.ordering))

I don't see how that changed anything. That just changes it to a functional 
style, but otherwise it's identical.

/ Anders
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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, file_name=file_name,
> content_type=content_type, content_length=content_length, charset=charset,
> content_type_extra=content_type_extra)
>

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.

The real problem with this code section wasn't the positional arguments,
but that it was so heavily indented. Whenever I have code so nested, I put
in a great deal of effort to refactor so that I can avoid the nesting of
many try/except, for, and if/else statements.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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
> library and this code doesn’t seem to handle that. We really want to avoid
> libraries using these convenience functions instead of creating their own
> warning that can be properly filtered.
>

I feel there could be solutions. Either module.__getattribute__ (which,
IIRC, was implemented recently), or just using a proxy/wrapper class around
non-Union[class, function] objects. Those are rare, though, in imported
modules. And I don't think this library will see much use without the
subjects being imported first - at least I know I do my refactors on a
per-file basis. And if you can't, you might want to split your files first.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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
>>
>> Is a pretty typical one.
>>
>
> That call is recursive, so it's unlikely that the author would shift the
> parameters around without testing the call and changing the argument
> positions appropriately.
>
>
> Maybe. Still it would be better with keyword arguments. Testing is one
> thing, quickly finding problems is another. Keyword arguments fail fast and
> cleanly with signature changes, positional arguments only do when you add
> or remove parameters at the very end, all other changes are potentially
> very annoying to debug because you can get a long way past the problem call
> site before hitting a type or behavior error.
>
> I'm not sure we even agree on this basic point though. Do you agree on
> that?
>

I agree those are benefits to keyword arguments, but I disagree that those
benefits accrue in all cases. I do not believe that keyword arguments are
strictly better than positional.

Maybe our difference of opinion stems from tooling and the way others
refactor the code we work on.

I enjoy using keywords to explain the values I'm passing. If I already have
a well-named variable, I'm less keen on using a keyword.


Here's a possible refactor. I didn't bother with keyword arguments, because
the variable names are easy to match up with arguments positionally. My
screen was large enough that I could read the signature at the same time as
I wrote the call.

def recurse(name):
return self.find_ordering_name(name, opts, alias, order, already_seen)
return itertools.chain.from_iterable(map(recurse, opts.ordering))
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 example if content_type and 
> file_name switch places. Those are the same time but the consequences for the 
> mixup are fairly large and potentially very annoying to track down. 
> 
> Do you disagree on this point?
> 
> The mixup you describe would probably cause an immediate error as the 
> filename would not be a valid content type. I suspect it'd be easy to track 
> down.

So no you don't agree?

> Keyword arguments are especially important when the type and value of two 
> arguments are hard to distinguish, like a height and width. If one is an int 
> and the other is a str, or if it must be a str with only a handful of valid 
> values, I'm not so worried about making mistakes.
> 
> Further, I think it's reasonable to use keyword arguments [...]

...now I'm confused. Now it sounds like you do agree? 

> [...] here and no more "painful" than the use of positional arguments in this 
> case. Both are annoyingly verbose.

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, file_name=file_name, 
content_type=content_type, content_length=content_length, charset=charset, 
content_type_extra=content_type_extra)

and it's pretty obvious when it's spelled out. Now compare to my two suggested 
syntaxes:

handler.new_file(*, field_name, file_name, content_type, content_length, 
charset, content_type_extra)
handler.new_file(=field_name, =file_name, =content_type, =content_length, 
=charset, =content_type_extra)

>  I'd prefer refactoring the new_file method, but I didn't spot where it's 
> defined.

People keep saying that, but I don't buy it. Refactoring isn't magic, it won't 
just make the data required to a function go away. 

I've been pressed to get hard numbers, I have. I've been pressed to come up 
with actual examples, I have. Now when I have a point you're just waving your 
hand and saying "refactoring". I don't think that's an actual argument.

/ Anders___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 need to work through.

> Python and open source have always been more about things like
inclusivity and diversity than about excessive political correctness. I'm
sure the historical concepts of master/slave were so distant to the
handsome young men that developed the computer > science concepts that they
didn't expect to cause any naming conflicts.

And not the kind of inclusivity you hear about in [current year]. Open
source and related cultures never cared about diversity, they always didn't
care about who you were or how you looked, and solely judged you by your
work or contributions. I don't use python because Guido or whoever is such
a great guy and really worked hard, I use Python because Python is a very
useful tool for me.

Inclusivity for inclusivity's sake is a bad thing and kills communities and
companies.

Any charged context is not our problem - it's societies' problem. I'll
admit it's a bigger problem, but it's one we need to address through
elections, demonstrations, or other political means. Not by self-censorship.

Even aside, Python is a world-wide language. Not american or even european.
If we have to ban "Ugly" for american sensitivities, then perhaps we need
to ban a number of others for china's sensitivities. Where will it end ?
Nowhere, it'll keep going on forever. That's why i'm +1 for reverting the
master/slave removal PR's.

> There are also nationalist jokes about Dutchs. That also must be stopped!
Well, we just are superior ;P

(If I wanted to whine, though"Dutch" isn't what we call ourselves.
Etymological, it's root is the same as our word "Duits" or the German word
"Deutz" (or something close), which means...German (Duitsland / Germany).
Since we had a war a bit ago where we were occupied, this makes Dutch sound
a lot like we'd still be under foreign rule by the nazi's. Terrible, huh ?
We call ourself "Nederlanders", which can't really be translated, as the
country name, translated as "The Netherlands", is already a multiple, so
the normal transformation like america -> american doesn't work very well.
Strangly, the Germans don't do this - they call us "Niederlanders", while
referring to themselves as "Deutschland".)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 more painful.
>>
>
> Why would keyword arguments be more painful here? They've already split
> the call across 4 lines. Why not go a bit further and use keyword args to
> make it 6 or 7 lines? Maybe they decided it reads fine as it is.
>
>
> Yes, exactly. Why not go further? This is exactly my point.
>
>
> Sure. Run this script against django:
>> https://gist.github.com/boxed/e60e3e19967385dc2c7f0de483723502
>>
>
>> It will print all function calls that are positional and have > 2
>> arguments. Not a single one is good as is, all would be better with keyword
>> arguments.
>>
>
> I disagree. Please expand your assertion by explaining why an example is
> not good as-is and would be better with keyword arguments.
>
>
> Because keyword arguments are checked to correspond to the parameters. The
> example I gave was:
>
>
> handler.new_file(
> field_name, file_name, content_type,
> content_length, charset, content_type_extra,
> )
>
>
> 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 example
> if content_type and file_name switch places. Those are the same time but
> the consequences for the mixup are fairly large and potentially very
> annoying to track down.
>
> Do you disagree on this point?
>

The mixup you describe would probably cause an immediate error as the
filename would not be a valid content type. I suspect it'd be easy to track
down.

Keyword arguments are especially important when the type and value of two
arguments are hard to distinguish, like a height and width. If one is an
int and the other is a str, or if it must be a str with only a handful of
valid values, I'm not so worried about making mistakes.

Further, I think it's reasonable to use keyword arguments here and no more
"painful" than the use of positional arguments in this case. Both are
annoyingly verbose. I'd prefer refactoring the new_file method, but I
didn't spot where it's defined.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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
>  
> 
> 
> Is a pretty typical one.
> 
> That call is recursive, so it's unlikely that the author would shift the 
> parameters around without testing the call and changing the argument 
> positions appropriately.

Maybe. Still it would be better with keyword arguments. Testing is one thing, 
quickly finding problems is another. Keyword arguments fail fast and cleanly 
with signature changes, positional arguments only do when you add or remove 
parameters at the very end, all other changes are potentially very annoying to 
debug because you can get a long way past the problem call site before hitting 
a type or behavior error.

I'm not sure we even agree on this basic point though. Do you agree on that?


> The signature uses the parameter "default_order" and the call uses the 
> argument "order". It seems that was a deliberate choice that wouldn't conform 
> to the `f(a=a)` pattern.

Maybe. It's a bit weirdly named quite frankly. Do you set the default_order by 
passing that argument? Or do you set the order? The code below sounds like it's 
order, but the signature sounds like it's default order. It can't be both, can 
it? 

I don't know the specifics but it might just be that this code is hard to read 
precisely because it doesn't conform to the pattern, and if it *did* use the 
suggested feature the mismatch in names would stand out and I would believe 
that it was intentional and not a mistake at the call site, because it would 
look like:


results.extend(self.find_ordering_name(
=item, 
=opts, 
=alias, 
default_order=order,
=already_seen,
))

now the odd ball out stands out instead of hiding. Different things should look 
different, and similar things should look similar (which would have been a good 
addition to the Zen of Python imo).

> The call is oddly split across lines 707 and 708, despite nearby lines being 
> much longer. it could easily have been written as a single line.

Agreed. It's the ghost of PEP8, but that's a totally different morass! Let's 
keep to one extremely controversial topic at a time :)

/ Anders

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 here? They've already split the 
> call across 4 lines. Why not go a bit further and use keyword args to make it 
> 6 or 7 lines? Maybe they decided it reads fine as it is.

Yes, exactly. Why not go further? This is exactly my point. 


> Sure. Run this script against django: 
> https://gist.github.com/boxed/e60e3e19967385dc2c7f0de483723502 
>  
> 
> It will print all function calls that are positional and have > 2 arguments. 
> Not a single one is good as is, all would be better with keyword arguments.
> 
> I disagree. Please expand your assertion by explaining why an example is not 
> good as-is and would be better with keyword arguments.

Because keyword arguments are checked to correspond to the parameters. The 
example I gave was:


handler.new_file(
field_name, file_name, content_type,
content_length, charset, content_type_extra,
)


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 example if content_type and 
file_name switch places. Those are the same time but the consequences for the 
mixup are fairly large and potentially very annoying to track down. 

Do you disagree on this point?

/ Anders___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 want to avoid libraries using 
these convenience functions instead of creating their own warning that can be 
properly filtered. 

I’m not sure what the solution to this would be. Maybe just accessing 
.DeprecationWarning dynamically? Seems a bit magical though. 

/ Anders
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/