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
I agree completely.
I propose Python register a trial of Stack Overflow Teams. Stack Overflow Teams is essentially your own private Stack Overflow. (I will address the private part later.) Proposals would be questions and additions or criticism would be answers. You can express your support or dissent of a proposal using the voting. Flags and reviews can be used to moderate.
Stack Overflow Chat can be used for quick and casual discussion, and also to move irregular or irrelevant discussions away from the main site.
Although the Stack Overflow platform is typically used for technical Q&A, there is precedent for using it as a way to discuss proposals: this is precisely what Meta Stack Overflow dies and it’s seen decent success.
Anyone can register a @python.org email. Stack Overflow Teams can be configured to allow anyone with a @python.org email join the python-ideas team.
I’m sure Stack Overflow Inc. is willing to grant Stack Overflow Teams to the PSF pro bono after the trial period expires.
You can configure stack overflow to get email notifications as well.
> On Sep 17, 2018, at 1:16 PM, Anders Hovmöller <boxed(a)killingar.net> wrote:
>
>
>> It’s been almost a week since this “discussion” first started. Can we please stop this in the name of productive work on python-ideas?
>
> A better use of time might be to discuss moving to a better forum system where moderation is easier/possible. Email somehow has a shape that makes those things 100% probable and you can’t easily silence discussions that are uninteresting.
>
> / Anders
> Frankly, I think the bigger issue is all too human -- we get sucked in and
> participate when we really know we shouldn't (or maybe that's just me).
>
That may be why some people misbehave, but we have no way of discouraging that misbehavior.
> And I'm having a hard time figuring out how moderation would actually
> result in the "good" discussion we really want in an example like the
> "beautiful is better than ugly" issue, without someone trusted individual
> approving every single post -- I don't imagine anyone wants to do that.
In a forum, the beautiful is better than ugly issue would be locked. No more posts can be added. If someone wants to discuss another proposal branching off of the original discussion, they can start a new thread. If they just want to lampoon, we can courteously ask them to 1) take it elsewhere or 2) move the post to a “malarkey” section of the forum where people don’t get notified.
> It's absence is a big advantage. We're not a social network with
> "likes". We don't need a bunch of argumentless "voting".
Up/ down voting indicates how much consensus we have among the entire community- an expert might agree with another expert’s arguments but not have anything else to add, and an outsider might agree with the scenario an expert presents without having much more to add. Granular up/down votes are useful.
> Believe it or not, I like the fact that you can't just edit posts. I've
> lost count of the number of forum threads I've been on where comments to
> the initial post make *no sense* because that initial post is nothing
> like it was to start with.
There is version history. Not all of us have the time to read through every single post beforehand to get the current state of discussion.
Hmm, what if we used GitHub as a discussion forum? You’d make a pull request with an informal proposal to a repository. Then people can comment on lines in the diff and reply to each other there. The OP can update their branch to change their proposal- expired/stale comments on old diffs are automatically hidden.
You can also create a competing proposal by forming from the OP’s branch and sending a new PR.
> Just editing your post and expecting people to notice
> is not going to cut it.
You would ping someone after editing the post.
> Approximately none of this has anything to do with the medium. If the
> mailing list is obscure (and personally I don't think it is), it just
> needs better advertising. A poorly advertised forum is equally
> undiscoverable.
It does have to do with the medium. First, people aren’t used to mailing lists- but that’s not what’s important here. If the PSF advertised for people to sign up over say twitter, then we’d get even more email. More +1 and more -1. Most of us don’t want more mailing list volume.
The fact that you can’t easily find an overview people will post arguments that have already been made if they don’t have the extreme patience to read all that has been said before.
For the rest of your comments, I advise you to read the earlier discussion that other people had in response to my email.
> That message was rather bad in my not so humble opinion -- it was
> just "I want my +1 button" without any argument. Your message is much
> better as it have arguments. See, the absence of the button work!
>
> We're proposing and *discussing* things here not "likes" each other.
> Write your arguments or be silent.
Please respond to the actual arguments in both of the two emails that have arguments in support of +1/-1.
+1/-1 reflects which usage scenarios people find valuable, since Python features sometimes do benefit one group at the detriment to another. Or use syntax/behavior for one thing that could be used for another thing, and some programming styles of python use cases would prefer one kind of that syntax/behavior.
> Frankly, I think the bigger issue is all too human -- we get sucked in and
> participate when we really know we shouldn't (or maybe that's just me).
>
That may be why some people misbehave, but we have no way of discouraging that misbehavior.
> And I'm having a hard time figuring out how moderation would actually
> result in the "good" discussion we really want in an example like the
> "beautiful is better than ugly" issue, without someone trusted individual
> approving every single post -- I don't imagine anyone wants to do that.
In a forum, the beautiful is better than ugly issue would be locked. No more posts can be added. If someone wants to discuss another proposal branching off of the original discussion, they can start a new thread. If they just want to lampoon, we can courteously ask them to 1) take it elsewhere or 2) move the post to a “malarkey” section of the forum where people don’t get notified.
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)
Hello Everyone,
Please excuse my being late for properly responding to the last thread
on "Pattern Matching Syntax" [1]. As Robert Roskam has already
pointed out at the beginning of that thread, there has been much
previous discussion about adding pattern matching to Python, and
several proposals exist. It is therefore not my intention to propose
yet another syntax choice for pattern matching, but more to share my
experience with implementing it, in the hope of making a worthwhile
contribution to the overall discussion.
This summer, I basically ended up requiring pattern matching in Python
for a research project I am working on. Some initial hacks have then
grown into a library for pattern matching in Python [2]. On the one
hand, my design is certainly heavily influence by Scala, with which I
also work on a regular basis. On the other hand, I ran into various
difficulties, challanges, and it has been particularly important to me
to find a design that blends well with Python, and harnesses what
Python already offers.
I have written down my experience in the form of a discussion on
several options concerning syntax [3], and implementation [4],
respectively. As the articles have turned out longer than I
originally intended, it might take up too much time for those who have
little interest in this matter in the first place. However,
considering that the subject of pattern matching has been coming up
rather regularly, my experience might help to contribute something to
the discussion. Let me provide a brief summary here:
1. PATTERN MATCHING IS NOT SWITCH/CASE
--------------------------------------
When I am talking about pattern matching, my goal is to do a deep
structural comparison, and extract information from an object.
Consider, for instance, the problem of optimising the AST of a Python
program, and eliminate patterns of the form `x + 0`, and `x - 0`.
What pattern matching should be offering here is a kind of comparison
along the lines of:
`if node == BinOp(?, (Add() or Sub()), Num(0)): ...`
Ideally, it should also return the value of what is marked by the
question mark `?` here, and assign it to a variable `left`, say. The
above comparison is often written as something like, e. g.:
`case BinOp(left, Add()|Sub(), Num(0)): ...`
This use of `case`, however, is not the same as a switch-statement.
2. ORTHOGONALITY
----------------
Getting the syntax and semantics of nested blocks right is hard.
Every block/suite in Python allows any kind of statements to occur,
which allows for things like nested functions definitions, or having
more than just methods in a class. If we use a two-levelled
block-structure, we run into the problem of finding good semantics for
what the following means (note the variable `x` here):
```
match node:
x = 0
case BinOp(left, Add(), Num(0)):
...
x += 1
case BinOp(left, Mul(), Num(1)):
...
```
In the case of a "switch block", such additional statements like the
`x=0`, and `x+=1` can become quite problematic. On the other hand,
requiring all statements inside the block to be case-statements
violates the orthogonality found otherwise in Python.
I feel that this dilemma is one of the core issues why the syntax of
switch statements, or pattern matching seems so exceptionally hard.
In the end, it might therefore, indeed, make more sense to find a
structure that is more in line with if/elif/else-chains. This would
lead to a form of pattern matching with little support for
switch-statement, though.
3. IMPLEMENTATION
-----------------
For the implementation of pattern matching, my package compiles the
patterns into context-manager-classes, adds these classes in the
background to the code, and then uses `with`-statements to express the
`case`-statement. If have found a neat way to make the execution of a
`with`-statement's body conditional.
Two things have been curcially important in the overall design: first,
the "recompilation" cannot change the structure of the original code,
or add any line. This way, all error messages, and tooling should
work as expected; the invasive procedure should be as minimal as
possible. Second, it is paramount that the semantics of how Python
works is being preserved. Even though the actual matching of patterns
is done in external classes, all names must be resolved "locally"
where the original `case`-statement lives. Similarly, the variables
defined by the pattern are to local variables, which are assigned if,
and only if, the pattern actually matches.
Should pattern matching ever be added to Python properly, then there
will be no need to use `with`-statements and context managers, of
course. But the implementation must make sure, nonetheless, that the
usual semantics with name resolving of Python is being respected.
4. SYNTAX OF PATTERNS
---------------------
The syntax of patterns themselves has been guided by two principles
(again). First, if there is a way to already express the same thing
in Python, use that. This applies, in particular, to sequence
unpacking. Second, patterns specify a possible way how the object in
question could have been created, or constructed in the first place.
Hence, it is no accident that the pattern `BinOp(left, Add(), Num(0))`
above looks almost like a constructor.
Other implementation are happy to redefine the meanings of operators
like `in`, or `is` (as in, e. g., `case x is str:`). While this might
look very convenient at first, it will most probably lead to many
subsequent bugs where people write `if x is str:` to mean the same
thing (namely test the type of `x`). Even though expressing patterns
requires reusing some operators in a new way, we have to extremely
careful to choose widely, and minimise confusion, and surprises.
Pattern matching could certainly make a great addition to Python, and
various current implementations act as proof of concepts. However,
choosing an appropriate syntax for pattern matching is hard, and we
should work hard to make sure that any such addition feels natural in
Python, even at the expense of having to write more, and being not as
terse as other languages.
I hope my thoughts in this matter can make a worthwhile constribution
to the discussion. And I would like to emphasise once more, that my
goal is not to propose a new syntax for pattern matching, but to
report on my experience while implementing it.
Kind regards,
Tobias Kohn
[1] https://groups.google.com/d/topic/python-ideas/nqW2_-kKrNg/discussion
[2] https://github.com/Tobias-Kohn/pyPMatch
[3]
https://tobiaskohn.ch/index.php/2018/09/18/pattern-matching-syntax-in-pyt...
[4] https://tobiaskohn.ch/index.php/2018/09/12/implementing-pattern-matching/
PEP 581 proposes the migration of bug tracking to GitHub issues. I have
done a project to collect all issues in https://bugs.python.org. I have
parsed the HTML data and migrated the issues to GitLab along with labels
for issues and comments which is pretty much similar to GitHub issues. I
have just added a comment from my account preceded by the Author name. I
have migrated around 140 issues out of the 30000 issues for a
demonstration. I can see some immediate benefits as follows which also
apply to GitHub :
* GitHub and GitLab support markdown thus code snippets can have
highlighting.
* Labels can be filtered from the UI and are helpful for triaging.
* GitLab allows subscription for a label so that developers can subscribe
for new issues in a label.
* There are categories like milestones and priority that can help in
release management.
* They provide API and thus we can build integrations around issues.
Some notes :
I haven't parsed code in comments to enable syntax highlighting since it's
hard to parse.
Repo and feedback welcome : https://gitlab.com/tirkarthi/python-bugs/issues
Thanks
Guten Tag,
I am Jack and I am grateful to see the efficiency of scientific
computing in Python.
However, What deeply saddens me is that the namesake "Python" has
unfortunately been derived from the title of the uncivilised British
jester troupe "Monty Python". This is something that deeply infuriates
me and is against the morals of my culture. Although humor is an
integral aspect of the life of an Untermensch, I believe that Python,
A language used as an interface to majority of Scientific computing
software should be renamed to something more suitable.
I hereby propose that the Language should be renamed to Cobra, after
the brilliant military strategist Cobra Commander , who has been
history's most efficient and brilliant strategist.
I hope that my message is not mistaken for an attempt to humor. I am
physically unable to experience the same. Please revert back to the
mail with your thoughts and constructive criticism.
Yours forever,
Jack Daniels
