On Tue, 22 Jun 2021 at 10:06, Petr Viktorin wrote:
> On 21. 06. 21 20:20, Guido van Rossum wrote:
> > Okay, I think your evidence can then be discounted. Really, any app that
> > relies on the publicly installed Python runs a serious risk of breaking
> > when that Python gets updated, regardless
On Mon, 10 May 2021 at 08:34, M.-A. Lemburg wrote:
> [...]
PS: It looks like the discussion has wondered off to Discourse
> now. Should we continue there ?
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
Pablo seems to want to redirect the discussion there yes, in particular to:
On Wed, 24 Feb 2021 at 10:18, Antoine Pitrou wrote:
> On Tue, 23 Feb 2021 20:29:52 -0500
> Jonathan Goble wrote:
> >
> > I can't speak for distributors or maintainers [1], but I can speak for
> > myself as a user. I run Debian testing (currently bullseye as that is
> > preparing for release) as
On Sat, 21 Nov 2020 at 19:58, Glenn Linderman wrote:
> Don't () already indicate an expression to be evaluated?
>
Does it?
[(a, b)] = [(0, 1)]
print(a)
gives 0 as output.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
>
> That would work, but would be slower for the reference implementation
> due to the repeated `isinstance(value, int)` checks.
>
If you wanted to avoid that you could use match/case inside the "case
int()" instead, i.e.:
case int():
match value:
case _ if value < 8:
// do
int():
raise OverflowError(value)
Which I think works as expected under the current PEP622?
On Mon, 17 Aug 2020 at 14:16, Mark Shannon wrote:
>
>
> On 17/08/2020 1:13 pm, Henk-Jaap Wagenaar wrote:
> > On Mon, 17 Aug 2020 at 11:30, Mark Shannon > <mailto:m..
On Mon, 17 Aug 2020 at 11:30, Mark Shannon wrote:
>
> I would also bring you attention to my rigorous analysis of the possible
> application to PEP 622 the entirety of CPython.
> If I have made any mistakes there, I'd be happy to correct them.
>
>
You say "I've elided a lot of complex logic int
On Mon, 13 Jul 2020 at 09:30, Federico Salerno wrote:
> On 13/07/2020 00:20, Guido van Rossum wrote:
>
> The need for a wildcard pattern has already been explained -- we really
> want to disallow `Point(x, y, y)` but we really need to allow `Point(z, _,
> _)`. Generating code to assign the value
On Wed, 8 Jul 2020 at 21:44, Guido van Rossum wrote:
> It works for me. Did you click on the box where the logs are supposed to
> appear? It will only show the logs when you click there.
>
>
I did click on that before, but I suddenly had a thought (I should have had
long ago): it seems my
On Wed, 1 Jul 2020 at 17:09, Guido van Rossum wrote:
> If you are interested in learning more about how PEP 622 would work in
> practice, but don't feel like compiling a Python 3.10 fork from source,
> here's good news for you.
>
> In a hurry?
>
On Wed, 8 Jul 2020 at 14:30, Paul Svensson wrote:
> On Wed, 8 Jul 2020, Rhodri James wrote:
>
> > 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
On Tue, 7 Jul 2020 at 17:09, Paul Moore wrote:
> On Tue, 7 Jul 2020 at 15:40, Henk-Jaap Wagenaar
> wrote:
> >
> > On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
> python-dev@python.org> wrote:
> >>
> >> I don't like the .name syntax
On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> I don't like the .name syntax (grit on Tim's monitor; does not
> suggest the meaning). [...] But I don't know what syntax (where necessary)
> to suggest.
+1(000)
> I'm not keen on special
On Fri, 3 Jul 2020 at 14:28, Chris Angelico wrote:
> On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev
> wrote:
> >
> >
> > On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:
> >
> > On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev wrote:
> >>
> &
On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev wrote:
> So what?
>
Unnecessary
> They'll have to synchronise their history to ours to be able to make a PR.
> And if they don't, it doesn't matter for us what they do with the data
> anyway since they are responsible for maintaining it and keeping it
>
On Fri, 3 Jul 2020 at 08:50, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
>
> Per
> https://mail.python.org/archives/list/python-dev@python.org/message/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/,
> we're talking about an infinitely
> less impactful peps repo (per
>
On Thu, 2 Jul 2020 at 20:33, Chris Angelico wrote:
> On Fri, Jul 3, 2020 at 5:17 AM Ivan Pozdeev via Python-Dev
> wrote:
> >
> > If you are talking about rewriting the PEP8 commit, it has proven to
> cause so much damage that this is warranted despite the inconveniences IMO.
> >
>
> I think I
On Thu, 2 Jul 2020 at 16:16, Éric Araujo wrote:
> Le 2020-07-02 à 09 h 52, Paul Moore a écrit :
> > 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
On Thu, 2 Jul 2020 at 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
On Tue, 30 Jun 2020 at 11:49, Ethan Furman wrote:
> - it has been modernized as times have changed (the 2000 edition removed
> the advice
>to use masculine pronouns whenever possible, and warns that some will
> find unnecessary
>masculine usage offensive)
>
PEP-8 however does not
I agree with you it is over the top, but let's enjoy the popcorn together!
On Wed, 1 Jul 2020 at 01:35, Greg Ewing wrote:
> Sorry for fanning the flames, but this whole thread is so over
> the top I'm finding it kind of entertaining.
>
> On 1/07/20 2:23 am, Piper Thunstrom wrote:
> > The
To paraphrase the Bible: "For where two or three gather, there is politics
with them."
Changing the commit message, as it has been merged, is now practically hard
and highly unusual. If you use GitHub search, you can find other examples
of commit messages that would be rewritten if that was
I used the same convention as you, and my vote was thus as the record will
show (note the negatives):
zip(strict=True) +1
itertools.zip_strict() +0
zip(mode='strict') -1
zip.strict() -1
And I stand by that: I think Python would be better off without the 3rd and
4th option, even if no alternative
On Fri, 15 May 2020 at 21:50, Eric V. Smith wrote:
> I fear that my comment on some text in the PEP was lost amidst the
> voting, so I'm repeating it here. This will probably screw up some
> threading, but this is the oldest message I have to reply to.
>
> The PEP says "At most one additional
I'll join in with the fun...
zip(strict=True) +1
itertools.zip_strict() +0
zip(mode='strict') -1
zip.strict() -1
On Fri, 15 May 2020 at 19:12, Paul Moore wrote:
> [Cut the previous votes because someone's quoting didn't survive my
> email client and I can't be bothered fixing it]
>
> If
The following deferred PEP seems to have become obsolete due to time/Python
marching on:
PEP 349 - Allow str() to return unicode strings
https://www.python.org/dev/peps/pep-0349/
As there is now not non-unicode strings anymore (unless I am
misunderstanding the PEP).
What should the state of
We seem to be, once again, rehashing about this. For example, I proposed
this in 2017, which was not the first time:
https://mail.python.org/archives/list/python-id...@python.org/thread/GFZFJAI4WGFYFFVQTF7DORHMY7F45XZZ/
(Gary's suggestion, and (counter) counter points to it are in the linked
On Tue, 3 Mar 2020 at 07:27, Serhiy Storchaka wrote:
> 03.03.20 01:03, Skip Montanaro пише:
> >> Atm we don't have an index of ideas, apart from pep 3099, and I'm not
> sure we can make one (can we?), so I do not see a way to prevent this from
> happening.
> >
> > Maybe an informational PEP
28 matches
Mail list logo
