Re: [Python-ideas] Moving to another forum system where
> Even so, there are mitigations to the firehose effect, including, but not > limited to digests I accidentally signed up with divest turned on for this list first. I got five digests in so many hours and I couldn’t figure out how to respond to individual threads. It’s a terrible choice and I personally would recommend removing the option because it seems broken or at least unusable. / 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] Moving to another forum system where
On Wed, Sep 19, 2018 at 7:49 AM Franklin? Lee wrote: > > On Tue, Sep 18, 2018 at 8:21 PM James Lu wrote: > > > > > Is that really an issue here? I personally haven't seen threads where > > > Brett tried to stop an active discussion, but people ignored him and > > > kept fighting. > > Not personally with Brett, but I have seen multiple people try to stop the > > “reword or remove beautiful is better than ugly in Zen of Python.” The > > discussion was going in circles and evolved into attacking each other’s use > > of logical fallacies. > > > Multiple people *without any authority in that forum* tried to stop a > discussion, and failed. Why would it be any different if it happened > in a forum? Those same people still wouldn't have the power to lock > the discussion. They could only try to convince others to stop. It would be different because some people use private mail addresses, and might not be very happy to start the day by seeing political/personal/meta/uninteresting/etc. discussions in mailbox. This aspect alone would make _any_ forum-like approach far better than mailing list. Mikhail ___ 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] Moving to another forum system where
Just an observation. I've been a member of this mailing list since (literally) five days ago and I am receiving a busload of emails. I'm a member of Stackoverflow and I visit the Q site daily... and I hardly ever receive emails. I suspect Discourse would be a good match for these discussions (although I have no experience whatsoever with it). TL;DR; I would appreciate receiving less mail. Cheers, Hans ___ 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] Moving to another forum system where
> > Most of the real decisions are actually taken > outside of it, with more direct channels in the small groups of > contributors. > It would be very nice if there was more transparency in this process. The language is better if more subjective personal experience heard- but to make that happen, the forum experience must be better for both On Tuesday, September 18, 2018 at 8:21:46 PM UTC-4, James Lu wrote: > > > Is that really an issue here? I personally haven't seen threads where > > Brett tried to stop an active discussion, but people ignored him and > > kept fighting. > Not personally with Brett, but I have seen multiple people try to stop the > “reword or remove beautiful is better than ugly in Zen of Python.” The > discussion was going in circles and evolved into attacking each other’s use > of logical fallacies. > > Other than that, my biggest issues with the current mailing system are: > > * There’s no way to keep a updated proposal of your own- if you decide to > change your proposal, you have to communicate the change. Then, if you want > to find the authoritative current copy, since you might’ve forgotten or you > want to join he current discussion, then you have to dig through the > emails and recursively apply the proposed change. It’s just easier if > people can have one proposal they can edit themselves. > * I’ve seen experienced people get confused about what was the current > proposal because they were replying to older emails or they didn’t see the > email with the clear examples. > * The mailing list is frankly obscure. Python community leaders and > package maintainers often are not aware or do not participate in > Python-ideas. Not many people know how to use or navigate a mailing list. > * No one really promotes the mailing list, you have to go out of your > way to find where new features are proposed. > * Higher discoverability means more people can participate, providing > their own use cases or voting (I mean using like or dislike measures, > consensus should still be how things are approved) go out of their way to > find so they can propose something. Instead, I envision a forum where > people can read and give their 2 cents about what features they might like > to see or might not want to see. >* More people means instead of having to make decisions from sometimes > subjective personal experience, we can make decisions with confidence in > what other Python devs want. > > Since potential proposers will find it easier to navigate a GUI forum, > they can read previous discussions to understand the reasoning, precedent > behind rejected and successful features. People proposing things that have > already been rejected before can be directed to open a subtopic on the > older discussion. > > > On Sep 18, 2018, at 3:19 PM, python-ideas-requ...@python.org wrote: > > > > Is that really an issue here? I personally haven't seen threads where > > Brett tried to stop an active discussion, but people ignored him and > > kept fighting. > ___ > 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] Moving to another forum system where
Oh wow, Google Groups is actually a much better interface. Any better forum software needs a system where people can voluntarily leave comments or feedback that is lower-priority. I'm not sure if Discourse has this, actually. Reddit comments are extremely compact as are Stack Overflow comments. I was going to propose that the PSF twitter account post a link to https://groups.google.com/forum/#!topic/python-ideas/, but I was worried that getting more subjective personal experiences might undesirably decrease the signal-to-noise ratio. On Wed, Sep 19, 2018 at 12:48 AM Franklin? Lee < leewangzhong+pyt...@gmail.com> wrote: > On Tue, Sep 18, 2018 at 8:21 PM James Lu wrote: > > > > > Is that really an issue here? I personally haven't seen threads where > > > Brett tried to stop an active discussion, but people ignored him and > > > kept fighting. > > Not personally with Brett, but I have seen multiple people try to stop > the “reword or remove beautiful is better than ugly in Zen of Python.” The > discussion was going in circles and evolved into attacking each other’s use > of logical fallacies. > > I disagree with your description, of course, but that's not important > right now. > > Multiple people *without any authority in that forum* tried to stop a > discussion, and failed. Why would it be any different if it happened > in a forum? Those same people still wouldn't have the power to lock > the discussion. They could only try to convince others to stop. > > If the ones with authority wanted to completely shut down the > discussion, they can do so now. The only thing that a forum adds is, > when they say stop, no one can decide to ignore them. If no one is > ignoring them now, then locking powers don't add anything. > > > Other than that, my biggest issues with the current mailing system are: > > > > * There’s no way to keep a updated proposal of your own- if you decide > to change your proposal, you have to communicate the change. Then, if you > want to find the authoritative current copy, since you might’ve forgotten > or you want to join he current discussion, then you have to dig through > the emails and recursively apply the proposed change. It’s just easier if > people can have one proposal they can edit themselves. > > * I’ve seen experienced people get confused about what was the current > proposal because they were replying to older emails or they didn’t see the > email with the clear examples. > > I agree that editing is a very useful feature. In a large discussion, > newcomers can comment after reading only the first few posts, and if > the first post has an easily-misunderstood line, you'll get people > talking about it. > > For proposals, I'm concerned that many forums don't have version > history in their editing tools (Reddit being one such discussion > site). Version history can be useful in understanding old comments. > Instead, you'd have to put it up on a repo and link to it. Editing > will help when you realize you should move your proposal to a public > repo. > > > * The mailing list is frankly obscure. Python community leaders and > package maintainers often are not aware or do not participate in > Python-ideas. Not many people know how to use or navigate a mailing list. > > * No one really promotes the mailing list, you have to go out of your > way to find where new features are proposed. > > * Higher discoverability means more people can participate, providing > their own use cases or voting (I mean using like or dislike measures, > consensus should still be how things are approved) go out of their way to > find so they can propose something. Instead, I envision a forum where > people can read and give their 2 cents about what features they might like > to see or might not want to see. > > Some of these problems are not about mailing lists. > > Whether a forum is more accessible can go either way. A mailing list > is more accessible because everyone has access to email, and it > doesn't require making another account. It is less accessible because > people might get intimidated by such old interfaces or culture (like > proper quoting etiquette, or when to switch to private replies). > Setting up an email interface to a forum can be a compromise. > > >* More people means instead of having to make decisions from > sometimes subjective personal experience, we can make decisions with > confidence in what other Python devs want. > > I don't agree. You don't get more objective by getting a larger > self-selected sample, not without carefully designing who will > self-select. > > But getting more people means getting MORE subjective personal > experiences, which is good. Some proposals need more voices, like any > proposal that is meant to help new programmers. You want to hear from > people who still vividly remember their experiences learning Python. > > On the other hand, getting more people necessarily means more noise > (no matter what system you use), and less time for
Re: [Python-ideas] Moving to another forum system where
Le 19/09/2018 à 15:28, Chris Angelico a écrit : > On Wed, Sep 19, 2018 at 11:23 PM Michel Desmoulin > wrote: >> - A is telling B this is a bad idea. It should be easy to tell if the >> person is experienced or not. You probably don't want to interact the >> same way with Victor and Yury, that have done numerous contributions to >> the Python core, and me, that is just a regular Python dev and don't >> know how the implementation work. > > Hmm, I'm not sure about this. Shouldn't a person's arguments be > assessed on their own merit, rather than "oh, so-and-so said it so it > must be right"? "Merit" is something hard to evaluate, having context help. If somebody comes and says "this is hard to implement so I doubt it will pass", Tim Peters does know better than the average Joe. If somebody says, "I advise you to do things the other way around, it works better on this mailing list". You will consider the advice more strongly if the author has been on the list 10 years or 10 days. Above all, if 2 people have opposite views, and that they both make sense, having the context of who they are helping. It's the same has if somebody gives you health advice. You do want to listen to everybody, but it's nice to know who is a doctor, and who is a somebody who repeats Facebook posts. It helps to decide. > > But if you want to research the people who are posting, you're welcome > to do that. The list of core dev experts is on the devguide: > > https://devguide.python.org/experts/ > > Translating those usernames back into real names would be done via BPO, I > think. This is a good summary of the problem with the list: you can do anything you want, but it cost you time and effort. And since you have many things to do, cumulatively, it's a lot of time and effort. I read all the posts and answered 2 mails on the list today. It took me 40 minutes. And I have been on the list for a long time so I know how the whole thing works so I'm pretty fast at doing this. Who can spend a lot of time every day, and yet feels to be just barely part of the discussion ? Who will take the time to do things right ? And among those few people, couldn't they do more good things if we'd save them time and energy ? Let's make the tool work for the community, and not against it. I agree that the mailing list is a great format for things like Python-dev. However, it's not a good fit for Python-idea: we have reached the limit of it for a long time. Most of the real decisions are actually taken outside of it, with more direct channels in the small groups of contributors. It slows down the decision process and it waste a lot of good will. > > 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] Moving to another forum system where
Le 19/09/2018 à 00:37, James Lu a écrit : >> Is that really an issue here? I personally haven't seen threads where >> Brett tried to stop an active discussion, but people ignored him and >> kept fighting. > Not personally with Brett, but I have seen multiple people try to stop the > “reword or remove beautiful is better than ugly in Zen of Python.” The > discussion was going in circles and evolved into attacking each other’s use > of logical fallacies. > > Other than that, my biggest issues with the current mailing system are: > > * There’s no way to keep a updated proposal of your own- if you decide to > change your proposal, you have to communicate the change. Then, if you want > to find the authoritative current copy, since you might’ve forgotten or you > want to join he current discussion, then you have to dig through the emails > and recursively apply the proposed change. It’s just easier if people can > have one proposal they can edit themselves. > * I’ve seen experienced people get confused about what was the current > proposal because they were replying to older emails or they didn’t see the > email with the clear examples. > * The mailing list is frankly obscure. Python community leaders and package > maintainers often are not aware or do not participate in Python-ideas. Not > many people know how to use or navigate a mailing list. > * No one really promotes the mailing list, you have to go out of your way > to find where new features are proposed. > * Higher discoverability means more people can participate, providing their > own use cases or voting (I mean using like or dislike measures, consensus > should still be how things are approved) go out of their way to find so they > can propose something. Instead, I envision a forum where people can read and > give their 2 cents about what features they might like to see or might not > want to see. >* More people means instead of having to make decisions from sometimes > subjective personal experience, we can make decisions with confidence in what > other Python devs want. > > Since potential proposers will find it easier to navigate a GUI forum, they > can read previous discussions to understand the reasoning, precedent behind > rejected and successful features. People proposing things that have already > been rejected before can be directed to open a subtopic on the older > discussion. +1 except for visibility I have been on this list for years and those issues have been a big problem ever since. But I agree with Antoine, quantity is not the problem. Quality is. However having no way to moderate efficiently means nobody does it, which means quality goes down. Since you have no way to identify who is who anyway, you can't know if the person telling you that you are out of line is an experienced member of the community or a newcomer with a lot of energy. Another things is that we keep having the same debates over and over. If you had the same duplication in code, it would never pass code reviews. The problem is looking up something, or making a reference to something is really hard on the list. A few scenario that seem important to me that are badly handled by this tool: - Person A is making a long constructive argument, and person B arrives, doesn't read anything, and make arguments against things that have been answered. It should be easy for somebody to link to the answers to this. - Somebody is making a proposal that has been already discussed and rejected several times. It should be easy to link to the discussions and conclusions about this. Even if the goal is to start the debate over again, at least we start ahead. - A is telling B this is a bad idea. It should be easy to tell if the person is experienced or not. You probably don't want to interact the same way with Victor and Yury, that have done numerous contributions to the Python core, and me, that is just a regular Python dev and don't know how the implementation work. - somebody wants to make a proposal. It should be easy to search if similar proposals already have been made, and read __ a summary __ of what happened. The bar to write a PEP is to high to serve that purpose: most proposal don't ever leave the list. ___ 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] Moving to another forum system where
On Tue, 18 Sep 2018 18:37:09 -0400 James Lu wrote: > * The mailing list is frankly obscure. Python community leaders and package > maintainers often are not aware or do not participate in Python-ideas. Not > many people know how to use or navigate a mailing list. > * No one really promotes the mailing list, you have to go out of your way > to find where new features are proposed. > * Higher discoverability means more people can participate, providing their > own use cases or voting (I mean using like or dislike measures, consensus > should still be how things are approved) go out of their way to find so they > can propose something. Instead, I envision a forum where people can read and > give their 2 cents about what features they might like to see or might not > want to see. I'm not sure that's a popular opinion, but I don't think I want more people around on python-ideas. There's enough quantity here. The problem is quality. 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 - How about using PEP 501?
>> I'd suggest using parso to do it. It's a really great library to write such >> transformations. > > Ah. It wasn't clear what your destination was, so I thought you were > talking about doing the translation itself using parso. But yeah, grab > one of these sorts of parsing libraries, do the transformation, save > back, then use a standard translation library. Seems a lot easier than > changing the language. Ah, my bad. I agree that this is the way forward for people who are trying to localize an existing app, but I still think we should _also_ change the language. F-strings are great and .format is powerful but there is a too big gap in usability and readability between them. This gap is one of the most compelling motivations for my suggestion of a short form for keyword arguments, while also helping us poor guys who deal with huge legacy code bases :) / 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] Combine f-strings with i18n - How about using PEP 501?
On Wed, Sep 19, 2018 at 4:52 PM Anders Hovmöller wrote:
>
>
> > How about this: Have a script that runs over your code, looking for
> > "translatable f-strings":
> >
> > _(f'Hi {user}')
> >
> > and replaces them with actually-translatable strings:
> >
> > _('Hi %s') % (user,)
> > _('Hi {user}').format(user=user)
> >
> > Take your pick of which way you want to spell it. Either of these is
> > easily able to be picked up by a standard translation package, is 100%
> > legal Python code in today's interpreters, and doesn't require any
> > bizarre markers and such saying that things need to be processed out
> > of order (the parentheses specify the order for you).
>
>
> I guess it wasn't clear before.. that's exactly what I was proposing :)
>
> I'd suggest using parso to do it. It's a really great library to write such
> transformations.
Ah. It wasn't clear what your destination was, so I thought you were
talking about doing the translation itself using parso. But yeah, grab
one of these sorts of parsing libraries, do the transformation, save
back, then use a standard translation library. Seems a lot easier than
changing the language.
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] Combine f-strings with i18n - How about using PEP 501?
> How about this: Have a script that runs over your code, looking for
> "translatable f-strings":
>
> _(f'Hi {user}')
>
> and replaces them with actually-translatable strings:
>
> _('Hi %s') % (user,)
> _('Hi {user}').format(user=user)
>
> Take your pick of which way you want to spell it. Either of these is
> easily able to be picked up by a standard translation package, is 100%
> legal Python code in today's interpreters, and doesn't require any
> bizarre markers and such saying that things need to be processed out
> of order (the parentheses specify the order for you).
I guess it wasn't clear before.. that's exactly what I was proposing :)
I'd suggest using parso to do it. It's a really great library to write such
transformations.
/ 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] Combine f-strings with i18n - How about using PEP 501?
On Wed, Sep 19, 2018 at 3:55 PM Steve Barnes wrote:
> Surely the simpler solution is to specify in I18n any items within
> un-escaped {} pairs is excluded from the translation, lookups, etc., and
> that translation needs to take place, also leaving the {} content alone,
> before f string processing. Other than that there is no change. So:
>
> _(f'Hi {user}') would be in the .po/.mo as just 'Hi ' and if our locale
> is set to FR this gets translated to f'Bonjor {user}' which then gets
> the user variable substituted in.
How about this: Have a script that runs over your code, looking for
"translatable f-strings":
_(f'Hi {user}')
and replaces them with actually-translatable strings:
_('Hi %s') % (user,)
_('Hi {user}').format(user=user)
Take your pick of which way you want to spell it. Either of these is
easily able to be picked up by a standard translation package, is 100%
legal Python code in today's interpreters, and doesn't require any
bizarre markers and such saying that things need to be processed out
of order (the parentheses specify the order for you).
Not everything has to be an f-string.
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] Pattern Matching Syntax (reprise)
Le mar. 18 sept. 2018 à 13:39, Tobias Kohn a écrit : > 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
