[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 16/07/2020 17:37, Steve Holden wrote: While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with try/except/except/.../finally/else, and nobody seems to think that the excepts should be indented. Or the finally. And naturally the match/else case are at the same indentation level, just as for/else, while/else and try/finally. So why, exactly, should case be indented? My take on the difference would be that "try" tries out a suite, while "match" matches an expression. If we did: match: case : then having an indented section which must be a single expression would be unique in Python syntax. I could easily see people being confused when the slew of statements they would inevitably decide they must be able to put there, and soon we'd have cats and dogs living together and the downfall of civilisation as we know it. Alternatively: match : case : would be the one place in Python where you end a line with a colon and *don't* indent the following line. Writers of simple formatters and the like (such as Python-mode in Emacs) would curse your name, etc, etc. My apologies for being a Bear of Very Little Brain. Nah, don't apologise. This is one of those things that everyone has opinions on, because there doesn't seem to be an obvious Right Answer. -- Rhodri James *-* Kynesim Ltd ___ 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/JYDDPBDO56EQWTFSWY2NNDNT2NDHWXG5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 constant value syntax idea
On 15/07/2020 12:37, Mohammad Foroughi via Python-Dev wrote:
Hi, I had an idea regarding the pattern matching issue of comparing with a
previous constant variable instead of assigning to a new local variable. I'm
not sure if this has been brought up before but instead of using a symbol with
the case statement what if we used a keyword.
Your mailer mangled your example a bit, but it's fairly clear all the
same. The problem with using a keyword is that it starts getting really
ungainly with complex patterns:
match value:
case global x:
print("value matches")
case Point(global x, y):
print("value matches x, y captured")
case Line(Point(global x1, y1), Point(x2, global y2)):
print("getting a bit hard to read here")
Probably the simplest thing to do is to use a namespace to force value
comparison.
from types import SimpleNamespace
# ... stuff ...
const = SimpleNamespace(x=x)
match value:
case const.x:
print("value matches")
case Point(const.x, y):
my_useful_struct.y = y
It's not ideal, but it's fairly clear what's going on if you choose your
names carefully. (And damn it, I've argued myself round to the position
I was trying to argue Tim out of a few weeks ago. Curses!)
--
Rhodri James *-* Kynesim Ltd
___
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/XVUUS4D5JMG5MWWGWPVDV6XNGR34AU6U/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 13/07/2020 15:33, Guido van Rossum wrote: On Mon, Jul 13, 2020 at 04:35 Rhodri James wrote: [Re: forbidding **_ in mapping patterns] I’d rather not. And the argument about disallowing obviously redundant syntax seems weak. My worry about allowing this is that it’ll be cargo culled and we’ll see it used not for emphasis (of what? The obvious?) but because people think it’s needed. And that’s just clutter. Fair enough. I'd likely use it to remind myself of cases when there will always be more keys in the mapping, but a comment will do just as well. Can I use pattern matching to pull byte strings apart? I thought I could, but trying it out in the playground didn't work at all. :-( It’s explicitly forbidden by the PEP, because we don’t want str or bytes to accidentally match sequence patterns. You could do ‘match list(b):’ if you really wanted to, but I think there are better tools for parsing bytes or strings. :-( As an embedded engineer, pulling apart network protocols was the first use I thought of for matching. Ah well. -- Rhodri James *-* Kynesim Ltd ___ 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/FDWO3SN3FTKUOMYCO3HRYDCPWMBGBM4P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 12/07/2020 23:20, Guido van Rossum wrote: So can we please lay this one to rest? Sure. One small thing before we leave it; I've decided I don't care about the special cases of not using _. to lead class names, but forbidding **_ in mapping patterns seems unnecessary. I know it's redundant, but I can imagine using it for emphasis. I can't think of anywhere else the language forbids something just because it isn't needed, though I didn't get a lot of sleep last night and I could well be missing something obvious :-) Can I use pattern matching to pull byte strings apart? I thought I could, but trying it out in the playground didn't work at all. :-( -- Rhodri James *-* Kynesim Ltd ___ 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/WD2E3K5TWR4E6PZBM4TKGHTJ7VDERTDG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 11/07/2020 12:20, Paul Sokolovsky wrote: Actually, the whole argument in PEP 622 regarding "else:", that its placement is ambiguous sounds like a rather artificial write-off. Individual "case"'s are aligned together, but suddenly, it's unclear how to align the default case, introduced by "else"? Who in good faith would align it with "match"? I would, if I'd used an "else" with a "for" recently. I would have a strong tendency to align the "else" with the "case" statements, but I can see how the other way around makes sense too. (I can't see how anyone likes the Linux case indentation style at all. It's horrible to read.) -- Rhodri James *-* Kynesim Ltd ___ 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/YAAEFSSIT3QL2AZJCUP6UZZTU7AYLVEF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 11/07/2020 20:13, Eric Nieuwland wrote: Just after I hit ‘send’ it dawned on me it might be preferable to make that match poly: p0 = Point(x0, y0) p1 = Point(x1, y1) p2 = Point(x2, y2) case Polygon(p0, p1, p2): … so the part preceded by ‘match’ is the preparation phase for matching. Are you intending p0, p1 and p2 to be subpatterns rather than object instantiations? That makes me a little twitchy; the difference between what you wrote and: match poly: p0 = Point(x0, y0) p1 = Point(x1, y1) case Polygon(p0, p1, p2): ... is very easy to miss. -- Rhodri James *-* Kynesim Ltd ___ 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/VOKSUVYJTFKTES6Z7SSEZAVKOW6FT4UQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 08/07/2020 19:27, Gustavo Carneiro wrote: Forgive the intrusion, in case this wasn't already mentioned (I only read a fraction of emails on this), we could say that name enclosed in parenthesis would mean loading a constant, instead of storing in a variable: It's discussed as the third bullet point under "Alternatives for constant value pattern": https://www.python.org/dev/peps/pep-0622/#id74 Basically it looks odd and we may need parentheses to manage grouping in patterns. -- Rhodri James *-* Kynesim Ltd ___ 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/MMIHVMJEUQASMBTPUKIWZZXINRG43E5V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 08/07/2020 19:08, Antoine Pitrou wrote:
On Wed, 8 Jul 2020 18:38:12 +0100
Rhodri James wrote:
On 08/07/2020 16:02, Guido van Rossum wrote:
Today I’m happy (and a little trepidatious) to announce the next
version of PEP 622, Pattern Matching.
Thank you very much to everyone who has been working on this, it is much
appreciated. I have one suggestion for the text: could the section on
Capture Patterns emphasise that only simple (i.e not dotted) names are
capture patterns? The simplified grammar is (fairly) clear and the
later section on Constant Value Patterns should make it obvious, but
somehow when reading version 1 I still managed to miss it. I was quite
surprised when it was pointed out that
case (point.x, point.y):
wasn't going to do what I expected!
Why did you expect? It's not clear to me what it should do at all :-)
I was expecting it to unpack a 2-tuple(/sequence?) into the x and y
attributes of this point object I happened to have in my back pocket
(assuming it matched, of course). It actually matches a 2-tuple against
the values of those attributes (i.e. they are constant value patterns).
It's obvious enough once you have time to read the PEP properly -- I
blame only having so many minutes of reading time in my
compile/download/test cycle!
To use code(ish) examples rather than confusable words, suppose we have:
class Point:
def __init__(self):
self.x = 0
self.y = 0
point = Point()
INCOMING = (1, 2)
match INCOMING:
case (point.x, point.y):
print("Point @", point.x, point.y)
case _:
print("Default")
I expected printout of:
Point @ 1 2
but I would actually get
Default
If on the other hand INCOMING was (0, 0), I would get
Point @ 0 0
because the first case is in fact the equivalent of
case (0, 0):
Obviously this is a pointless example (pun intended) because you would
use a class pattern if you really wanted to do something like what I
first thought of.
--
Rhodri James *-* Kynesim Ltd
___
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/5IWR4AM7YFXG2CK4IHTAJB45FTBXH3AK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 08/07/2020 16:02, Guido van Rossum wrote: Today I’m happy (and a little trepidatious) to announce the next version of PEP 622, Pattern Matching. Thank you very much to everyone who has been working on this, it is much appreciated. I have one suggestion for the text: could the section on Capture Patterns emphasise that only simple (i.e not dotted) names are capture patterns? The simplified grammar is (fairly) clear and the later section on Constant Value Patterns should make it obvious, but somehow when reading version 1 I still managed to miss it. I was quite surprised when it was pointed out that case (point.x, point.y): wasn't going to do what I expected! (PS: I'm still pushing for an "else" clause, and I can see arguments for it going at either indentation level. Since putting the clause at the wrong level would be a syntax error, I don't see it being a particularly big issue where it goes.) -- Rhodri James *-* Kynesim Ltd ___ 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/OZI6TIM6272O5WMSNEL4YQUBTRPUKJ6T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup
On 08/07/2020 11:05, Federico Salerno wrote: What I don't like is the use of _ as catch-all, which is different and not interdependent with its use as throwaway. Any name used as a pattern is a catch-all. The only difference between "case dummy:" and "case _:" is that "_" doesn't bind to the thing being matched, but "dummy" does bind to it. -- Rhodri James *-* Kynesim Ltd ___ 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/ZU6MJDE4CMMQDYYAJLKWTA2FOAIR5IPG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]
On 07/07/2020 15:31, Henk-Jaap Wagenaar wrote: On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: I'm not keen on special treatment of the '_' variable, and would prefer to be able to use 'else:' after 'match'. I used to be in this "camp", however, a (I think valid) point was raised that "else:" is not a (full) alternative. Due to the restriction on repeated names (e.g. Point(x, x) is illegal), if you want to "throw away" intermediate matches, you will have to either have to come up with new names (Point(unused_1, unused_2)) or use the "_" as currently instituted (Point(_, _)) and "else:" does not cover that insofar as I can tell. There are two things here, the specialness of "_" and using "else:" as the catch-all clause. I'm not quite convinced about making "_" non-binding, mostly because of the knock-on effects in the PEP for other types of patterns. It seems to breed more special cases, and I can't help but feel that's a bad sign. On the other hand "else:" would have exactly the effect of "case _:", so we're into arguments about there preferably being only one obvious way to do things. I'd maintain that "else:" is obvious :-) -- Rhodri James *-* Kynesim Ltd ___ 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/EIBEIZ7QLBO3RBH253D7ZK5WTRNKHSYD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 04/07/2020 21:23, MRAB wrote: On 2020-07-04 19:23, Paul Moore wrote: On Sat, 4 Jul 2020 at 17:48, MRAB wrote: > > On 2020-07-04 05:51, Greg Ewing wrote: > > On 4/07/20 4:33 am, Jim J. Jewett wrote: > >> If Bob and Alice seem neutral to you, would you do a double-take on Kehinde or Oladotun? > > > > Maybe we should use randomly generated names for hypothetical persons? > > > Ideally they should be short names, one or two syllables. Surely the obvious thing to do would be to use Monty Python characters? True, but if they were all called Eric it could be confusing. Yes, we'd have to call them Bruce to avoid confusion. -- Rhodri James *-* Kynesim Ltd ___ 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/N3GPOQ4ZJPM2MEFCOJ4PLOMO6TWDEKD5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Flexible assignment targets
On 03/07/2020 00:12, Nick Coghlan wrote: On Fri., 3 Jul. 2020, 2:27 am MRAB, wrote: IMHO, the assignment statement should remain as it is, not sometimes assign and sometimes not. There could be another form that does matching: try ?x, 0 = (4,5) Huh, this made me wonder if "match/try" may fit people's brains better than "match/case". I know for me that I want to read case clauses the same way I would read them in C, which is thoroughly unhelpful. The following looks weird though, so I don't think I actually like it in practice: === match shape: try Point(x, y): ... try Rectangle(x0, y0, x1, y1, painted=True): ... I'm actually surprised at how much I like that. It certainly gets me out of the C mindset and makes it easier for me to recognise that Point(x,y) isn't an instantiation. -- Rhodri James *-* Kynesim Ltd ___ 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/R32T63WXY3ILFKSMISY3KIKA7LUGBKZC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On 03/07/2020 01:10, Łukasz Langa wrote: Commit messages aren't usually scrutinized to this extent. Commit messages are usually political statements. Formal proposal: leave this alone. -1. Simply by having it in the repository, the statement implicitly has the support of the Python community (more specifically the Steering Council). Given the manifest controversy, leaving it alone is... a brave decision, minister[*] [*] See the original UK TV series "Yes, Minister" and "Yes, Prime Minister". The senior civil servant praises his minister for making a "brave decision" when he wants to point out consequences the minister won't like. -- Rhodri James *-* Kynesim Ltd ___ 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/7CZMBZUCD4VV3RQPFC3CNZTP7RVDWYRZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 02/07/2020 17:47, Piper Thunstrom wrote: In terms of modern English vernacular, singular "they" has been continuously and rigorously treated as inappropriate. I think you may be being a tad parochial again. I can think of plenty of English vernaculars that treat singular "they" as perfectly appropriate. I don't like it personally, but I've only ever thought of RP (in my British parochialism) as trying to suppress it with any serious effort. -- Rhodri James *-* Kynesim Ltd ___ 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/KO7QFT5IEZM7RPKC4CAQFT46WPHLVP2L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 02/07/2020 18:12, MRAB wrote: English isn't Latin. Bizarre as it may sound, I still occasionally find that hard to remember. My English Language teachers were only really interested in teaching English Literature, and considered grammar to be one of those unfortunate things it was better to hide from students. It was in Latin classes that I learned how sentences are put together, and that's what I default to when I'm not thinking hard enough. -- Rhodri James *-* Kynesim Ltd ___ 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/B323CAMMYNWEVQIFWTMHS7DK3LSJBGE6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 02/07/2020 15:25, Inada Naoki wrote: I don't think I can write such clear English without help. But having such a goal is inclusive for non native English readers. I wouldn't be so certain. You have an advantage over native English speakers in that you don't use idiomatic cultural references, so you will tend to write clearly and with common vocabulary. Just as Strunk and White would advise :-) -- Rhodri James *-* Kynesim Ltd ___ 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/G56XDSCQ2GJPUFZ2LWWB45J2WZ62WILH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 02/07/2020 14:52, Paul Moore wrote:
On Thu, 2 Jul 2020 at 14:34, Henk-Jaap Wagenaar
wrote:
PEP-8 however does not mention a particular edition and the version that is readily
available (in the public domain) does contain this problematic section "to use the
masculine pronouns whenever possible" which is not inclusive.
(This is a genuine question, and I'm terrified of being yelled at for
asking it, which gives an idea of the way this thread has gone - but I
genuinely do want to know, to try to improve my own writing).
What *is* the correct inclusive way to refer to an unidentified person
in a technical document, without sacrificing clarity by using
convoluted circumlocutions like "he/her/they" or over-use of the
passive voice? My impression is that commonly accepted language rules
and usage are lagging behind, and there's no good answer to this
question yet :-(
It depends a bit on circumstances. Often it's easy to rephrase to use a
plural noun ("If users want to be able to frobnicate, they can set
ALLOW_FROBNICATION=1..."). If you can't do that, you're basically
stuffed. "He or she" is unlovely, all the variations of it that people
have come up with over the years are worse, "he" will trigger people
prone to seeing overarching patriarchalism, "she" will trigger people
prone to seeing overarching feminism, and "they" will trigger people who
think it's just wrong :-/
--
Rhodri James *-* Kynesim Ltd
___
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/ECFLQNMKIX4RRBHDAHM4NMGKSDOHX76R/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Flexible assignment targets
On 01/07/2020 15:50, Guido van Rossum wrote: Before we all get a little too excited here, I think that allowing ``` 1 = x ``` as a sneaky way of writing ``` assert x == 1 ``` would be a terrible mistake. +1 One of Python's major virtues is that it's pretty easy to read and get the gist of what's going on, even if the details take a bit more work. If you have to second-guess every assignment, much of that virtue is lost. -- Rhodri James *-* Kynesim Ltd ___ 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/PF4UPIUEB5QNPVWU3FOSZX26VQOPFTNH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 30/06/2020 16:54, Piper Thunstrom wrote: I do not. We must, as a community, examine our prejudices and aim to be welcoming or we're going to see a split in Python much worse than Py2 -> Py3. Curiously I am yet to see any acknowledgement that the change itself may be detrimental to neuro-atypical people, of whom there are a fair number in the wider Python community (I've taught a number of them Python, so I know that to be true). I didn't consider the point before Steven and Stephen raised it -- like most people, I don't automatically scan for prejudices except the ones I know I am prone to -- but it does fit with what I know of the Aspergers kids I've met. The fundamental issue is this: your politics are not my politics. Keara's politics are not my politics. I don't know either of you well enough, but I strongly suspect that your politics and Keara's politics are not the same either. That's a perfectly natural state of affairs for human beings. The commit message going with the (mild) relaxation of writing standards is a political statement. I hope there's no argument about that. That sets a precedent. Unless the Steering Committee pronounce otherwise (and I hope they do), it is now OK to publish political statements as part of a commit message, presuming they can be contorted to relevance somehow (and that's usually not hard). I guarantee you won't like some of those message, _but the precedent is being set._ Just because a statement is controversial doesn't mean it can't be accepted. Ultimately, putting political statements in non-political places is divisive. This whole exercise is a demonstration of that divisiveness. That's why I don't think they should be allowed in commit messages, even when I agree with them. And that's why I think the commit message in question should be amended ASAP. -- Rhodri James *-* Kynesim Ltd ___ 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/LKLSLDAPRJRDH5SMVBBROLSAGO4RZWFC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 30/06/2020 18:02, Mark Lawrence wrote: I suggest Geordie or Glaswegian on the grounds that most people outside of the UK have probably never heard of them hence they should be regarded as neutral in any world wide debate on English. Possibly not. I do recall an occasion when a Glaswegian and a Texan (I think, he was from somewhere Deep South) tried to communicate. They had to get a passing Dutchman to translate for them. (No joke, that really happened.) -- Rhodri James *-* Kynesim Ltd ___ 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/JAUQEWNWPHSZQ2L4467Q4SL6O6OFWM3K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On 30/06/2020 17:48, Alan G. Isaac wrote: Which people in the Python community are entitled to say that they find a commit message to be offensive and have that claim treated seriously, compassionately, and as a good reason for accommodative action? Anyone, for any reason. IMHO, obviously. We (individually and collectively) may decide that their reasons don't hold water, but we should always listen. -- Rhodri James *-* Kynesim Ltd ___ 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/BVE4X7PQGPSLBL5QDMKTRZ3TDU3EGT5D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 30/06/2020 13:58, Thomas Wouters wrote: I wasn't speaking for the PSF or the Steering Council, I'm afraid as politicians around the world discover on a daily basis, it doesn't work that way. Particularly on political matters such as this, you do speak as a Steering Council member and PSF board member unless you very explicitly say otherwise, and even then your comments will reflect on both organisations. This is the sort of behaviour that gets local politicians suspended from their parties. nor was my intent to "silence or force out people guilty of thought-crime and holding the wrong opinion". Perhaps you should re-read what you wrote. "Unfriendly" is an extremely polite term for the tone of it, and I for one felt threatened. [Steven D'Aprano said:] I think that Thomas' post violated the CoC: Please report all CoC violations to the CoC WG. Good point. Duly done. -- Rhodri James *-* Kynesim Ltd ___ 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/P77K5QFSYLZU3ROHJP354JQZCGGH3KEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.
On 30/06/2020 13:43, Emily Bowman wrote: I completely agree with this, that UTF-8 has become the One True Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside of the Win32 API. Nearly all basic emoji can't be represented in UCS-2 wchar_t, let alone composite emoji. You say that as if it's a bad thing :-) So how to make that C-compatible? Make everything a void* and it just comes back with as many bytes as it gets? I'd be inclined to something like that. You really don't want people trying to roll their own UTF-8 handling if you can help it. That does imply the C API will need to be pretty comprehensive, though. (If you want nightmares, take a look at the parsing code in Expat. Multiple layers of macros and function tables make it a horror to comprehend.) -- Rhodri James *-* Kynesim Ltd ___ 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/7HPGNVZ46ROP3HMRUJXJXX2WI4LI4JAL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.
On 30/06/2020 13:16, Richard Damon wrote: On 6/30/20 7:53 AM, M.-A. Lemburg wrote: Since the C world has adopted wchar_t for this purpose, it's the natural choice. I would disagree with this comment. Microsoft Windows has chosen to use 'wchar_t' for Unicode, because they adopted UCS-2 before it morphed into UTF-16 due to the expansion of Unicode above 16 bits. The *nix side of the world has chosen to use UTF-8 as the preferred way to store Unicode characters. Also, in Windows, wchar_t doesn't really meet the requirements for what C defines wchar_t to mean, as wchar_t is supposed to represent every character as a single unit, and thus would need to be at least a 21 bit type (typically, it would be a 32 bit type), but Windows makes it a 16 bit type due to ABIs being locked before the Unicode expansion. Seconded. I've had to do cross-platform (Linux and Windows)* unicode work in C. Using wchar_t was eventually rejected as infeasible. * Sorry, I had a Blues Brothers moment. -- Rhodri James *-* Kynesim Ltd ___ 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/Y5SZNQYUULRY75CVHV34CSQTUI2FBUZ6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 30/06/2020 10:52, Thomas Wouters wrote: I don't have words for the irony of complaining about changing words while objecting to the wording in a commit message. Especially considering the commit message isn't nearly as visible as the places that people have actually been fixing things like master/slave. I'm sorry, I was a little deafened by the irony that it's only wrong to complain about changes you agree with. The commit was over-hasty, but that's not a crime. It improves matters for those who find the idea of writing formal English daunting, but at the expense of those who find the idea of filling a blank box with words terrifying. A little more thought could have catered for both, but it's not the end of the world. With a sufficient supply of round tuits I can always submit a PR myself. The commit message is a political message that flatly does not belong in the repository. Do you see the difference? I really wish you hadn't brought up the master/slave debacle again. I may feel obliged to submit PRs to restore the accepted usage because, and I can't believe I have to keep saying this, *creating taboos only ever makes things worse.* -- Rhodri James *-* Kynesim Ltd ___ 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/H3NRQMSKAMC7HO4WZB4WF7VYO7CLJ54I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 29/06/2020 21:40, Antoine Pitrou wrote: IMHO, the fact that the "Strunk & White standard" is not known by everybody (it's certainly not by me) was enough of a reason to remove that wording and replace it with a clearer phrasing. Or perhaps to amplify on why something like S is a good guide (and not a standard) in how to write formal English? If you aren't interested in the nuts and bolts of the English language there's no reason for you to know of Strunk and White, the Chicago Manual of Style or any of a number of other similar books on the subject. They are all useful to someone who intends to write much, though. -- Rhodri James *-* Kynesim Ltd ___ 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/ZW67TJBA4Q6OQWTY6CO7JVRNQZRAD2WF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 29/06/2020 17:24, Abdur-Rahmaan Janhangeer wrote: Threads like these are meaningless, does not provide any learning value and is nowhere near the single vs double quote thread. I'm afraid I couldn't disagree more. Since the PSF has seen fit to make a political statement (re Black Lives Matter, and I don't particularly disagree with either the statement or the choice of making it), threads like these are both inevitable and necessary. When such statements are made, it is generally a good idea to be reasonably sure that the community one is representing is broadly OK with that statement. (I speak in vague terms because you will never get 100% agreement from anyone on anything!) The commit message that sparked this all was, quite unnecessarily, a political statement. The threads have demonstrated that it is not even vaguely universally accepted, so it being in the PEPs repository (not just a PR, it's there, public, and effectively representing you and me) is a problem. That it's still there now is pretty unacceptable in my book. -- Rhodri James *-* Kynesim Ltd ___ 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/HP2NJGITNURNCP4XOSUO7Y65IUUIX6KM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 29/06/2020 15:02, Paul Sokolovsky wrote: Hello, On Mon, 29 Jun 2020 06:21:36 -0700 Nathaniel Smith wrote: You all are displaying breathtakingly levels of ignorance here. [snippety snip] I'm not going to try to educate you Dude, you totally aren't going to. So please leave your supremacist, center-of-the-world patronizing tone behind. Thank you. OK guys, enough. Paul, you were trying to be good here, but your previous comment was flamebait. Nathaniel, that was exceptionally patronising, and I do somewhat take offense. Both of you know better, now please behave like it. (Yes, I'm allowed to get offended. I'm half Welsh, growing up on the English side of the border with an obviously Welsh name. I know all about language and racism, thank you very much.) -- Rhodri James *-* Kynesim Ltd ___ 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/TVIT5NAKA4LB5FIYKCKVHMK566GRLAEA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 27/06/2020 10:36, Stephen J. Turnbull wrote: Richard Damon writes: > As long as the bindings in match also make the symbol a local > (which seems reasonable) then you would get a similar restriction. It's quite different. First, it surely won't make other symbols match-local. Of course there will be times when you do all the work inside the match statement. But often you'll want to do bindings in a match statement, then use those outside. The second problem is that this use of '_' isn't optional. It's part of the syntax. That means that you can't use the traditional marking of a translateable string (and it's not just tradition; there is a lot of external software that expects it) in that scope. So it's practically important, if not theoretically necessary, that 'case _' not bind '_'. That's the clearest explanation of why "_" needs to be treated carefully, but I don't think it argues for the PEP's special treatment. Those people like me who just write for ourselves and don't care about internationalisation use "_" like any other variable with a strong implication that it's a dummy, so don't really care. Those people like you who care about internationalisation presumably avoid using "_" anyway, so the PEP's usage goes against your current instincts. -- Rhodri James *-* Kynesim Ltd ___ 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/RXUG2UJCSINOMBHSWWIPIUAGLVRTEMNH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 29/06/2020 11:31, Steve Holden wrote: If I am being oversensitive it is perhaps because I have trodden in these waters before, and have frequently been surprised by what other people find distasteful or offensive. I do not necessarily require my opinions to be thought reasonable, even by other reasonable people. I don't think you are being insensitive, I too found that commit message offensive. Personally I think equating standardised English -- specifically Strunk and White -- with racist supremacy is itself a racist remark which should not have been made. -- Rhodri James *-* Kynesim Ltd ___ 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/PHOEKSHGZPUNVEHY5PNQCH4KBZJN23ID/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 28/06/2020 21:47, Daniel Moisset wrote: I've been going over the PEP this weekend, trying to get a deeper understanding of what are its main ideas and consequences, and wrote some notes. I'm not posting the notes directly to this list because it's a bit of a long read, but I also tried to make it helpful as an analysis for people involved in the discussion. So here's a link: https://github.com/dmoisset/notebook/blob/811side of thingsbf66/python/pep622/understanding-pep-622.md <https://github.com/dmoisset/notebook/blob/811bf66/python/pep622/understanding-pep-622.md> . I may update this in master, but for clarity I'm permalinking the current version. I'll soon switch to "proposing solutions" mode (rather than "analysis mode" as this text is) soon, but needed to do this first, and hopefully this helps someone else in this list organise ideas. Thank you for that, Daniel. That's a very nice analysis that makes my own misgivings clearer and put some of them to rest. I think you are right that generalised destructuring is probably the thing to concentrate on; once we have something cohesive there, pattern syntax should become a lot more obvious. -- Rhodri James *-* Kynesim Ltd ___ 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/U5OB7BCVQZ7G7LR36DXQIFAC3G2H3RYV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 25/06/2020 23:20, Emily Bowman wrote: On my personal "potentially inscrutable uses of a tool" this still rates well below list comprehensions, so there's that; the biggest pet peeve I Clearly YMMV. To me list comprehensions like "[f(x) for x in l]" were obviously related to the "f(x) ∀ x ∊ l" familiar from my maths degree. have anymore is understanding at a glance what is and isn't an assignment. Yes, this does seem to be a lot of people's problem. My point is we get to that position one step at a time, so maybe we should be examining the first steps in that chain and re-evaluating whether they were in fact the right ones, given where we end up. I accept the PEP's general point that name patterns will be common, but I don't think something like "case int as x:" is hard to write and it brings in the idea that we are talking about types right at the start. -- Rhodri James *-* Kynesim Ltd ___ 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/UV6P5TV4WAQHTB47WJBLCPV4JDZO24AR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 25/06/2020 16:48, Tim Peters wrote:
[Tim]
See reply to Glenn. Can you give an example of a dotted name that is
not a constant value pattern? An example of a non-dotted name that is?
If you can't do either (and I cannot)), then that's simply what "if
[Rhodri James ]
case long.chain.of.attributes:
[Tim]
That's a dotted name and so is a constant value pattern - read the PEP.
Every dotted name in a pattern is looked up using normal Python
name resolution rules, and the value is used for comparison by
equality with the matching expression (same as for literals).
[Rhodri]
Then I am surprised, which is worse. "long.chain.of.attributes" looks
like an assignment target, and I would have expected the case to have
been a name pattern.
As always, I don't care whether something is obvious at first glance.
I care whether something can be learned with reasonable effort, and
"sticks" _after_ it's learned. There's essentially nothing truly
obvious about programming.
This, from the PEP, is the entire grammar for a "name pattern'"
name_pattern: NAME !('.' | '(' | '=')
That's it. A plain name not followed by a dot, left paren, or equality sign.
While it may or may not surprise any given person at first glance,
it's very simple. Put a fraction of the effort into learning it as
you're willing to expend on articulating surprise, and it would
already be far behind you ;-)
Well, now is the time for expressing surprise :-p
As I've said before, one of my main problems with the PEP is as you go
through it, more and more special cases and surprises appear, and the
consequences of earlier surprises generate more special cases and
surprises. You claim not unreasonably that it's easy to remember that
"_" is special in matches. Maybe you're right, but that decision has
consequences spelled out later in the PEP that are less easy to
remember. Another example: I had not previously thought the definition
of name patterns to be surprising, but apparently they are (it just
surprised me, at any rate). That consequently makes the definition of
constant value patterns, which I was already iffy about, really quite
surprising.
Each individual learning curve might be small, but cumulative total by
the time you reach the end of the PEP is large. Simple match statements
will, with adequate squinting, look recognisably like other areas of
Python. Complex match statements won't. And that's a problem for
anyone who wants to be able to read someone else's code.
Bear in mind I am predominantly a C programmer who uses Python from time
to time for tools and glue. If I have to put in effort to learn new
special-case rules in Python, that's an active discouragement; I'm
frankly unlikely to bother, and more likely to write those tools and
glue in C instead. I'm certainly much less likely to use someone else's
tools and glue if I have to re-read the spec to remind myself what all
the gotchas are.
--
Rhodri James *-* Kynesim Ltd
___
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/5KCFYS3FEXQV65VJUX33IJI57OTXEMEV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 25/06/2020 15:42, Greg Ewing wrote: On 26/06/20 1:18 am, Rhodri James wrote: I will quickly and regularly forget that in this one place, "_" is special. You don't have to remember that it's special to understand what 'case _' does. Even if it were treated as an ordinary name, it would still have the effect of matching anything. Maybe. It's still ugly. -- Rhodri James *-* Kynesim Ltd ___ 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/OJQDY6VFNDZVNO6GZRGNSGX4BPQNVT4M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 25/06/2020 15:40, Tim Peters wrote: [Rhodri James ] See reply to Glenn. Can you give an example of a dotted name that is not a constant value pattern? An example of a non-dotted name that is? If you can't do either (and I cannot)), then that's simply what "if case long.chain.of.attributes: That's a dotted name and so is a constant value pattern - read the PEP. Every dotted name in a pattern is looked up using normal Python name resolution rules, and the value is used for comparison by equality with the matching expression (same as for literals). Then I am surprised, which is worse. "long.chain.of.attributes" looks like an assignment target, and I would have expected the case to have been a name pattern. -- Rhodri James *-* Kynesim Ltd ___ 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/HKW7XZTN6JAYGMM7BQBKKC7M5OH6SARG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On 25/06/2020 00:54, Tim Peters wrote: [Ethan Furman ] "case _:" is easy to miss -- I missed it several times reading through the PEP. As I said, I don't care about "shallow first impressions". I care about how a thing hangs together _after_ climbing its learning curve - which in this case is about a nanometer tall ;-) You're not seriously going to maintain that you're struggling to grasp the meaning of "case _:" now, right? I'm seriously going to maintain that I will forget the meaning of "case _:" quickly and regularly, just as I quickly and regularly forget to use "|" instead of "+" for set union. More accurately, I will quickly and regularly forget that in this one place, "_" is special. while _ does not bind to anything, but of what practical importance is that?) . One obvious way to do it is of major practical importance. Yeah, but the "obvious" is being contended, and saying "but it's obvious" doesn't really constitute an argument to those of us for whom it isn't obvious. ".NAME" grated at first, but extends the idea that dotted names are always constant value patterns to "if and only if". So it has mnemonic value. How do you get from "." to "iff" ? See reply to Glenn. Can you give an example of a dotted name that is not a constant value pattern? An example of a non-dotted name that is? If you can't do either (and I cannot)), then that's simply what "if case long.chain.of.attributes: or more likely case (foo.x, foo.y) for the first. For the second, it's a no-brainer that you can't have a non-dotted name as a constant value pattern, since the current constant value pattern mandates a leading dot. -- Rhodri James *-* Kynesim Ltd ___ 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/AW53OVSLMPMFH4PSMDU35SQTCUAVVT2O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup
On 25/06/2020 10:15, Chris Angelico wrote: On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou wrote: On Wed, 24 Jun 2020 12:38:52 -0700 Guido van Rossum wrote: Everyone, If you've commented and you're worried you haven't been heard, please add your issue *concisely* to this new thread. Note that the following issues are already open and will be responded to separately; please don't bother commenting on these until we've done so: - Alternative spellings for '|' - Whether to add an 'else' clause (and how to indent it) - A different token for wildcards instead of '_' - What to do about the footgun of 'case foo' vs. 'case .foo' (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a variable binding and '?' for a wildcard.) I don't know if you read it, so I'll reiterate what I said :-) """ Overall, my main concern with this PEP is that the matching semantics and pragmatics are different from everything else in the language. When reading and understanding a match clause, there's a cognitive overhead because suddently `Point(x, 0)` means something entirely different (it doesn't call Point.__new__, it doesn't lookup `x` in the locals or globals...). Obviously, there are cases where this is worthwhile, but still. AIUI, the case clauses are far more akin to *assignment targets* than they are to expressions. If you see something like this: [x, y] = foo() then you don't expect it to look up x or y in the current scope, nor to construct a list. That argument works for name patterns, but not for class patterns. "Cls(x,y)" does not look like an assignment target at all. -- Rhodri James *-* Kynesim Ltd ___ 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/XRKDUCQXHKHV3L4XJPF23BPHKGDBMBAI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
will dissuade people from using it thoughtlessly. Sequence and mapping patterns are a bit more than just syntactic sugar for class patterns for list, tuple, and dict. I wouldn't change them, given other changes to the definition of "pattern" here. To me, this is just easier to wrap my head around. Patterns are either expressions, classes or sequence/mapping combinations of patterns. There's no awkwardness about when is a name a value and when is it something to be bound, there's no proliferation of special cases, and it is pretty readable I think. It could be argued to be verbose, but terseness is not one of Python's objectives, and I think the consistency is worth it. -- Rhodri James *-* Kynesim Ltd ___ 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/2QRE6TGF34TSAIBLR5NW6T2C4N4MBXYM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On 15/05/2020 16:56, Chris Angelico wrote: On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou wrote: On Fri, 15 May 2020 10:46:25 -0400 David Mertz wrote: 1. +1 itertools.zip_strict function 2. +1 zip.strict(*args) 3. +1 zip(*args, mode='strict') # mode='shortest' by default 4. +0 zip(*args, strict=True) Mostly I agree with Steven on relative preference: itertools.zip_strict() +1 zip.strict() +0.5 zip(mode='strict') +0 zip(strict=True) -0.5 For me: * zip(strict=True) +1 * zip(mode='strict') -0 * itertools.zip_strict() -0.5 * zip.strict() -1 (but really, I'd like to make this -1e10) Since we're posting: itertools.zip_strict() +1 zip.strict() +0.1 zip(strict=True) -0.5 zip(mode='strict') -1 Well, if it's what all the cool kids are doing... * itertools.zip_strict() +1 * zip.strict() +0 * zip(mode='strict') -0 * zip(strict=True) -1 The middle two would be weird if zip_longest doesn't get folded in eventually, which might push them (more) negative. -- Rhodri James *-* Kynesim Ltd ___ 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/VMJUFQMW2IGR5B73MKRJDPLSR72YROXB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On 10/05/2020 17:04, Brandt Bucher wrote: I have pushed a second draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any new feedback that hasn't yet been addressed in the PEP! I still don't buy your dismissal of the new function alternative. In particular: It seems that a great deal of the motivation driving this alternative is that zip_longest already exists in itertools. However, zip_longest is really another beast entirely: it takes on the responsibility of filling in missing values, a problem neither of the other variants even have. But zip_equals() is also another beast entirely; it takes on the responsibility of raising an exception, a problem neither of the other variants even have. -- Rhodri James *-* Kynesim Ltd ___ 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/DQDD3WGYNVUKVMANZ6QO6SQBQ7Z44PYJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Modify the C API to hide implementation details
On 13/04/2020 11:17, Steve Dower wrote: On 11Apr2020 1156, Rhodri James wrote: On 10/04/2020 18:20, Victor Stinner wrote: Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C extensions which cannot be rewritten with Cython. If this is true, the documentation on python.org needs a serious rewrite. I am in the throes of writing a C extension, and using Cython or cffi never even crossed my mind. Sorry you missed the first two sections: "Recommended third party tools" and "Creating extensions without third party tools". https://docs.python.org/3/extending/index.html "Creating extensions without third party tools" is what I read, because the preceding sections suggested to me that was what I was supposed to do. The opening paragraph of the document more or less reads as "This is how you write C extensions." It's an intro. That's fair enough. The next section, "Recommended third party tools", basically says "Third party tools exist." It notably does not say "Use them in preference to what follows," so I didn't even look at them. There is in fact a mild statement at the end of the first paragraph of the next section that should have clued me in, but I missed it because I'd already skipped to the table of contents. If you have any suggestions on how to make this recommendation more obvious, please open an issue and describe what would have helped. I'll give it some thought, but fundamentally if you want people to use the third party tools, you need a much stronger statement to that effect. I'm sure I'm not the only one whose reaction to "third party" is "not official then". -- Rhodri James *-* Kynesim Ltd ___ 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/4NDJSPJC7FKY7QGHLE3PVK4FGPMBW3EV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Modify the C API to hide implementation details
On 10/04/2020 18:20, Victor Stinner wrote: Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C extensions which cannot be rewritten with Cython. If this is true, the documentation on python.org needs a serious rewrite. I am in the throes of writing a C extension, and using Cython or cffi never even crossed my mind. -- Rhodri James *-* Kynesim Ltd ___ 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/NEYKZMQ6ZWB5VGS22SZTVQPVOJETDKUQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Problem with instantiating a C extension class from another class
On 06/04/2020 20:41, Musbur wrote: Hi Nick, thanks for forwarding the post. BTW, I've posted a complete, self-contained example on stackoverflow (which also received zero attention so far): After that comment I'm not particularly inclined to solve your problem for you, so I'll just say that you should compare your module init function to the example one in the Embedding and Extending docs. -- Rhodri James *-* Kynesim Ltd ___ 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/WZAOA3AAJFAMRAPTFGYL5LQZC5IYT4DI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Debug C++
On 30/03/2020 23:20, Leandro Müller wrote: Hi Are there any away to debug C module during python debug? In a word, gdb. I've been doing this quite a lot lately. The trick is to start Python up under gdb, set a pending breakpoint in your C module, then carry on as normal. For example: rhodri@Wildebeest:~/hub_module$ gdb python3 GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git Copyright (C) 2018 Free Software Foundation, Inc. [...large amounts of boilerplate omitted for brevity...] Reading symbols from python3...Reading symbols from /usr/lib/debug/.build-id/28/7763e881de67a59b31b452dd0161047f7c0135.debug...done. done. (gdb) b Hub_new Function "Hub_new" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (Hub_init) pending. (gdb) run Starting program: /home/rhodri/Work/Lego/hub_module/hat_env/bin/python3 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Python 3.6.9 (default, Nov 7 2019, 10:44:02) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from hub import hub Breakpoint 1, Hub_new (type=0x76236340 , args=(), kwds=0x0) at src/hubmodule.c:164 164 HubObject *self = (HubObject *)type->tp_alloc(type, 0); (gdb) ...and off you go! -- Rhodri James *-* Kynesim Ltd ___ 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/4JVUDRD5YZVVZ4FWC3BYN3RJDXBNBTIF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 23/03/2020 14:50, Dan Stromberg wrote:
On Fri, Mar 20, 2020 at 3:28 PM Victor Stinner wrote:
The builtin ``str`` class will gain two new methods with roughly the
following behavior::
def cutprefix(self: str, pre: str, /) -> str:
if self.startswith(pre):
return self[len(pre):]
return self[:]
I tend to be mistrustful of code that tries to guess the best thing to do,
when something expected isn't found.
How about:
def cutprefix(self: str, pre: str, raise_on_no_match: bool=False, /) -> str:
if self.startswith(pre):
return self[len(pre):]
if raise_on_no_match:
raise ValueError('prefix not found')
return self[:]
I'm firmly of the opinion that the functions should either raise or not,
and should definitely not have a parameter to switch behaviours.
Probably it should do nothing; if the programmer needs to know that the
prefix wasn't there, cutprefix() probably wasn't the right thing to use
anyway.
--
Rhodri James *-* Kynesim Ltd
___
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/SA5RZNAJESODSMNGBX7OD2F77YMHWH5Z/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
On 05/02/2020 12:27, Musbur wrote: I have one suggestion: Wouldn't it be useful for these operators to also accept sets (functionally acting like a dict with None for all values)? This would make it very elegant to 'normalize' dicts by pruning (dict & set) or padding (set | dict) dictionaries. I would find this useful for efficient data sanitation purposes, as when processing input from web forms. Why None? Why not 0, or False, or 42? This sort of thing belongs more in a function or method, IMHO. On the original PEP, I'm resigned to it being the union operator and +1 on the whole thing. Good work, guys! -- Rhodri James *-* Kynesim Ltd ___ 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/WUOEEIO3TDP6TOT2UWYEXVVQBEZ7XN2G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On 03/02/2020 22:06, Mike Miller wrote: On 2020-02-03 01:50, Petr Viktorin wrote: When the changes are rolled out gradually across minor releases, those that cause unforeseen trouble in real-world code can be identified in the alphas/betas, and rethought/reverted if necessary. To be clear, my suggestion was to maintain gradual deprecations and warnings, but have a single removal event at the start of a new version major number. So there will be many years of betas and releases to haggle over. I think that just enables laziness. "We don't need to worry about the deprecations, nothing is going to happen for years yet," is more or less what happened with the Python2 to Python3 shift. People naturally enjoy adding shiny new features to their projects over maintenance. As a refinement to the idea above, perhaps a sub rule could be added: - No deprecations should appear in a X.9 release to give folks time to prepare. That feels like a very bad idea indeed. If you don't tell people things are going away, they definitely won't prepare for that. -- Rhodri James *-* Kynesim Ltd ___ 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/43S4KEWSIYTZ7HBZ6KBYEMFZG6KUQOBD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python library for the ServiceNow REST API
On 28/01/2020 10:47, IT Canvass wrote: It should be compatible with modern versions of ServiceNow. If there's API breakage or new features implemented, I usually have that fixed/incorporated into pysnow in a week or two. Hi there, python-dev is the mailing list for development of core Python and the Standard Library. The ServiceNow package is provided on PyPI rather than being part of the standard library. You will probably be better off addressing your request to the project's GitHub page: https://github.com/locaweb.python-servicenow. -- Rhodri James *-* Kynesim Ltd ___ 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/7OMO4HM6KTY54VVF4HXYDMGZG5FUTTW5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 611: The one million limit.
On 11/12/2019 21:35, Antoine Pitrou wrote: In any case, this will have to be judged on benchmark numbers, once Mark (or someone else) massages the interpreter to experiment with those runtime memory footprint reductions. This I absolutely agree with. Without evidence we're just waving our prejudices and varied experiences at one another (for example, my experience that the "modern processors" you were talking about have massive caches, so memory access isn't as much of an issue as you might think vs your experience that memory access matters more than doing a shift-and-mask all the time). I've seen no hard evidence of any actual improvement of any size, and without that there really isn't a decision to be made. -- Rhodri James *-* Kynesim Ltd ___ 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/N4UNHOHCQHCOIUEFQKFJMKTKIAEHTM52/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: More feedback on PEP 611, please
On 11/12/2019 11:12, Mark Shannon wrote: P.S. On the subject of tradeoffs, here's a bonus question: What, in your opinion, increase in memory consumption is acceptable for a 1% improvement in speed, or vice versa? Depends on the phase of the moon, the hardware I'm trying to run on, and the problem I'm trying to solve. In some cases, 1% increase in speed might be a godsend I'd sacrifice my non-existent first-born for. In others, no increase in memory consumption might be acceptable. -- Rhodri James *-* Kynesim Ltd ___ 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/YIPF7EH4VRICEO5PBOL2WE7U4LR6LARR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please be more precise when commenting on PEP 611.
On 10/12/2019 00:01, Chris Angelico wrote: Exactly. Yes, I know that I massively oversimplified things in that post. But you nonetheless acknowledge here that we are*still* quite lacking in any actual evidence. We have people who believe that a bit mask will slow things down, others who claim that improved cache locality will speed things up, and Mark asks us to please justify our objections with numbers. But surely it's up to Mark to show numbers first? +1 -- Rhodri James *-* Kynesim Ltd ___ 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/Y2SKFQBYZRWWLRWD35M6NKSFQWDMECZP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please be more precise when commenting on PEP 611.
On 09/12/2019 14:05, Mark Shannon wrote: I would like to ask a favour; please be more specific in your comments. Ideally state which part of the PEP you are disagreeing with and why you disagree with the relevant part of the rationale/motivation. This is rather hard to do when I don't think you have made the case for limits yet. Certainly not convincingly. Without that argument, all I can really do is say that I think you're wrong. -- Rhodri James *-* Kynesim Ltd ___ 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/XTN4GMCV4PIOEPCFFUPJDP25RYHA4SIX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 611: The one million limit.
Apologies again for commenting in the wrong place. On 05/12/2019 16:38, Mark Shannon wrote: Memory access is usually a limiting factor in the performance of modern CPUs. Better packing of data structures enhances locality and> reduces memory bandwith, at a modest increase in ALU usage (for shifting and masking). I don't think this assertion holds much water: 1. Caching make memory access much less of a limit than you would expect. 2. Non-aligned memory access vary from inefficient to impossible depending on the processor. 3. Shifting and masking isn't free, and again on some processors can be very expensive. Mark wrote: >>> here is also the potential for a more efficient instruction format, >>> speeding up interpreter dispatch. I replied: >> This is the ARM/IBM mistake all over again. Mark challenged: > Could you elaborate? Please bear in mind that this is software > dispatching and decoding, not hardware. Hardware generally has a better excuse for instruction formats, because for example you know that an ARM only has sixteen registers, so you only need four bits for any register operand in an instruction. Except that when they realised that they needed the extra address bits in the PC after all, they had to invent a seventeenth register to hold the status bits, and had to pretend it was a co-processor to get opcodes to access it. Decades later, status manipulation on modern ARMs is, in consequence, neither efficient nor pretty. You've talked some about not making the 640k mistake (and all the others we could and have pointed to) and that one million is a ridiculous limit. You don't seem to have taken on board that when those limits were set, they *were* ridiculous. I remember when we couldn't source 20Mb hard discs any more, and were worried that 40Mb was far too much... to share between twelve computers. More recently were the serious discussions of how to manage transferring terabyte-sized datasets (by van, it turned out). Sizes in computing projects have a habit of going up by orders of magnitude. Text files were just a few kilobytes, so why worry about only using sixteen bit sizes? Then flabby word processors turned that into megabytes, audio put another order of magnitude or two on that, video is up in the multiple gigabytes, and the amount of data involved in the Human Genome Project is utterly ludicrous. Have we hit the limit with Big Data? I'm not brave enough to say that, and when you start looking at the numbers involved, one million anythings doesn't look so ridiculous at all. -- Rhodri James *-* Kynesim Ltd ___ 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/I5KOXNVB3RCDP3D3CYKUBWCAWGZLWLOF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Macros instead of inline functions?
On 04/12/2019 18:22, Serhiy Storchaka wrote:
In these files (symtable.c, compile.c, ast_opt.c, etc) there are
sequences of calls for child nodes. Every call can return an error, so
you need to check every call and return an error immediately after the
call. With inline functions you would need to write
if (!VISIT(...)) {
return 0;
}
if (!VISIT(...)) {
return 0;
}
if (!VISIT(...)) {
return 0;
}
instead of just
VISIT(...);
VISIT(...);
VISIT(...);
Can I just say as a C programmer by trade that I hate this style of
macro with the burning passion of a thousand fiery suns? Code like the
second example is harder to comprehend because you can't simply see that
it can change your flow of control. It comes as a surprise that if
something went wrong in the first VISIT(), the remaining VISIT()s don't
get called.
It's not so bad in the case you've demonstrated of bombing out on
errors, but I've seen the idiom used much less coherently in real-world
applications to produce code that is effectively unreadable. It took me
a long time to wrap my brain around what the low-level parsing code in
Expat was doing, for example. I strongly recommend not starting down
that path.
--
Rhodri James *-* Kynesim Ltd
___
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/IRNQHQUE7PX5RM63IHXGFOODBOFCZGAI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.
resources. The proposed one million limit is a limit on human generated code. While it is possible that generated code could exceed the limit, it is easy for a code generator to modify its output to conform. The author has hit the 64K limit in the JVM on at least two occasions when generating Java code. The workarounds were relatively straightforward and probably wouldn't have been necessary with a limit of one million bytecodes or lines of code. I can absolutely guarantee that this will come back and bite you. Someone out there will be doing something more complicated than you think is plausible, and eventually someone will hit your limits. It may not take as long as you think, either. -- Rhodri James *-* Kynesim Ltd ___ 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/6BJVZ6KA3OSDP5ID2RFZM3KRGLZS6VAD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Deprecating the "u" string literal prefix
On 03/12/2019 17:16, Serhiy Storchaka wrote: The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features kept for compatibility with 2.7. When we are going to deprecate and remove the "u" prefix? [1] https://www.python.org/dev/peps/pep-0414/ You are presupposing that the answer to the question "Are we going to deprecate and remove the "u" prefix" is "Yes". I'm not convinced it is. -- Rhodri James *-* Kynesim Ltd ___ 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/YOCNBXZ7K3VN4UBF7ASBKPWB32QAG63L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The Python 2 death march
On 09/09/2019 15:51, brian.sk...@gmail.com wrote: it's getting better? No it's not, it'll be stone dead in a moment. -- Rhodri James *-* Kynesim Ltd ___ 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/AUMYGJ444W53RFXK5LGUX46UGDBC4RCB/
