[Python-Dev] Re: Keeping Python a Duck Typed Language
I think what Christopher says is fair. My question (with little understanding of the underlying infrastructure) is can we define a 'type' that communicates that? Something like 'object that implements .read', or '.upper and .__iter__ for a spring-like object's? toonarmycaptain Original message From: python-dev-requ...@python.org Date: 4/21/21 2:44 PM (GMT-06:00) To: python-dev@python.org Subject: Python-Dev Digest, Vol 213, Issue 128 Send Python-Dev mailing list submissions to python-dev@python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman3/lists/python-dev.python.org/ or, via email, send a message with subject or body 'help' to python-dev-requ...@python.org You can reach the person managing the list at python-dev-ow...@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. Re: PEP 654: Exception Groups and except* [REPOST] (srku...@mail.de) 2. Re: PEP 654: Exception Groups and except* [REPOST] (Yury Selivanov) 3. Re: Keeping Python a Duck Typed Language. (Christopher Barker) -- Message: 1 Date: Wed, 21 Apr 2021 20:48:29 +0200 From: "srku...@mail.de" Subject: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST] To: Irit Katriel Cc: Irit Katriel , python-dev , Yury Selivanov Message-ID: <04512110-64b5-4ab3-ae54-ae6889c77...@mail.de> Content-Type: text/plain; charset=utf-8 Removing two concepts and preserving semantics simplifies the matter for users. People need less to memorize and less to learn. Or am I missing something here? Couldn’t we achieve our goal without these two new classes? Splitting, wrapping and exception handling semantics are perfectly fine and serve their purposes. So, of course this still needs to be implemented. > On 20. Apr 2021, at 23:26, Irit Katriel wrote: > > I don’t see what this simplifies. We still need to implement split, and to > worry about wrapping or not wrapping BaseExceptions and we still need to > define exception handling semantics (except/except*). > > >> On 20 Apr 2021, at 22:12, srku...@mail.de wrote: >> >> So, forgive me my relatively simple mental model about ExceptionGroup. I >> still try to create one for daily use. >> >> As noted in the discussion, an EG provides a way to collect exceptions from >> different sources and raise them as a bundle. They have no apparent relation >> up until this point in time (for whatever reason they have been separate and >> for whatever reason they are bundled now). The result would be a tree graph >> in any case. >> >> A usual datastructure for a tree is to store all child nodes at the parent >> node. >> >> That was the idea behind the content of BaseException.__group__: it’s the >> list of child exceptions bundled at a specific point in time and raise as >> such a bundle. So all exceptions could become EGs with the additional >> semantics you‘ve described in the PEP. >> >> Illustrative Example: > bundle_exc.__group__ >> [IOError(123), RuntimerError(‘issue somewhere’)] >> >> I was wondering what of the PEP could be removed to make it simpler and more >> acceptable/less confusing (also looking at reactions from Twitter etc.) and >> I found these additional classes to be a part of it. Additionally, I fail to >> see how to access these bundled exceptions in an easy manner like __cause__ >> and __context__. (As the PEP also referring to them). So, I removed the >> classes and added a regular attribute. >> >> The reason I brought this up what the section “rejected ideas” didn’t showed >> anything in this direction (or I managed to missed that). >> >> Sven >> >>> On 20. Apr 2021, at 22:05, Irit Katriel wrote: >>> >>> Hi Sven, >>> >>> I don’t follow. What would the value of __group__ be and how would it work? >>> >>> Irit >>> > On 20 Apr 2021, at 20:44, srku...@mail.de wrote: Hi Irit, reading this subthread specifically, I just got a wild idea and I couldn‘t find any related information in the PEP: Why not extending BaseException by __group__ among __cause__ and __context__? Would this reduce some of the added complexity and thus increase broader acceptance? Cheers, Sven >> -- Message: 2 Date: Wed, 21 Apr 2021 11:58:23 -0700 From: Yury Selivanov Subject: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST] To: "srku...@mail.de" Cc: Irit Katriel , Irit Katriel , python-dev , Yury Selivanov Message-ID: Content-Type: text/plain; charset="UTF-8" On Wed, Apr 21, 2021 at 11:50 AM srku...@mail.de wrote: > > Removing two concepts and preserving semantics simplifies the matter for > users. People need less to memorize and less to learn. > > Or am I mis
[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion
Add my name. From: python-dev-requ...@python.org Sent: Sunday, August 9, 2020 11:00 AM To: python-dev@python.org Subject: Python-Dev Digest, Vol 205, Issue 17 Send Python-Dev mailing list submissions to python-dev@python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman3/lists/python-dev.python.org/ or, via email, send a message with subject or body 'help' to python-dev-requ...@python.org You can reach the person managing the list at python-dev-ow...@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. Re: Python Documentation, Python language improvement, and productive discussion (Mats Wichmann) -- Date: Sun, 9 Aug 2020 09:39:32 -0600 From: Mats Wichmann Subject: [Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion To: python-dev@python.org Message-ID: <421995fd-99ae-99a5-0262-33d243c93...@python.org> Content-Type: text/plain; charset=utf-8 On 8/5/20 10:43 AM, Dominic Davis-Foster wrote: > Hi Carol, > > I was wondering if you've been able to set up the workgroup yet? I'd > certainly be interested in participating the there's an opportunity. > > > Stay safe > > Dom Indeed, I was wondering if there were any updates - I'm also interested in participating. -- mats -- Subject: Digest Footer ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ -- End of Python-Dev Digest, Vol 205, Issue 17 *** ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LB4UEY5BQB4PDLOTSVYLCCAOFL6ZBYS5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion (Antoine Pitrou)
actually names). Leaving this commit as it is will leave no trace of any "comment on the c= ommit" and later discussion to a future onlooker. And as a commit=20 is the official codebase, it will still appear as endorsed by the dev tea= m. There'd be no clue that this is not the "final" thoughts on the=20 matter and there something else, somewhere else, and who knows where. While editing the message to just state facts (clarifying the wording) an= d omit specuilations, it will still serve its purpose -- while=20 stating the actual, valid, endorsed by the team (since the concensus is t= hat the change itself was useful and should not be reverted but=20 could be improved further, as a separate initiative), clean from speculat= ions intent of the edit. On 02.07.2020 23:17, David Antonini wrote: > No contention to the contrary, but as a routine, post-merge git history= rewrite, not a grand plan, from what I understand. > > Oh the other hand, an 'official' comment on the commit, recognising the= issue with the original commit message, the following discussion,=20 > and any conclusions that get reached, might be better, in my opinion. I= prefer to recognise and critique, rather than erase, > 'historical' history, as a rule (as opposed to git history). I think si= milar damage is done in this case, when the record, and opportunity=20 > to point to and learn from it, is erased. > > David > > --- > Date: Thu, 2 Jul 2020 21:33:56 +0300 > From: Ivan Pozdeev > Subject: [Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou) > To: python-dev@python.org > Message-ID: > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed > On 02.07.2020 21:20, Chris Angelico wrote: > > On Fri, Jul 3, 2020 at 4:09 AM David Mertz wrote: > >>> An issue is that commit messages are uneditable after merge, so som= ething written somewhere suggesting consideration of this would be=20 > a good idea, with authors/mergers bearing this in mind, however unusual= a change on this basis would be. This would be additional burden=20 > on the core dev team, but if commitment is to be made to inclusivity, i= t might be what's necessary. > >> > >> I don't think so. https://docs.github.com/en/github/committing-chang= es-to-your-project/changing-a-commit-message. Interactive rebasing=20 > is perfectly possible, isn't it. I admit my git-fu isn't that strong, b= ut I've done something that I *think* is the same as this.=A0 It's=20 > possible I'm missing some distinction between the trees I've modified a= nd the current one, but I don't think so. > >> > > When you do that sort of rewriting, you're constructing a new and > > independent history and then saying "hey, this is the history I want > > everyone to respect now, thanks". It's full-on Back To The Future > > stuff, and can have annoying or serious consequences with everyone wh= o > > has a clone or fork of the repo. > > > > It would be extremely annoying to anyone who has an open PR at the > > time of the rewrite, but the annoyance would be temporary (hopefully > > one-off). > > > If you are talking about rewriting the PEP8 commit, it has proven to ca= use so much damage that this is warranted despite the=20 > inconveniences IMO. > > > ChrisA > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at https://mail.python.org/archives/list/python-dev@= python.org/message/A2XBFOH5WGEOASSXHHKRWEHMZBN625SU/ > > Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.= org/psf/codeofconduct/> > > -- > > Regards, > > Ivan > > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at https://mail.python.org/archives/list/python-dev@py= thon.org/message/ZZKGBAROR7TR2M7TM4EYSIIHXTUBQB4Y/ > Code of Conduct: http://python.org/psf/codeofconduct/ > --=20 > Regards, > Ivan --0905C79342DDD68A7F40BFCF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At https://git-scm.com/bo= ok/en/v2/Git-Branching-Rebasing#_rebase_vs_merge">https://git-scm.com/boo= k/en/v2/Git-Branching-Rebasing#_rebase_vs_merge, they say that the argument of whether to allow overwriting history in VCSes
[Python-Dev] Re Re: Recent PEP-8 change (Ivan Pozdeev)
No contention to the contrary, but as a routine, post-merge git history rewrite, not a grand plan, from what I understand. Oh the other hand, an 'official' comment on the commit, recognising the issue with the original commit message, the following discussion, and any conclusions that get reached, might be better, in my opinion. I prefer to recognise and critique, rather than erase, 'historical' history, as a rule (as opposed to git history). I think similar damage is done in this case, when the record, and opportunity to point to and learn from it, is erased. David --- Date: Thu, 2 Jul 2020 21:33:56 +0300 From: Ivan Pozdeev Subject: [Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou) To: python-dev@python.org Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed On 02.07.2020 21:20, Chris Angelico wrote: > On Fri, Jul 3, 2020 at 4:09 AM David Mertz wrote: >>> An issue is that commit messages are uneditable after merge, so something >>> written somewhere suggesting consideration of this would be a good idea, >>> with authors/mergers bearing this in mind, however unusual a change on this >>> basis would be. This would be additional burden on the core dev team, but >>> if commitment is to be made to inclusivity, it might be what's necessary. >> >> I don't think so. >> https://docs.github.com/en/github/committing-changes-to-your-project/changing-a-commit-message. >> Interactive rebasing is perfectly possible, isn't it. I admit my git-fu >> isn't that strong, but I've done something that I *think* is the same as >> this. It's possible I'm missing some distinction between the trees I've >> modified and the current one, but I don't think so. >> > When you do that sort of rewriting, you're constructing a new and > independent history and then saying "hey, this is the history I want > everyone to respect now, thanks". It's full-on Back To The Future > stuff, and can have annoying or serious consequences with everyone who > has a clone or fork of the repo. > > It would be extremely annoying to anyone who has an open PR at the > time of the rewrite, but the annoyance would be temporary (hopefully > one-off). If you are talking about rewriting the PEP8 commit, it has proven to cause so much damage that this is warranted despite the inconveniences IMO. > ChrisA > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/A2XBFOH5WGEOASSXHHKRWEHMZBN625SU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- > Regards, > Ivan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZZKGBAROR7TR2M7TM4EYSIIHXTUBQB4Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
Surely, if the argument is to be as inclusive and easy as possible, British English should be used? Things may have changed, but my impression is that the majority of English-second-language (ESL) speakers learn British English, not American. So maybe that should be the switch, if inclusivity and lowering the bar as much as possible is the ideal? Admittedly, I essentially switch between UK/US/Australian/Eastern European/Geordie/southern US/NZ English/French on a regular basis, so it's not a problem for me (but is something I'm possibly more conscious of than most), nor do I think a huge switch of US to UK spellings achieves much, but the nuances and connotation differences are meaningful. On the whole I agree with fixing on a policy where language style that is clear to the most people is the idea. I'm not sure of the wording that should be used to codify that, but something expressing a preference for clear expression in British English (or whatever dialect), with humility insisted on, and deference to 'the community' as to the clarity of wording. Politics aside, clarity and comprehension for the most is the goal, surely? [is what's already done, more or less with the docs, if I understand correctly?] An issue is that commit messages are uneditable after merge, so something written somewhere suggesting consideration of this would be a good idea, with authors/mergers bearing this in mind, however unusual a change on this basis would be. This would be additional burden on the core dev team, but if commitment is to be made to inclusivity, it might be what's necessary. The potential for inclusion and mentoring of contributors whose skill set is more toward documentation, and others who in future might contribute to CPython code is an added bonus. I've been holding this thought a little while, but since the discussion on English dialects has been raised, I think it's a point worth making. yours, David PS The issue with 'they' tends to be that it doesn't adequately convey singular/plural, as I encountered a *lot* writing Communications/Cultural Studies papers when I was at university/in college (see the dialects...). Other languages (say, French) have plural forms of gendered singular, but not an non-gendered form of either. An non-gendered singular, and gendered plurals in English could be useful, but I don't see either becoming accepted soon. The solution, for what it's worth, tended to be a neutral role noun, eg 'the coder', 'the writer', 'the consumer' - which in some cases has an advantage in clarity over they/he/she vis a vis both added role/verb information and gender neutral singular/pluralisation. -- Date: Thu, 2 Jul 2020 11:58:16 +0200 From: Antoine Pitrou Subject: [Python-Dev] Re: Recent PEP-8 change To: python-dev@python.org Message-ID: <20200702115816.77335477@fsol> Content-Type: text/plain; charset=US-ASCII On Thu, 2 Jul 2020 19:38:28 +1000 Chris Angelico wrote: > Standardizing on a > single language ensures that everyone can read the comments in a > single, consistent language. That was precisely my point. But "language" doesn't stop at the broad category "English" or "French", there are variations thereof, and that's why there can be more precise recommendations to ensure standardizing on a common variant of (for example) "English". Let's say someone write Python comments or documentation in "William Faulkner English" or "James Joyce English". It's gonna be very difficult to read for people like me. Regards Antoine. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KSBGDA3OYU2EMMD2MLXNGZFGHYSLVEZW/ Code of Conduct: http://python.org/psf/codeofconduct/
