[Python-Dev] Re: [RELEASE] Expedited release of Python3.11.0b3!!
Le 01/06/2022 à 19:11, Miro Hrončok a écrit : On 01. 06. 22 17:47, Pablo Galindo Salgado wrote: Hi everyone, Due to a known incompatibility with pytest and the previous beta release (Python 3.11.0b2) and after some deliberation, me and the rest of the release team have decided to do an expedited release of Python 3.11.0b3 so the community can continue testing their packages with pytest and therefore testing the betas as expected. Thank you for doing this. I know it meant a lot of extra work for you and the release team. I could stand behind this. ___ 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/WTRQ6DCBMCPH6THHN3H72KEH7NW57VQZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available
Le 01/06/2022 à 00:02, Pablo Galindo Salgado a écrit : You may be able to work around this issue by preventing pytest to rewrite the assert statements by adding `--assert=plain` to the command line invocation until we have beta 3 next month. Thank you! That did the trick. Worth mentioning in those release announcements that are editable, perhaps. Best, Jean ___ 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/ZRLDVI4XWUUBOUMQG65F7MTHUY4GDYQA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available
Hi, Le 31/05/2022 à 15:31, Pablo Galindo Salgado a écrit : We **strongly encourage** maintainers of third-party Python projects to **test with 3.11** during the beta phase and report issues found to [the Python bug tracker](https://github.com/python/cpython/issues) as soon as possible. I just tried doing that on the project I help maintaining (Pygments), but it turns out that it's a bit hard, presumably for many projects too, due to https://github.com/pytest-dev/pytest/issues/10008 which prevents pytest from running with 3.11.0b2. The fix for this issue is on the way (thanks!), but it has missed this release. Given pytest's popularity, this means 3.11.0b2 is sadly likely not to get as much testing exposure as wished ... Thus I wonder, would it be reasonable to exceptionally do another release shortly after this fix lands? Best, Jean PS: I tried to post this reply in Discourse, but apparently I'm not allowed to post in the category of the release announcement. ___ 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/HLJULN55TWU2DYNL6R7RO22IQV37JTZW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is it possible to view tokenizer output?
Le 30/05/2022 à 00:59, Jack a écrit : Hi, I'm just getting into the CPython codebase just for fun, and I've just started messing around with the tokenizer and the grammar. I was wondering, is there a way to just print out the results of the tokenizer (as in just the stream of tokens it generates) in a human readable format? It would be really helpful for debugging. Hope the question's not too basic. python -m tokenize file.py ? See https://docs.python.org/3/library/tokenize.html#command-line-usage Cheers, Jean ___ 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/AKIHN3EVNBRJCOLR4ABXV7OADYKXKKUU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: GSOC
Hi, Le 19/04/2022 à 01:56, faresbaso...@gmail.com a écrit : i want to contribute in mailman which is a sub-org under python software Where do you see this? I can't find it under github.com/python. The repository seems to be living here: https://gitlab.com/mailman/mailman Wait, actually, I see a merge request from you there. Did you find it in the meantime? in GSOC there's 2 templates to submit i want to know which template is the correct one, the one in mailman's site or the one in python's site Whatever infrastructure Mailman may share with Python, it is an entirely separate project, so this will almost certainly be the template from the Mailman project. Best, Jean ___ 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/AREDYQMSWMDLQK77LIYUHWDVHLER6WOG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: About PEPs being discussed on Discourse
Le 07/04/2022 à 15:59, Victor Stinner a écrit : Hi, Would it be possible to announce new PEPs on python-dev please? I don't go often to Discourse, like once a month. I don't get any notification by email. I expected new PEPs to be announced on python-dev, but they are not announced here anymore. Is it possible to get Discourse notifications by email, but only for new PEPs? Using mailing lists, it's easy: just select the mailing list that you would like to subscribe to. So I went to Discourse, I click on "New Topics" and I don't see any new PEP... ... But if I go manually to the PEP category, there are 2 new PEPs proposed (PEP 678, PEP 687). In this category, if I click on the bell: it says "You will be notified if someone mentions your @name or replies to you". I can change this parameter to "You will be notified of new topics in this category but not replies to the topics." I don't recall if I changed this parameter manually, but it seems like the choice to only be notified of new topics is a new (i don't think that it existed 1 year ago). I don't recall that I opted in to not be notified of new PEPs. Now I see that Inada-san submitted the PEP 686 to the SC: https://github.com/python/steering-council/issues/118 I didn't read the discussion about this PEP which interest me. I knew that it exists because I saw related issues and pull requests about this PEP, but I didn't go to the discussion because I don't have the habit of visiting Discourse. I guess that it's my fault of not going to Discourse often enough. It's sometimes hard to keep track of everything happening around Python development. The discussions are scattered between multiple communication channels: * Issues * Pull requests * python-dev * python-committers * (private) Discord * Discourse * (public) IRC #python-dev Sometimes, I already confused by the same topic being discussed in two different Discord rooms :-) It's also common that some people discuss on the issue, and other people have a parallel discussion (about the same topic) on the related pull request. There are also Language Summit (sadly, I cannot attend it this year, for the first time) and CPython core dev sprints. Sometimes, a discussion happens on Twitter, but if it becomes serious, it moves to the above communication channels, so it's fine. I'm not going to https://python.zulipchat.com/ anymore, I guess that it has been replaced with Discord. Victor I'm only a lurker here, but find the split between this mailing list and various Discourse categories a little confusing from the outside. As far as I understand, the Discourse server was originally an experiment. Today, it has grown far past the size of an experiment though. Are there any plans to retire either Discourse or the mailing list and use a unified communication channel? This is a curiosity question. Best, Jean ___ 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/BVBF7AU7AEII35EIMTZ72BDHIR3GQLOB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python 3.9.11
> Le 15 mars 2022 à 18:43, "Prasad, PCRaghavendra" > a écrit : > > Hi Team, > > Can someone please let us know the release date of Python 3.9.11 ( with > libexpat 2.4.8 security issues fixed ) > > In the python.org releases it was mentioned as 14-march-2022, but still, I > couldn’t see the bin/source code. > > Can someone help with this > > Thanks, > Raghavendra > Have a look at https://discuss.python.org/t/py-day-is-coming-a-joint-security-release-spree-for-python-3-7-3-8-3-9-and-3-10-on-march-14th/14109/2 Best, Jean > Internal Use - Confidential > ___ > 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/5LWAYP7A4BBGPXXBAUWTSL6YQWHDX25N/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ 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/O2G6WQV3JZ7BB2J4Y5ALLIVKN53CHDGW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
Hello,
In the context of pattern matching, not accepting a match
subject that does not match any of the case clauses is
probably going to be frequent if not the most frequent.
Thus, when PEP 634, 635, 636 are -- hopefully -- accepted,
and experience with the feature is gained, this idea might
be worth reconsidering, allowing the rewrite of something like
https://github.com/gvanrossum/patma/blob/master/examples/over.py#L57-L68
```
match args:
case [Point2d(x, y)]:
return Point3d(x, y, 0)
case [p := Point3d()]:
return p
case [x := int(), y := int()]:
return Point3d(x, y, 0)
case [x := int(), y := int(), z := int()]:
return Point3d(x, y, z)
case _:
raise TypeError("Huh?")
```
into
```
match args:
case [Point2d(x, y)]:
...
case ...:
...
case ...:
...
case ...:
...
case _:
impossible
```
where `impossible` raises AssertionError.
Best regards,
Jean Abou-Samra
___
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/3D6TDUJ4V3Q6DF3UCSBUF7ETGYAG46AJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)
> (the example with changing HTTP_OK value is downright horrifying). As was just mentioned by Guido in another thread, there is a SyntaxWarning to alert you. > This leads to the idea that, if a special syntax if eventually used for Value > Patterns, using the comparison operator in it might be useful. Have a look at https://www.mail-archive.com/python-dev@python.org/msg109254.html . Unfortunately, this doesn't scale well with attribute checks... Cheers, Jean Abou Samra___ 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/FXHQ57FFHPJLAHOG7MQO2MTFWXGK4BRA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 questions
> OOI, what possibilities? I'm genuinely interested know what problems PEP 622 > would solve for you. It's somehow the same use case as Oscar Benjamin's: transform algebraic expressions (the goal being to calculate them step by step -- still under development). You have a series of rules to apply, like transforming x*1 into x, and more complicated ones. These rules can be written naturally using patterns. Also, I have the loose project of writing a new ABC to LilyPond converter (both are text-based music notation formats). This is all about manipulating different tree structures held in dataclasses, so the match statement, possibly in conjunction with algebraic types, would be useful as well. Best, Jean Abou Samra ___ 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/WYJWDEJKSGFM3OWTBM6P56R5D6GVHAS2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 questions
Hi,
Thanks for your reply!
> Le 16 août 2020 à 22:41, Guido van Rossum a écrit :
>
>> On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra wrote:
>> Hi there,
>>
>> As a poor user, I am extremely excited about the possibilities PEP 622
>> (structural pattern matching) opens. I'd like to ask a few questions.
>>
>> I hope these were not already answered in other threads, which it is hard to
>> follow given the amounts of information.
>
> Most of the threads can hardly be considered information -- at best it's
> debate, arguments and opinions. :-)
You're entirely right.
>
>> First, I'd like to know wether walrus patterns are encouraged as an
>> expressive way to explain the code in addition to comments, for example:
>>
>> match number:
>> case exact := numbers.Rational():
>> ...
>> case inexact:
>> ...
>>
>> Here we rename number depending on the case clause that was taken. Would
>> this be considered good practice? Maybe it'd be worth codifying in PEP 8 if
>> PEP 622 is accepted?
>
> I think we should wait a while to see what style develops before recommending
> specifics. Right now I'm not excited about it, mostly because the first case
> is a lot longer. Assuming the code blocks in the cases aren't very long, it
> doesn't seem hard to keep the context ("is the number exact or inexact
> here?") in mind without using the different variable names.
I recognise that my example was somehow too trivial; it would likely look more
natural when rewriting visitors, where you could end up with a lot of code in
each case clause. For instance, if I had to rewrite
https://github.com/sympy/sympy/blob/c3087c883be02ad228820ff714ad6eb9af1ad868/sympy/parsing/ast_parser.py
I may write: case num := Num(), etc.
(By the way, if you read sympy_parser.py in the same directory, it's full of
examples where pattern matching would be useful.)
I also noticed this in the PEP, under "Capture patterns":
match greeting:
case "":
print("Hello!")
case name:
print(f"Hi {name}!")
Anyway, I agree that the best way forward is to wait and see what usage
patterns develop (no pun intended).
>> A nit: how is the keywords module going to integrate soft keywords? Perhaps
>> not at all?
>
> Already taken care of -- it has a separate list `softkwlist` (currently
> empty) and corresponding function `issoftkeyword`. If any soft keywords
> appear in the grammar the code generation process will update keyword.py.
My bad, I should have checked out the dev documentation since the PEG parser is
a novelty...
>> Also, I see potential for a caveat:
>>
>> match number:
>> case int: # missing parentheses!
>> ...
>> case float:
>> ...
>> case Fraction:
>> ...
>>
>> In this case, if I understand the specification correctly, the first case
>> will always match, right? Maybe the interpreter could throw a SyntaxWarning
>> when a bare capture pattern (without a guard) is used as a pattern in any
>> case clause other than the last one? As far as I understand, this could
>> possibly prevent many of the mistakes in load/store that people have been
>> rightfully complaining about so far. It's merely a stronger measure than
>> letting static checkers do the work (since we don't all use these tools).
>
> The reference implementation in fact does issue a SyntaxWarning for this case.
Good! (Sorry, I couldn't check that as mybinder.org currently seems
unavailable... :-( ).
>> Finally, was as-based syntax considered as an alternative to walrus
>> patterns, that is, PATTERN as NAME instead of NAME := PATTERN, as we have in
>> the try statement? Given the extensive discussion, I guess it might have
>> been rejected, so it could deserve a place under "Rejected ideas" -- this
>> holds for all the above too, which I'm sorry about if it's dumb.
>
> I don't recall it was discussed. A very early draft (that wasn't published)
> used `as` instead of `case`, and that draft used `:=` for this purpose. It's
> always made sense to use that, so I've never considered `as`. Do you think
> there are situations where `as` has a clear advantage over `:=`?
Let's see: it probably avoids some uglinesses that occur with the use of = in
class patterns.
case Expr(value=(add := BinOp(op=Add(:
vs.
case Expr(value=(BinOp(op=Add()) as add))
There is also
case Line(start := Point(x, y), end):
which might be confused with
case Line(start=Point(x, y), end):
However, the main reason why I was asking i
[Python-Dev] PEP 622 questions
Hi there, As a poor user, I am extremely excited about the possibilities PEP 622 (structural pattern matching) opens. I'd like to ask a few questions. I hope these were not already answered in other threads, which it is hard to follow given the amounts of information. First, I'd like to know wether walrus patterns are encouraged as an expressive way to explain the code in addition to comments, for example: match number: case exact := numbers.Rational(): ... case inexact: ... Here we rename number depending on the case clause that was taken. Would this be considered good practice? Maybe it'd be worth codifying in PEP 8 if PEP 622 is accepted? A nit: how is the keywords module going to integrate soft keywords? Perhaps not at all? Also, I see potential for a caveat: match number: case int: # missing parentheses! ... case float: ... case Fraction: ... In this case, if I understand the specification correctly, the first case will always match, right? Maybe the interpreter could throw a SyntaxWarning when a bare capture pattern (without a guard) is used as a pattern in any case clause other than the last one? As far as I understand, this could possibly prevent many of the mistakes in load/store that people have been rightfully complaining about so far. It's merely a stronger measure than letting static checkers do the work (since we don't all use these tools). Finally, was as-based syntax considered as an alternative to walrus patterns, that is, PATTERN as NAME instead of NAME := PATTERN, as we have in the try statement? Given the extensive discussion, I guess it might have been rejected, so it could deserve a place under "Rejected ideas" -- this holds for all the above too, which I'm sorry about if it's dumb. Best regards, Jean Abou Samra ___ 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/2HDCJYULPKEDLHLMQH563VYZTG47ST3N/ Code of Conduct: http://python.org/psf/codeofconduct/
