Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
I don't see how this immediately helps the OP, who wants a *literal*
expression that automatically invokes the translation machinery as
well as the interpolation machinery.
Actually, no, I do not want the expression to be automatically
translated at compile time. It should be translated at run-time. There
are three situations.
1. No translation, just a regular f-string.
2. App translation. The f-string gets translated to the configured language.
3. On the fly translation. The string gets translated to the language
passed as an argument as required.
In code, this would be.
1. f'Hi {user}'
2. f'{!g}Hi {user}'
3. f'{lang!g}Hi {user}'
Cases 2 and 3 need some additional code, just like with gettext.
I'm sorry if that wasn't clear from the start. All I want is the code to
be simpler to write and maintain. I do not want to have complicated
parsing for the compiler.
Another way forward could be a preprocessor. All this can be done with a fairly
simple script using parso.
This is probably the idea.
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] Combine f-strings with i18n
On 17/09/18 19:42, Stephen J. Turnbull wrote:
> That's why I would like to see a parameter that can be passed to
> the f-string.
This doesn't make sense to me.
If I get a request in English, I need to return English.
If I get a request in French, I need to return French.
# At the start of the app, the languages get loaded in memory.
translate = translation('app','.locale')
translate.install()
es = translation('app','.locale',languages=['es'])
es.install()
# Get the preferred user language from the http request T(_('Hello {user}...'),
user_language,user=user)
def T(translatable_string, language=None, *args, **kwargs):
if 'es' == language:
# Return translated, formatted string return
es.gettext(translatable_string).format(**kwargs)
# Default, return formatted string return
translatable_string.format(**kwargs)
Such configurations are long-lasting.
If it is for the whole app, yes. Not if it is just the request.
1. No translation, just a regular f-string.
2. App translation. The f-string gets translated to the configured
language. Long lasting configuration.
3. On the fly translation. The string gets translated to the language
passed as an argument as required.
What could work is an extension to the formatting language. I suggest
abusing the *conversion flag*. (It's an abuse because I'm going to
apply it to the whole f-string, while the current Language Reference
says it's applied to the value being formatted.[1]) This flag would only
be allowed as the first item in the string. The idea is that
`f"{lang!g}Hello, {user}!"` would be interpreted as
Excellent. The syntax is unimportant to me.
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] Retire or reword the namesake of the Language
On Mon, 17 Sep 2018 22:06:28 -0400 "Franklin? Lee" wrote: > Monty Python had the goal of making people laugh, while python-ideas > has the goal of improving Python. With those priorities, we can have > fun, but not at the expense of potential contributions and > contributors. You are right. 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
On 17/09/18 20:10, Eric V. Smith wrote: See also PEP 501, which could be used for i18n. My first idea was to propose a t-string (for translatable string). 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 moderation is possible
Mike Miller writes: > A decent mail program can thread discussions and ignore the boring > ones. +100, but realistically, people aren't going to change their MUAs, especially on handhelds. The advantage of something like Discourse is that the server side controls the UX, and that's what people who don't want to change MUAs usually want. IMO the problems of these lists are a scale problem -- too many people, too many posts. As far as I can see, the only way to "fix" it is to become less inclusive, at least in terms of numbers. It's possible that a different technology will allow us to become more inclusive in terms of diversity at the same time that we become fewer. Steve ___ 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 moderation is possible
On Tue, Sep 18, 2018 at 2:37 PM Jonathan Goble wrote: > > On Tue, Sep 18, 2018, 2:00 PM Franklin? Lee > wrote: >> >> On Tue, Sep 18, 2018 at 11:02 AM Jonathan Goble wrote: >> > >> > The biggest moderation issue I see with mailing lists is the inability to >> > lock threads and delete posts (i.e. those that are spam or a Code of >> > Conduct violation). Both of those are basic features that are core to >> > virtually every forum system in existence today. >> >> 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. > > > Perhaps not, but part of that might be because stopping an active discussion > on a mailing list can be hard to do, so one might not even try. Some > discussions, I suspect, may have gone on in circles long past the point where > they would have been locked on a forum. With forum software, it becomes much > easier, and would be a more effective tool to terminate discussions that are > going nowhere fast and wasting everyone's time. But there's no evidence that such tools would help. Software enforcement powers are only necessary if verbal enforcement isn't enough. We need the current moderators (or just Brett) to say whether they feel it isn't enough. What people may really be clamoring for is a larger moderation team, or a heavier hand. They want more enforcement, not more effective enforcement. ___ 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 moderation is possible
On Tue, Sep 18, 2018, 2:00 PM Franklin? Lee wrote: > On Tue, Sep 18, 2018 at 11:02 AM Jonathan Goble > wrote: > > > > On Tue, Sep 18, 2018 at 10:49 AM Robert Vanden Eynde < > robertv...@gmail.com> wrote: > >> > >> About moderation, what's the problem on the list ? > > > > > > The biggest moderation issue I see with mailing lists is the inability > to lock threads and delete posts (i.e. those that are spam or a Code of > Conduct violation). Both of those are basic features that are core to > virtually every forum system in existence today. > > 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. > Perhaps not, but part of that might be because stopping an active discussion on a mailing list can be hard to do, so one might not even try. Some discussions, I suspect, may have gone on in circles long past the point where they would have been locked on a forum. With forum software, it becomes much easier, and would be a more effective tool to terminate discussions that are going nowhere fast and wasting everyone's time. > ___ 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 moderation is possible
On 09/18/2018 12:05 PM, Franklin? Lee wrote: On Tue, Sep 18, 2018 at 2:37 PM Jonathan Goble wrote: Perhaps not, but part of that might be because stopping an active >> discussion on a mailing list can be hard to do, so one might not even >> try. Some discussions, I suspect, may have gone on in circles long past >> the point where they would have been locked on a forum. With forum >> software, it becomes much easier, and would be a more effective tool to >> terminate discussions that are going nowhere fast and wasting everyone's >> time. True. But there's no evidence that such tools would help. Software enforcement powers are only necessary if verbal enforcement isn't enough. We need the current moderators (or just Brett) to say whether they feel it isn't enough. It isn't enough. What people may really be clamoring for is a larger moderation team, or a heavier hand. They want more enforcement, not more effective enforcement. More ineffective enforcement will be, um, ineffective. Let's have a test. I'm a moderator (from -List). We're* working on avenues to improve the mailing tools and simultaneously testing other options. I'm not seeing anything new in this thread that will impact that one way or another, so I'm asking for all of us to move on to other topics. -- ~Ethan~ * Various moderators from various lists. ___ 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 moderation is possible
> But there's no evidence that such tools would help. Software > enforcement powers are only necessary if verbal enforcement isn't > enough. We need the current moderators (or just Brett) to say whether > they feel it isn't enough. These systems work radically differently. You don’t get notifications for all messages in all threads by default. > What people may really be clamoring for is a larger moderation team, > or a heavier hand. They want more enforcement, not more effective > enforcement. If you just have good (granular, configurable) notifications for threads you don’t even need moderation. It side steps the entire problem. / 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 moderation is possible
> 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. SO is for Q, not for discussions. I recently had good success at the company I work for with Discourse, the sister/brother software to SO, which is designed specifically for discussions. https://www.discourse.org On Tue, Sep 18, 2018 at 11:12 AM, Oleg Broytman wrote: > On Tue, Sep 18, 2018 at 04:48:18PM +0200, Robert Vanden Eynde < > robertv...@gmail.com> wrote: > > As said 100 times in the list, email is powerful, configurable but needs > a > > lot of configuration (especially hard on mobile) and has a lot of rules > > (don't top post, reply to the list, don't html, wait, html is alright) > > whereas a web based alternative is easier to grasp (more modern) but adds > > more abstraction. > > > > I can't find the link we had explaining the difference between those two, > > but mailing list is easily searchable and archivable and readable on a > > terminal. > >May I show mine: https://phdru.name/Software/mail-vs-web.html ? > > 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/ > -- Juancarlo *Añez* ___ 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 moderation is possible
On Tue, Sep 18, 2018 at 11:02 AM Jonathan Goble wrote: > > On Tue, Sep 18, 2018 at 10:49 AM Robert Vanden Eynde > wrote: >> >> About moderation, what's the problem on the list ? > > > The biggest moderation issue I see with mailing lists is the inability to > lock threads and delete posts (i.e. those that are spam or a Code of Conduct > violation). Both of those are basic features that are core to virtually every > forum system in existence today. 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] An experiment migrating bug tracker to GitLab
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 3 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 ___ 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 moderation is possible
Since 1972, there have been hundreds of reinventions of a means of carying on electronic conversations intended to be "better than email." The one thing they all have in common is that they are vastly worse than email. On Tue, Sep 18, 2018, 6:04 PM Jan Claeys wrote: > On Tue, 2018-09-18 at 11:02 -0400, Jonathan Goble wrote: > > The biggest moderation issue I see with mailing lists is the > > inability to lock threads > > That actually wouldn't be hard to implement in a mailing list software > as a semi-automatic moderation feature... > > > -- > Jan Claeys > ___ > 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 moderation is possible
On Tue, 2018-09-18 at 11:02 -0400, Jonathan Goble wrote: > The biggest moderation issue I see with mailing lists is the > inability to lock threads That actually wouldn't be hard to implement in a mailing list software as a semi-automatic moderation feature... -- Jan Claeys ___ 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
> 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/
Re: [Python-ideas] Moving to another forum system where
It would be nice if there was a guide on using Python-ideas and writing PEPs. It would make it less obscure. ___ 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 moderation is possible
On Tue, Sep 18, 2018, 8:43 PM Jan Claeys wrote: > On Tue, 2018-09-18 at 18:07 -0400, David Mertz wrote: > > Since 1972, there have been hundreds of reinventions of a means of > > carying on electronic conversations intended to be "better than > > email." The one thing they all have in common is that they are vastly > > worse than email. > > I don't 100% agree with that. > > E.g., there are better protocols when you need real-time conversations, > because (internet) email isn't necessarily good at that (by design). > Good point, 1988 IRC also serves a good purpose that is also poorly copied in hundreds of new systems. :-) > ___ 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, 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 new people to acclimate. > 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. A kind of GUI version already exists, precisely because this is a public mailing list. Google Groups provides a mirror of the archives. https://groups.google.com/forum/#!forum/python-ideas It's searchable, and possibly replyable. You can even star conversations (but not hide them). If it isn't listed on some python.org page, maybe it should be. Personally, when I want to
Re: [Python-ideas] Moving to another forum system where moderation is possible
On Tue, 2018-09-18 at 18:07 -0400, David Mertz wrote: > Since 1972, there have been hundreds of reinventions of a means of > carying on electronic conversations intended to be "better than > email." The one thing they all have in common is that they are vastly > worse than email. I don't 100% agree with that. E.g., there are better protocols when you need real-time conversations, because (internet) email isn't necessarily good at that (by design). And I'm sure there are other circumstances or purposes where another protocol/standard is more appropriate. But in general, email is pretty good. :) -- Jan Claeys ___ 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 10:21 AM James Lu wrote: > > 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. > That's what the PEP system exists for. But with the "remove the word ugly from the zen" proposal, it's not serious enough for anyone to actually want to write up a PEP about it. Normally, what happens is that the "authoritative current copy" can always be found at https://www.python.org/dev/peps/pep-/ for some well-known PEP number. That PEP generally has a single authoritative author (sometimes two or three, but always a small number). For any proposal that actually has currency, this system does work (well enough that I've wanted to introduce something like it in other contexts). 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] Moving to another forum system where moderation is possible
On Wed, Sep 19, 2018 at 10:43 AM Jan Claeys wrote: > > On Tue, 2018-09-18 at 18:07 -0400, David Mertz wrote: > > Since 1972, there have been hundreds of reinventions of a means of > > carying on electronic conversations intended to be "better than > > email." The one thing they all have in common is that they are vastly > > worse than email. > > I don't 100% agree with that. > > E.g., there are better protocols when you need real-time conversations, > because (internet) email isn't necessarily good at that (by design). Which part of email or internet is "by design" not good for real-time conversation? With any non-stupid MUA, emails are sent virtually instantly, unless the destination server is down. Of course, if you're used to accessing Gmail via your mobile phone app, you probably aren't accustomed to real-time conversations in email; but that is not the *design* of email. 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] Moving to another forum system where
On Wed, Sep 19, 2018 at 11:05 AM James Lu wrote: > > It would be nice if there was a guide on using Python-ideas and writing PEPs. > It would make it less obscure. https://www.python.org/dev/peps/pep-0001/ On Wed, Sep 19, 2018 at 11:17 AM Michael Selik wrote: > > On Tue, Sep 18, 2018 at 5:57 PM Chris Angelico wrote: > > For any proposal that actually has currency, this system does work > > The trouble is the ambiguity of knowing what "actually has currency" > is and how to get it. PEP 1 states, "Following a discussion on > python-ideas, the proposal should be submitted as a draft PEP via a > GitHub pull request." However, PEP 1 does not give instruction on how > to evaluate whether that discussion has been completed satisfactorily. Fair point. However, if there's enough in an idea that it's worth pushing forward, and too much for it to just go straight to the issue tracker or a GitHub PR, someone will usually recommend it at some point. In borderline cases, the decision of whether it's PEP-worthy or not generally comes down to "is someone willing to write and shepherd the PEP" - it's a fair bit of work, and a lot of incoming emails to deal with. 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] Moving to another forum system where moderation is possible
On 9/18/18 11:02 AM, Jonathan Goble wrote: > On Tue, Sep 18, 2018 at 10:49 AM Robert Vanden Eynde > mailto:robertv...@gmail.com>> wrote: > > About moderation, what's the problem on the list ? > > > The biggest moderation issue I see with mailing lists is the inability > to lock threads and delete posts (i.e. those that are spam or a Code > of Conduct violation). Both of those are basic features that are core > to virtually every forum system in existence today. > > Mailing lists offer no moderation of posts or threads unless every > post is held in a moderation queue and manually approved before being > sent, which isn't practical for large high-traffic lists like this. > Instead, the only recourse is to moderate the user by banning or > muting them, which can sometimes result in essentially using a > sledgehammer to kill a fly. That is particularly the case if the only > problems are on one heated thread where five people are attacking each > other, but all are contributing constructively to other threads, in > which case the best response is to simply terminate the argument by > locking the thread. But on a mailing list, one would have to ban or > mute all five users instead, impacting all of the other threads those > users were contributing to. This is incorrect. I run a moderate volume (~100 posts per day) mailing list for my local community using the same software as python.org. When a thread gets out of bounds I can enter a message filter to hold for review any message matching the subject of that thread (or specified parts of it). While people can get around the filter by changing the subject line, they can do the same on a forum by starting a new topic. Someone who intentionally does this does get themselves on personal moderation. -- Richard Damon ___ 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 18/09/2018 08:59, Hans Polak wrote:
>
>>> I don't see how this immediately helps the OP, who wants a *literal*
>>> expression that automatically invokes the translation machinery as
>>> well as the interpolation machinery.
> Actually, no, I do not want the expression to be automatically
> translated at compile time. It should be translated at run-time. There
> are three situations.
>
> 1. No translation, just a regular f-string.
> 2. App translation. The f-string gets translated to the configured
> language.
> 3. On the fly translation. The string gets translated to the language
> passed as an argument as required.
>
> In code, this would be.
> 1. f'Hi {user}'
> 2. f'{!g}Hi {user}'
> 3. f'{lang!g}Hi {user}'
>
> Cases 2 and 3 need some additional code, just like with gettext.
>
> I'm sorry if that wasn't clear from the start. All I want is the code to
> be simpler to write and maintain. I do not want to have complicated
> parsing for the compiler.
>
>>> Another way forward could be a preprocessor. All this can be done
>>> with a fairly simple script using parso.
> This is probably the idea.
>
> 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/
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.
If you wanted to insert into an f string a value that is itself subject
to I18n you need to mark the content assigned to that value for
translation. For example:
parts_of_day = [_("Morning"), _("Afternoon"), _("Evening"), _("Night"), ]
tod = lookup_time_as_pod()
greeting = _(f"Good {tod}")
If our locale happens to be a German one and our current time of day is
morning then tod will be assigned as "morgan" and our greeting will be
"Gutten Morgan", etc.
This should work without any major problems whether our locale is fixed
at start-up or changes dynamically.
As far as I can see the only possibly required change to the core python
language is that the evaluation order may need to be able to be
override-able so that the translate function, (with the leave {.*} alone
rule), is called _before_ the f string formatting, (I think that with
current precedence it would not). Is there, or could there be, an
"@eager" or "@push_precedence" decorator, or some such, that could be
added to translate so as to do this? The remaining changes would be in
the translate/I18n package(s) and the documents of course.
--
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.
---
This email has been checked for viruses by AVG.
https://www.avg.com
___
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)
Needless to say it's interesting to see what others language have (pros and cons), I'm thinking about Scala for example (but I'm sure perl can show us a long list of pros and cons). Le mar. 18 sept. 2018 à 13:38, 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
Re: [Python-ideas] Moving to another forum system where moderation is possible
As said 100 times in the list, email is powerful, configurable but needs a lot of configuration (especially hard on mobile) and has a lot of rules (don't top post, reply to the list, don't html, wait, html is alright) whereas a web based alternative is easier to grasp (more modern) but adds more abstraction. I can't find the link we had explaining the difference between those two, but mailing list is easily searchable and archivable and readable on a terminal. However, providing guis to mailing list is a nice in between to have the better of two worlds. About moderation, what's the problem on the list ? Le mar. 18 sept. 2018 à 10:44, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> a écrit : > Mike Miller writes: > > > A decent mail program can thread discussions and ignore the boring > > ones. > > +100, but realistically, people aren't going to change their MUAs, > especially on handhelds. The advantage of something like Discourse is > that the server side controls the UX, and that's what people who don't > want to change MUAs usually want. > > IMO the problems of these lists are a scale problem -- too many > people, too many posts. As far as I can see, the only way to "fix" it > is to become less inclusive, at least in terms of numbers. > > It's possible that a different technology will allow us to become more > inclusive in terms of diversity at the same time that we become fewer. > > Steve > ___ > 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/
[Python-ideas] Pattern Matching Syntax (reprise)
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
Re: [Python-ideas] Moving to another forum system where moderation is possible
On Tue, Sep 18, 2018 at 10:49 AM Robert Vanden Eynde wrote: > About moderation, what's the problem on the list ? > The biggest moderation issue I see with mailing lists is the inability to lock threads and delete posts (i.e. those that are spam or a Code of Conduct violation). Both of those are basic features that are core to virtually every forum system in existence today. Mailing lists offer no moderation of posts or threads unless every post is held in a moderation queue and manually approved before being sent, which isn't practical for large high-traffic lists like this. Instead, the only recourse is to moderate the user by banning or muting them, which can sometimes result in essentially using a sledgehammer to kill a fly. That is particularly the case if the only problems are on one heated thread where five people are attacking each other, but all are contributing constructively to other threads, in which case the best response is to simply terminate the argument by locking the thread. But on a mailing list, one would have to ban or mute all five users instead, impacting all of the other threads those users were contributing to. ___ 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 moderation is possible
On Tue, Sep 18, 2018 at 04:48:18PM +0200, Robert Vanden Eynde wrote: > As said 100 times in the list, email is powerful, configurable but needs a > lot of configuration (especially hard on mobile) and has a lot of rules > (don't top post, reply to the list, don't html, wait, html is alright) > whereas a web based alternative is easier to grasp (more modern) but adds > more abstraction. > > I can't find the link we had explaining the difference between those two, > but mailing list is easily searchable and archivable and readable on a > terminal. May I show mine: https://phdru.name/Software/mail-vs-web.html ? 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/
